General, Noticias y Actualidad, Posicionamiento Web

¿Qué son las Core Web Vitals y por qué necesitas conocerlas?

Por Javier Picapeo Alcutén
¿Qué son las Core Web Vitals y por qué necesitas conocerlas?

Hoy vamos a hablarte de una de las últimas novedades anunciadas por Google, las Core Web Vitals. Detrás de ese nombre lo que tenemos son las nuevas métricas utilizadas por Google para impulsar una mejor experiencia de usuario y evaluar la velocidad de carga de una web.

Google lleva tiempo trabajando en este sentido y empujando para que los usuarios disfruten de un ecosistema web más rápido y que les ofrezca una mejor experiencia. Para ello ha lanzado herramientas como PageSpeed Insights o Lighthouse, ha impulsado la adaptación a móviles dándoles prioridad en su rastreo o apostado por iniciativas como AMP - Accelerated Mobile Pages-.


Las Core Web Vitals fueron anunciadas desde el blog de Chrome a principio de mayo como unas métricas esenciales para la salud de un sitio. Son el corazón de la nueva iniciativa Web Vitals, la cual además de dichas métricas incluye una serie de herramientas y guías para ayudar a los desarrolladores a cumplir el objetivo de ofrecer una experiencia de usuario perfecta.

Más recientemente hubo un nuevo anuncio por parte de Google, esta vez en su blog para webmasters, en el que avisa de que están trabajando para incorporar las nuevas métricas como factores de posicionamiento en su ranking de resultados de búsqueda.

¿Qué son las Core Web Vitals?

Como ya hemos anticipado, se trata de un nuevo conjunto de métricas útiles para valorar la velocidad de carga, el tiempo de respuesta y la estabilidad visual de una web, con el objetivo de poder brindar una mejor experiencia de navegación a los usuarios.

Google lleva años ofreciendo diferentes herramientas y guías para ayudar a los propietarios de sitios web a medir y mejorar el rendimiento de sus páginas. Después de un tiempo ha llegado a la conclusión de que podía estar dando un exceso de recursos e información que acaban complicando la vida a los responsables de las web en vez de ayudarles.

Con la iniciativa Web Vitals su objetivo es unificar criterios, simplificar este panorama y ayudar a los sitios a centrarse en lo que realmente consideran importante, las Core Web Vitals. Con este objetivo han reducido todo a 3 métricas clave, cada una centrada en una faceta específica de la experiencia de usuario.

Esquema de las nuevas métricas de UX de Google

Largest Contentful Paint (LCP)

Largest contentful paint (LCP), mide la velocidad de carga del contenido

El LCP se centra en la velocidad de carga, concretamente trata de medir cuánto tiempo pasa hasta que el usuario puede percibir como "cargada" una web, es decir, cuando ve totalmente renderizados los elementos que aparecen en su pantalla al acceder a una url.

Para ello se mide cuando se ha pintado el elemento de contenido que ocupa el mayor espacio en la pantalla del usuario al cargarse la página, dando por hecho que en ese momento será visible la mayor parte del contenido que se muestra en pantalla. Y para que este dato se consideré bueno no debería superar los 2’5 segundos.

Establecer esto no ha resultado sencillo y por eso se han venido utilizando diferentes métricas a lo largo del tiempo. Inicialmente se utilizaron los eventos load, que se activa cuando se ha cargado toda la página incluyendo estilos, imágenes, etc. y DOMContentLoaded, que se activa cuando se ha cargado el html inicial (sin esperar a cargar nada más). El problema es que estos eventos no son representativos de lo que el usuario ve en pantalla pecando en un caso por exceso y en otro por defecto.

De ahí se pasó a utilizar métricas de rendimiento más modernas que sí tenían en cuenta y buscaban centrarse en la experiencia de usuario como el FCP que mide cuando se pinta el primer elemento en pantalla. Sin embargo, no resulta útil en el momento en que se utilizan pantallas de bienvenida o indicadores de carga, por eso se empezó a recomendar tener en cuenta otras métricas. Se llegó a un punto en que todo se había complicado mucho y además las medidas no resultaban fiables para identificar cuando el usuario realmente percibe como cargada una página.

