Core Web Vitals para empresas: preguntas y respuestas con Kathy Brown y Karl Kleinschmidt

Core Web Vitals para empresas: preguntas y respuestas con nuestros propios Kathy Brown y Karl Kleinschmidt

El 18 de febrero, organizamos nuestra sesión Core Web Vitals for Enterprise Businesses para abordar la nueva actualización del factor de clasificación de experiencia de página de Google. La sesión se centró en qué eran los Core Web Vitals y por qué eran importantes. Nuestros expertos se sumergieron en lo que significaba cada una de las nuevas señales de clasificación y cómo afectarían al SEO. Aunque proporcionamos sugerencias y consejos prácticos, todavía había muchas preguntas sobre FID, LCP, CLS y más.

A continuación se encuentran las preguntas recopiladas de nuestra audiencia y nuestros expertos Kathy y Karl las abordan.

¿Cuál es la diferencia entre los datos de campo y de laboratorio?

Kathy : Los datos de laboratorio son los datos de rendimiento que ve en un entorno específico. Herramientas como Chrome Dev Tools, así como herramientas como webpagetest.org le proporcionan datos de laboratorio. Los datos de campo son datos recopilados de muchos usuarios que utilizan Chrome para navegar por las páginas de su sitio. Puede ver los datos de campo en Google Search Console y, a menudo, en Google Page Speed ​​Insights (que informará los datos de laboratorio y de campo de una página). Para las necesidades de automatización, se puede acceder a los datos de campo a través de BigQuery. Recuerde que los datos de laboratorio son para pruebas, los datos de campo son para clasificar. Según los comentarios de John Mueller, anticipamos que inicialmente, CWV solo afectará las clasificaciones móviles y que deberá estar "en verde" para que las tres métricas se clasifiquen más alto.

¿Qué hace cuando no hay datos de campo disponibles?

Kathy : si no hay datos de campo disponibles, es probable que la página no reciba mucho tráfico. Use Google Page Speed ​​Insights para verificar sus páginas más populares y ver si los datos de campo están disponibles para esas páginas. A continuación, puede extrapolar los resultados de todas sus páginas que pertenecen a ese tipo de página. Intente configurar un informe CrUX para ver si hay uno para su origen (su dominio). Puede encontrar una plantilla de Google Data Studio preconstruida y esto le dará datos de rendimiento para su sitio en general.

Si aún no puede encontrar ningún dato de campo, determine los principales dispositivos y navegadores más comunes que acceden a su sitio y pruebe con esos entornos. Recuerde configurar los controles de aceleración y ancho de banda para simular lo más cerca posible los entornos de sus visitantes.

Durante el desarrollo, nuestros sitios web se ejecutan en servidores secundarios que son mucho más lentos que nuestros servidores de producción. ¿Cómo haces para probar la velocidad de la página en esta situación?

Kathy: Una cantidad significativa de la puntuación de Core Web Vital dependerá del cliente y del código que se esté ejecutando. Entonces, un puntaje CLS bajo no tiene nada que ver con un servidor lento. Sin embargo, LCP podría verse afectado por un servidor lento debido a protocolos de enlace de conexión más lentos y al tiempo que lleva enviar los recursos. Un enfoque a considerar es crear una comparación para sus servidores para métricas como TTFB (tiempo hasta el primer byte) para una variedad de páginas, además de comparar el tiempo para entregar cada 1 KB de datos. Además, si tiene operaciones de base de datos o JS del lado del servidor, también sería útil conocer las diferencias entre esos tiempos de ejecución en cada servidor. Compare los gráficos de cascada entre los dos y vea cuánto tiempo de espera adicional hay en el entorno de desarrollo. Conocer estas diferencias ayudaría a evaluar el rendimiento de LCP en su servidor de desarrollo más fácilmente.

¿Cree que la carga previa de enlaces (para páginas posteriores) afectará a LCP O cree que LCP depende solo de la primera página que carga el usuario?

