El método completo de diagnóstico, de principio a fin

Todo lo anterior del track son herramientas. Este nivel es el procedimiento que decide cuál coger y en qué orden, que es lo que separa a quien sabe optimizar de quien sabe arreglar un problema concreto. El método tiene nueve pasos, empieza mucho antes de abrir ningún panel y termina bastante después de que la métrica mejore, y su propiedad más importante es que en cada paso se puede descubrir que la hipótesis era falsa, que es exactamente lo que hay que querer que pase.

Los nueve pasos

flowchart TB
A[1 Definir el sujeto] --> B[2 Mirar el campo y segmentar]
B --> C[3 Cuantificar el hueco]
C --> D[4 Formular el mecanismo]
D --> E[5 Reproducir en laboratorio]
E -->|No reproduce| D
E -->|Reproduce| F[6 Atribuir el tiempo por partes]
F --> G[7 Intervenir sobre la parte mayor]
G --> H[8 Verificar en laboratorio y en campo]
H -->|El campo no se mueve| B
H -->|Confirmado| I[9 Blindar con presupuesto y comprobacion]
style A fill:#cba6f7,color:#11111b
style B fill:#89b4fa,color:#11111b
style D fill:#cba6f7,color:#11111b
style E fill:#f9e2af,color:#11111b
style F fill:#89b4fa,color:#11111b
style G fill:#fab387,color:#11111b
style I fill:#a6e3a1,color:#11111b

Los dos ciclos de vuelta son la parte importante del diagrama. Si no consigues reproducir, tu modelo del problema es falso y hay que volver a la hipótesis, no seguir adelante a ver si suena la flauta. Y si el laboratorio mejora y el campo no se mueve, has arreglado algo que no era el problema de tus usuarios, y toca volver a segmentar.

Uno: definir el sujeto. “El sitio va lento” no es un problema, es un sentimiento. El sujeto de una afirmación de rendimiento tiene siempre cuatro componentes: qué página, qué población de usuarios, qué momento de la interacción y qué percentil. “El pintado del elemento más grande en el percentil 75 de las sesiones móviles que entran por campaña a las fichas de producto.” Con el sujeto bien definido, la mitad del trabajo de diagnóstico ya está hecha, porque las siguientes preguntas tienen a qué referirse.

Dos: mirar el campo y segmentar. Antes de cualquier medida de laboratorio. Las cinco dimensiones que hay que cortar siempre, en este orden de rentabilidad: clase de dispositivo, tipo de conexión, geografía, ruta o plantilla, y primera visita frente a recurrente. Cada corte puede revelar que el problema no está repartido sino concentrado, y un problema concentrado es un problema con causa identificable.

Tres: cuantificar el hueco. Cuánto hay que ganar y en qué población. Un objetivo sin número no se puede cumplir ni fallar. Y el número debe ser el del percentil del segmento, no el agregado, por lo visto sobre segmentación.

Cuatro: formular el mecanismo. Una frase causal, concreta y falsable. “La imagen principal no se descubre hasta que se ejecuta el JavaScript, así que su descarga empieza 1,8 segundos tarde.” Si tu hipótesis no dice qué medida concreta debería cambiar al arreglarla, no es una hipótesis.

Cinco: reproducir en laboratorio. El escenario mínimo que reproduce el problema, con la limitación calibrada del dispositivo objetivo. Reproducir es la comprobación de que tu modelo es correcto, y es el paso que más gente se salta. Si no reproduces, no sigas.

Seis: atribuir el tiempo por partes. El paso que convierte una métrica en tareas, y el que más rendimiento da. Lo desarrollo abajo.

Siete: intervenir sobre la parte mayor. Una cosa cada vez. Cambiar cinco a la vez y ver que mejora no enseña nada, y deja cinco cambios que nadie sabe si hacían falta.

Ocho: verificar. Primero en laboratorio, que es rápido; después en campo, que es la verdad. Y el campo tarda: hay que esperar a que la ventana de agregación se llene.

Nueve: blindar. Un presupuesto y una comprobación automática que impidan volver atrás. Sin este paso, la mejora tiene fecha de caducidad.

La atribución por partes

Cada métrica se descompone en sumandos, y el sumando mayor es la tarea. Esta es la parte del método que más veces resuelve el problema por sí sola.

El pintado del elemento más grande tiene cuatro partes:

