Core Web Vitals para sitios PHP: cómo arreglar LCP, INP y CLS

Core Web Vitals para sitios PHP no es un tema exclusivo del front-end. Una página PHP lenta puede dedicar un segundo a producir HTML, y ninguna optimización de la imagen recupera eso. Al mismo tiempo, un servidor muy rápido no ayuda si una imagen principal de 1,5 MB bloquea la pintura más grande. Así es como abordamos ambas partes en nuestros propios sitios PHP (integrono.com ejecuta PHP-FPM detrás de nginx y Cloudflare) y en proyectos de clientes.

Qué miden Core Web Vitals

• LCP ( Largest Contentful Paint): cuando se representa el elemento visible más grande (generalmente una imagen principal o un bloque de encabezado). Bueno es 2,5 segundos o menos.
• INP ( Interaction to Next Paint): qué tan rápido responde visualmente la página después de hacer clic, tocar y presionar teclas, durante toda la visita. Lo bueno es 200 ms o menos.
• CLS ( Cumulative Layout Shift): cuánto contenido salta durante la carga. Bueno es 0,1 o menos.

Google los evalúa con datos de campo de usuarios reales de Chrome, en el percentil 75, por separado para dispositivos móviles y de escritorio. Eso significa que un modelo lento o un país lento pueden fallarle a todo el grupo. Las herramientas de laboratorio como Lighthouse sirven para depurar, no para obtener la puntuación final.

Paso 1. Mida de la manera correcta

1. Abra el informe Core Web Vitals en Google Search Console para ver qué grupos de URL fallan y en qué métrica.
2. Consulte PageSpeed Insights para ver una URL de cada grupo fallido. El bloque superior de "datos de campo" es lo que cuenta; El bloque Lighthouse a continuación es una prueba de laboratorio que explica por qué.
3. Utilice el panel Rendimiento en Chrome DevTools con desaceleración de CPU 4x y "4G lento" para reproducir una experiencia móvil típica.
4. Para un seguimiento continuo, recopile datos de usuarios reales con la biblioteca JavaScript web-vitals y envíelos a sus análisis.

<script type="module">
  import {onLCP, onINP, onCLS} from 'https://unpkg.com/web-vitals@4?module';
  const send = (m) => navigator.sendBeacon('/vitals', JSON.stringify({
    name: m.name, value: m.value, id: m.id, url: location.pathname
  }));
  onLCP(send); onINP(send); onCLS(send);
</script>

Paso 2. Primero arregle el tiempo de respuesta del servidor ( TTFB)

LCP incluye el tiempo antes de que llegue el primer byte. Si su HTML tarda 800 ms en generarse, ya ha gastado un tercio del presupuesto. En los sitios PHP las palancas habituales son:

• Habilite OPcache y asegúrese de que sea lo suficientemente grande para contener todos los scripts. Sin él, PHP vuelve a compilar archivos en cada solicitud.
• Sintonice PHP-FPM. Muy pocos trabajadores ponen en cola solicitudes y demasiada memoria agotada. Mire la página de estado PHP-FPM para "cola de escucha" y "número máximo de niños alcanzados".
• Almacene en caché páginas completas para visitantes anónimos (nginx fastcgi_cache, un caché de respuesta Laravel o reglas de caché Cloudflare) y fragmentos de caché o resultados de consultas con Redis.
• Solucionar consultas lentas. Active el registro de consultas lento, busque patrones N+1 y agregue índices. Una página que ejecuta 120 consultas es lenta independientemente de la versión de PHP.
• Mantenga PHP actualizado. Las versiones más nuevas de PHP son más rápidas y utilizan menos memoria.

# php.ini (production)
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0   ; reload php-fpm on each deploy

# php-fpm pool
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500

Configure pm.max_children desde la memoria real: divida la memoria que puede darle a PHP por el tamaño promedio de un proceso de trabajo (consulte con ps). Con validate_timestamps=0 recuerde recargar PHP-FPM después de cada implementación; de lo contrario, el código antiguo permanece en la memoria.

En el nivel del servidor web, habilite HTTP/2 o HTTP/3, Brotli o gzip y encabezados de almacenamiento en caché de larga duración para archivos estáticos:

location ~* \.(?:css|js|webp|avif|jpg|png|svg|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}
gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;

Utilice nombres de archivos versionados o una consulta ?v= basada en el tiempo de modificación del archivo para que "inmutable" nunca proporcione activos obsoletos.

Paso 3. Arregle el elemento LCP

Busque el elemento LCP en PageSpeed Insights o en el panel Rendimiento de DevTools. En la mayoría de las páginas de contenido es una imagen principal. Entonces:

