Barry Pollard, el defensor del desarrollador de rendimiento web de Google Chrome, explicó cómo encontrar las causas reales de un puntaje de pintura contento más bajo y cómo solucionarlas.
Pintura contentful más grande (LCP)
LCP es una métrica Core Web Vital que mide cuánto tiempo tarda el elemento de contenido más grande en exhibirse en un sitio Visitantes Viewport (la parte que un usuario ve en un navegador). Un elemento de contenido puede ser una imagen o texto.
Para LCP, los elementos de contenido más grandes son elementos HTML a nivel de bloque que ocupan el espacio más grande horizontalmente, como el párrafo
encabezados (H1 – H6) e imágenes (Básicamente, la mayoría de los elementos HTML que ocupan una gran cantidad de espacio horizontal).
1. Sepa qué datos está viendo
Barry Pollard escribió que un error común que cometen los editores y los SEO después de ver que PageSpeed Insights (PSI) marca una página para un puntaje de LCP pobre es depurar el problema en la herramienta del faro o a través de las herramientas de desarrollo de Chrome.
Pollard recomienda quedarse en PSI porque ofrece múltiples pistas para comprender los problemas que causan un bajo rendimiento de LCP.
Es importante comprender qué datos le está brindando PSI, particularmente los datos derivados del Informe de Experiencia del Usuario de Chrome (Crux), que provienen de puntajes de visitantes de Chrome anonimizados. Hay dos tipos:
- Datos de nivel de URL
- Datos a nivel de origen
Los puntajes de nivel URL son los de la página específica que se está depurando. Los datos a nivel de origen son puntajes agregados de todo el sitio web.
PSI mostrará datos de nivel de URL si ha habido suficiente tráfico medido a una URL. De lo contrario, mostrará datos a nivel de origen (la puntuación agregada en todo el sitio).
2. Revise la puntuación TTFB
Barry recomienda echar un vistazo a la puntuación TTFB (Time to First Byte) porque, en sus palabras, “TTFB es lo primero que le sucede a su página”.
Un byte es la unidad más pequeña de datos digitales para representar texto, números o multimedia. TTFB le dice cuánto tiempo le tomó un servidor responder con el primer byte, revelando si el tiempo de respuesta del servidor es una razón para el bajo rendimiento de LCP.
Él dice que enfocar los esfuerzos de optimización de una página web nunca solucionará un problema enraizado en una mala llaga de TTFB.
Barry Pollard escribe:
“Un TTFB lento básicamente significa 1 de 2 cosas:
1) Tarda demasiado tiempo para enviar una solicitud a su servidor
2) Su servidor tarda demasiado en responderPero lo cual es (¡y por qué!) Puede ser difícil de resolver y hay algunas razones posibles para cada una de esas categorías “.
Barry continuó su descripción general de depuración de LCP con pruebas específicas que se describen a continuación.
3. Compare TTFB con la prueba de laboratorio de Lighthouse
Pollard recomienda probar con las pruebas de laboratorio de Lighthouse, específicamente la auditoría del “tiempo de respuesta del servidor inicial”. El objetivo es verificar si el problema TTFB es repetible para eliminar la posibilidad de que los valores de PSI sean más rápidos de lo que la mayoría de los usuarios ven.
Los resultados del laboratorio son sintéticos, no se basan en visitas reales de los usuarios. Sintético significa que están simulados por un algoritmo basado en una visita provocada por una prueba de faro.
Las pruebas sintéticas son útiles porque son repetibles y permiten que un usuario aisle una causa específica de un problema.
Si la prueba de laboratorio de Lighthouse no replica el problema, eso significa que la prueba no ha visto los mismos problemas de TTFB que los usuarios han visto.
Él aconsejó:
“Una cosa clave aquí es verificar si el TTFB lento es repetible. Por lo tanto, desplácese hacia abajo y vea si la prueba de laboratorio del faro coincidía con este TTFB de usuario real lento cuando probara la página. Busque la auditoría del “Tiempo de respuesta del servidor inicial”.
En este caso, eso fue mucho más rápido, ¡eso es interesante! “
4. Consejo experto: cómo verificar si CDN está ocultando un problema
Barry dejó caer un excelente consejo sobre las redes de entrega de contenido (CDN), como CloudFlare. Un CDN mantendrá una copia de una página web en los centros de datos que acelerarán la entrega de las páginas web, pero también enmascarará cualquier problema subyacente a nivel de servidor.
El CDN no guarda una copia en cada centro de datos de todo el mundo. Cuando un usuario solicita una página web, el CDN obtendrá esa página web del servidor y luego hará una copia en ese servidor que esté más cerca de esos usuarios. De modo que esa primera búsqueda siempre es más lenta, pero si el servidor es lento para comenzar, entonces esa primera búsqueda será aún más lenta que entregar la página web directamente desde el servidor.
Barry sugiere los siguientes trucos para sortear el caché del CDN:
- Pruebe la página lenta agregando un parámetro de URL (como agregar “? Xyz” al final de la URL).
- Pruebe una página que no se solicite comúnmente.
También sugiere una herramienta que se puede usar para probar países específicos:
“También puede verificar si son particularmente los países que son lentos, particularmente si no está utilizando un CDN, con Crux y @Alekseykulikov.bsky.social, el treo es una de las mejores herramientas para hacerlo.
Puede ejecutar una prueba gratuita aquí: teo.sh/sitespeed y desplazarse hacia abajo hasta el mapa y cambiar a TTFB.
Si los países particulares tienen TTFBS lentos, verifique cuánto tráfico proviene de esos países. Por razones de privacidad, Crux no le muestra volúmenes de tráfico (aparte de si tiene suficiente tráfico para mostrar), por lo que deberá ver su análisis para esto “.
Con respecto a las conexiones lentas de áreas geográficas específicas, es útil comprender que el rendimiento lento en ciertos países en desarrollo podría deberse a la popularidad de los dispositivos móviles de gama baja. Y vale la pena repetir que Crux no revela exactamente de cuánto tráfico provienen los puntajes de cada país. Además, la mayoría de las herramientas no muestran ni siquiera esos datos limitados de país de quid.
5. Arregle lo que se puede repetir
Barry terminó su discusión al aconsejar que un problema solo se puede solucionar una vez que se verifica como repetible.
Él aconsejó:
“Para los problemas del servidor, ¿el servidor tiene poca potencia?
¿O el código es demasiado complejo/ineficiente?
¿O la base de datos que necesita ajuste?
Para conexiones lentas desde algunos lugares, ¿necesita un CDN?
O investigar por qué tanto tráfico de allí (¿Ad-Champaign?)
Si ninguno de esos se destaca, entonces podría deberse a redireccionamientos, particularmente a partir de anuncios. Pueden agregar ~ 0.5s a TTFB, ¡por redirección!
Intenta reducir las redirecciones tanto como sea posible:
– Use la URL final correcta para evitar la necesidad de redirigir a www o https.
– Evite múltiples servicios de acortador de url ”.
Relacionado: Core Web Vitals: una guía completa
Takeaways: cómo optimizar para la pintura contentful más grande
Barry Pollard de Google Chrome ofreció cinco consejos importantes.
1. Los datos de PageSpeed Insights (PSI) pueden ofrecer pistas para depurar problemas de LCP, además de otros matices discutidos en este artículo que ayudan a dar sentido a los datos.
2. Los datos de PSI TTFB (Tiempo para el primer byte) pueden señalar por qué una página tiene puntajes de LCP pobres.
3. Las pruebas de laboratorio de fallos son útiles para la depuración porque los resultados son repetibles. Los resultados repetibles son clave para identificar con precisión la fuente de problemas de LCP que luego permiten aplicar las soluciones correctas.
4. Los CDN pueden enmascarar la verdadera causa de los problemas de LCP. Use el truco de Barry descrito anteriormente para evitar el CDN y obtener una verdadera puntuación de laboratorio que pueda ser útil para la depuración.
5. Barry enumeró seis causas potenciales para puntajes de LCP pobres:
- Rendimiento del servidor
- redireccionamiento
- código
- base de datos
- Conexiones lentas específicas debido a la ubicación geográfica
- Conexiones lentas de áreas específicas que se deben a razones específicas como campañas publicitarias.
Lea la publicación de Barry en Bluesky:
Me he comunicado con algunas personas recientemente pidiendo ayuda con los problemas de LCP.
Imagen destacada de Shutterstock/BestforBest
(Tagstotranslate) Noticias