El segundo sumando es el que suele ser enorme y el que nadie mira. Un retraso de carga grande significa que el navegador no sabía que necesitaba ese recurso, y eso apunta directamente a que el recurso lo descubre JavaScript, o a que está detrás de una hoja de estilos, o a que hay una cascada delante. Es la causa individual más frecuente de un LCP malo en sitios modernos.

// Descomposicion del LCP en sus cuatro partes.
new PerformanceObserver((lista) => {
  const entradas = lista.getEntries();
  const lcp = entradas[entradas.length - 1];
  const nav = performance.getEntriesByType('navigation')[0];
  const ttfb = nav ? nav.responseStart : 0;

  // Si el elemento es una imagen, su entrada de recurso tiene los tiempos.
  const recurso = lcp.url
    ? performance.getEntriesByName(lcp.url).at(-1)
    : null;

  const inicioCarga = recurso ? recurso.requestStart : ttfb;
  const finCarga = recurso ? recurso.responseEnd : ttfb;

  console.table({
    ttfb: Math.round(ttfb),
    retrasoDeCarga: Math.round(inicioCarga - ttfb),
    tiempoDeCarga: Math.round(finCarga - inicioCarga),
    retrasoDeRender: Math.round(lcp.startTime - finCarga),
    total: Math.round(lcp.startTime),
    elemento: lcp.element?.tagName,
    url: lcp.url || '(texto)',
  });
}).observe({ type: 'largest-contentful-paint', buffered: true });

La interacción hasta el siguiente pintado tiene tres partes:

La utilidad de esta descomposición es que cada parte tiene un conjunto de remedios distinto y disjunto. Si el retraso de entrada domina, optimizar tu manejador no sirve absolutamente de nada, porque el problema es lo que había ocupando el hilo antes. Es el error de diagnóstico más caro de esta métrica.

new PerformanceObserver((lista) => {
  for (const e of lista.getEntries()) {
    if (!e.interactionId) continue;
    const retrasoEntrada = e.processingStart - e.startTime;
    const procesamiento = e.processingEnd - e.processingStart;
    const presentacion = e.startTime + e.duration - e.processingEnd;
    if (e.duration < 100) continue;
    console.log(e.name, {
      total: Math.round(e.duration),
      retrasoEntrada: Math.round(retrasoEntrada),
      procesamiento: Math.round(procesamiento),
      presentacion: Math.round(presentacion),
      objetivo: e.target?.tagName,
    });
  }
}).observe({ type: 'event', durationThreshold: 16, buffered: true });

El tiempo hasta el primer byte también se descompone, en redirecciones, resolución de nombre, conexión, negociación TLS y tiempo de servidor, y su desglose está en la entrada de navegación. La regla de lectura: si el tiempo de servidor domina, el problema es tuyo y está en el origen; si domina el establecimiento, el problema es de distancia y de número de orígenes, y se ataca con lo visto en la geografía de la latencia.

El reparto del presupuesto

Un objetivo de métrica se convierte en tareas repartiéndolo. Si el objetivo es un LCP de 2,5 segundos en el percentil 75 móvil y hoy estás en 4,8:

Actual                              Objetivo             Tarea
------------------------------------------------------------------
TTFB              1.900 ms          800 ms      -1.100  Cachear en el borde
Retraso de carga  1.400 ms          150 ms      -1.250  Sacar la imagen del JS
Tiempo de carga   1.200 ms          900 ms        -300  AVIF y srcset correcto
Retraso de render   300 ms          250 ms         -50  Nada, ya esta bien
------------------------------------------------------------------
Total             4.800 ms        2.100 ms      -2.700

Esa tabla es el documento de trabajo. Tiene tres virtudes sobre un objetivo global. Cada fila es una tarea asignable con su propio responsable y su propia estimación. Se ve inmediatamente dónde está el dinero: las dos primeras filas son el ochenta y siete por ciento de la ganancia, y las otras dos se pueden posponer sin culpa. Y permite parar a tiempo: si con las dos primeras filas llegas al objetivo, las otras dos no se hacen.

Y un aviso sobre el orden de ejecución que ahorra trabajo: ataca primero lo que no depende de nada. El retraso de carga de la imagen se arregla con una etiqueta de precarga y quince minutos de trabajo; cachear en el borde requiere coordinación con infraestructura y dos semanas. Empezar por lo barato da una mejora medible el primer día, y esa mejora medible es lo que financia políticamente lo caro.