Para hacer nuestro contenido accesible a más usuarios, hemos traducido este artículo del inglés al español mediante traducción automática. Haz clic aquí para leer el artículo original. Si detectas algún problema en el contenido, no dudes en escribirnos a report-osteam@semrush.com.
Como la última fase del despliegue tuvo lugar en agosto de 2021, la actualización de Core Web Vitals ya está aquí. Esto significa que ya podemos pasar de las evaluaciones preliminares e identificar algunas pautas comunes.
Nuestro amplio estudio Core Web Vitals abarca las siguientes áreas:
- Tomando datos históricos, revisamos cómo estaban de preparados para las actualizaciones tanto los sitios web para móviles como los de escritorio, y qué métricas de Core Web Vitals (Mayor Pintura de Contenido, Tiempo Total de Bloqueo* y Desplazamiento de Diseño Acumulado) presentaban mejores valores.
- También hemos conseguido destacar los factores más cruciales que afectan al rendimiento de las páginas en relación con las tres métricas.
- Utilizando información de nuestra herramienta de Auditoría del Sitio, hemos examinado los valores medios de LCP, TBT y CLS y hemos identificado los problemas más frecuentes en cada métrica.
Armado con estos conocimientos, puedes estar mejor equipado para optimizar tus páginas para que cumplan al máximo la CWV y garantizar así la máxima facilidad de uso y una mejor clasificación.
*Nota: en la Auditoría de Sitios, utilizamos la métrica Tiempo Total de Bloqueo (TBT) en lugar de la métrica Retraso en la Primera Entrada (FID), ya que esta última implica tener acceso a datos de usuarios reales. El propio Google declaró que estas dos métricas se correlacionan entre sí y que ambas pueden utilizarse para evaluar los problemas de interactividad.
Metodología del estudio
Nuestro estudio se divide en varias partes:
- La evaluación de los cambios para el cumplimiento del VTC antes y después de la actualización.
- Un vistazo a los factores que influyen en que un sitio supere los umbrales de cada métrica.
- Una auditoría CWV completa de los sitios web analizados para explorar los problemas más y menos frecuentes de cada métrica.
La primera parte del estudio se basa en el análisis de 1,7 millones de URL de ordenadores de sobremesa y 324.000 URL de móviles. Hemos comparado los valores anteriores a la actualización de junio de 2021 de las métricas LCP, TBT y CLS con las estadísticas de septiembre de 2021, cuando se completó la actualización.
Para hacer la comparación, comprobamos cuántas páginas estaban dentro de los tres rangos de categorías - "buena", "mala", "a mejorar"- para cada métrica antes y después de la actualización.
| Bien | Necesita mejorar | Pobre | |
| LCP | ≤ 2.5s | ≤ 4s | > 4s |
| TBT | < 300 ms | ≥ 300ms ≤ 600ms | > 600 ms |
| CLS | ≤ 0,1 | ≤ 0.25 | > 0.25 |
También mencionamos las puntuaciones "Cualquier TBT" y "Cualquier CLS". Simplemente reflejan el promedio de las métricas de todas las URL, sin tener en cuenta su rendimiento TBT o CLS.
Para identificar los factores que afectan a cada métrica y ver qué errores aparecen con más frecuencia que otros, tomamos la auditoría de Site Audit de septiembre de 2021 de 4M de URL de escritorio y 1,7M de URL móviles. En total, la herramienta pasó estas páginas por 23 comprobaciones diferentes específicas de CWV.** lo que nos permitió revelar las auditorías más difíciles y las más fáciles de pasar.
Todo el estudio se basa en datos de laboratorio.
**Nota: Puedes encontrar una lista de todas las comprobaciones, sus definiciones y un desglose completo de la auditoría para móvil y escritorio al final del post.
Conclusiones del estudio Core Web Vitals para móviles & Desktop
Cuántas URL aumentaron sus puntuaciones en LCP, TBT y CLS
Los gráficos siguientes muestran cuántas páginas -móviles y de escritorio- superaron realmente los umbrales buenos para las tres métricas CWV (combinadas e individuales) en junio de 2021 frente a septiembre de 2021.
Antes de la actualización, sólo el 34,5% de las páginas de escritorio alcanzaban los umbrales requeridos para las tres métricas. Tras la actualización, el número de URL de escritorio con todas las puntuaciones "buenas" para LCP, TBT y CLS aumentó en 7 puntos porcentuales.
Las URL para móviles muestran un panorama más sombrío, con menos del 4% de las páginas para móviles que superan los umbrales "buenos" en las tres métricas. En junio de 2021, esta cifra era casi tres veces mayor, lo que implicaba que las páginas móviles estaban menos preparadas para las actualizaciones que sus homólogas de escritorio.
Evaluación de los Cambios Positivos de las Métricas CWV Antes y Después de la Actualización
Sin embargo, la métrica CWV tiene más capas que una mera puntuación "buena". LCP, TBT y CLS pueden clasificarse en tres categorías: "Bueno", "A mejorar" y "Deficiente".
Para analizar los cambios posteriores a la actualización a un nivel más granular, comprobamos todas las mejoras que se produjeron en las tres métricas, explorando cuántas URL obtuvieron algunas victorias, moviendo sus puntuaciones LCP, TBT y CLS de una categoría a otra.
En cuanto a los cambios positivos en las puntuaciones anteriores y posteriores a la actualización, observamos las siguientes tendencias:
URL móviles
| TOTAL (cualquier cambio de mejora entre umbrales) | Para mejorar -> Bien | Pobre -> Bueno | Pobre -> A mejorar | |
| porcentaje de URL que mejoraron (las 3 métricas) | 0,1% | 0.01% | 0.07% | 0.02% |
| porcentaje de URL que mejoraron (sólo TBT) | 14% | 5% | 3% | 6% |
| porcentaje de URL que mejoraron (sólo CLS) | 19% | 8% | 7% | 4% |
| porcentaje de URL que mejoraron (sólo LCP) | 7% | 1% | 1% | 5% |
| porcentaje de URL que mejoraron (al menos 1 métrica) | 38% | 14% | 10% | 14% |
URL de escritorio
| TOTAL (cualquier cambio de mejora entre umbrales) | A mejorar → Bien | Mal → Bien | Pobre → A mejorar | |
| porcentaje de URL que mejoraron (las 3 métricas) | 0.09% | 0.05% | 0.03% | 0.01% |
| porcentaje de URL que mejoraron (sólo TBT) | 7% | 4% | 1% | 1% |
| porcentaje de URL que mejoraron (sólo CLS) | 21% | 9% | 7% | 5% |
| porcentaje de URL que mejoraron (sólo LCP) | 14% | 9% | 2% | 4% |
| porcentaje de URL que mejoraron (al menos 1 métrica) | 39% | 21% | 10% | 9% |
- Vimos un número muy bajo -hasta un 0,1%- de páginas que mejoraron todas las puntuaciones en general. Sin embargo, un tercio de todas las páginas mejoraron su puntuación en al menos una métrica. Esto es cierto tanto para las URL de móvil como para las de escritorio.
- En el móvil, el cambio de categoría más popular para las tres métricas fue del rango "deficiente" al de "a mejorar". Las URL de escritorio muestran tendencias más positivas, ya que la mayoría de las puntuaciones LCP, TBT y CLS de las URL pasaron de la categoría "a mejorar" a "buena".
- En móvil, el salto de "pobre" a "bueno" parece casi misión imposible, con una sola excepción. CLS parece tener directamente el umbral más fácil para pasar de "deficiente" a "bueno", y más páginas mejoraron significativamente su puntuación en CLS.
Recopilamos nuestros datos después de que Google redujera el umbral CLS, por lo que la aparente facilidad está probablemente relacionada con este cambio.
- Las páginas para móviles son las que experimentan los cambios menos positivos en lo que se refiere al LCP, mientras que para las URL de escritorio, el TBT parece causar los mayores problemas, mostrando la tendencia de cambio positivo más baja -un 6,7%-.
Factores que influyen en las puntuaciones LCP, TBT y CLS
Analizando con más detalle los elementos de cada métrica, conseguimos identificar los factores que afectan a esas puntuaciones.
¿Cuáles son las causas de las malas puntuaciones en el PCL?
Como LCP mide el tiempo de carga del mayor elemento de la página -imagen o bloque de texto- dentro de la ventana gráfica del usuario, todo lo que se extienda más allá de la pantalla no cuenta.
Por lo tanto, nos fijamos en cuáles de los siguientes elementos están presentes/ausentes en las páginas analizadas:
- <img> las etiquetas son imágenes, imágenes de póster de vídeo, imágenes de fondo, etc;
- <Las etiquetas div> / <sección> implican cualquier elemento (contenedor) de la página;
- <p> etiqueta es un párrafo (texto);
- <span> la etiqueta suele apuntar a algún tipo de elemento de texto; y
- <Las etiquetas h1> / <h2> / <h3> se utilizan para indicar varios encabezados y subencabezados de página.
Nuestro análisis demostró que las etiquetas <img> y <div> son los elementos más comunes que provocan lentitud en el LCP.
Sin embargo, si miramos más de cerca, veremos más diferencias entre los elementos de la etiqueta móvil-escritorio que afectan a las puntuaciones LCP.
- <Las etiquetas img> y <div> son sobre todo un problema para las URL móviles que están dentro de un rango LCP "pobre". Las páginas móviles que tienen LCP dentro del rango "bueno" y "a mejorar" se ven afectadas sobre todo por las etiquetas <p> y <img> .
- Los H1 empiezan a ser un problema en móvil, probablemente porque los h1 son uno de los elementos más grandes en viewport cuando tratamos con pantallas más pequeñas.
Esto significa que hay una diferencia entre lo que se considera el elemento más grande en el móvil y en el escritorio.
Puedes utilizar la herramienta Auditoría del sitio para saber qué elemento específico de la página se considera el elemento de mayor contenido dentro de la ventana gráfica en tu caso concreto.
Qué afecta a las puntuaciones TBT
Como el TBT mide la rapidez con la que los usuarios pueden empezar a interactuar con los elementos de la página, tuvimos que fijarnos en las tareas largas.
Como las tareas largas forman parte de un código JavaScript que congela la interfaz de usuario, para obtener una "buena" puntuación en el TBT, tienes que mantener el TBT general por debajo de 300 ms.
Aunque puedes tener tantas tareas largas como quieras (siempre que no superen el umbral de 300 ms), sigue siendo interesante ver que tanto las páginas móviles como las de escritorio que tienen una "buena" puntuación TBT presentan el menor número de tareas largas:
De media, una página de escritorio con una puntuación TBT "mala" tiene 6 veces más tareas largas en comparación con las que se encuentran dentro del rango "bueno". En móvil, esta diferencia es más modesta: se triplica.
Qué afecta a las puntuaciones CLS
La métrica CLS, que mide la estabilidad visual de la página, depende en gran medida de los desplazamientos de diseño que aparecen siempre que hay un cambio de posición de un elemento visible de un fotograma renderizado al siguiente.
Al igual que con la TBT, los cambios de disposición tienen que ver más con el alcance que con el número de esos cambios. Y si no vimos pruebas directas de ello con el TBT, nuestro análisis CLS lo hace evidente:
No vemos una gran diferencia en el número de cambios de maquetación entre páginas con distintas puntuaciones CLS, lo que significa que puedes permitirte tener bastantes cambios siempre que cumplan los umbrales.
Los problemas más comunes de la Web Vitals y cómo solucionarlos
Aunque hemos señalado los principales factores que afectan a las puntuaciones CWV de las páginas, eso no significa que puedan considerarse los problemas más acuciantes para los propietarios de sitios web.
Aquí es donde entra en juego el informe Core Web Vitals de Site Audit, que ayuda a identificar las comprobaciones más difíciles de superar.
La herramienta Auditoría del sitio hace pasar cualquier página por 23 comprobaciones distintas en las que tomamos en consideración la lógica de Pagespeed Insights:
- Si la comprobación supera la marca de 90, la página pasa a la zona verde, y consideramos que esta auditoría está superada;
- La marca 50-89 hace que la página entre en la zona amarilla; y
- Si el valor es inferior a 49, la página pasa a la zona roja para un control determinado.
A vista de pájaro, podemos ver que las páginas para móviles se enfrentan a un número mucho mayor de problemas con la CWV. Las URL de escritorio parecen estar haciendo un buen trabajo al pasar las comprobaciones de CWV, con la mayoría -el 68%- de las comprobaciones en el punto verde.
A diferencia del escritorio, donde las páginas superaron la mayoría de las comprobaciones, en el móvil, sólo el 34% de las comprobaciones son verdes. Un preocupante 65% de todas las auditorías son amarillas o rojas, lo que significa que las páginas móviles no cumplen los requisitos del CWV para estas comprobaciones.
Echemos un vistazo más matizado a todas las comprobaciones y veamos cuáles son las tres más fáciles y las más difíciles de superar, tanto para las páginas móviles como para las de escritorio.
La parte superior tiene casi el mismo aspecto, ya se trate de URL para ordenadores de sobremesa o para móviles:
- Los elementos de imagen que no tienen anchura y altura explícitas parecen ser el mayor problema tanto en las páginas para móviles como en las de escritorio.
- Los módulos duplicados en paquetes de JavaScript, las redirecciones a varias páginas y el uso de formatos de vídeo para contenidos animados eficaces suelen aprobarse sin apenas problemas.
- Sin embargo, cuando se trata de eliminar recursos que bloquean la renderización, la diferencia es sorprendente: los USL de escritorio casi pasan esta comprobación, mientras que los móviles apenas llegan a la zona amarilla.
La Auditoría del Sitio no sólo detecta problemas en todas las métricas, sino que también los separa en problemas relacionados con LCP, CLS y OTC.
Asegúrate de repasar el desglose métrica a métrica de los problemas más comunes de tus páginas concretas, ya que la Auditoría del Sitio realmente da forma al problema de manera que incluya la solución.
Resumen
Con la actualización de Core Web Vitals ya aquí, no te queda más remedio que mejorar tu puntuación en las tres métricas (CLS, LCP y TBT) para demostrar a Google que tus páginas ofrecen la máxima facilidad de uso y merecen esas clasificaciones.
Esperamos que nuestro estudio, que abarcó mucho terreno y reveló ideas clave, proporcione una orientación clara para apoyar aún más tus esfuerzos de optimización.
Aunque te sugerimos que vuelvas a echar un vistazo a todos los descubrimientos, hay algunas cosas que deberías extraer de este estudio:
- La web aún no está totalmente preparada para el CWV.
Sólo un tercio de las URL de escritorio y un 3% de las de móvil superan los umbrales de las tres métricas CWV.
Desde la actualización, sólo hemos observado mejoras generalizadas en alrededor del 1% de las páginas. Y sólo menos del 40% obtuvo mejores puntuaciones en al menos una métrica.
Esto significa que lo más probable es que tengas mucho espacio para mejorar, y, si se hace bien y pronto, tus esfuerzos de optimización de la página pueden dar a tus páginas una ventaja competitiva.
- Presta especial atención a tus páginas para móviles.
La mayoría de las comprobaciones para ordenadores de sobremesa son verdes (es decir, aprobadas), mientras que para móviles, vemos sobre todo amarillas y rojas. Esto significa que es más fácil pasar las auditorías en el ordenador de sobremesa que en el móvil, y que las páginas móviles se enfrentan de media a más problemas que las de sobremesa.
Lo más probable es que esto se deba a los umbrales móviles y al hecho de que los datos del laboratorio se simulan en un dispositivo 3G.
- Trabaja en tus puntuaciones LCP (para móvil) y TBT (para escritorio).
Con CLS como métrica menos "problemática", tienes que trabajar para mejorar tus puntuaciones en LCP y TBT:
- Es más probable que las mejoras del CLS te den un salto rápido de la franja de puntuación "mala" a "buena".
- Realiza una auditoría de tus etiquetas <img>, <div>, <p>, y <h1> para asegurarte de que no están reduciendo tu puntuación LCP. Utiliza la herramienta Auditoría del Sitio para localizar los elementos de la página que están causando la lentitud.
- Mantén tu tiempo total de bloqueo por debajo de 300 ms para asegurar una "buena" puntuación TBT. Una vez más, la herramienta Auditoría del Sitio te ayudará a determinar qué tareas largas están obstaculizando más tu puntuación general de TBT.
- Vigila la extensión de tus desplazamientos de trazado y deshazte de los que ocupen demasiado espacio del umbral CLS. La Auditoría de obras refleja la contribución al CLS de cada uno de los turnos de trazado más grandes.
-
Ten cuidado con la altura y anchura de los elementos de la imagen y otros problemas comunes de CWV.
Echa un segundo vistazo a las auditorías más difíciles de aprobar. La mayoría de los problemas -tanto en las URL para móviles como para ordenadores de sobremesa- se producen con el tamaño de las imágenes. Como se trata de una comprobación relacionada con el CLS que tiene una solución bastante rápida, puedes utilizarla como una victoria rápida para mejorar tu puntuación en el CLS.
- Mantén unas expectativas razonables.
Para los ordenadores de sobremesa, el cambio más habitual es pasar del rango "a mejorar" a "bueno". Pero la mayoría de las URL móviles saltan de la categoría "deficiente" a "a mejorar", con la única excepción de CLS. Así que no esperes pasar rápidamente de todas las puntuaciones "malas" a todas las puntuaciones "buenas" en todas y cada una de las métricas del VCC, y estate atento a cualquier cambio en los umbrales.
Bonus: Una lista completa de los problemas más comunes del CWV para las URL de móviles y ordenadores de sobremesa
Si tienes curiosidad por explorar la lista completa de todas las comprobaciones de la Auditoría de Sitios y ver las puntuaciones medias de las páginas para móviles y ordenadores de sobremesa, desplázate a la tabla siguiente y obtén la imagen completa.
Puntuación media de las auditorías
| Auditoría | Puntuación media (escritorio) | Puntuación media (móvil) |
| Eliminar módulos duplicados en paquetes JavaScript | 100% | 100% |
| Evita redireccionar varias páginas | 100% | 100% |
| Utiliza formatos de vídeo para contenidos animados | 100% | 99% |
| Reducir CSS | 100% | 98% |
| Evita servir JavaScript heredado a los navegadores modernos | 99% | 97% |
| Reduce el impacto del código de terceros | 99% | 72% |
| Reduce el tiempo de ejecución de JavaScript | 99% | 88% |
| Minificar JavaScript | 99% | 96% |
| Minimizar el trabajo del hilo principal | 99% | 74% |
| Preconecta los orígenes necesarios | 94% | 86% |
| Activar la compresión de texto | 93% | 88% |
| Eliminar CSS no utilizado | 92% | 72% |
| Evita enormes cargas de red | 92% | 92% |
| Evita un tamaño excesivo del DOM | 91% | 91% |
| Eliminar JavaScript no utilizado | 85% | 55% |
| Reducir los tiempos de respuesta del servidor (TTFB) | 82% | 82% |
| Eliminar los recursos que bloquean la renderización | 76% | 57% |
| Garantizar que el texto permanezca visible durante la carga de la fuente web | 33% | 36% |
| Los elementos de imagen no tienen anchura y altura explícitas | 24% | 29% |
Para tu comodidad, añadimos las notas de Google en cada comprobación de auditoría:
- Reduce el tiempo de ejecución de JavaScript: Cuando tu JavaScript tarda mucho en ejecutarse, ralentiza el rendimiento de tu página de varias formas, como el coste de red, el coste de análisis sintáctico y compilación, el coste de ejecución o el coste de memoria;
- Evita un tamaño excesivo del DOM: Un árbol DOM grande puede ralentizar el rendimiento de tu página de múltiples formas, como la eficiencia de la red y el rendimiento de la carga, el rendimiento en tiempo de ejecución y el rendimiento de la memoria;
- Eliminar módulos duplicados en paquetes JavaScript: Los paquetes de JavaScript de la mayoría de las páginas web suelen construirse importando código de bibliotecas, dependencias y paquetes populares. A menudo, esto puede hacer que tu página herede módulos duplicados de múltiples fuentes;
- Utiliza formatos de vídeo para los contenidos animados: Los GIF grandes son ineficaces para transmitir contenido animado, por lo que es mejor utilizar formatos de vídeo
- Asegúrate de que el texto permanece visible durante la carga de la fuente web: Las fuentes suelen ser archivos grandes que tardan en cargarse. Algunos navegadores ocultan el texto hasta que se carga la fuente, provocando un destello de texto invisible;
- Evita servir JavaScript heredado a los navegadores modernos: Evita servir código JavaScript heredado (es decir, el estándar ES5) a los navegadores modernos para evitar que los usuarios descarguen archivos JavaScript innecesariamente grandes;
- Minimiza el trabajo del hilo principal: El proceso de renderizado del navegador es lo que convierte tu código en una página web con la que tus usuarios pueden interactuar. Por defecto, el hilo principal del proceso de renderizado suele manejar la mayor parte del código: analiza el HTML y construye el DOM, analiza el CSS y aplica los estilos especificados, y analiza, evalúa y ejecuta el JavaScript;
- Evita redireccionar varias páginas: Los redireccionamientos ralentizan la velocidad de carga de tu página;
- Elimina los recursos que bloquean la renderización: La sección Oportunidades de tu informe Lighthouse enumera todas las URL que bloquean la primera pintura de tu página. El objetivo es reducir el impacto de estas URL que bloquean la renderización, alineando los recursos críticos, aplazando los recursos no críticos y eliminando todo lo que no se utilice;
- Reduce los tiempos de respuesta del servidor: La sección Oportunidades de tu informe Lighthouse informa del Tiempo hasta el primer byte, el tiempo que tarda el navegador de un usuario en recibir el primer byte del contenido de la página;
- Carga perezosa recursos de terceros con fachadas: Los recursos de terceros se utilizan a menudo para mostrar anuncios o vídeos e integrarse con las redes sociales. El enfoque por defecto es cargar los recursos de terceros en cuanto se carga la página, pero esto puede ralentizar innecesariamente la carga de la página. Si el contenido de terceros no es crítico, este coste de rendimiento puede reducirse cargándolo perezosamente;
- Reduce el impacto del código de terceros: Para añadir una red publicitaria, un botón de redes sociales, una prueba A/B o un servicio de análisis a tu página, normalmente necesitas añadir un script de terceros a tu HTML. Estos scripts de terceros pueden afectar significativamente al rendimiento de carga de tu página;
- Evita las cargas útiles de red enormes: Las grandes cargas de red están altamente correlacionadas con largos tiempos de carga. También cuestan dinero a los usuarios; por ejemplo, los usuarios pueden tener que pagar por más datos móviles. Por tanto, reducir el tamaño total de las peticiones de red de tu página es bueno para la experiencia de tus usuarios en tu sitio y para sus carteras;
- Minificar CSS: La sección Oportunidades de tu informe Lighthouse enumera todos los archivos CSS sin minificar, junto con el ahorro potencial en kibibytes (KiB) cuando estos archivos se minifican;
- Minificar JavaScript: Minificar los archivos JavaScript puede reducir el tamaño de la carga útil y el tiempo de análisis de los scripts;
- Imágenes sin tamaño: La imagen se ve bien, pero está malgastando los datos de los usuarios y perjudicando el rendimiento de la página;
- Elimina las reglas CSS no utilizadas: La sección Oportunidades de tu informe Lighthouse enumera todas las hojas de estilo con CSS no utilizado con un ahorro potencial de 2 KiB o más. Elimina el CSS no utilizado para reducir los bytes innecesarios consumidos por la actividad de la red;
- Elimina el JavaScript no utilizado: El JavaScript no utilizado puede ralentizar la velocidad de carga de tu página;
- Preconectar a orígenes requeridos.: La sección Oportunidades de tu informe Lighthouse enumera todas las solicitudes clave que aún no tienen prioridad a las solicitudes fetch con <link rel=preconnect>;
- Activa la compresión de texto: Los recursos basados en texto deben servirse con compresión para minimizar el total de bytes de red.