¿Qué elementos se consideran?

Actualmente se consideran los siguientes elementos de contenido:

  • Imágenes (<img> e <image> dentro de un elemento <svg>).
  • Imagen de portada de vídeos (elemento <video>).
  • Elementos con una imagen de fondo cargada por css.
  • Elementos de bloque html que contienen textos.

Aunque avisan de que se podrían añadir más elementos en el futuro si se consideran relevantes.

¿Cómo se determina el tamaño de un elemento?

Básicamente se tiene en cuenta el tamaño que ocupa dentro de la pantalla del usuario en el momento de cargar la página. Si un elemento se extiende más allá de la ventana visible para el usuario, solo se tiene en cuenta la parte que queda dentro de dicha ventana visible.

Además no se tienen en cuenta es espacio dedicado a márgenes, bordes, etc., esto es especialmente relevante en los bloques de texto, ya que solo se contabiliza el espacio del área más pequeña que ocupa el texto.

Otro dato curioso a tener en cuenta es que, en el caso de las imágenes que se muestran redimensionadas, se toma siempre el tamaño más pequeño. Es decir, si tenemos una imagen grande que redimensionados por css para mostrarla más pequeña utilizará el tamaño con el que se muestra, mientras que si tenemos una imagen pequeña y la estiramos utilizará el tamaño real de la imagen.

¿Cómo se decide cual es el elemento de mayor tamaño?

A veces conforme una web va cargando pasa por diferentes etapas que pueden hacer que el elemento de mayor tamaño vaya cambiando, para tener esto en cuenta el navegador va informando del elemento de mayor tamaño descubierto en las distintas fases de carga. Además, si un elemento considerado que es cargado inicialmente se considera el más grande pero acaba desapareciendo, es sustituido por el elemento más grande que acaba siendo visible al final de la carga.

Selección del LCP durante la carga de la nueva home de Palbin

Selección del LCP durante la carga de la web de The New York Times

En las imágenes anteriores puedes ver como en el primer caso, en la nueva home de nuestra web, en la primera carga de contenido (FCP) se detecta el encabezado como contenido de mayor tamaño y este se mantiene como tal hasta que la página ha cargado completamente, por lo que en este caso el valor del FCP y del LCP sería el mismo (1’5s). En cambio, en la segunda imagen lo que ves es como inicialmente se elige un texto cuando se empieza a pintar el contenido de la página, pero este cambia más adelante al cargar una imagen que ocupa el mayor espacio en pantalla, por lo que el LCP cambia (1,9s).

First Input Delay (FID)

First input delay (FID) mide la interactividad de la página

La segunda métrica es el FID, en ese caso se centra en medir la interactividad de la página, es decir, el tiempo que el navegador tarda en responder ante la primera acción realizada por el usuario, como por ejemplo un clic en un enlace.

En este caso, a diferencia del LCP, se necesita una acción real de un usuario para poder medir el tiempo de respuesta, por lo que no podremos ver directamente este valor utilizando herramientas como Lighthouse. Como veremos más adelante tenemos formas de conocerlo si nuestra web ya es pública y en caso contrario podemos utilizar otras métricas para hacernos una idea de si lo estamos haciendo bien o no. Un buen valor para el FID no debe ser mayor de 100ms.

A todos nos ha pasado alguna vez que cuando parece que una web está cargada, tratamos de hacer algo en ella pero el navegador no responde, especialmente cuando navegamos desde el móvil. Normalmente esto ocurre porque aunque parece que la página se ha terminado de cargar y ya estamos viendo el contenido cuando tratamos de interactuar con ella en realidad el navegador está procesando algún fichero descargado de forma asíncrona, habitualmente ficheros de javascript, por lo que hasta que no haya terminado esa tarea no podrá responder a la petición del usuario generando un retraso o latencia entre la acción del usuario y la respuesta del navegador, este tiempo es precisamente lo que mide el FID.

