By Bruchentko
Todos sabemos que a los motores de búsqueda le interesa tanto generar ingresos como brindar excelentes experiencias a los usuarios. Para lograr esto último, una de las claves es optimizar la velocidad de carga de las páginas web gracias al Google Core Web Vitals. Es en este contexto donde surge CWV (Core Web Vitals), un conjunto de métricas diseñadas como un «checker» para identificar y corregir pequeñas fallas en el rendimiento del sitio.
El Core Web Vitals se encarga de optimizar el tiempo de carga, para hacerlo se necesita rastrear y cachear los recursos ineficientes. Luego iremos viendo cómo, pero el CWV se vale de tres métricas principales. Optimizarlas ayudarán con nuestro posicionamiento SEO y mejorarán la experiencia del usuario.
Desde el punto de vista del usuario, una buena experiencia con un sitio consiste en encontrar lo qué busca. Ya sea, hallar las respuestas a las preguntas, encontrar un contenido puntual, o simplemente reírse un rato. Y para ello se requiera también, una buena velocidad y estabilidad en los sitios.
Hoy vamos a hablar de eso, de la estabilidad emocional de la velocidad de los sitios web mediante un buen Core Web Vitals. ¿Vamos?, ¡Vamos!.
¿Qué es el Core Web Vitals?
El Core Web Vitals es una métrica «compuesta de más métricas ¡yay!» creadas por una iniciativa Google, con el objetivo de ganar más dinero mejorar la experiencia del usuario.
Google sabe qué es complejo optimizar los tiempos de carga. Pues, hay gran variedad de factores y métricas diversas qué miden el impacto desde qué se abre una página, hasta qué está completamente cargada. El Google Core Web Vitals llega para eso, para normalizar y unificar las métricas.
Estas métricas se centran en distintas etapas del período de carga, dándonos señales de rendimiento, y algunas ideas de cómo mejorar.
Las tres métricas son:
- Largest Contentful Paint «LCP»: Es el tiempo qué tarda la página en carga. Pero también antes de qué cargue el LCP debe cargar el First Contentful Paint «FCP».
- First Input Delay «FID»: Tiempo hasta la primera interacción y ayuda con la interactividad del sitio. A esta métrica también se la asocia con el Total Blocking Time «TBT».
- Cumulative Layout Shift «CLS»: Permite la estabilidad visual del contenido a medida qué carga la página.
Recuerdo cuando el propio Google anunció el desarrollo de estas métricas, con cuyo fin de dar una mano a los desarrolladores de sitios web. El punto era qué querían unificar criterios, y establecer un estándar.
Sobre las métricas del Core Web Vitals
Para medir el Core Web Vitals «Web Vitals para los amigos de GTmetrix», debemos contar con tres métricas principales. Pues, estas métricas agrupan a su vez distintos factores relevantes que permiten la carga de un sitio.
Estas métricas son el LCP, el TBT «o FID», y el CLS.
Ahora veremos de qué va cada una:
1. Largest Contentful Paint «LCP» en el Core Web Vitals
El Largest Contentful Paint es una métrica qué mide la velocidad en la que carga completamente el contenido del sitio para el usuario.
Está métrica vino a reemplazar otros indicadores relevantes «qué también se siguen usando», cómo:
- First Meaningful Paint «FMP»: Mide el tiempo de renderizado de la página principal, pero no se usa tanto porque es muy inexacto. También es llamado First Paint.
- First Contentful Paint «FCP»: Mide únicamente la carga de la primera página de contenido.
Pero, volviendo al LCP, este mide la velocidad de carga en función de tiempo renderizado. El punto más relevante es qué no finaliza la carga del LCP hasta qué, justamente, el elemento más grande «imagen, video, o texto» se renderiza. Pues, este último elemento se asume cómo el principal del sitio, de ahí el nombre Largest Contentful Paint.
Pero, no menos cierto, es qué hay factores qué aumentan o reducen el tiempo de carga del LCP: cómo el tiempo del propio servidor; el CSS; el JavaScript; entre otros. Por eso tener el mejor servidor no hace resultado a la velocidad final, pues, son varios los factores a tener en cuenta.
En la imagen vemos cómo va cargando el sitio en modo cascada. De allí podemos deducir por qué también le dicen cómo «La mejor impresión de contenido«.
También vale aclarar qué los elementos qué están fuera de la pantalla o que requieran interacción por parte del usuario, no modifican el LCP. Incluso sí este elemento es el más pesado. Pues, el LCP mide «lo que está en pantalla«.
¿Cuál es un buen tiempo para el Largest Contentful Paint?
- Buen tiempo: LCP menor a 2,5 segundos.
- Ok, pero mejorable: LCP de entre 2,5 y 4,0 segundos. Con mejoras simples probablemente podrás mejorar esta métrica.
- Malo: LCP de más de 4,0 segundos. Es mala señal este valor, deberías hacer algo al respecto porque perderás visitas.
¿Cómo puedo medir el Largest Contentful Paint de una URL?
Hay diversas herramientas para ver el Largest Contentful Paint, pero una de ellas es la qué utilicé para las imágenes arriba. ¡Sí!, se trata de GTmetrix. Más adelante en el post lo veremos con un poco más de detalle de cómo medir esto.
¿Qué factores influyen en la carga del Largest Contentful Paint?
Hay muchos factores que influyen en el tiempo de carga del LCP. Algunos de ellos son:
- TTFT: El Time-to-First-Byte (TTFB) depende principalmente de la respuesta del servidor y de la consulta en la base de datos.
- API’s: Algunas APIs pueden tardar en resolverse, y generan una demora en los tiempos de carga.
- Mucho código: El CSS es muy lindo, pero pesado, un exceso de CSS ralentiza la carga del sitio. Lo mismo sucede con el JavaScript.
- Recursos no optimizados: Los recursos no optimizados van a influir directamente en el LCP, pues, generalmente resultan ser el recurso más pesado.
2. First Input Delay o Total Blocking Time en el Core Web Vitals
Cómo segunda métrica, generalmente se utiliza el FID «First Input Delay» o el TBT «Total Blocking Time». Los más clásicos y puristas prefieren hablar de FID «First input Delay», en cambio, los más actuales hablan de TBD. Pero da igual, es más o menos lo mismo.
El TBT es una métrica introducida en 2020 qué cuantifica la capacidad de respuesta de carga luego de que el usuario ingrese en dicha URL. Es decir, la cantidad de tiempo qué bloquea el sitio.
En la imagen anterior se muestra una página que realiza solicitudes de red para recursos (CSS y JavaScript) y, luego que se terminan de descargar esos recursos, se procesan en el subproceso principal. El resultado son periodos en los que el subproceso principal momentáneamente está ocupado, lo que se indica mediante los bloques de tareas de color beige.
En cambio, el First Input Delay mide la velocidad de respuesta de la primera interacción del usuario con la página. Esta puede ser un clic o un JavaScript activándose.
Por eso los primeros dicen qué debería medirse por capacidad del sitio independientemente de la respuesta del usuario; y los FID believers creen qué es mejor también tener en cuenta la respuesta del usuario.
Da igual cuál de las dos métricas prefieras, total ambas miden el tiempo de interacción. Pero lo importante es poder combinarlas con el LCP para mejorar el rendimiento del sitio.
¿Cuál es un buen tiempo de FID o TBT?
Lo ideal sería que no haya ningún retardo en el tiempo de interacción, ni en pruebas de campo, ni en laboratorio.
Los retrasos en la primera entrada suelen ocurrir entre el First Contentful Paint (FCP) y el Time to Interactive (TTI). Esto se debe a que la página ha cargado parte de su contenido pero aún no es completamente interactiva. Si un usuario intenta interactuar en este período, experimentará demoras antes de que la página responda.
First Input Delay
Esta métrica indica cuanto tiempo tarda en reaccionar la página web cuando el usuario interactúa con algún elemento.
Lo podemos medir con la herramienta de PageSpeed y los tiempos ideales son:
- Buen tiempo: TBT menos de 0,1 segundos.
- Ok, pero mejorable: TBT de entre 0,1 y 0,3 segundos.
- Malo: TBT de más de 0,3 segundos.
En la métrica mala, lo más probable es qué el usuario abandone el sitio. En el valor Ok, un usuario fiel puede quedarse porque quiere ese contenido, pero un desconocido probablemente abandone el sitio.
En la imagen vemos un ejemplo en la que un usuario intenta interactuar con la página entre FCP y TTI, experimentando demoras. Esto es especialmente cierto si la interacción ocurre justo antes de una tarea larga, ya que el navegador debe completar la tarea antes de responder. Este tiempo de espera se conoce como el valor de FID para ese usuario en esa página.
Un retardo en el FID puede darse principalmente por problemas de ejecución del JavaScript, por lo que habría que analizar al código en detalle. Particularmente se da mucho cuando tenés activados los anuncios.
Total Blocking Time
En cambio, el TBT mide el tiempo total en el que el sitio está bloqueado, evitando la interacción por parte del usuario.
Buen tiempo: TBT menor a 0,15 segundos.
OK, Pero mejorable: Un TBT entre 0,15 y 0,25 segundos es aceptable, pero mejorable.
Malo, pero funcional: TBT entre 0,25 y 0,35 segundos.
Malo e inaceptable: TBT de más de 0,35 segundos.
3. Cumulative Layout Shift «CLS» en el Core Web Vitals
El Cumulative Layout Shift o simplemente CLS, que en español significa cambio de diseño acumulativo. Esta es una métrica qué se encarga de medir la frecuencia y relevancia de los cambios inesperados en un sitio web.
— Pero, ¿de qué cambios hablamos?. Estos cambios son elementos que inesperadamente se posicionan en otro lugar qué no debían. Sucede cuando, por ejemplo, querés hacer clic en una parte del sitio; pero justo se ejecuta un Script, qué hace que tu sitio se desplace, provocando un clic en otro lado.
Ese desplazamiento del sitio es altamente molesto, y de hecho puede generar problemas en la UX.
Normalmente, ocurre en sitios con carga diferida «Lazy Loading», o que tienen alguna dinámica de contexto qué modifique la organización del sitio. Ocurre muchísimo con páginas qué están llenas de anuncios, cómo sucede con Marca.com.
Este sitio además de tener anuncios qué te movilizan todo el sitio, además son lentos porque las imágenes son muy pesadas, penalizando más el CLS.
¿Cuál es un buen tiempo de Cumulative Layout Shift?
Medir el CLS es distinto al resto de las demás métricas. Pues, en los otros dos apartados se analizaban tiempos de carga, pero en el CLS se analiza el desplazamiento.
Este desplazamiento se mide cómo resultado de la fracción de impacto que se mueve. Es decir, el porcentaje del contenido original qué cambia de posición, y en qué valor porcentual lo hace.
- Ideal: 0% de desplazamiento, qué es lo mismo a un valor de 0.
- Aceptable: Entre 1% y 10%, es decir, valores menores a 0,1.
- Debe mejorar: Valores entre 10% y 25% de desplazamiento, o sea 0,1 y 0,25.
- Mal: Más de 25%, es decir, valores por encima del 0,25.
El Cumulative Layout Shift tiene cómo objetivo poner límite a la carga de elementos que modifican la visualización a medida qué se van cargando. Sin embargo, esto puede generar problemas de inestabilidad.
En el ejemplo de arriba vemos cómo un video salvaje aparece, y desplaza el contenido hacia abajo. Ese porcentaje de desplazamiento es el CLS.
Eso es malo para la experiencia del usuario, por lo tanto, también es malo para el posicionamiento SEO. Pues, en la primera imagen está todo correctamente ordenado, hasta qué aparece dicho video para crear caos, y en consecuencia, perdida de visitas.
Otras métricas complementarias al Core Web Vitals
Estas tres no son las únicas métricas que te ayudan a medir la experiencia que ofrece una determinada página. El Google Core Web Vitals se une a otros factores con el fin de evaluar la calidad de un sitio web.
Algunas de ellas son:
- Mobile Friendly «compatibilidad con dispositivos móviles».
- Safe Browsing «Navegación segura».
- HTTPS «Uso de protocolo de seguridad HTTPS».
- No Intrusive Interstitials «Ventanas emergentes».
Estas métricas se unen junta a otros tantos factores SEO, permitiendo un buen posicionamiento SEO.
— ¿Y el AMP?. Bueno, las Accelerated Mobile Pages están siendo discontinuadas. Pues, ya no es relevante tener una versión más liviana para compensar la falta potencia de los dispositivos móviles.
Implementación del Core Web Vitals
Por allá, por el 2020, Google comenzó a implementar los cambios en el Core Web Vitals. Alegando qué a partir de junio de 2021 el algoritmo tomará en cuenta la relevancia de un correcto CWV, por sobre otras métricas.
En el gráfico se puede ver cómo ponderan los diferentes parámetros. Siendo el TBT y el LCP los más relevantes, por eso, potenciar estas métricas es lo más relevante.
Mantener actualizado te dará una ventaja competitiva por sobre el resto. Hacé esto para mantenerte en las mejores posiciones de las SERP.
Core Web Vitals y el SEO: Optimización para Google y Experiencia del Usuario
Los motores de búsqueda, especialmente Google, han establecido una serie de directrices y métricas para optimizar la experiencia del usuario y, por ende, mejorar el posicionamiento en los resultados de búsqueda. A lo largo de los años, estas directrices han evolucionado, abarcando métricas de diversa relevancia. Sin embargo, en la actualidad, la experiencia del usuario es el pilar fundamental.
Importancia Actual y Futura de Core Web Vitals
Aunque es probable que la relevancia de Core Web Vitals disminuya en el futuro, en este momento, es un factor crucial para el SEO. Los sitios web con métricas del Google Core Web Vitals sólidas tienen una mayor probabilidad de retener a sus usuarios y, por lo tanto, de mejorar su posicionamiento en Google.
Velocidad de Carga y Experiencia del Usuario en Dispositivos Móviles
Desde siempre, la velocidad de carga ha sido un factor clave para el posicionamiento en Google. Sin embargo, la importancia de este factor se intensificó en 2018 cuando Google incorporó métricas de velocidad específicas para dispositivos móviles, cambiando así las reglas del juego. Con el auge de los dispositivos móviles, que ahora representan el 50% de la cuota de mercado, Google ha tenido que adaptar sus algoritmos para ofrecer una experiencia óptima en estos dispositivos.
El Google Core Web Vitals como Checker de Calidad en los Resultados de Búsqueda
”Desde la actualización de Google en agosto de 2021, las métricas de Core Web Vitals se han convertido en un checker” significativo para evaluar la calidad de un sitio web. Google había estado anunciando la importancia de estas métricas desde mayo del mismo año, y ahora, los resultados de búsqueda (SERPs) están cada vez más orientados hacia la experiencia del usuario.“Desde la actualización de Google en agosto de 2021, las métricas de Google Core Web Vitals se han convertido en un checker” significativo para evaluar la calidad de un sitio web. Google había estado anunciando la importancia de estas métricas desde mayo del mismo año, y ahora, los resultados de búsqueda (SERPs) están cada vez más orientados hacia la experiencia del usuario.
— ¡El qué avisa no es traiciona!. By Google.
Google Core Web Vitals Checker: 7 Herramientas para medir el Core Web Vitals
A la hora de medir datos de Core Web Vitals, podemos hacerlo de dos maneras, es decir, con dos Checker. En un examen de campo «con datos reales», o con datos de laboratorio «con datos en un entorno controlado». Los resultados del primero son los qué utiliza Google en su algoritmo. Entonces, podemos deducir qué:
- FID: Solo se puede medir en campo porque requiere a un usuario interactuando con la página. En tal caso se usa el TBT para calcular un FID aproximado.
- LCP y CLS: Se pueden medir tanto en campo cómo en laboratorio, y reflejan los valores antes vistos.
Ahora, podemos ver qué hay muchísimas herramientas qué miden las diferentes métricas. Veamos algunas de ellas:
1. GTmetrix
GTmetrix es una herramienta de medición de tiempos de carga. Para ello, usa datos de PageSpeed, generando los resultados de las métricas relevantes.
Además, GTmetrix se nutre de valores mundiales para contextualizar nuestro sitio y saber con certeza lo qué podemos y debemos mejorar. Esto es especialmente útil, pues, podemos ver la relación de nuestros recursos con nuestro sitio y el de los demás.
Para medirlo, necesitamos entrar en GTmetrix ??. Luego, en la barra, insertamos la URL qué queremos medir. El proceso durará unos segundos, y arrojará los resultados en un reporte.
2. Lighthouse
Lighthouse es una herramienta open source qué encontramos en disponible en la tienda de Chrome ??. Gracias a esta API, podemos realizar una auditoría de nuestro sitio. El cual evalúa las distintas métricas y parámetros, brindándonos las oportunidades de mejora:
- Performance: En la performance se evalúa el rendimiento en general, incluyendo el Core Web Vitals, con sus respectivas mejoras (este checker es el que nos permite medir la velocidad de carga).
- Accessibility: En este parámetro se evalúan los atributos de accesibilidad para personas con discapacidad visual y auditiva.
- Best Practices: Está relacionado con las buenas prácticas de seguridad y errores relacionados con el sitio.
- SEO: Se evalúan todos los atributos relevantes del SEO on-page.
- PWA: Evalúa sí la web funciona cómo progressive web app.
Pero, en el apartado de rendimiento claramente se pueden ver las diversas métricas, cómo el LCP, TBT, CLS, etc. Los datos de Lighthouse son tomados del propio PageSpeed Insights.
Para ejecutar un análisis con Lighthouse simplemente debemos instalar Lighthouse desde la tienda de Chrome. Una vez instalado, vamos al sitio qué queremos analizar, hacemos clic en el ícono con forma Faro, y generamos el reporte.
3. PageSpeed ??Insights
El PageSpeed Insights ?? es una herramienta qué se utiliza para medir exclusivamente la velocidad de los sitios web. Entre las métricas que encontramos dentro de este checker, están las propias del Core Web Vitals, lo cual, resulta claver para poder medir y optimizar la velocidad de nuestro sitio.
Pero, la particularidad, es qué podemos hacerlo tanto como sí se emulara un dispositivo móvil, y uno de escritorio.
Pero, también, podemos ver los datos qué se evalúan tanto en laboratorio y de campo.
4. GiftOfSpeed
GiftOfSpeed ?? es un sitio qué te permite analizar la velocidad de las páginas web desde distintas localizaciones de servidor.
El reporte es bastante general, pero te brinda interesantes oportunidades de mejora. Además, cuenta con una variedad de herramientas interesantes qué pueden darte información relevante de tu sitio.
Este checker no es sólo una API del propio Page Speed Insights, ya que GiftOfSpeed cuenta con otras herramientas que te permiten optimizar rápidamente los Core Web Vitals por medio de análisis específicos. Uno de ellos es el GZIP o Brotli Test, el cual es un análisis de sistemas de compresión, y al activar este sistema de compresión, tendremos un quick-win diferencial; ya que con pequeños cambios, obtendremos grandes resultados.
5. WebPageTest
WebPageTest ?? es otra herramienta de análisis de la experiencia de la página. Este checker usa datos de laboratorio para informar las métricas de Core Web Vitals; entonces, con dicha información, podremos realizar un plan de acción para poder optimizar estas métricas.
Además, como factor específico, WebPageTest te permite analizar páginas individuales gracias a la API de PageSpeed, pero además, te proporciona orientación específica para mejorar el rendimiento y optimizar tus Core Web Vitals.
6. Search Console
Hablar de Google Search Console da para mucho. Pero, también tenés las opciones de ver las métricas de Experiencia en la página, métricas web principales, y la usabilidad móvil.
Varias de las métricas hacen referencia a las Google Core Web Vitals por medio de su propio checker en la propia herramienta.
Lo que sí es clave en esta herramienta, es que GSC te dice qué y cómo optimizar tus Core Web Vitals; ya que, al ser una herramienta de Google, esta refleja los datos de lo que el propio Googlebot está midiendo.
7. Otros checker dentro de las extensiones de Google Chrome que miden el Core Web Vitals
Desde la propia tienda de Chrome podemos encontrar varias aplicaciones de terceros disponibles para brindarnos análisis de las Core Web Vitals; y así, lograrlas optimizar de manera simple.
9 ideas para mejorar y optimizar el Core Web Vitals
Ya vimos todo lo técnico sobre el Google Core Web Vitals, y con las herramientas recién mencionadas ya sabemos analizarlo. Ahora, restaría simplemente ver cómo implementar las mejoras.
Para ello se requerirá cierto conocimiento en lenguaje de programación HTML y JavaScript, además de conocimientos sobre SEO técnico. Pero, incluso sí no sabes mucho y te das maña, pues sos persistente, estas recomendaciones te van a servir.
1. Tiempo de respuesta del servidor
Este factor no es del todo controlable por tu cuenta, ya qué requiere de la intervención del servidor. Cuanto más tiempo se tarda en recibir respuesta del servidor, más tiempo se demoran los datos en procesar. Este retraso afectará al LCP y al FID o TBT. Optimizar los recursos del servidor es importante, y muchas veces no se solucionan cambiando de servidor; es por eso que al momento de analizar el Core Web Vitals, tengas en cuenta esto.
Sí queremos cambiar de servidor está bien, pero sí seguís teniendo problemas, da igual estar en tal o cual, vas a seguir con lo mismo. Por eso, veamos algunas cosas qué podemos hacer:
- Evitar qué los recursos del sitio se almacenen en otros servidores.
- Evitar los servidores compartidos en general.
- Dirigir a los usuarios a un CDN.
- Almacenar datos del sitio web en la caché de Google.
- Transmitir primero las páginas HTML almacenadas en la caché, luego el resto.
- Anticiparte a conexiones de terceros.
2. Minimizar y diferir el código
Los Scripts y el CSS puede llegar a ser un problema sí el código es muy grande, ya que penaliza directamente al Largest Contentful Paint.
Cuando se abre una URL, el navegador analiza el código del sitio antes de comenzar el renderizado. Ahí es donde puntualmente te penaliza un código muy grande.
Para solucionar este problema, se pueden hacer dos cosas, o bien, minimizar el código eliminando cosas innecesarias, o cargarlos de manera diferida.
El AMP funciona para minimizar el código creando una versión nueva completamente minimizada.
Otra idea es eliminar las cosas qué no se utilizan, usando un plugin minimizador de código. Con buscar «minimizar CSS» en la tienda de aplicaciones alcanza. Luego tendrás una amplia gama de opciones.
La carga diferida o lazy load es una de las mejores ideas para disminuir el impacto de los recursos en tu sitio. Y lo mejor de todo es qué no elimina partes del código, simplemente los carga de otra manera.
3. Optimizar el tiempo de carga para recursos pesados del Core Web Vitals
Los elementos pesados son un problema para los tiempos de carga de la página, eso resulta en afectar el LCP.
Lo más relevante para mejorar esta métrica es utilizar lo último en la tecnología para comprimir la información. El Brotli es el mejor algoritmo de compresión a día de hoy. De esta manera podrás:
- Optimizar y comprimir imágenes: Utiliza Brotli, Gzip, WebP, JPG, etc.
- Pre-cargar recursos.
- Comprimir archivos de texto.
- Brindar un servicio adaptativo para entregar diferentes activos basados en la conexión de red.
- Habilitar el sistema de almacenamiento caché.
4. Divide JavaScript pesado en tareas asincrónicas o diferidas
El JavaScript está relacionado directamente on la interacción del usuario. Por lo tanto, un JavaScript pesado, empeorará nuestro First Input Delay «FID» y el Total Blocking Time «TBT».
En ocasiones, este JavaScript es importante y no puede modificarse, por lo tanto, la eliminación del mismo no es una opción.
— Entonces, ¿se puede hacer algo?. Sí, se puede. Para ello tenemos qué dividir las tareas largas en pequeñas, qué se carguen de manera diferida «asincrónica». Pues, la división de tareas ayuda a reducir el tiempo de las métricas antes mencionadas.
Ejemplo de carga asincrónica JavaScript
Para generar etiquetas <script> diferidas o asincrónicas necesitamos un proceso similar pero con una diferencia:
Ejemplo de asincrónico:
El atributo async es un atributo de HTML5. Este estipula que una vez que el script esté disponible, se ejecutará de forma asincrónica «se ejecutará inmediatamente una vez que se complete la descarga».
Cabe señalar que el atributo async solo es aplicable a scripts externos.
<script type="text/javascript" src='https://tupacbruch.com/randomscript.js' async="async"></script>
Ejemplo de diferido:
El atributo defer establece qué se debe retrasar la ejecución del script hasta que se cargue completamente la página.
<script type="text/javascript" src='https://tupacbruch.com/randomscript.js' defer="defer"></script
A tener en cuenta sobre los atributos async y defer:
Sí no hay un atributo establecido, el navegador ejecutará el Script inmediatamente y bloqueará al siguiente.
Pero, sí hay un atributo async, el proceso de carga y renderizado se realizará en paralelo con la ejecución del JS actual. Estos scripts se ejecutan fuera de orden, sin prioridad alguna, mientras se esté cargando.
5. Web Worker
El Web Worker es una aplicación que bloquea el JavaScript. Este Worker lo ejecuta de manera paralela sin afectar al thread principal del navegador, pues, lo hace en segundo plano.
El FID mejora notablemente porque cambia el flujo de trabajo. Para hacerlo se requiere un plugin en WordPress o directamente editándolo desde el código en JS.
6. Carga las fuentes con una API
Un detalle pequeño, pero no menor es el tema de la carga de fuentes. Pues, la carga de fuentes suele retrasar la carga de los sitios web, y terminan perjudicando la experiencia del usuario.
Algo qué se puede hacer es cargar una fuente invisible «FOIT o Flash of Invisible Text» o una genérica «FOUT o Flash of Unstyled Text». Estas fuentes minimizan mucho el impacto de las fuentes mientras se carga la que debería hacerlo.
Si no, también podés cargar las fuentes con un estilo «precargado«, utilizando una API. Usar Google Fonts es algo muy útil, y está disponible en muchos plugins de varias tiendas CMS.
7. Incluye atributos para imágenes y videos
Existen dos atributos de dimensión qué podemos utilizar con las imágenes y los videos. Estos dos atributos son el ancho «width» y el alto «height».
Cuando no establecemos estos atributos, las imágenes y los videos se ponen con su valor por defecto, y en muchas ocasiones, termina perjudicando el CWV.
8. Reserva de espacios fijos para elementos dinámicos
El contenido dinámico a veces es bueno, otras veces es muy molesto, en especial cuando se trata de anuncios. Cuando colocamos anuncios por medio de una etiqueta, generalmente no le asignamos un espacio predeterminado.
Entonces, al no tener ese espacio fijo, básicamente, aparecen donde quieren. Esa irrupción genera problemas al Core Web Vitals, en especial al CLS, pues, desplaza el contenido; entonces, si lo queremos optimizar, debemos mantener fijos todos los elementos para evitar el desplazamiento.
Este desplazamiento perjudica la experiencia de usuario, y resulta en la perdida de resultados en las SERPs.
Veamos un ejemplo:
9. Optimiza el tamaño del DOM
Reducir el tamaño del DOM es importante para mejorar la velocidad del sitio y el tiempo de carga. Tiene su complejidad, pero podés hacerlo.
Conclusión:
Hemos llegado al final de este post. Espero que este artículo sobre los Core Web Vitals te haya proporcionado las herramientas necesarias para entender, analizar y optimizar estas métricas cruciales por medio de puntas o checker en el análisis de tu proceso de SEO técnico. Al implementar las mejoras sugeridas, no solo mejorarás la experiencia del usuario sino que también tendrás la oportunidad de escalar posiciones en las SERPs de Google.
El SEO es un campo en constante evolución, y siempre hay algo nuevo que aprender. Te invitamos a explorar los enlaces y recursos que hemos mencionado en este artículo para profundizar aún más en tu comprensión del tema.
Recuerda, el éxito en SEO no es un destino, sino un viaje que requiere planificación cuidadosa, ejecución efectiva y seguimiento constante de los resultados. Mantén siempre la disposición de aprender y adaptarte a los cambios en el algoritmo de Google y en las tendencias del mercado.
Si encuentras valor en nuestro contenido y deseas apoyarnos, considera hacer una donación a través de PayPal?? o Cafecito??. Tu generosidad nos permitirá mantener este blog libre de publicidad y seguir ofreciendo información de calidad.
Si estás pensando en lanzar tu propio sitio web, te recomendamos WordPress como tu plataforma de elección. Haz clic en el banner a continuación para obtener un descuento de $25 al crear tu sitio web con WordPressdescuento de $25 al crear tu sitio web con WordPress??.
Preguntas frecuentes sobre cómo optimizar el Core Web Vitals
¿Qué es Core Web Vitals?
El Core Web Vitals es una métrica compuesto por otros tres parámetros qué tiene cómo objetivo brindar oportunidades de mejora a nuestro sitio web.
¿Cuáles son las métricas del Core Web Vitals?
Las métricas del Core Web Vitals son tres:
- Largest Contentful Paint.
- First Input Delay o Total Blocking Time.
- Cumulative Layout Shift.
¿De dónde provienen los datos de Core Web Vitals que Google Search considera?
Los datos provienen del Informe de experiencia del usuario de Chrome, basados en las visitas e interacciones reales de los usuarios con las páginas web (datos de campo), no en simulaciones de laboratorio o visitas de Googlebot.
¿Cómo se calculan las puntuaciones de las URL individuales para Core Web Vitals?
Las métricas se calculan en el percentil 75 durante una ventana de 28 días. Si una página alcanza los objetivos recomendados para las tres métricas, pasa la evaluación de Google Core Web Vitals.
¿Cómo se calcula una puntuación para una URL que se publicó recientemente y aún no ha generado 28 días de datos?
Para las páginas con poco o ningún tráfico, se utilizan técnicas como agrupar páginas similares y calcular puntuaciones basadas en esa agregación.
P: ¿Por qué veo diferentes valores de métricas en diferentes herramientas, como Lighthouse y el Informe de experiencia del usuario de Chrome?
Core Web Vitals se basa en visitas reales de usuarios, mientras que herramientas como Lighthouse son simulaciones de laboratorio. Las condiciones del usuario y sus interacciones pueden influir en los datos.
¿Por qué no veo la página que estoy buscando en el informe Core Web Vitals en Search Console?
Search Console enumera un subconjunto de URL representativas de varios tipos de páginas en el informe para ayudar a identificar problemas y mejorar todo el tipo de página.
¿Las páginas noindex y las páginas "bloqueadas por robots.txt" están incluidas en el conjunto de datos de CrUX?
Los datos de CrUX se pueden acceder a nivel de página a través de PSI y la API de CrUX o a nivel de origen a través del conjunto de datos de Big Query público, que puede incluir datos agregados de todas las páginas públicas y privadas. De ahí la importancia de la etiqueta noindex.
Un servicio de terceros está ralentizando mi sitio. ¿Qué puedo hacer?
Evaluar periódicamente el impacto de los componentes de terceros en la experiencia del usuario y buscar mejoras que se reflejen en las métricas de Core Web Vitals.
¿Por qué la guía de Google usa los mismos umbrales para CWV para todos los tipos de páginas?
Core Web Vitals se aplican a todo tipo de páginas. Los rangos de umbral se determinan basados en la investigación de los requisitos básicos de la experiencia del usuario.
¿Qué es la actualización de la experiencia de la página y qué importancia tiene en comparación con otras señales de clasificación?
Es una nueva señal que se utilizará junto con otras señales para determinar el mejor contenido para mostrar. No anula tener contenido excelente y relevante.
¿Son Core Web Vitals un factor de clasificación cuando se usa la Búsqueda de Google en navegadores que no son Chrome?
Sí, se aplican globalmente en todos los navegadores móviles.
¿Cómo funciona la clasificación de la experiencia de la página con respecto a la guía publicada sobre qué valores de Core Web Vitals se consideran en el umbral "bueno"?
La clasificación se basa en cada elemento fundamental de la Web como una señal de clasificación independiente. Las páginas en el rango «bueno» obtienen un impulso en la clasificación.
¿Soy elegible para el carrusel de Top Stories si mi página web no cumple con Core Web Vitals?
Sí, todas las páginas son elegibles para el carrusel de Top Stories, que se basará en políticas de contenido de Google News.
¿Significa esto que AMP se convertirá efectivamente en una señal de clasificación?
No, AMP no es una señal de clasificación. Es un marco para crear páginas web de alto rendimiento.
¿Mis páginas AMP siempre tendrán una buena experiencia de página?
No necesariamente. Las páginas AMP deben cumplir con los criterios de Core Web Vitals para una buena experiencia de página.
¿Google sigue invirtiendo en AMP?
Sí, Google sigue invirtiendo en AMP para ofrecer páginas web con una excelente experiencia de usuario. Pero se descontinuará eventualmente.
¿Qué más debo tener en cuenta si decido dejar de usar AMP?
Dejar AMP no afectará la clasificación de las páginas. Los editores deben asegurarse de mantener una buena experiencia de página.
¿Qué te ha parecido?
???
¡Gran aporte!
si tengo amp cual es la que analiza el corewevvitals? la amp o la común?
¡Muy buena información!
¿Son Core Web Vitals un factor de clasificación?
Se pueden ver y testeast las páginas bloqueads o noindex?
me pasa que veo diferentes valores con diferentes herramientas, por que es?
¿Cómo se calcula una puntuación para una URL?