La Respuesta Breve
El bajo rendimiento en Salesforce es un síntoma acumulativo: una página de registro con 14 componentes, tres automatizaciones que se ejecutan en el mismo evento de guardado, una consulta que escanea un millón de registros y una integración que extrae datos en horas pico. La única manera de mejorar sin malgastar el presupuesto es medir por capas, identificar la capa dominante y abordarla —y luego volver a medir.
Las Cinco Capas y Qué Medir en Cada Una
| Capa | Síntoma Típico | Herramienta de Medición | Acción Común |
|---|---|---|---|
| Navegador y Red | Lentitud solo en algunos usuarios | Aplicación Lightning Usage por usuario | Latencia organizacional, versión del navegador, VPN |
| Página y Componentes | EPT alto en una página de registro central | EPT por Página, Modo Depuración | Reducción de componentes, carga diferida, pestañas (Tabs) |
| Automatización | Guardado lento, tiempo de espera (Timeout) en actualizaciones masivas | Registros de depuración (Debug Logs), Flujos ejecutados (Flow Interviews) | Consolidación de Flows, transición a asíncrono |
| Datos y Consultas | Informes que fallan, vista de lista (List View) atascada | Plan de Consulta (Query Plan), Trabajos de Apex (Apex Jobs) | Filtrado selectivo, Índice, Archivación |
| Integración | Picos de carga en horas fijas | Monitoreo de Eventos (Event Monitoring), Uso de API (API Usage) | Bulk API, ventanas de ejecución, Throttling |
Trabajo con Grandes Volúmenes de Datos
Por encima de aproximadamente un millón de registros en un objeto (Object), las reglas del juego cambian. La asimetría de datos (Data Skew) —por ejemplo, 200 mil cuentas (Accounts) asignadas al mismo propietario (Owner) o padre (Parent)— crea bloqueos de fila y ralentiza cada actualización masiva. La solución es distribuir la propiedad, no agregar hardware, que de todos modos no está bajo su control. Al mismo tiempo, conviene considerar la archivación: los registros cerrados de hace cinco años que nadie consulta encarecen cualquier consulta que realice un escaneo.
Páginas: Menos es Más Rápido
La página de registro (Record Page) promedio en una organización de Salesforce con antigüedad acumula componentes a razón de dos o tres por año, porque cada parte interesada solicita "un widget más". Cada componente Lightning realiza sus propias llamadas. Dos acciones generan la mayor mejora: mover componentes secundarios a pestañas (Tabs) separadas que se cargan solo al hacer clic, y aplicar visibilidad de componentes (Component Visibility) según el tipo de registro (Record Type) o el rol, de modo que el usuario solo vea lo que le es relevante. La combinación de ambos reduce el EPT en decenas de puntos porcentuales sin cambios en el código.
El Orden de Acciones que Funciona
Comenzar con una semana de medición sin cambios, para establecer una línea base (Baseline) fiable para cinco páginas centrales y tres procesos clave. Luego, abordar las páginas, que es lo más económico y rápido. En la tercera etapa, consolidar las automatizaciones por objeto (Object), y solo en la cuarta etapa intervenir en las consultas y el modelo de datos. Las integraciones se abordan en paralelo, si la medición ha demostrado que son el factor causante.
La lógica de este orden es económica: las primeras capas son económicas y reversibles, las últimas son costosas y requieren pruebas de regresión. Una expansión sobre este tema aparece en Salesforce Health Check y en Señales para la Actualización del Sistema.
Riesgos Comunes y Acciones Preventivas
El mayor riesgo es la optimización sin una línea base (Baseline): se realizan diez cambios, los usuarios siguen quejándose y no hay forma de saber qué ayudó. Medir antes y después de cada cambio significativo es una condición, no un lujo.
Un segundo riesgo es abordar el síntoma más ruidoso. La página de la que más se quejan no es necesariamente la más lenta; a veces, es simplemente la que se abre más veces al día. Un tercer riesgo es modificar las automatizaciones sin cobertura de pruebas: la consolidación de Flows es la acción con mayor potencial para romper silenciosamente la lógica de negocio.
Cómo Medir el Éxito
Cuatro métricas son suficientes: EPT promedio en las cinco páginas principales, tiempo de guardado (Save) en el proceso de negocio principal, número de fallos de tiempo de espera (Timeout) y límites de gobernador (Governor Limit) por mes, y el porcentaje de consultas que tardan más de cinco segundos. Una quinta métrica —complementaria y no técnica— es el número de quejas de rendimiento en el Service Desk, que debería disminuir con la mejora efectiva.