• No lo cargues de forma diferida. loading="lazy" en la imagen LCP lo retrasa. Utilice fetchpriority="high" en su lugar.
• Sirve el tamaño correcto. Una imagen de 2400 px para una ranura de 900 px desperdicia bytes. Utilice srcset y sizes.
• Utilice WebP o AVIF. Los ahorros típicos son del 30 al 60 por ciento en comparación con JPEG de calidad similar.
• Evite las cadenas. Una imagen configurada a través de un fondo CSS o inyectada mediante JavaScript se descubre tarde. Póngalo en HTML como <img>.
• Preconectar o hospedar orígenes de terceros de los que depende el LCP (fuentes, imagen CDN).

<img src="/images/hero-1200.webp"
     srcset="/images/hero-640.webp 640w, /images/hero-1200.webp 1200w"
     sizes="(max-width: 1040px) 92vw, 960px"
     width="1200" height="630"
     alt="Descriptive alt text"
     decoding="async" fetchpriority="high">

Este es el patrón que utiliza el artículo que cubre el blog: dos tamaños WebP, dimensiones explícitas y alta prioridad de búsqueda para el héroe.

Paso 4. Eliminar cambios de diseño ( CLS)

• Establezca siempre width y height (o aspect-ratio en CSS) en imágenes, videos e iframes para que el navegador reserve el espacio.
• Reserve espacio para banners, avisos de cookies y anuncios. Insértelos en un contenedor con una altura mínima fija en lugar de empujar el contenido hacia abajo después de la carga.
• Fuentes: use font-display: swap u optional, precargue el archivo de fuente principal y subconjunto. Elija una fuente alternativa con métricas similares.
• No inyecte contenido encima del contenido existente a menos que el usuario lo haya activado.
• Animar con transform y opacity, no con propiedades que cambian el diseño (top, height).

Paso 5. Mejorar INP: menos JavaScript en el hilo principal

INP es la métrica más nueva y la que los desarrolladores de PHP descuidan, porque el servidor no influye directamente en ella. Las causas están en el navegador: tareas largas de paquetes grandes, scripts pesados de terceros (análisis, widgets de chat, administradores de etiquetas) y controladores que realizan demasiado trabajo de forma sincrónica.

• Auditar scripts de terceros. Elimina lo que nadie usa, carga el resto con defer o después de la primera interacción.
• Divida tareas largas. Divida el trabajo en partes con requestIdleCallback, setTimeout o la Scheduler API; mover cálculos pesados a un Web Worker.
• Mantenga el DOM pequeño. Miles de nodos hacen que cada actualización sea lenta.
• Evite diseños sincrónicos forzados en bucles (lectura y escritura de propiedades de diseño alternativamente).
• Muestre retroalimentación inmediata (un estado presionado o una rueda giratoria) antes de comenzar el trabajo lento.

Paso 6. Guárdelo en su proceso de implementación

El rendimiento retrocede silenciosamente: una nueva etiqueta, un héroe más pesado, una consulta adicional en la página de inicio. Agregue Lighthouse CI o una verificación programada de la API de PageSpeed para sus cinco plantillas más importantes, establezca presupuestos ( LCP, tamaño total de JS, peso de la imagen) y avise cuando se excedan. Compare TTFB antes y después de cada lanzamiento; si salta, la causa casi siempre es una consulta o un caché que ya no llega.

Un orden de trabajo realista

1. Mida los datos de campo e identifique grupos de URL defectuosos.
2. Habilite OPcache, revise la configuración de PHP-FPM, agregue almacenamiento en caché de página completa para tráfico anónimo.
3. Corrige imágenes destacadas: formato, tamaño, prioridad, dimensiones.
4. Reserva espacio para todo lo que se carga tarde.
5. Reducir y diferir JavaScript; eliminar terceros no utilizados.
6. Vuelva a medir después de 28 días, porque los datos de campo son una ventana móvil.

Espere que aparezcan mejoras en Search Console gradualmente: el informe utiliza aproximadamente los últimos 28 días de datos, por lo que una solución enviada hoy es completamente visible solo después de aproximadamente un mes.

¿Cómo podemos ayudar?

Realizamos trabajo de rendimiento en proyectos PHP y Laravel como parte de un compromiso técnico de SEO y como ajuste único: almacenamiento en caché, consultas, imágenes y correcciones de front-end enviadas en código. Si desea saber cuál de los cambios anteriores daría frutos en su sitio, reserve una consulta o un análisis del servidor. Para obtener una lista de verificación más amplia sobre rastreo e indexación, lea nuestra lista de verificación de auditoría técnica de SEO.