Auditar las Core Web Vitals antes del lanzamiento del sitio web
Establecer los criterios de aprobación de las Core Web Vitals
Comienza la auditoría definiendo criterios de lanzamiento medibles para las tres Core Web Vitals: Largest Contentful Paint, Interaction to Next Paint y Cumulative Layout Shift. Una buena experiencia requiere un LCP de 2,5 segundos o menos, un INP de 200 milisegundos o menos y un CLS de 0,1 o menos. Google evalúa estos umbrales en el percentil 75 de las visitas a las páginas, por separado para móviles y ordenadores. Trátalos como requisitos de lanzamiento, no como objetivos de optimización opcionales.
Crea una lista representativa de URL antes de ejecutar cualquier herramienta. Incluye la página de inicio, una página de cada plantilla principal y rutas de conversión de alto valor, como las de producto, precios, checkout, registro o formularios de captación de leads. Un sitio de 500 páginas creado a partir de ocho plantillas normalmente necesita pruebas más exhaustivas sobre esas ocho plantillas, además de las páginas inusuales, en lugar de realizar comprobaciones idénticas en las 500 URL. Registra la plantilla, el perfil del dispositivo, el entorno de prueba, el resultado de la métrica, la causa sospechada, el responsable y el estado de la repetición de la prueba para cada muestra.
Probar las páginas en un entorno similar al de producción
Audita una build similar a producción, ya que el modo de desarrollo puede distorsionar los resultados de rendimiento. Activa la misma minificación, compresión de imágenes, caché, red de distribución de contenidos, redirecciones, analítica, gestor de consentimiento y scripts de terceros previstos para el lanzamiento. Verifica que las páginas de prueba no estén sirviendo accidentalmente source maps sin optimizar, bundles de depuración o recursos locales. Mantén el entorno de staging bloqueado para los motores de búsqueda mediante autenticación o controles de indexación adecuados, pero configura la propia aplicación lo más cerca posible de producción.
La ubicación de red y la configuración del servidor también son importantes. Una página puede alcanzar un LCP de 1,8 segundos desde una oficina cercana al servidor de origen, pero superar los 3 segundos para un usuario móvil situado en otro continente. Realiza pruebas desde las regiones donde se encuentra el público objetivo e incluye perfiles de redes móviles y CPU más lentos. Registra por separado las ejecuciones con caché caliente y caché fría, porque un visitante nuevo no se beneficia de los recursos ya almacenados en el navegador.
Combinar Lighthouse con datos de campo
Utiliza Google Lighthouse o PageSpeed Insights para realizar diagnósticos de laboratorio reproducibles, pero no confundas una única puntuación con una evidencia completa. Ejecuta al menos tres pruebas móviles por página y utiliza el resultado mediano, ya que las condiciones de red y CPU varían entre ejecuciones. Examina las métricas individuales, la cascada de solicitudes, el trabajo del hilo principal, los recursos que bloquean el renderizado y las evidencias de cambios de diseño, en lugar de centrarte únicamente en la puntuación general de rendimiento. Una puntuación de 90 aún puede ocultar una métrica deficiente en una plantilla crítica para el negocio.
Los datos de campo reflejan el comportamiento de visitantes reales y, por tanto, son esenciales cuando están disponibles. PageSpeed Insights y el Chrome User Experience Report pueden mostrar una vista móvil de 28 días a nivel de URL o de origen, pero es posible que un dominio o una plantilla nuevos no tengan un historial utilizable antes del lanzamiento. En ese caso, compara páginas equivalentes del sitio actual, ejecuta una beta controlada o incorpora monitorización de usuarios reales al tráfico previo al lanzamiento. Recuerda que las pruebas de laboratorio estiman el Total Blocking Time como un proxy útil, mientras que INP depende de las interacciones reales de los usuarios.
Diagnosticar Largest Contentful Paint
Cuando LCP falla, identifica primero el elemento exacto que se ha registrado como el contenido visible de mayor tamaño. A menudo es una imagen hero, una fotografía de producto, una imagen de póster o un encabezado grande, pero el cuello de botella puede comenzar antes de que ese elemento se descargue. Divide la métrica en retraso de respuesta del servidor, retraso en el descubrimiento del recurso, tiempo de carga del recurso y retraso de renderizado. Esta descomposición evita que el equipo comprima una imagen cuando el problema real es un servidor lento o el renderizado del lado del cliente.
Para un LCP basado en imágenes, utiliza un recurso AVIF o WebP con el tamaño adecuado, incluye candidatos de imagen responsive y evita la carga diferida del contenido visible en la parte superior de la página. Precarga únicamente una imagen verdaderamente crítica, establece una prioridad de descarga alta cuando corresponda y confirma que el navegador la descubre directamente en el HTML inicial. Si la respuesta HTML tarda 900 milisegundos y la imagen hero comienza a descargarse en el segundo 1,4, reducir 100 milisegundos de la decodificación de la imagen no resolverá el retraso mayor. Prueba también las páginas autenticadas, localizadas y personalizadas, porque sus rutas de respuesta del servidor pueden ser diferentes.
Medir Interaction to Next Paint
INP mide la rapidez con la que una página ofrece respuesta visual después de las interacciones del usuario a lo largo de una visita. Durante la auditoría, haz clic en menús, filtros, acordeones, controles de formulario, sugerencias de búsqueda, botones de añadir al carrito y controles de consentimiento, en lugar de probar únicamente la carga de la página. Utiliza las grabaciones de rendimiento de Chrome DevTools para localizar tareas largas y controladores de eventos costosos. Un filtro que responde en 80 milisegundos en un ordenador de escritorio puede tardar más de 250 milisegundos en un teléfono de gama media cuando un bundle grande de JavaScript bloquea el hilo principal.
Reduce el retraso de interacción eliminando JavaScript no utilizado, dividiendo los bundles por ruta o funcionalidad y posponiendo el código de terceros no esencial. Divide el trabajo que consume mucha CPU en tareas más pequeñas para que el navegador pueda procesar la entrada y renderizar la respuesta entre ellas. Actualiza únicamente la parte necesaria de la interfaz en lugar de reconstruir un árbol grande de componentes después de cada clic. Por ejemplo, cambiar un filtro de producto no debería recalcular sincrónicamente cientos de elementos ocultos antes de mostrar el estado seleccionado.
Encontrar y prevenir los cambios de diseño
Los problemas de CLS suelen aparecer cuando las imágenes, los anuncios, los elementos incrustados, los banners o las fuentes web modifican el diseño después del renderizado inicial. Añade atributos explícitos de ancho y alto o una relación de aspecto CSS a los recursos multimedia para que el navegador reserve espacio antes de que lleguen los archivos. Reserva contenedores predecibles para anuncios y elementos incrustados, incluso cuando no haya inventario disponible. Cuando sea posible, inserta los avisos que aparecen tarde debajo del contenido existente en lugar de desplazar hacia abajo la navegación, los encabezados o los controles de compra.
Prueba la estabilidad del diseño durante recorridos completos del usuario, no solo durante los primeros segundos de carga de la página. Abre un banner de cookies, activa mensajes de validación, cambia los filtros, carga más resultados y espera a que aparezcan los componentes promocionales con retraso. DevTools puede resaltar las regiones que cambian y agrupar los cambios de diseño relacionados, lo que facilita identificar el elemento responsable. Un pequeño desplazamiento repetido cinco veces puede producir un resultado acumulado deficiente, aunque ningún movimiento individual parezca significativo.
Ejecuta la comprobación técnica final de SEO
Después de implementar las correcciones, vuelve a ejecutar las mismas URL con el mismo dispositivo, red, ubicación y condiciones de caché utilizados para establecer la línea base. Compara los resultados medianos de varias ejecuciones e investiga las regresiones en el tamaño transferido, el número de solicitudes, las tareas largas y el tiempo de respuesta del servidor. Realiza pruebas en los puntos de ruptura responsive habituales, ya que una plantilla móvil puede cargar imágenes o scripts diferentes de los de su equivalente de escritorio. Verifica también que los cambios de rendimiento no hayan afectado a las etiquetas canónicas, los datos estructurados, las redirecciones, la analítica, la accesibilidad ni el seguimiento de conversiones.
Define un criterio de aprobación para el lanzamiento que refleje tanto el rendimiento como el riesgo empresarial. Por ejemplo, exige que todas las plantillas críticas cumplan los tres umbrales en escenarios de laboratorio reproducibles, permite excepciones documentadas únicamente con un responsable asignado y programa una revisión de los datos de campo 28 días después del lanzamiento. Añade Lighthouse CI u otra comprobación automatizada del rendimiento web al pipeline de despliegue para evitar que lanzamientos posteriores vuelvan a introducir silenciosamente imágenes sobredimensionadas o scripts que bloqueen la carga. Core Web Vitals respalda el SEO técnico, pero la decisión final de lanzamiento también debe tener en cuenta la rastreabilidad, la indexabilidad, la calidad del contenido y las pruebas funcionales.
Lecturas recomendadas
Etiquetas :
- SEO técnico
