Velocidad de un sitio: las Core Web Vitals para un directivo

Un día llega a su mesa un informe de velocidad, con una puntuación en rojo y siglas en inglés: LCP, INP, CLS. La tentación es pasárselo al proveedor y olvidarse. Sería una pena: detrás de esas siglas hay tres sensaciones que experimenta cada uno de sus visitantes, y algunas decisiones que no son técnicas, sino suyas. Este artículo las traduce. Para el contexto técnico (por qué un sitio estático parte con ventaja), vea nuestra guía de la migración a Astro.

En resumen

• Tres mediciones: el tiempo en mostrar el contenido principal, el tiempo de reacción a un clic y la estabilidad de la página.
• Google las mide en sus visitantes reales y juzga sobre las tres cuartas partes más lentas de las visitas, en móvil y en ordenador.
• Cuentan en la clasificación, pero menos que la pertinencia: su primer efecto recae en las solicitudes recibidas.
• Las causas son a menudo decisiones: imágenes demasiado pesadas, scripts de marketing añadidos uno a uno, una página fabricada en cada visita.

Tres mediciones, tres sensaciones

Cada medición describe lo que siente un visitante, y Google publica un umbral para cada una:

Dos precisiones cambian la lectura. Primero, Google recomienda juzgar en el percentil 75: no basta con que la media de las visitas sea rápida, tres visitas de cada cuatro deben serlo, con móvil y ordenador por separado. Después, la reacción a los clics (INP) sustituyó en 2024 a una medición anterior que solo miraba la primera interacción: un sitio que estaba «en verde» hace tres años puede haber dejado de estarlo sin haber cambiado.

Lo que Google hace con ellas

Google lo dice en su documentación sobre las Core Web Vitals: unos buenos resultados coinciden con lo que sus sistemas de clasificación intentan recompensar. Pero la misma casa matiza:

Google añade que una buena puntuación en sus informes no garantiza un lugar a la cabeza de los resultados. Dicho de otro modo: un sitio lento pero único en responder a una pregunta sigue siendo visible, y un sitio rápido sin contenido útil no sube. La velocidad desempata entre páginas comparables; no sustituye ni al contenido ni a la reputación.

Lo que la lentitud cuesta realmente

El efecto más directo de la velocidad no está en la clasificación, sino en lo que hacen los visitantes una vez que llegan. El estudio más citado sobre el tema, realizado por Deloitte a petición de Google sobre los sitios móviles de 37 marcas europeas y estadounidenses, midió lo que cambia una ganancia de una décima de segundo:

Estas cifras proceden de grandes marcas y de un estudio encargado por Google: indican una dirección, no una promesa para su sitio. La dirección, en cambio, se confirma allí donde se mide. Nuestro artículo sobre las páginas de destino muestra lo que cuesta cuando se paga cada clic.

Dónde están los sitios que conocemos

Este es el tiempo en mostrar el contenido principal, medido por Lighthouse en simulación móvil, en tres sitios que conocemos de cerca:

La tienda de peluches mostraba además una puntuación Lighthouse móvil de 65 y una página de 4,2 MB. En este sitio, la misma medición da una puntuación de 99 y 233 KiB transferidos. La diferencia no se debe al talento de los equipos: se debe a lo que el navegador tiene que descargar y ejecutar antes de mostrar nada.

Medición de laboratorio, medición de campo

Circulan dos familias de cifras, y no dicen lo mismo:

• El laboratorio (Lighthouse, la parte de «diagnóstico» de PageSpeed Insights) simula un teléfono medio en una red media. Es la medición adecuada para comparar antes y después de un cambio, en condiciones idénticas.
• El campo procede de las visitas reales. El informe Core Web Vitals de Search Console se basa en estos datos de uso real, procedentes del informe de experiencia de usuario de Chrome, y clasifica sus grupos de páginas como «Buena», «Necesita mejorar» o «Mala».

Es el campo lo que cuenta para Google, y para sus clientes. Un sitio puede parecer rápido con la fibra de la oficina y lento en un tren: el informe de campo lo dice, su impresión no lo dirá.

Lo que ralentiza un sitio, y quién lo decide

Las causas técnicas se reducen a menudo a decisiones tomadas sin relacionarlas con la velocidad:

• Las imágenes. Una foto exportada a plena resolución pesa diez veces lo necesario. En Palmora Property, la cadena de imágenes convirtió 3 892 originales en 7 784 archivos en los formatos adecuados, y una miniatura pasó de 353 KB a 17 KB.
• Los scripts añadidos uno a uno. Chat, opiniones de clientes, seguimiento publicitario, mapa: cada uno es útil, y cada uno se carga. En la tienda de peluches se cargaban cuatro o cinco sistemas de opiniones, sin que se mostrara ninguna opinión.
• La página fabricada en cada visita. Un sitio que ensambla sus páginas en un servidor espera a ese servidor; un sitio estático sirve un archivo ya preparado, desde el punto más cercano al visitante (vea nuestra comparativa de alojamiento).
• Las extensiones. En un CMS, cada extensión puede añadir sus scripts y sus estilos a todas las páginas, y sus actualizaciones que vigilar (vea por qué se piratea un sitio WordPress).

Tres decisiones corresponden, por tanto, al directivo. Exigir una medición fechada antes de cualquier proyecto, para saber qué ha cambiado. Escribir los umbrales en el pliego de condiciones de un rediseño, al mismo nivel que las páginas y los idiomas (vea el coste de un sitio de empresa y la selección de páginas antes de un rediseño). Arbitrar los scripts de terceros: cada herramienta de marketing añadida debe valer el tiempo que hace perder en cada visita.

La velocidad se une también a la accesibilidad: una página que no se mueve bajo el dedo y reacciona rápido sirve primero a quienes navegan con el teclado o con una ayuda técnica (vea lo que cambia la obligación europea de accesibilidad). Los sitios cuyo contenido procede de un CMS headless conservan estas ventajas para el visitante, como explica nuestro artículo sobre Astro y Sanity; los formularios y la búsqueda también, si están conectados página a página. Y cuando se producen textos con una IA para ir más rápido, la cuestión de decirlo se plantea aparte.

Un sitio corporativo que entregamos está construido para ser rápido en móvil desde su puesta en línea; una migración a un sitio estático mide la velocidad antes y después, en las mismas condiciones.

Preguntas frecuentes

Fuentes

1. Web.dev (Google), las Core Web Vitals (nueva pestaña)web.dev
2. Google Search Central, Core Web Vitals (nueva pestaña)developers.google.com
3. Ayuda de Search Console, informe Core Web Vitals (nueva pestaña)support.google.com