Uno de los motivos de medir el retraso de respuesta solamente para la primera acción del usuario es precisamente que los principales problemas de interactividad de un sitio web se producen durante la carga inicial. Pero no es el único, también se puede justificar por la importancia de causar una buena primera impresión en el usuario y porque una latencia alta en la respuesta a acciones del usuario cuando la página ya está totalmente cargada suele tener su origen en problemas muy distintos, por lo que la métrica sería menos útil a la hora de poner una solución.

Representación de la carga de una web

La imagen anterior representa la carga de una página web. Por un lado, en gris claro vemos representadas las peticiones de red hechas por el navegador para descargar los recursos necesarios desde el servidor (html, css, js, imágenes, etc.). Por otro lado, en azul vemos las tareas que el navegador realiza para procesar los recursos descargados y poder mostrar la web correctamente al usuario. Cuando las tareas de procesamiento han finalizado la página se considera completamente preparada para la interacción con el usuario (TTI).

Pero hasta aquí no ha habido todavía ninguna acción por parte del usuario y por tanto no sabemos cual es el FID, vamos a ver una situación en la que podríamos tener un FID elevado.

Representación del FID durante la carga de una web

Sobre la primera imagen, ahora hemos representado una acción del usuario llevada a cabo a la vez que el navegador todavía está ocupado en una tarea, por lo tanto el usuario deberá esperar a que finalice dicha tarea antes de que haya una respuesta a su acción. Ese tiempo de espera es el valor FID para ese usuario en esa visita a la página.

Se mide desde el momento en el que el usuario realiza la acción hasta que el hilo principal de procesado del navegador queda libre para poder atenderla. De esta forma el FID no depende de que la acción tenga un detector de eventos asociado, ya que muchas acciones de usuario no lo requieren.

Podemos ver pues, que el FID depende mucho del momento en el que el usuario interactúa con nuestra página, por eso es necesaria una medición con interacciones reales de usuarios reales y lo que veremos será el tiempo promedio de respuesta. De hecho, habrá usuarios que no realicen ninguna acción en nuestro sitio y no generen valores de FID, otros que lo tengan muy bueno y otros no tanto.

Como ya hemos adelantado, se considera que el FID es bueno si es menor a 100 ms y si lo es, al menos, para el 75% de los usuarios que visitan nuestra web.

Cumulative Layout Shift (CLS)

Cumulative layout shift (CLS) mide la estabilidad visual de una página

Por último tenemos el CLS, que sirve para evaluar la estabilidad visual de la página. Esta métrica ofrece información sobre los movimientos inesperados que se producen en los elementos visibles de la página, tanto por desplazamiento como por cambio de tamaño de algún elemento. Para considerarse buena su valor tiene que ser inferior a 0,1.

La intención de Google con esta métrica, al igual que con las dos anteriores, es que sirva para ayudarnos a mejorar la usabilidad de la web. Hoy en día es muy habitual que al navegar por una web, sobre todo desde el móvil, veamos movimientos repentinos que generan desplazamientos en el texto que estamos leyendo o en peor de los casos nos pueden llevar a pulsar un botón erróneamente al aparecer justo en el hueco del enlace que queríamos clicar. Esto resulta molesto para el usuario y es precisamente lo que se pretende medir con el CLS para así poder detectar si nuestra web tiene un problema y en ese caso poner una solución.

¿Qué cambios de diseño se consideran perjudiciales para la usabilidad?

Es importante tener en cuenta que lo que supone un problema son los movimientos o cambios de diseño que resultan inesperados para el usuario. Por lo tanto se pueden seguir utilizando elementos móviles en nuestra web (animaciones, sliders, etc.), simplemente debemos hacerlo de forma apropiada.