Kathy: Cuando se trata de datos de campo, el rendimiento de todas las páginas es importante. El almacenamiento en caché de activos estáticos (lo que ayuda para visitas y páginas posteriores) ayudará a sus puntajes de campo. La precarga de estilos CSS mediante el enlace probablemente también ayudará al rendimiento de todas las páginas.

¿Podría una CDN con una buena optimización de caché disminuir significativamente la puntuación de LCP?

Kathy: Ciertamente es posible que si el LCP aparece más rápidamente para todos los usuarios (tanto nuevos como recurrentes), entonces su puntaje LCP mejorará.

¿Cómo se utilizan las ventanas emergentes sin que afecten a Core Web Vitals?

Karl: Para problemas de LCP, verifique que las ventanas emergentes no ocupen un porcentaje demasiado grande de la ventana gráfica, especialmente en dispositivos móviles.

Para problemas de CLS, verifique que las ventanas emergentes no hagan que el resto de sus elementos se muevan, sino que estén frente a ellos.

¿Cómo deberíamos pensar en CWV en el contexto de la indexación móvil primero?

Karl: CWV se implementará primero en dispositivos móviles y se retrasará para computadoras de escritorio (no sabemos cuánto). CWV no se trata realmente de cómo Google rastrea su sitio, sino de cómo los visitantes interactúan con su sitio, por lo que la indexación móvil primero no debería marcar la diferencia.

¿Cuál es la diferencia entre el tiempo total de bloqueo (TBT) y FID?

Karl: El tiempo total de bloqueo es la cantidad total de milisegundos que las tareas de bloqueo del subproceso principal están bloqueando la interacción (se restan 100 ms por tarea). FID es el tiempo promedio que tarda su sitio web en responder a las interacciones de los visitantes. Por lo tanto, el tiempo total de bloqueo es la cantidad total de milisegundos en la carga de la página donde podría tener un FID superior a 0, mientras que FID captura cómo los usuarios realmente interactúan con su sitio.

Vemos cambios de puntuación en Google Search Console sin que hagamos cambios/mejoras de nuestra parte.

¿Cuál sería el motivo de estas fluctuaciones dentro de la consola de búsqueda?

Karl: Para Search Console son datos de campo, depende de cómo interactúan los usuarios con su sitio. Los cambios en el comportamiento del usuario pueden significar diferentes puntajes CLS porque los visitantes se desplazan de manera diferente o diferentes puntajes LCP porque un porcentaje más alto de visitantes son clientes recurrentes, por lo que tienen ciertas imágenes almacenadas en caché. Hay muchas causas posibles para las fluctuaciones en las métricas y recuerde que los datos se retrasan alrededor de 28 días, por lo que es posible que haya publicado algo hace 28 días y ahora esté viendo los cambios en los datos.

Si alguien obtiene resultados diferentes de Search Console y PageSpeedTest, ¿deberíamos preocuparnos solo por lo que se informa en Search Console?

Karl: Fuera de los datos de Field vs. Lab, hay dos causas principales para los diferentes datos entre la consola de búsqueda y la información sobre la velocidad de la página. Si una de sus páginas no ha recibido suficiente tráfico, Google usa datos de páginas similares en las estadísticas de velocidad de la página, mientras que en la consola de búsqueda se agrupan páginas similares que podrían tener suficientes datos. Por lo tanto, también es posible que una de sus páginas tenga suficiente tráfico, pero ninguna de las páginas similares tenga suficiente tráfico, lo que también podría causar una diferencia en las puntuaciones. También hubo una actualización de los informes de la consola de búsqueda, que podría haber tenido un impacto.

¿Necesita recursos adicionales?

Tenemos mucho contenido excelente sobre este tema. Consulte nuestra página Core Web Vitals, donde reunimos una biblioteca de recursos de expertos, como podcasts, seminarios web y blogs. Puede encontrar todo lo que necesita para prepararse para la actualización del factor de clasificación de Experiencia de página de Google.