Google tiene la misión de mejorar el rendimiento de la web con Core Web Vitals. ¿Por qué? Porque el negocio de Google se basa predominantemente en la web: los sitios y las aplicaciones web lentos empujan a los usuarios a las aplicaciones nativas.
Tu ubicación en los resultados de búsqueda de Google está determinada en gran medida por las palabras clave del término de búsqueda, el uso de esas palabras clave dentro de tu página y la popularidad de tu página según el número (y la calidad) de los enlaces desde otros lugares. A partir de agosto de 2021, Google se está esforzando por evaluar también las páginas en función del rendimiento.
Este artículo te mostrará cómo puedes optimizar tu sitio para las métricas de Google Core Web Vitals.
¿Por qué Core Web Vitals?
El contenido sigue siendo crucial. Pero si se comparan dos sitios con texto y popularidad similares, el que ofrezca la mejor experiencia web tendrá mayor prioridad en los resultados de búsqueda de Google.
Además de una mejora en el rango de la página, los sitios de alto rendimiento son elegibles para su inclusión en el carrusel de búsqueda móvil. Anteriormente esto estaba reservado para las páginas móviles aceleradas (AMP), que requerían que se portara el contenido a un sitio separado alojado en Google. AMP ha suscitado críticas, sobre todo porque las páginas no siempre son más rápidas que un sitio estático o de WordPress bien optimizado. Sin embargo, eso ya no es un requisito.
Independientemente de lo que elijas, cuanto más rápido y receptivo sea tu sitio, más posibilidades tendrás de aparecer en los resultados de búsqueda de Google.
Si tenemos en cuenta que la página media ocupa unos 2 MB, realiza más de 60 peticiones HTTP y tarda 16 segundos en renderizarse por completo en un dispositivo móvil, veremos que hay margen para mejorar tu sitio. Te mostraremos las mejores formas de conseguir esas mejoras.
Factores clave de clasificación de Google
Hay cuatro factores clave de clasificación que hay que examinar antes de empezar a evaluar el rendimiento:
- HTTPS: HTTPS es esencial. ¿Establece tu sitio una conexión segura entre el navegador del usuario y el servidor web?
- Facilidad para los móviles:Tu sitio debe funcionar bien en un dispositivo móvil. ¿Es tu sitio utilizable en dispositivos de pantalla pequeña? ¿Se muestra sin desbordamientos de contenido? ¿Es el texto lo suficientemente grande? ¿Las áreas en las que se puede hacer clic son lo suficientemente amplias para el control táctil?
- Sin intersticiales:Evita los intersticiales intrusivos que requieren una cantidad excesiva de espacio en la pantalla. ¿Es tu contenido siempre legible? ¿Está parcialmente oscurecido por intersticiales emergentes o banners? ¿La publicidad o las promociones de marketing dificultan el uso del sitio?
- Navegación segura: Tu sitio debe estar libre de malware, virus, phishing, fraude y otras estafas.
Una vez que cumplas estos requisitos, se evaluará el rendimiento de tu sitio web.
¿Cómo evalúa Google el rendimiento de la web?
Hacer que tu sitio web se cargue rápidamente, se renderice con rapidez y que sea receptivo antes es vital. Pero, ¿se siente rápido para los usuarios?
Las aplicaciones de medición del rendimiento, como el navegador DevTools, informan de mediciones técnicas como:
- Tiempo de bloqueo: El tiempo de espera para que se inicie una descarga, normalmente debido a que otros activos, como las hojas de estilo y los scripts, tienen mayor prioridad.
- Resolución DNS: El tiempo para resolver un nombre de host a una dirección IP para recuperar un activo.
- Tiempo de conexión: El tiempo de inicialización de una conexión TCP.
- Time to First Byte (TTFB): El tiempo total entre la solicitud y el primer byte de la respuesta.
- Tiempo de recepción: El tiempo de recuperación de todo el activo.
- Tiempo de carga del DOM: El tiempo para descargar y renderizar el Modelo de Objetos del Documento HTML. Suele ser el primer punto en el que los scripts que analizan o modifican el DOM pueden ejecutarse de forma fiable.
- Tiempo de carga de la página: El tiempo de descarga de la página y de todos los activos como imágenes, hojas de estilo, scripts, etc.
- Peso total de la página: El tamaño total de todos los activos. A menudo se informa de un tamaño comprimido (descarga) y de un tamaño sin comprimir.
- El número de elementos DOM: El número total de elementos HTML en la página. Cuantos más elementos, más tiempo tarda la página en procesarse.
- First Contentful Paint (FCP): El tiempo que pasa antes de que el navegador renderice el primer píxel de contenido.
- First Meaningful Paint (FMP): El tiempo que transcurre antes de que el contenido de la página principal sea visible para el usuario.
- Time to Interactive (TTI): El tiempo que pasa antes de que una página sea totalmente interactiva y pueda responder de forma fiable a la entrada del usuario.
- Primer tiempo de inactividad de la CPU: El tiempo que tarda la CPU en renderizar la página y ejecutar todos los scripts de inicialización, a la espera de más entradas.
- Uso de la CPU: La actividad de procesamiento necesaria mientras se renderiza la página y se responde a la entrada del usuario.
- Diseños por segundo: La velocidad a la que el navegador tiene que recalcular los estilos y diseños de las páginas.
Pueden utilizarse para determinar cuellos de botella específicos, como la carga del servidor, la caché del CMS, la caché del navegador, la velocidad de descarga y la eficiencia de JavaScript. Pero no pueden determinar si una página proporciona una buena o mala experiencia al usuario. Por ejemplo:
- Una aplicación puede descargarse y aparecer rápidamente pero dejar de responder tras la primera interacción porque está ejecutando una gran cantidad de código JavaScript no optimizado.
- Una aplicación de chat podría descargar continuamente datos a medida que los usuarios publican mensajes. Una herramienta de evaluación podría suponer que no ha terminado de cargarse, a pesar de que la página parece responder.
Core Web Vitals es el propósito de Google para resolver estos dilemas.
¿Qué son las Core Web Vitals?
Las Core Web Vitals (CWV) de Google son tres métricas de rendimiento que evalúan la experiencia del usuario en el mundo real:
- Largest Contentful Paint -LCP (tiempo de renderización del mayor elemento de contenido visible): Rendimiento de la carga
- First Input Delay- FID (retraso en la primera entrada): Rendimiento de la interactividad
- Cumulative Layout Shift-CLS (cambio de diseño acumulativo): Rendimiento de la estabilidad visual
Esta nueva actualización del algoritmo de Google ha comenzado a desplegarse globalmente a finales de agosto de 2021. Las métricas de Core Web Vitals afectan principalmente a los resultados de las búsquedas en móviles, pero los equivalentes para ordenadores de sobremesa seguirán si el experimento tiene éxito.
Las puntuaciones de LCP, FID y CLS de una página se basan en los últimos 28 días de métricas de usuarios reales recogidas de forma anónima a través del navegador Chrome. Estas mediciones pueden variar debido al dispositivo del usuario, la conexión y otras actividades concurrentes, por lo que se calcula el percentil 75 en lugar de una media.
En otras palabras, las métricas de todos los usuarios se ordenan de mejor a peor, y se toma la cifra en el punto de las tres cuartas partes. Por tanto, tres de cada cuatro visitantes del sitio web experimentarán ese nivel de rendimiento o uno mejor.
Cualquier página que obtenga una buena puntuación (verde) en las tres métricas de Core Web Vitals recibirá una mejor clasificación en los resultados de búsqueda y se incluirá en el carrusel de «Top Stories» de la aplicación Google News.
En las siguientes secciones, describiremos el algoritmo utilizado para calcular una métrica, las herramientas que puede utilizar para identificar la puntuación de una página, las causas típicas de las puntuaciones bajas y los pasos que puede dar para resolver los problemas de rendimiento.
Largest Contentful Paint (LCP)
Largest Contentful Paint mide el rendimiento de la carga. En esencia, ¿con qué rapidez se renderiza el contenido utilizable en la página?
LCP analiza el tiempo que tarda la imagen o el bloque de texto más grande en ser visible dentro de la ventana gráfica del navegador (por encima del pliegue). En la mayoría de los casos, el elemento más prominente será una imagen principal, un banner, un encabezado o un bloque de texto grande.
Cualquiera de los siguientes elementos es elegible para el análisis de la pintura de mayor contenido:
- imágenes (elemento
<img>) - imágenes dentro de gráficos vectoriales (una
<image>incrustada en un<svg>) - miniaturas de vídeo (un atributo de póster establecido en una URL de imagen dentro de un elemento
<video>) - elementos con imágenes de fondo (normalmente cargados con la propiedad CSS
background-image url()) - elementos a nivel de bloque que contienen texto
Las páginas en las que la Largest Contentful Paint se completa en los primeros 2,5 segundos de la carga de la página se consideran buenas (verde). Las páginas que superan los 4,0 segundos se consideran malas (rojo):
Herramientas de análisis de Largest Contentful Paint
LCP es la métrica de Core Web Vital más fácil de comprender, pero puede que no sea obvio qué elemento se elegirá para el análisis.
El panel DevTools Lighthouse se proporciona en los navegadores basados en Chromium como Chrome, Edge, Brave, Opera y Vivaldi. Abre DevTools desde el menú del navegador -generalmente en Más herramientas > Herramientas de desarrollo o los atajos de teclado Ctrl | Cmd + Shift + i o F12– y luego navega hasta la pestaña Lighthouse (las ediciones más antiguas pueden nombrarla Auditoría).
Genera un informe de Rendimiento móvil y examina la sección de Rendimiento resultante. El mayor tiempo de Largest Contentful Paint se muestra con una sección ampliable, que identifica el elemento elegido:
Puedes generar información idéntica en las herramientas online PageSpeed Insights y web.dev Measure si no tienes acceso a un navegador basado en Chromium:
El panel de DevTools Performance también muestra un indicador de LCP. Para empezar, haz clic en el icono circular de Registro, recarga tu página y, a continuación, haz clic en el botón Detener para ver el informe. Haz clic en el icono LCP de la sección Tiempos para identificar el elemento y ver un resumen de las estadísticas.
La extensión Web Vitals está disponible para Google Chrome, pero puede instalarse en la mayoría de los navegadores basados en Chromium. Calcula las métricas de Core Web Vitals para cada sitio que visites, y su icono se vuelve verde, naranja o rojo en función del resultado. También puedes hacer clic en el icono de la extensión para ver más detalles de LCP:
Search Console de Google ofrece ahora una sección de Core Web Vitals si tu sitio se añade como propiedad. El informe ilustra cómo han cambiado las métricas de CWV a lo largo del tiempo. Ten en cuenta que no identifica las métricas específicas de LCP, y que sólo están disponibles los sitios con un tráfico razonablemente alto:
El informe sobre la experiencia de los usuarios de Chrome permite consultar las estadísticas de uso real, incluida la LCP en diferentes países, conexiones y dispositivos, para una URL específica. Es un proyecto público en Google BigQuery, por lo que debes registrarte en una cuenta de Google Cloud Platform y proporcionar los datos de facturación. De nuevo, el informe solo será útil cuando una URL tenga un nivel de tráfico razonablemente alto.
Por último, la biblioteca JavaScript de web-vitals es un pequeño script de 1 kB que puede calcular LCP y otras métricas de Core Web Vital para usuarios reales en tu sitio en vivo. Como se puede descargar desde un CDN, puedes añadir el siguiente script a tu HTML <head>:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getLCP } from 'https://unpkg.com/web-vitals?module';
getLCP(console.log);
</script>
<!-- rest of page -->
getLCP() es una función asíncrona a la que se le pasa una llamada de retorno que se activa cuando se ha calculado el valor de LCP (aunque puede que nunca se active si la página se carga en una pestaña de fondo). A la función callback se le pasa un objeto que contiene:
name: el nombre de la métrica («LCP» en este caso)value: el valor calculadoid: un ID único que representa esta métrica para la página actualdelta: el delta entre el valor actual y el último valor comunicadoentries: una matriz de entradas utilizadas en el cálculo del valor
El script anterior envía el objeto a la consola, aunque es más práctico enviar los datos a un servidor o a Google Analytics para su posterior análisis.
Causas comunes de las puntuaciones de Largest Contentful Paint
Las puntuaciones bajas de LCP suelen estar causadas por páginas de carga lenta que impiden que el bloque más grande aparezca rápidamente:
- La respuesta del servidor puede ser lenta porque está sobrecargado o está haciendo demasiado trabajo para renderizar una página. Esto no tiene por qué ser culpa de tu sitio, sino que puede deberse a las limitaciones del servidor si utilizas un servicio de alojamiento compartido.
- El CSS y el JavaScript que bloquean la renderización pueden retrasar la carga de la página si están referenciados en el HTML por encima del contenido principal.
- Otros recursos, como las imágenes y los vídeos de gran tamaño, pueden reducir el ancho de banda disponible y tardar más tiempo en renderizarse.
- El contenido de la página generado en el cliente y no en el servidor también tarda más en aparecer.
Cómo mejorar las puntuaciones de Largest Contentful Paint
Una auditoría exhaustiva puede identificar los problemas de carga, pero generalmente se trata de reducir la cantidad de datos enviados al navegador. Los siguientes consejos ayudarán a conseguir una puntuación LCP más saludable:
- Actualiza tu servidor y/o servicio de alojamiento. Asegúrate de que la velocidad de descarga siga siendo rápida incluso en momentos de alto uso.
- Activa la compresión del servidor y HTTP/2+. No hay razón para no hacerlo.
- Reduce el esfuerzo del servidor. Elimina el código y los plugins de CMS que no se utilicen y habilita un almacenamiento en caché eficaz.
- Asegúrate de que el navegador puede almacenar los archivos en caché de forma eficaz. Establece los Expires, Last-Modified y/o ETag adecuados en la cabecera HTTP, para que los archivos no se vuelvan a solicitar.
- Utiliza una red de distribución de contenidos (CDN) para dividir la carga y alojar los activos en servidores geográficamente más cercanos a los usuarios.
- Aumenta tu optimización general utilizando la función de minificación de código que está integrada en el panel de MyKinsta.
- Optimiza tus imágenes. Redúcelas a sus dimensiones más pequeñas y utilice un formato adecuado para minimizar el tamaño de los archivos. Asegúrese de que cualquier imagen en el bloque de contenido más grande se solicite lo antes posible; una precarga podría ayudar.
- Lazy-load de imágenes añadiendo un atributo
loading="lazy". Añade atributos de anchura y altura para asegurar que se reserva el espacio adecuado en la página antes de que la imagen termine de cargarse. - Reducec al mínimo las solicitudes de terceros y considera la posibilidad de trasladar los activos a tu dominio principal para evitar búsquedas de DNS extrañas.
- Minimiza el número y el tamaño de los archivos solicitados, especialmente en la parte superior de su HTML.
- Asegúrate de cargar sólo las fuentes web necesarias. Cambia a fuentes seguras para la web para obtener el máximo rendimiento.
- Eliminar los archivos JavaScript y CSS que no se utilizan.
- Concatene y minifique los archivos JavaScript y CSS.
- Evita las sentencias CSS @import, ya que bloquean la renderización y cargan los estilos en serie.
- Evita la codificación Base64: aumenta el tamaño de los archivos y requiere un procesamiento adicional.
- Considera el CSS crítico en línea. Incrusta el CSS esencial «por encima de la página» en un bloque
<link>en la parte superior de la página, y luego carga otras hojas de estilo de forma asíncrona. - Utiliza JavaScript asíncrono, diferido o de módulo ES para ejecutar scripts más tarde. Ejecuta procesos JavaScript de larga duración en un trabajador de servicios.
First Input Delay (FID)
El First Input Delay mide la capacidad de respuesta de tu página. En esencia, ¿con qué rapidez responde a las acciones del usuario, como hacer clic, tocar o desplazarse?
La métrica FID se calcula como el tiempo que transcurre entre la interacción del usuario y el procesamiento de su solicitud por parte del navegador. No mide el tiempo de ejecución de la función manejadora, que normalmente procesaría la entrada y actualizaría el DOM.
Las páginas con un tiempo FID de 100 milisegundos o menos se consideran buenas (verde). Las páginas que superan los 300 milisegundos se consideran malas (rojo):
Herramientas de análisis del First Input Delay
El First Input Delay es imposible de simular porque sólo puede medirse cuando la página se sirve a un usuario real que interactúa con ella. Por lo tanto, el resultado depende de la velocidad y las capacidades del procesador de cada dispositivo.
El FID no se calcula en el panel DevTools Lighthouse ni en PageSpeed Insights. Sin embargo, pueden determinar el Tiempo Total de Bloqueo (TBT). Esta es una aproximación razonable para el First Input Delay. Mide la diferencia de tiempo entre:
- La First Contentful Paint (FCP), o el momento en que el contenido de la página comienza a renderizarse, y
- El Time to Interactive (TTI), o el tiempo en el que la página puede responder a la entrada del usuario. El TTI se presume cuando no hay tareas de larga duración activas y quedan menos de tres peticiones HTTP por completar.
La extensión Web Vitals para Google Chrome también puede mostrar una métrica FID después de interactuar con la página desplazándose o haciendo clic. Haz clic en el icono de la extensión para ver más información:
Al igual que el LCP, el informe de experiencia de usuario de Chrome permite consultar las estadísticas reales de FID registradas en diferentes países, conexiones y dispositivos para una URL específica.
La biblioteca JavaScript de web-vitals también puede calcular las métricas FID para usuarios reales en tu sitio en vivo. Puede añadir la siguiente secuencia de comandos a su HTML <head> para dar salida a las métricas FID a una función de devolución de llamada:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getFID } from 'https://unpkg.com/web-vitals?module';
getFID(console.log);
</script>
<!-- rest of page -->
Causas comunes de la mala puntuación del First Input Delay
Las puntuaciones pobres de FID y TBT suelen estar causadas por código del lado del cliente que acapara el procesador, como:
- Cantidades significativas de CSS y JavaScript que bloquean la renderización, lo que detiene la carga de la página mientras se descarga y analiza el código
- Scripts grandes y de gran intensidad de proceso que se ejecutan inmediatamente cuando se carga la página
- Tareas de JavaScript de larga duración o mal optimizadas
Por defecto, los navegadores se ejecutan en un único hilo, que sólo puede procesar una tarea a la vez. Si una función de JavaScript tarda un segundo en ejecutarse, todos los demás procesos de renderización se bloquean durante ese segundo. La página no puede reaccionar a la entrada del usuario, actualizar el DOM, mostrar animaciones, etc. Incluso las animaciones GIF pueden bloquearse en los navegadores más antiguos.
Cómo mejorar las puntuaciones de la First Input Delay
Una auditoría de JavaScript del lado del cliente puede identificar problemas, pero generalmente se trata de eliminar el código redundante y asegurar que las tareas se ejecuten rápidamente.
Los siguientes consejos ayudarán a conseguir una puntuación FID más saludable:
- Generar y almacenar en caché la mayor cantidad posible de contenido HTML estático en el servidor. Intenta no depender de los frameworks JavaScript del lado del cliente para renderizar el mismo HTML para todos.
- Asegúrate de que el navegador puede almacenar los archivos en la caché de forma eficaz. Establece los Expires, Last-Modified y/o ETag adecuados en la cabecera HTTP, para que los archivos no se vuelvan a solicitar.
- Adoptar técnicas de mejora progresiva, para que la interfaz se pueda utilizar en HTML y CSS antes de que se ejecute JavaScript.
- Eliminar los archivos JavaScript y CSS que no se utilizan.
- Concatener y minificar tus archivos JavaScript y CSS.
- Evite el uso excesivo de propiedades CSS costosas como box-shadow y filter.
- Utiliza JavaScript asíncrono, diferido o de módulo ES para ejecutar los scripts más tarde.
- Reducir al mínimo las solicitudes de JavaScript de terceros para análisis, widgets de redes sociales, foros de discusión, etc. Estos pueden acumular rápidamente varios megabytes de JavaScript.
- Cargar de forma lazy-loading componentes de JavaScript bajo demanda, por ejemplo, widgets de chat, reproductores de vídeo, etc.
- Retrasar la carga de scripts menos críticos como los de análisis, publicidad y herramientas de redes sociales.
- Dividir las tareas de JavaScript de larga duración en una serie de trabajos más pequeños que se ejecutan después de un breve retraso de requestIdleCallback, setTimeout o requestAnimationFrame.
- Considera la posibilidad de ejecutar procesos JavaScript de larga duración en un web worker, que utiliza un hilo de fondo.
Cumulative Layout Shift (CLS)
CLS mide la estabilidad visual de la página. En esencia, ¿el contenido de la página se mueve o salta inesperadamente, especialmente durante la carga inicial?
CLS calcula una puntuación cuando los elementos se mueven sin previo aviso o sin la interacción del usuario. Probablemente lo has experimentado al leer un artículo en un dispositivo móvil: el texto salta repentinamente fuera de la pantalla y pierde su lugar. En el peor de los casos, podría hacer clic en un enlace incorrecto.
Los problemas de CLS son más evidentes cuando se carga una imagen o un anuncio de gran tamaño por encima de la posición de desplazamiento actual y un espacio de altura cero crece instantáneamente en varios cientos de píxeles.
Las puntuaciones de Cumulative Layout Shift se calculan multiplicando las siguientes métricas:
- La fracción de impacto: Es el área total de todos los elementos inestables en la ventana gráfica, es decir, los que «saltarán». Si los elementos que cubren el 60% de la ventana gráfica se desplazan durante la carga de la página, la fracción de impacto es de 0,6. Ten en cuenta que los elementos que han provocado ese desplazamiento, como una imagen o un anuncio, se consideran estables porque no se mueven necesariamente después de ser renderizados.
- La fracción de distancia: Es la mayor distancia desplazada por cualquier elemento inestable en la ventana gráfica. Si el mayor desplazamiento se produce en un elemento que se mueve de 0,100 a 0,800, se ha desplazado 700 píxeles verticales. Si la ventana gráfica del dispositivo tiene 1.000 px de altura, la fracción de distancia es de 700 px / 1000 px = 0,7. Por lo tanto, la puntuación calculada del Desplazamiento de Diseño Acumulado es de 0,6 x 0,7 = 0,42.
Google ha realizado cambios en la métrica CLS para adaptarse a las siguientes situaciones:
- Los turnos de disposición se agrupan en «sesiones» que duran cinco segundos pero que se cierran después de un segundo si no se producen más turnos de disposición. Si se producen dos o más desplazamientos en un segundo, se suman sus puntuaciones.
- Los cambios de diseño no se registran hasta 500 ms después de la interacción del usuario, como un clic. En algunos casos, esto desencadena actualizaciones del DOM (por ejemplo, abrir un menú, mostrar un mensaje de error, mostrar un diálogo modal, etc.).
- Las aplicaciones de una sola página que permanecen abiertas durante períodos más prolongados y realizan numerosas actualizaciones del DOM no se ven afectadas negativamente.
Las páginas con una puntuación CLS de 0,1 o menos se consideran buenas (verde). Las páginas que superan el 0,25 se consideran malas (rojo):
Herramientas de análisis del Cumulative Layout Shift
Las métricas de CLS se calculan en el panel DevTools Lighthouse, PageSpeed Insights y las herramientas web.dev Measure:
La extensión Web Vitals para Google Chrome también muestra la métrica CLS:
Al igual que el LCP y el FID, el Informe de la experiencia del usuario de Chrome te permite consultar las estadísticas reales del CLS registradas en diferentes países, conexiones y dispositivos para una URL específica.
La biblioteca JavaScript de web-vitals también puede calcular las métricas de CLS para usuarios reales en tu sitio en vivo, al igual que lo hace con LCP y FID. La siguiente secuencia de comandos podría añadirse a tu HTML <head> para dar salida a las métricas CLS a una función de devolución de llamada:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>My page</title>
<script type="module">
import { getCLS } from 'https://unpkg.com/web-vitals?module';
getCLS(console.log);
</script>
<!-- rest of page -->
Causas comunes de las bajas puntuaciones de
Las puntuaciones bajas de CLS suelen deberse a la lentitud de carga de los activos de la página y a los elementos dinámicos o sin tamaño del DOM:
- El espacio de la página no está reservado para imágenes, iframes, anuncios, etc.
- El contenido se inyecta dinámicamente en el DOM, normalmente después de una solicitud de red para anuncios, widgets de redes sociales, etc.
- La carga de fuentes web provoca un notable Flash de Texto Invisible (FOIT) o Flash de Texto sin Estilo (FOUT).
Cómo mejorar las puntuaciones de Cumulative Layout Shift
Una auditoría del lado del cliente puede identificar los problemas, pero generalmente se trata de asegurar que el espacio está reservado para el contenido antes de que se descargue. Los consejos de optimización del servidor sugeridos para Largest Contentful Paint tendrán algún beneficio, pero es posible realizar más mejoras:
- Añade atributos de anchura y altura a las etiquetas HTML
<img>y<iframe>o utiliza la nueva propiedad CSS aspect-ratio para asegurarte de que se reserva el espacio adecuado en la página antes de que se descarguen los activos. - Establece las dimensiones adecuadas para los elementos contenedores que encierran contenidos de terceros que se cargan lentamente, como los anuncios y los widgets.
- Asegúrate de que las imágenes y otros activos que aparecen hacia la parte superior de la página se solicitan lo antes posible: una precarga podría resultar útil.
- Reduzce al mínimo el uso de las fuentes web y considera la posibilidad de utilizar las fuentes disponibles en el sistema operativo cuando sea posible.
- Carga las fuentes web y configure la visualización de fuentes CSS como opcional o de intercambio. Asegúrate de utilizar una fuente de reserva de tamaño similar para minimizar el cambio de diseño.
- Evita insertar elementos hacia la parte superior de la página a menos que responda a una acción del usuario como un clic.
- Asegúrate de que las interacciones del usuario se completan dentro de los 500 milisegundos siguientes a la activación de la entrada.
- Utiliza la transformación y la opacidad de CSS para lograr animaciones más eficientes que no impliquen un rediseño.
- Considera el CSS crítico en línea. Incrusta el CSS esencial «por encima de la página» en un bloque
<link>en la parte superior de la página, y luego carga las hojas de estilo adicionales de forma asíncrona. - Cuando sea necesario, considera la contención, una nueva función de CSS que permite identificar subárboles aislados de una página. El navegador puede optimizar el procesamiento al renderizar -o no renderizar- bloques de contenido DOM específicos.
Resumen
Los desarrolladores no siempre están dispuestos a bailar al son de Google. La empresa tiene un poder considerable, y las pequeñas actualizaciones del motor de búsqueda pueden afectar negativamente a la productividad y la rentabilidad de las organizaciones basadas en la web.
Dicho esto, Core Web Vitals adopta un enfoque de «zanahoria» más que de «palo». Los sitios bien optimizados y utilizables que renuncian a los patrones oscuros tienen más posibilidades de éxito que los sitios hinchados y con muchas ventanas emergentes que ofrecen una interfaz de usuario móvil deficiente.
Core Web Vitals proporciona una forma medible de evaluar la experiencia del usuario para ayudarte a centrarse en las mejoras más críticas. Puede que los cambios en los vitales no aumenten los ingresos, pero tus usuarios estarán más contentos y serán más fieles.
¿Tienes otro consejo para mejorar Core Web Vitals? Compártelos en la sección de comentarios.
Deja una respuesta