Google nos da algunas pautas en este sentido, cómo utilizar la propiedad transform de css, con las funciones scale() y translate() podemos redimensionar y mover elementos sin que afecte negativamente al CLS de nuestra página.

Y, por supuesto, también podemos tener movimientos provocados por una acción del usuario, como por ejemplo que al hacer clic en un botón se despliegue un texto informativo. En este caso, aunque haya un desplazamiento del texto que venía a continuación, no se tendría en cuenta a la hora de calcular el CLS, al ser provocado por el usuario y no resultar inesperado para el mismo.

En este sentido, lo que aconseja Google es que si es necesario cargar recursos que pueden tardar en estar disponibles se reserve ya el espacio necesario y se utilice algún indicador para que el usuario sea consciente de que algo está esperando a ser cargado en ese hueco. Los cambios de diseño que se producen en los 500 ms posteriores a una acción del usuario no se tienen en cuenta a la hora de calcular el CLS.

¿Cómo se calcula el CLS?

El CLS es la métrica más diferente de las Core Web Vitals en cuanto a su forma de calcularse. Tanto el LCP como el FID miden tiempos, así que simplemente tenemos que saber de qué momento a qué otro momento cronometran, pero en el caso del CLS lo que se mide es la acumulación de cambios en la disposición del contenido o los elementos de la web, por lo que la cosa se complica un poco más.

Para empezar, pueden producirse varios cambios de diseño en el tiempo que dura la visita de un usuario a una determinada página, por lo que será necesario asignar un valor o una puntuación a cada uno de ellos, es lo que se denomina layout shift score. El CLS para esa visita será el resultado de sumar los valores asignados a cada uno de los cambios producidos.

Estos cambios de diseño pueden producirse porque un elemento visible en pantalla cambie de tamaño, porque cambie de posición o ambos al mismo tiempo. Por ello, para calcular su puntuación (layout shift score) se realiza el producto de dos medidas distintas, la del cambio de tamaño o espacio ocupado en la pantalla, denominada fracción de impacto o impact fraction en inglés, y la del movimiento, llamada fracción de distancia o distance fraction. Ahora veremos cómo se calcula cada una de ellas.

layout shift score = impact fraction * distance fraction
Impact Fraction

Mide como un elemento inestable impacta en el espacio ocupado en la pantalla por dicho elemento entre dos frames o dos momentos distintos.

Para calcular la fracción de impacto se mide el porcentaje de pantalla ocupado por la unión del espacio ocupado en el momento inicial y el espacio ocupado finalmente, en la siguiente imagen lo verás más claramente.

CLS, fracción de impacto

En este ejemplo tenemos una imagen que carga a un determinado tamaño inicialmente y luego se hace más grande, la fracción de impacto sería el área marcada en rojo divido entre el área total de la pantalla. Suponiendo que el movimiento hubiese sido el contrario, cargando primero a mayor tamaño y siendo reducida posteriormente, la fracción de impacto sería exactamente la misma.

Distance Fraction

Mide la distancia que se ha desplazado un elemento inestable en la pantalla entre dos frames o momentos distintos.

Para calcular la fracción de distancia se divide la mayor distancia que un elemento se ha desplazado (bien en horizontal o bien en vertical) y se divide entre la mayor dimensión de la pantalla (ancho o alto), es decir, calculamos el porcentaje del mayor desplazamiento respecto a la mayor longitud de la pantalla. De nuevo lo ilustramos en una imagen para entenderlo más fácilmente.

CLS, fracción de distancia

En este caso, además, podemos ver como pese a que la imagen ha mantenido su tamaño, su desplazamiento hacia abajo no solo tiene un valor de fracción de distancia, sino que también tiene un valor de fracción de impacto (igual al área marcada en la segunda imagen dividida por el área total de la pantalla).

¿Cómo puedo medir las Core Web Vitals de mi web?

