Aspectos fundamentales de la Web para empresas empresariales: preguntas y respuestas con Kathy Brown y Karl Kleinschmidt

El 18 de febrero celebramos nuestro Sesión de Core Web Vitals for Enterprise Businesses para abordar la nueva actualización del factor de clasificación de la experiencia de página de Google. La sesión se centró en lo que 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 presentan 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 los 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 Field a través de BigQuery. Recuerde que los datos de laboratorio son para pruebas, los datos de campo son para clasificación. Basándonos en los comentarios de John Mueller, anticipamos que inicialmente, CWV solo afectará las clasificaciones móviles y que tendrá que estar «en verde» para que las tres métricas tengan una clasificación más alta.

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

Kathy: Si no hay datos de campo disponibles, esto probablemente significa que la página no recibe mucho tráfico. Utilice Page Speed Insights de Google para comprobar 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 de CrUX para ver si hay uno para su origen (su dominio). Puedes encontrar un preconstruido Plantilla de Google Data Studio y esto le proporcionará datos de rendimiento de su sitio en general.

Si aún no puede encontrar ningún dato de Field, determine los principales dispositivos y navegadores más comunes que acceden a su sitio y pruebe utilizando esos entornos. Recuerde configurar los controles de estrangulamiento 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 se prueba la velocidad de la página en esta situación?

Kathy: Una cantidad significativa de puntuación de Core Web Vital dependerá del cliente y del código que se esté ejecutando. Entonces, una puntuación CLS pobre no tiene nada que ver con un servidor lento. Sin embargo, LCP podría verse afectado por un servidor lento debido a los apretones de manos de conexión más lentos y al tiempo que se tarda en 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, así como 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 en 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 más fácilmente el rendimiento de LCP en su servidor de desarrollo.

¿Cree que la carga previa de enlaces (para las páginas siguientes) 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 será importante. El almacenamiento en caché de activos estáticos (que ayuda para las visitas y páginas posteriores) ayudará a sus puntuaciones de campo. La precarga de estilos CSS mediante el enlace, la precarga probablemente también ayudarán 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: Sin duda, es posible que si el LCP aparece más rápidamente para todos los usuarios (tanto nuevos como recurrentes), su puntuación de 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 de dispositivos móviles 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 de dispositivos móviles primero no debería marcar la diferencia.

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

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

Vemos cambios en la puntuación en Google Search Console sin que hagamos cambios / mejoras por 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 únicamente por lo que se informa en Search Console?

Karl: Fuera de los datos de campo frente a los de laboratorio, existen dos causas principales para la diferencia de 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 utiliza datos de página similares en información sobre la 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 informes de la consola de búsqueda, que podría haber tenido un impacto.

¿Necesitas recursos adicionales?

Tenemos mucho contenido excelente sobre este tema. Echa un vistazo a nuestro Página de Core Web Vitals donde hemos reunido una biblioteca de recursos 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 Page Experience de Google.