Aprenda a mejorar Core Web Vitals sabiendo cómo diagnosticar y proporcionar soluciones para una mejor experiencia centrada en el usuario.
Los humanos reales quieren buenas experiencias web. ¿Cómo se ve eso en la práctica?
Bueno, un estudio reciente citado por Google en una publicación de blog sobre Core Web Vitals descubrió que los usuarios de la web móvil solo mantuvieron su atención en la pantalla durante 4-8 segundos a la vez. study
Lee eso de nuevo.
Tiene menos de 8 segundos para entregar contenido interactivo y hacer que un usuario complete una tarea.
Introduzca Core Web Vitals (CWV). Estas tres métricas están diseñadas para medir el rendimiento del sitio en la experiencia humana.. El proyecto Chromium de código abierto anunció las métricas a principios de mayo de 2020 y se adoptaron rápidamente en todos los productos de Google.
¿Cómo calificamos el rendimiento en las mediciones centradas en el usuario?
Fundamentalmente, Core Web Vitals mide cuánto tiempo lleva completar las funciones de secuencia de comandos necesarias para pintar el contenido de la mitad superior de la página.. El escenario para estas tareas hercúleas es una ventana de visualización de 360 x 640. ¡Cabe justo en tu bolsillo!
Este tambor de guerra para la deuda tecnológica no abordada es una bendición para muchos propietarios de productos y profesionales de SEO tecnológico que se han atrasado en favor de nuevas funciones y adornos brillantes.
¿La actualización de Page Experience será Mobileggedon 4.0?
Probablemente no.
Pero cuando su página pasa las evaluaciones de CWV, los usuarios tienen un 24% menos de probabilidades de abandonar las cargas de la página.. Estos esfuerzos benefician a todas las fuentes y medios, y lo más importante, a los humanos reales. 24%
La actualización de la experiencia de la página
A pesar de todo el alboroto, CWV serán elementos en una señal de clasificación. Se espera que se implemente gradualmente desde mediados de junio hasta agosto de 2021, el Ranking de experiencia de página estará compuesto por:
La documentación actualizada aclara que la implementación será gradual y que «los sitios generalmente no deben esperar cambios drásticos». documentation
Cosas importantes que debe saber sobre la actualización:
- La experiencia de la página se evalúa por URL.
- La experiencia de la página se basa en un navegador móvil.
- AMP ya no es necesario para los carruseles de Historias destacadas.
- Pasar CWV no es un requisito para aparecer en los carruseles de Top Stories.
Un nuevo informe de experiencia de página en Search Console
Search Console ahora incluye un informe de experiencia de página. El recurso nuevo incluye datos retroactivos de los últimos 90 días. Page Experience report
Para que una URL sea «buena», debe cumplir con los siguientes criterios:
- La URL no tiene problemas de usabilidad móvil según el informe de usabilidad móvil.
- El sitio no tiene problemas de seguridad.
- La URL se sirve a través de HTTPS.
- El sitio no tiene problemas con la experiencia publicitaria o no se evaluó la experiencia publicitaria.
El nuevo informe ofrece widgets de alto nivel que se vinculan a informes para cada uno de los cinco criterios «buenos».
Flujo de trabajo para diagnosticar y aplicar mejoras de CWV
Primero, una advertencia importante con respecto a los datos de campo vs laboratorio.
Los datos de campo son datos de rendimiento recopilados de cargas de páginas reales que sus usuarios experimentan en la naturaleza. Es posible que también escuche que se hace referencia a los datos de campo como monitoreo de usuarios reales.
Las evaluaciones Core Web Vitals y Page Experience Ranking Signal utilizarán datos de campo recopilados por Chrome User Experience Report (Crux).
¿Qué usuarios forman parte del informe de experiencia de usuario de Chrome?
Los datos cruciales son usuarios agregados que cumplen tres criterios:
Crux es su fuente de información para Core Web Vitals Assessment.
Puede acceder a los datos de Crux mediante Google Search Console, PageSpeed Insights (a nivel de página), proyecto público de Google BigQuery o como un panel de nivel de origen en Google Data Studio. Public Google BigQuery project
¿Por qué usarías algo más?
¿Por qué mi página no tiene datos disponibles de Crux?
Al probar su página, es posible que vea «El Informe de experiencia del usuario de Chrome no tiene suficientes datos de velocidad del mundo real para esta página».
Esto se debe a que los datos de Crux son anónimos.. Debe haber suficientes páginas cargadas para informar sin la posibilidad razonable de que se identifique al usuario individual.
Web Core Vitals se identifica mejor utilizando datos de campo y luego se diagnostica/QAed utilizando datos de laboratorio.
Lab Data le permite depurar el rendimiento con una visibilidad profunda y de extremo a extremo en UX. Se llama «laboratorio» ya que estos datos emulados se recopilan dentro de un entorno controlado con dispositivos predefinidos y configuraciones de red.
Puede obtener datos de laboratorio de PageSpeed Insights, web.dev/measure, el panel Lighthouse de Chrome DevTool y rastreadores basados en Chromium como NodeJS Lighthouse local o DeepCrawl.
Sumerjámonos en un proceso de flujo de trabajo.
1. Identifique problemas con los datos de Crux agrupados por patrones de comportamiento en Search Console.
Comience con el informe Core Web Vitals de Search Console para identificar grupos de páginas que requieren atención. Este conjunto de datos utiliza datos de Crux y tiene la amabilidad de agrupar URL de ejemplo en función de patrones de comportamiento.
Si resuelve el problema raíz de una página, es probable que lo solucione para todas las páginas que comparten ese problema de CWV. Por lo general, estos problemas los comparte una plantilla, una instancia de CMS o un elemento en la página.. GSC hace la agrupación por usted.
Concéntrese en los datos móviles, ya que Google se está moviendo hacia un índice móvil primero y CWV está configurado para afectar los SERP móviles. Priorice sus esfuerzos en función de la cantidad de URL afectadas.
Haga clic en un problema para ver URL de ejemplo que muestran los mismos patrones de comportamiento.
Guarde estas URL de ejemplo para probarlas durante el proceso de mejora.
2. Utilice PageSpeed Insights para casar los datos de campo con los diagnósticos de laboratorio.
Una vez que haya identificado las páginas que necesitan trabajo, use PageSpeed Insights (con tecnología de Lighthouse y Chrome UX Report) para diagnosticar problemas de laboratorio y de campo en una página.
Recuerde que las pruebas de laboratorio son pruebas emuladas únicas. Una prueba no es una fuente de verdad o una respuesta definitiva. Pruebe varias URL de ejemplo.
PageSpeed Insights solo se puede usar para probar URL indexables y disponibles públicamente.
Si está trabajando en páginas sin índice o autenticadas, los datos de Crux están disponibles a través de API o BigQuery. Las pruebas de laboratorio deben usar Lighthouse.
3. Crear un boleto. Hacer el trabajo de desarrollo.
Los animo como profesionales de SEO a ser parte de los procesos de control de calidad y refinamiento de tickets.
Los equipos de desarrollo suelen trabajar en sprints. Cada sprint incluye entradas fijas. Tener tickets bien escritos le permite a su equipo de desarrollo dimensionar mejor el esfuerzo y obtener el ticket en un sprint.
En tus entradas, incluye:
Historia del usuario
As a < type of user/site/etc >, I want < action > in order to < goal >.
Como
Por ejemplo: como sitio de alto rendimiento, quiero incluir CSS en línea para el nodo X en la plantilla de página Y para lograr la pintura con mayor contenido para esta plantilla de página en menos de 2,5 segundos.
Criterios de aceptación
- Incluya cualquier CSS de ruta crítica utilizado para el contenido de la mitad superior de la página incluyéndolo directamente en .
- El CSS crítico (léase: el relacionado con el nodo X) aparece encima de los enlaces de recursos de JS y CSS en el .
Prueba de URL/Estrategia . Proporcione un conjunto de pasos que deben seguir los ingenieros de control de calidad.
Enlaces al documento del desarrollador . Por favor, no blogs esponjosos. ¿Por favor?
4. Cambios en el control de calidad en los entornos de ensayo con Lighthouse.
Antes de que el código pase a producción, a menudo se coloca en un entorno de ensayo para realizar pruebas.. Use Lighthouse (a través de Chrome DevTools o una instancia de nodo local) para medir Core Web Vitals.
Si es nuevo en las pruebas con Lighthouse, puede obtener información sobre las formas de probar y la metodología de prueba en Una guía técnica de SEO para las métricas de rendimiento de Lighthouse.
Tenga en cuenta que los entornos inferiores suelen tener menos recursos y tendrán un rendimiento inferior al de producción.
Confíe en los criterios de aceptación para determinar si el trabajo de desarrollo completado cumplió con la tarea asignada.
Pintura con contenido más grande
Representa: Experiencia de carga percibida.
Medida: El punto en la línea de tiempo de carga de la página cuando la imagen o el bloque de texto más grande de la página es visible dentro de la ventana gráfica.
Comportamientos clave: las páginas que usan las mismas plantillas de página suelen compartir el mismo nodo LCP.
Objetivo: el 75 % de las cargas de página alcanzan LCP en < 2,5 segundos.
Disponible como: Datos de laboratorio y de campo.
¿Qué puede ser LCP?
La métrica LCP mide cuándo está visible el elemento de imagen o texto más grande en la ventana gráfica.
Los posibles elementos que pueden ser el nodo LCP de una página incluyen:
Espere ver elementos adicionales como
Cómo identificar LCP usando Chrome DevTools
¿Qué causa el LCP deficiente?
Hay cuatro problemas comunes que causan un LCP deficiente:
Los problemas de origen para LCP están pintados a grandes rasgos en el mejor de los casos. Lamentablemente, es probable que ninguna de las frases individuales anteriores sea suficiente para transmitirlas a su equipo de desarrollo con resultados significativos.
Sin embargo, puede darle un impulso al problema si se concentra en cuál de los cuatro orígenes está en juego.
Mejorar LCP va a ser colaborativo. Arreglarlo significa participar en las actualizaciones de desarrollo y hacer un seguimiento como parte interesada.
Diagnóstico de un LCP deficiente debido a un tiempo de respuesta lento del servidor
Dónde buscar: Crux Dashboard v2: tiempo hasta el primer byte (TTFB) (página 6) Crux Dashboard v2 – Time to First Byte (TTFB) (page 6)
SI ve un TTFB constantemente deficiente en sus datos de campo, entonces es un tiempo de respuesta lento del servidor que arrastra a LCP.
Cómo corregir el tiempo de respuesta lento del servidor
El tiempo de respuesta del servidor está compuesto por numerosos factores adaptados a la pila de tecnología del sitio. Aquí no hay balas de plata.. Su mejor curso de acción es abrir un ticket con su equipo de desarrollo.
Algunas formas posibles de mejorar TTFB son:
Diagnóstico de LCP deficiente debido a JavaScript y CSS que bloquean el renderizado
Dónde buscar: Lighthouse (a través de web.dev/measure, Chrome DevTools, Pagespeed Insights o instancia de nodeJS). Cada una de las soluciones a continuación incluye una marca de auditoría relevante. web.dev/measure
Cómo arreglar el CSS que bloquea el renderizado
CSS es inherentemente bloqueador de renderizado e impacta el rendimiento crítico de la ruta de renderizado. De forma predeterminada, CSS se trata como un recurso de bloqueo de procesamiento.
El navegador descarga todos los recursos CSS, independientemente del comportamiento de bloqueo o no bloqueo.
Minimizar CSS.
Si su sitio utiliza un paquete de módulos o una herramienta de compilación, busque el complemento que minimice sistemáticamente los scripts.
Aplazar CSS no crítico.
El informe Cobertura de código en DevTools lo ayudará a identificar qué estilos se usan en la página. Si no se usa en ninguna página, elimínelo por completo. (Sin juzgar, los archivos CSS pueden inflarse rápidamente en el proverbial cajón de basura).
CSS crítico en línea.
Incluya el CSS de ruta crítica utilizado para el contenido de la mitad superior de la página (según lo identificado por el informe Cobertura de código) directamente en
.Utilice consultas de medios dinámicos.
Las consultas de medios son filtros simples que, cuando se aplican a los estilos CSS, dividen los estilos en función de los tipos de dispositivos que representan el contenido.
El uso de consultas de medios dinámicos significa que, en lugar de calcular estilos para todas las ventanas gráficas, está llamando y calculando esos valores en la ventana gráfica solicitante.
Cómo arreglar JavaScript que bloquea el renderizado
Minimiza y comprime archivos JavaScript.
La minificación implica la eliminación de espacios en blanco y código innecesarios. Es mejor hacerlo sistemáticamente con una herramienta de compresión de JavaScript. Minification
La compresión implica modificar algorítmicamente el formato de los datos para lograr interacciones entre el servidor y el cliente. Compression
Diferir JavaScript no utilizado. La división de código corta grandes porciones de JS para entregar paquetes más pequeños. A continuación, puede cargar primero los que son importantes en el contenido de la mitad superior de la página. Code splitting
Minimice los polyfills no utilizados.
Ahora que Googlebot es perenne, también se conoce con el nombre de deuda tecnológica.
Algunos compiladores tienen funcionalidades integradas para eliminar los polyfills heredados.
Cómo arreglar secuencias de comandos de terceros que bloquean el renderizado
Retrasarlo.
Si la secuencia de comandos no contribuye al contenido de la parte superior de la página, use atributos asíncronos o diferidos.
quitarlo
Si el script usa un