Ahora que ya sabes lo que son las nuevas métricas de Google para mejorar la experiencia de usuario, probablemente lo siguiente que quieras saber es cómo medirlas en tu web. Antes de empezar a hablar de herramientas, es importante tener claro que existen dos formas de medir, utilizando datos de campo o en base a experimentos de laboratorio.

¿Qué son y cómo se obtienen los datos de campo?

Los datos de campo son datos extraídos por Chrome de forma anónima directamente de usuarios reales que visitan tu web, tanto en móvil como en escritorio. Como se indica en las políticas de privacidad de Google Chrome, por defecto el navegador envía datos estadísticos de uso, informes de fallos, etc.

Los datos de campo son los más fiables debido a que te ofrecen información real de cómo se está comportando tu web. Obviamente, al tratarse de datos obtenidos de las visitas reales a tu web, para disponer de ellos necesitas que tu sitio esté ya publicado y además tenga tráfico.

¿Qué son y cómo se obtienen los datos de laboratorio?

Los datos de laboratorio son datos obtenidos a través de un experimento realizado en el momento de realizar la medición con la herramienta que se utilice. La ventaja es son datos actuales por lo que te permiten conocer cómo se comporta tu web después de haber realizado algún cambio sin necesidad de esperar a recopilar datos de usuarios reales.

Además, si tu web está en fase de desarrollo y todavía no se ha publicado o es pública pero no todavía no recibe tráfico, está es la única forma en que podrás medir las Core Web Vitals.

Herramientas para realizar una medición de campo

Puedes acceder a los datos de campo recopilados por Google por medio de tres herramientas que ellos mismos ponen a tu disposición.

  • El informe de experiencia de usuario de Chrome
  • La herramienta Page Speed Insights
  • El nuevo informe de Métricas web principales de Search Console

Desde cualquiera de ellas podrás obtener los promedios de valores de las tres nuevas métricas obtenidos de las visitas reales de tus usuarios.

Informe de experiencia de usuario de Chrome (CrUX)

Se trata de la fuente original de los datos y el resto de herramientas lo que haces en beber de ella. Pero también es posible acceder directamente a sus datos, por ejemplo utilizando BigQuery. Lo más fácil es hacerlo a través del conector creado para Google Data Studio por el equipo encargado del CrUX, de esta forma podremos obtener un dashboard con toda la información de nuestra web.

Dashboard en Google Data Studio del reporte de usabilidad de Chrome

Eso sí, los datos obtenidos con este dashboard serán los promedios de los valores para todo el origen de datos, es decir, nuestro dominio (o subdominio) accediendo a través de un protocolo concreto. Por ejemplo, el origen que vemos en la imagen es "https://www.palbin.com", en nuestro caso el origen recoge todos los datos de nuestra web, pero si tu sitio fuese accesible tanto por http como por https, los datos estarían divididos entre dos orígenes distintos, aunque esto es algo que deberías evitar.

Page Speed Insights

Esta herramienta nos proporciona un acceso rápido para conocer los valores de las Core Web Vitals de una URL en concreto, así como a los datos agregados de todo el origen. Además, nos proporciona tanto datos de campo como de laboratorio.

En realidad esta herramienta no cuenta con datos propios, sino que accede a los datos del informe de UX de Chrome para obtener los datos de campo y utiliza Lighthouse para realizar un experimento y mostrarnos los datos de laboratorio.

Resultados de las Core Web Vitals con Page Speed Insights

Informe de métricas web principales de Search Console

Desde finales de mayo podemos encontrar este nuevo informe en Search Console, que ha sustituido al informe de rendimiento que proporcionaba antes.

De nuevo son datos que provienen del informe de experiencia de usuario de Chrome, la ventaja en este caso es que vas a tener una visión global de cuantas URL de tu sitio están bien, regular o mal y te va a señalar los problemas detectados en cada una para que puedas solucionarlos.

Informe de Métichas web principales en Google Search Console

