Core Web Vitals: Todo lo que necesitás saber

Ya sabemos todos qué a Google le gusta el dinero brindar buenas experiencias a los usuarios. Para ello requiere, entre otras cosas, una velocidad de carga aceptable. Y así es cómo nació el Core Web Vitals, para detectar esas pequeñas fallas en el rendimiento.

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!.


Tabla de contenidos

¿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 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 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.

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.

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 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

Los buscadores en general, y Google en particular, han implementado directrices para mejorar las posiciones de búsqueda en la web.

Durante todo ese tiempo, las directrices han sido muy diversas, con métricas más y menos relevantes. Pero, a día de hoy, lo principal es la experiencia del usuario.

El Core Web Vitals seguramente dejará de ser importante dentro de un par de años, pero, a día de hoy esto no es así. Pues, los sitios qué tienen buenas métricas en el CWV, tienen más probabilidades de retener a sus usuarios.

Velocidad de carga y la experiencia del usuario

Desde tiempos inmemoriales, la velocidad es un factor de posicionamiento en Google. Pero no fue hasta 2018, qué se incorporó las métricas de velocidad para dispositivos móviles, cambiando radicalmente las reglas de juego.

Pero, conforme al avance de los dispositivos móviles, Google se vio en la necesidad de brindarles una buena experiencia a dichos aparatos. Pues, a día de hoy alcanza el 50% de la cuota de mercado.

Entonces, ¿cómo el Core Web Vitals modifica los resultados de búsqueda?

Desde la actualización de agosto del 2021, el resultado de las Core Web Vitals se volvió realmente significante. Pues, Google viene avisando de esto desde Mayo del mismo año, e incluso antes. Entonces, lo que nos encontramos en las SERPs esta cada vez más orientado al usuario.

— ¡El qué avisa no es traiciona!. By Google.


7 Herramientas para medir el Core Web Vitals

A la hora de medir datos de Core Web Vitals, podemos hacerlo de dos maneras. 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.
  • 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, están las propias del Core Web Vitals. 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. Como por ejemplo el GZIP Brotli Test, qué es un análisis de sistemas de compresión.

5. WebPageTest

WebPageTest ↗ es otra herramienta de análisis de la experiencia de la página. Utiliza datos de laboratorio para informar las métricas de Core Web Vitals. Te permite analizar páginas individuales y proporciona orientación para mejorar el rendimiento.

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 Core Web Vitals.

7. Otras extensiones 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.


9 ideas para mejorar el Core Web Vitals

Ya vimos todo lo técnico sobre el 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.

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

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='http://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='http://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.

En cambio, sí hay un atributo defer, el proceso de carga se lleva a cabo en paralelo con la carga del JS. Pero esto no pasa, pues, se difiere la carga luego de analizar los elementos.

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.

Este desplazamiento perjudica la experiencia de usuario, y resulta en la perdida de resultados en las SERPs.

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.


Conclusiones

Bueno, llegamos al final. Espero qué este post te haya sido de utilidad para comprender el funcionamiento del Core Web Vitals; cómo analizarlo; y cómo optimizarlo.

Al implementar las mejoras, podrás escalar varias posiciones en las SERPs.

Poné en práctica todo lo aprendido en tu sitio web. — ¿Qué no tenés un sitio web?. Bueno, te dejo un regalito de 25 dólares en el banner acá abajo para tu próximo sitio de WordPress.

Consigue 25 dólares para tu próximo sitio WordPress

1 comentario en “Core Web Vitals: Todo lo que necesitás saber”

  1. Pingback: 🦵🦿 PWA: Las Progresive Web App se imponen en el SEO • Tupac Bruch

Deja un comentario Cancelar respuesta

Post relacionados

Por si te quedaste con ganas de más...

Como seguramente seguis con muchas ganas de leer post de mni blog «dijo nunca, nadie», te dejo algunos otros post que podrían ser de interés, ordenados de manera completamente random.

¿Necesitás contactarte conmigo?

Si tenés ganas de ponerte en contacto porque necesitás ayuda particular o simplemente te falta uno para el fútbol, no dudes en dejarme un mensaje por mail o en las redes sociales.

error: Content is protected !!