Core Web Vitals: la Velocidad de Página es Ahora Más Importante para el SEO

Patrick Stox
Patrick Stox es asesor de producto, técnico en SEO y embajador de marca Ahrefs. Organiza el Raleigh SEO Meetup, Raleigh SEO Conference, Beer & SEO Meetup, Findability Conference y modera en / r / TechSEO.
Estadísticas de artículo
  • Tuits 3
Datos de Content Explorer

Muestra cuántas sitios web distintos enlazan a esta pieza de contenido. Como regla general, cuantas más sitios web te enlacen, más alto posicionarás en Google.

Te muestra una estimación del tráfico de búsqueda mensual a este artículo según los datos de Ahrefs. El tráfico real de búsqueda (el recogido en Google Analytics) es normalmente 3-5 veces más alto.

El número de veces que este artículo fue compartido en Twitter.

    Core Web Vitals son las métricas de velocidad que forman parte de las señales de Experiencia de Página que Google usa para medir la experiencia de usuario. Las métricas miden la carga visual con Largest Contentful Paint (LCP, renderizado del mayor elemento con contenido), la estabilidad visual con Cumulative Layout Shift (CLS, cambios de diseño acumulados) y la interactividad con First Input Delay (FID, latencia de la primera interacción) 

    La experiencia de la página y las métricas incluidas en Core Web Vitals (Métricas Web Principales en español) se usarán para el posicionamiento de las páginas en junio de 2021.

    Fuente: Google

    La forma más fácil de ver las métricas de tu sitio es con el informe de Métricas web principales en Google Search Console. Con el informe, puedes ver fácilmente si tus páginas están categorizadas como “URLs pobres”, “URLs necesitan una mejora” o “URLs buenas”.

    Dentro del informe, puedes encontrar información más detallada sobre los problemas concretos y una lista de las páginas afectadas.

    Factor 1: Las métricas se separan entre ordenador y móvil, pero solo las señales móviles serán usadas para el posicionamiento de las páginas. Google está pasando a una indexación 100% mobile-first desde marzo, así que tiene sentido usar las señales de velocidad móvil, ya que las páginas indexadas también se basarán en las versiones móviles.

    Factor 2: Los datos provienen desde el informe de User Experience de Chrome (CrUX), que recoge datos de los usuarios que han dado permiso. Las métricas serán evaluadas en el percentil 75º de los usuarios, así que si el 70% de tus usuarios están en la categoría “buena” y el 5% está en la categoría “necesita una mejora”, tu página será evaluada como “necesita una mejora”.

    Factor 3: Las métricas serán evaluadas para cada página, pero si no hay suficientes datos, John Mueller afirma que se pueden usar las señales de las secciones de un sitio o del sitio en general.

    Factor 4: Con la inclusión de estas nuevas métricas, AMP se eliminará como un requisito desde la funcionalidad Top Stories (historias destacadas) en móvil. Ya que las nuevas historias no tendrán datos sobre las métricas de velocidad, es probable que las métricas de una categoría más grande de páginas o incluso el dominio entero pueda ser usado para esto.

    Factor 5: Las aplicaciones de página única (Single Page Applications) no miden un par de las métricas, FID y LCP, a través de las transiciones de página. Hablaremos de estas en un minuto,

    Factor 6: Las métricas pueden cambiar con el tiempo, así como los umbrales. Google ya ha cambiado las métricas usadas para medir la velocidad en sus herramientas a lo largo de los años, así como sus umbrales de lo que se considera o no rápido. Con toda probabilidad todo esto cambiará de nuevo en el futuro. De hecho, trabajamos algo en mejorar las métricas anteriores el año pasado, pero necesitamos trabajar una vez más para mejorar las nuevas métricas.

    Solo para establecer las expectativas, recuerda que hay más de 200 factores de posicionamiento. No esperaría mucha mejora al mejorar las Core Web Vitals. Se desconoce cuánto impactarán en el posicionamiento, pero no es probable que se trate de una señal fuerte, especialmente si tenemos en cuenta que Google ya estaba usando muchos de los componentes de la experiencia en las páginas para determinar el posicionamiento en los rankings.

    Veamos cada una de las core web vitals (métricas web principales) en más detalle.

    Aquí están los tres componentes actuales de las Métricas Web Principales o Core Web Vitals:

    Renderizado del mayor elemento con contenido (Largest Contentful Paint, LCP)

    LCP es el elemento único visible más grande cargado en el campo de visión.

    (Cargando)

    LCP

    Largest Contentful Paint

    Renderizado del mayor elemento con contenido

    Bueno | Necesita Mejorar | Pobre

    2.5 segs.   4.0 segs

    Fuente: web.dev/vitals

    El elemento más grande normalmente será una imagen destacada o quizá la etiqueta <h1>, pero podría ser cualquiera de estos:

    • Elemento <img>
    • Elemento <image> dentro de un elemento <svg>
    • La imagen dentro de un elemento <video>
    • La imagen de fondo cargada con la función url()
    • Bloques de texto

    <svg> y <video> puede que se añadan en el futuro.

    Cómo ver el LCP

    En PageSpeed Insights, el elemento LCP se especificará en la sección de Diagnósticos. Para la página de prueba, el LCP es nuestra imagen destacada en el post del blog.

    En las herramientas para desarrolladores de Chrome, sigue estos pasos:

    1. Performance (rendimiento) > comprueba “Screenshots”
    2. Haz clic en ‘Start profiling and reload page’ (empezar a perfilar y recargar la página)
    3. LCP está a la derecha en el gráfico de tiempo
    4. Haz clic en el nodo; este es el elemento LCP

    Optimizando LCP

    Siendo nuestro elemento LCP en esta y muchas otras páginas la imagen destacada, probablemente podemos mejorar esto precargando esta página o posiblemente incluyendo la imagen completa para hacer que se descargue junto al código HTML. Básicamente, queremos cargar esta imagen más rápido de lo que lo hace actualmente.

    Recursos

    Cambios de diseño acumulados (Cumulative Layout Shift, CLS) — estabilidad visual

    CLS mide cómo los elementos se mueven o cuán estable es el diseño de la página. Tiene en cuenta el tamaño del contenido y la distancia que se mueve. Un problema grande con la métrica es que continúa midiéndose incluso después de la carga inicial de la página. Google está recogiendo feedback sobre esta métrica en particular, así que probablemente veremos algunos cambios en ella en el futuro.

    (Estabilidad Visual)

    Cumulative Layout Shift

    Cambios de diseño acumulados

    Buena                 Necesita Mejorar         Pobre

    0.1         0.25

    Puede ser incómodo si intentas hacer click en algo de la página que se mueve y acabas haciendo clic en algo en lo que no querías. A mí me pasa todo el tiempo. Hago clic en una cosa, y de repente, estoy haciendo clic en un anuncio y ni siquiera en la misma página. Es frustrante como usuario.

    Entre las causas comunes de CLS se incluyen:

    • Imágenes sin dimensiones
    • Anuncios, embeds (elementos incrustados), y iframes sin dimensiones
    • Inyección de contenidos con JavaScript
    • Aplicar fuentes o estilos tarde al cargar

    Cómo ver el CLS

    En PageSpeed Insights, bajo los diagnósticos, encontrarás una lista de los elementos que se están moviendo.

    Usa WebPageTest. En la Filmstrip View, marca las siguientes opciones:

    • Marca Layout Shifts
    • En Thumbnail Size (tamaño de miniatura): elige Huge (enorme)
    • En Thumbnail Interval (intervalo de miniatura): marca 0.1 sec

    Fíjate en cómo nuestra fuente cambia de estilo entre 5.1s‑5.2s, cambiando el diseño cuando nuestra fuente personalizada se aplica.

    Puede que quieras probar el Layout Shift GIF Generator

    Smashing Magazine también disponía de una técnica interesante que compartieron, donde añadieron una línea de contorno de color rojo sólido de 3px a todo y grabaron un vídeo de la página para identificar dónde ocurrían los cambios de posición.

    Optimizando CLS

    Para nuestra página de test, puede que lo que queramos hacer sea precargar nuestra fuente personalizada, abandonar la fuente personalizada por completo (es algo dudoso que hagamos esto) o usar una fuente por defecto en la carga inicial de la página y cargar solo nuestra fuente en las cargas de página posteriores. Estas medidas suponen sacrificios en marca, estilo, consistencia, etc. y tendremos que decidir cuál es el mejor camino más adelante. 

    Recursos

    Latencia de la primera interacción (First Input Delay, FID) — interactividad

    FID es el tiempo desde que un usuario interactúa con tu página hasta que la página puede responder. También puedes pensar en esto como la capacidad de respuesta. Esto no incluye hacer scroll o zoom.

    Ejemplos de interacción:

    • hacer clic en un enlace o botón
    • Introducir texto en un campo en blanco
    • elegir un elemento de un menú desplegable
    • hacer clic en una casilla (checkbox)

    Puede ser frustrante intentar hacer clic en algo y que nada pase en la página.

    (Interactividad)

    FID

    First Input Delay

    Latencia de la primera interacción 

    Buena — Necesita Mejorar — Pobre

    100 ms        300 ms

    No todos los usuarios interactúan con una página, así que puede que no tengan un valor de FID. Esto es por lo que las herramientas de testeo no tendrán el valor, porque no están interactuando con la página. Usa el Total Blocking Time (TBT, tiempo total bloqueado) en su lugar.

    Causas de FID

    JavaScript compitiendo por el hilo principal. Solo hay un hilo principal y JavaScript compite por ejecutar las tareas en él.

    Tareas Cortas                 Tareas Largas

    Fuente: https://web.dev/long-tasks-devtools

    Mientras una tarea se está ejecutando, una página no puede responder a los inputs del usuario. Este es el retraso que se siente. Cuanto más larga sea la tarea, más largo será el retardo experimentado por el usuario. Los descansos entre tareas son las oportunidades que la página tiene para cambiar al input del usuario y responder a lo que querían hacer.

    Optimizando FID

    No veo nada preocupante en nuestro sitio en FID, pero en general, quieres dividir las tareas largas y retrasar cualquier JavaScript que no se necesite a un momento posterior.

    Recursos

    La diferencia entre los datos de campo y laboratorio se encuentra en que los datos de campo miran a usuarios reales, condiciones de red, dispositivos, cacheo, etc. y los datos de laboratorio se testan de forma consistente en base a las mismas condiciones, con la esperanza de que los resultados de la prueba sean repetibles.

    Datos de campo

     LCPFIDCLS
    Chrome User Experience Report
    PageSpeed Insights
    Google Search Console (Informe de Métricas Web Principales)
    Web-vitals JavaScript library
    web.dev
    Web Vitals Extension

    Datos de Laboratorio

     LCPFIDCLS
    Chrome DevTools✘ (usa TBT)
    Lighthouse✘ (usa TBT)
    WebPageTest✘ (usa TBT)
    PageSpeed Insights✘ (usa TBT)
    web.dev✘ (usa TBT)

    Me gusta el informe en GSC porque puedes ver los datos de muchas páginas a la vez, pero los datos tienen algo de retardo y son una media móvil de 28 días, así que puede que los cambios tarden algo de tiempo en mostrarse en el informe. En Chrome 88, Google está añadiendo Core Web Vitals (Métricas Web Principales) directamente en las herramientas para desarrolladores.

    También puedes encontrar las ponderaciones de las puntuaciones de Lighthouse en cualquier momento y ver los cambios históricos.

    Reflexiones finales

    Quieres mejorar las Métricas Web Principales (Core Web Vitals) para que tus usuarios tengan una mejor experiencia. Todavía queda por ver qué impacto tendrán en el SEO, pero como mencioné en mi artículo de velocidad de la página, deberían ayudarte a recoger más datos en tu analítica que se “sienta” como un incremento.

    Trabaja con tus desarrolladores; aquí son ellos los expertos. La velocidad de página puede ser extremadamente compleja. Si estás por tu cuenta, puede que necesites apoyarte en un plugin o servicio para gestionar esto, como WP Rocket or NitroPack.

    • Tuits 3
    Datos de Content Explorer