En un primer momento te muestra dos líneas temporales en las que puedes ver cómo han ido evolucionando las URLs de tu sitio, segmentando los datos entre móvil y ordenador. Junto a cada gráfico hay un enlace que te permite acceder a un informe más detallado para ver qué problemas se han detectado y haciendo clic sobre cada uno de ellos podrás ver a qué URLs afecta. Eso sí, te mostrará algunos ejemplos pero agrupará aquellas URLs que consideré similares (por ejemplo los post del blog por un lado, categorías por otro, etc.).

Detalle del informe de Métichas web principales en Google Search Console

Herramientas para realizar una medición de laboratorio

Si lo que quieres es obtener datos actuales realizando un experimento para conocer los valores de las Core Web Vitals en el momento de la comprobación puedes utilizar las siguientes herramientas:

  • Lighthouse
  • Las herramientas de desarrollo de Google Chrome
  • Web Page Test

Las dos primeras son herramientas proporcionadas por Google, mientras que Web Page Test es una herramienta de código abierto pero el propio Google la ofrece como una opción válida para obtener estos datos.

Es importante tener en cuenta que al tratarse de datos de laboratorio obtenidos a través de un experimento automatizado en el que no interviene un usuario real no van a proporcionar el FID. Como alternativa, si no dispones de datos de campo, Google propone utilizar el TBT en su lugar, es decir el Total Blocking Time o tiempo total de bloqueo.

Sin extendernos demasiado, el TBT es la suma de los periodos en los que permanece bloqueado el hilo principal del navegador desde que se empieza a pintar la página hasta que está totalmente interactiva. Siempre esos bloqueos sean mayores de 50 ms y ese tiempo se restará del tiempo que dura el bloqueo a la hora de sumarlos.

Lighthouse

Se trata de una herramienta creada para auditar webs, existen múltiples formas de acceder a ella, pero la más sencilla es a través de Google Chrome. Inicialmente era necesario instalar una extensión de Chrome, pero en las últimas versiones viene integrado como parte de las DevTools o herramientas de desarrollo. No obstante, si quieres utilizarla para obtener datos de Core Web Vitals necesitarás instalar Chrome Canary.

Resultados de las Core Web Vitals en Lighthouse v6

Herramientas de desarrollo de Chrome (Chrome DevTools)

Además de poder utilizarlas para acceder a los informes de Lighthouse, en la pestaña Performance puedes ver en detalle el comportamiento de tu web durante la carga, analizar qué tareas están bloqueando la interactividad del navegador durante más tiempo, si algún recurso tarda demasiado en cargar, etc.

Análisis de la carga de una web con Chrome DevTools

Web Page Test

webpagetest.org es una herramienta que te permite analizar el rendimiento de una web configurando aspectos como el lugar desde el que se realiza la conexión, el navegador o el tipo de conexión a internet utilizados. Además, te permite grabar un vídeo del comportamiento durante la carga que puede resultar muy útil para detectar algunos problemas a golpe de vista como que un elemento de gran tamaño que esté tardando en cargar y te haga tener un mal LCP.

Resultados de Core Web Vitals en webpagetest.org

Podríamos profundizar mucho más en la información que nos ofrece cada una de estas herramientas y cómo utilizarla para optimizar una web, si bien ese no es el propósito de este artículo. Aquí sólo pretendemos presentarte algunas de las opciones disponibles para que puedas empezar a investigarlas y trabajar con ellas, probablemente escribamos otro artículo más adelante para adentrarnos en ello.

¿Por qué son importantes las Core Web Vitals?

En primer lugar, se trata de métricas que te van a ayudar a mejorar la experiencia de usuario (UX) de tu web, lo cual debería ser una prioridad para cualquier propietario o administrador de un sitio. Ya que mejorar la UX de tu página va a hacer que los usuarios que la visiten les guste y se sientan cómodos en ella, lo que va a aumentar el reconocimiento de tu marca y te va a facilitar el fidelizarlos.

Además, una buena experiencia de usuario es clave para lograr unas buenas tasas de conversión, no vamos a entrar en detalle, pero hay cientos de informes reputados que demuestran que una web lenta o una web con una mala usabilidad convierte mucho menos que una similar que tenga bien trabajados estos aspectos. Llevándolo al mundo del ecommerce, puede ser la diferencia entre que un usuario que llega a tu web te acabe comprando o se vaya a la competencia.

Además, aunque de forma indirecta, la experiencia de usuario también afecta al posicionamiento orgánico (SEO) de tu web, al CPC que vas a pagar por tus anuncios en Google Ads y a la visibilidad que vas a lograr con ellos.

¿Afectan las Core Web Vitals al SEO?

La respuesta corta es que por ahora no, pero Google ha anunciado que lo harán. Google lleva tiempo moviéndose hacia dar cada vez más peso a la experiencia de usuario a la hora de dar más o menos visibilidad a una página.

Para ellos una parte importante para ofrecer una buena experiencia al usuario es tener una web con un buen rendimiento. En este sentido ya lleva un tiempo utilizando métricas de velocidad en su algoritmo, aunque hasta ahora servían sobre todo para "penalizar" a aquellas web que tenían serios problemas de rendimiento o que resultaban mucho más lentas que otras que podían ofrecer más o menos lo mismo al usuario.

Como comentábamos al inicio de este artículo, Google publicó un post en su blog para webmasters en que anuncia que van a trabajar para incorporar las Core Web Vitals, combinadas con otras señales que ya están utilizando para medir la experiencia de usuario, en su algoritmo encargado de calcular el ranking de resultados.

Por ahora no sabemos cuándo se llevará a cabo la actualización del algoritmo con el que se empezaran a tener en cuenta estas métricas, en ese sentido, lo único que podemos decir es que Google ha confirmado que no será durante este año ya que entienden que muchos propietarios de sitios web deben centrarse en paliar las consecuencias que el COVID ha tenido para sus negocios, además aseguran que informaran de la aplicación del cambio de algoritmo al menos con 6 meses de tiempo.

Tampoco sabemos qué peso tendrán realmente a la hora de decidir en qué posición aparece una determinada página, ni siquiera podemos asegurar si se tendrán en cuenta a nivel de página (URL) o de sitio, aunque todo parece apuntar a que será a nivel de página.

Conclusiones

Como ya hemos dicho antes, mejor la experiencia de usuario de tu web siempre es una buena idea y las Core Web Vitals han llegado con la intención de facilitarte esta tarea ofreciéndote una valiosa información sobre cómo se comporta tu página.

Además, Google ha anunciado que es algo que pretende incorporar a su algoritmo de posicionamiento, por lo que en el futuro afectarán a la visibilidad de tu web, aunque todavía es pronto para saber en qué medida.

Desde Palbin te recomendamos que empieces cuanto antes a trabajar para mejorar el rendimiento de tu web, si has leído este artículo ya has dado el primer paso informándote sobre qué son las Core Web Vital y cómo medirlas. Próximamente publicaremos más contenido profundizando en cómo optimizar tu sitio, hablaremos sobre las novedosas técnicas que hemos aplicado en la renovación de nuestra propia web y otras en las que todavía estamos trabajando, etc.

Si quieres mantenerte al día y no perderte ninguno de nuestras publicaciones, te recomiendo que te suscribas a nuestra newsletter.


¿Quiéres mejorar tu e-commerce?
x
Academia digital

Únete a nuestra Academia Digital y recibe los mejores trucos y consejos sobre Comercio Electrónico y Marketing Digital diréctamente en tu correo.

Recibirás un email para confirmar tu suscripción.

Comentarios


No se encontraron resultados.

Deja un Comentario

Tu email no será publicado


©2020 Siokia SL | Palbin.com: Crea tu tienda en dos pasos, 1 y 2. Condiciones de uso y Política de privacidad