Velocidad del sitio web y Core Web Vitals: Una guía completa

Lo que significan los Core Web Vitals en lenguaje sencillo

Comencemos con lo esencial.Core Web Vitals son tres métricas que Google utiliza para medir cómo se carga realmente una página a través de los ojos de un ser humano real, no de un robot. Responden a tres preguntas simples: ¿apareció rápidamente el contenido principal?, ¿reaccionó el sitio rápidamente a tu acción?, y ¿se mantuvo el diseño en su lugar bajo tu dedo?

LCP — qué tan rápido se muestra el contenido principal

LCP (Pintura de Contenido Más Grande) es el momento en que el elemento visible más grande termina de renderizarse: generalmente una imagen principal, un titular o un gran banner. Un visitante considera que la página está cargada cuando ese bloque aparece, no cuando llega el último script del pie de página. Un objetivo sólido en 2026 es aproximadamente 2.5 segundos en una conexión móvil típica.

INP — qué tan rápido responde el sitio

INP (Interacción para la Siguiente Pintura)reemplazó el antiguo FID y mide la capacidad de respuesta: tocas un botón, abres un menú, comienzas a escribir, y cuántos milisegundos pasan antes de que la interfaz reaccione visiblemente. Si no sucede nada durante medio segundo después de un clic, el cerebro se convence de que el sitio se congeló. Un rango cómodo es inferior a 200 milisegundos.

CLS — cuán estable es el diseño

CLS (Desplazamiento Acumulativo de Diseño)captura el error más molesto: apuntas a un botón, se carga una imagen o banner encima, todo salta hacia abajo y haces clic en lo incorrecto. Es un desplazamiento acumulativo del diseño, y cuanto más cerca de cero, más ordenado se siente el sitio. Un valor saludable es inferior a 0.1.

Recuerda una fórmula simple: LCP se trata de ver, INP se trata de tocar, CLS se trata de no saltar. Google recopila los tres de usuarios reales de Chrome y los trata como parte de una señal de calidad de página para el ranking.

Por qué la velocidad afecta el SEO y la conversión

Seamos claros: un sitio lento pierde dinero en la puerta, antes de que el visitante haya leído una sola palabra. Cada segundo adicional de espera aumenta la proporción de personas que cierran la pestaña y se van a un competidor que se abre instantáneamente.

Velocidad y rankings de búsqueda

Los Core Web Vitals son un factor de ranking oficial. Esto no significa que una página rápida pero vacía supere a una lenta pero experta: el contenido sigue siendo lo primero. Pero cuando dos piezas están cerca en calidad, la velocidad se convierte en el desempate que te eleva más alto. Un sitio rápido también es rastreado más a fondo: con el mismo presupuesto de rastreo, el bot llega a más de tus páginas.

Velocidad y dinero

En proyectos comerciales, el vínculo entre velocidad del sitio web y los ingresos es evidente. Acelerar la primera pantalla eleva notablemente la conversión en el proceso de pago y en los formularios, reduce tu costo de adquisición (dejas de perder la mitad de tu tráfico pagado en la pantalla de carga) y aumenta la profundidad de navegación de las personas. Hemos visto esto repetidamente en nuestro trabajo de desarrollo y optimización: el rendimiento técnico se recupera más rápido que otra campaña publicitaria más.

También hay una capa de reputación. Un sitio lento se lee subconscientemente como poco confiable: si todo se entrecorta aquí, ¿puedo confiar en él con mi pago? La velocidad es el primer apretón de manos de tu marca, y debería sentirse segura.

Cómo medir la velocidad: laboratorio vs campo

Antes de arreglar algo, mide con honestidad. Y aquí es vital separar dos tipos de datos fundamentalmente diferentes, porque las personas los confunden constantemente.

Datos de laboratorio

Laboratorio las mediciones son tomadas por una herramienta en condiciones controladas: una conexión fija, un dispositivo definido, un ambiente limpio. Esto es Lighthouse (integrado en Chrome DevTools) y la sección de laboratorio de PageSpeed Insights. La ventaja es la repetibilidad: cambias el código y ves inmediatamente si las cosas mejoraron. La desventaja es que es una simulación, no personas reales.

Datos de campo

Campo los datos son métricas recopiladas de usuarios reales de Chrome (el conjunto de datos CrUX). Estos son exactamente los que Google utiliza para el ranking. Muestran cómo se comporta el sitio en dispositivos reales, redes reales y geografía real. Los números de campo se miden en el percentil 75: el objetivo es que el sitio sea rápido no en promedio, sino para tres cuartas partes de la audiencia.

Un pedido de medición práctico

1. Ejecuta tus plantillas clave (inicio, categoría, producto, formulario) a través de PageSpeed Insights — por separado para móvil y escritorio.
2. Mira primero el campo Core Web Vitals si existen; usa la puntuación del laboratorio como una herramienta de depuración.
3. Abre la pestaña de Rendimiento en DevTools y encuentra qué elemento impulsa LCP y qué scripts bloquean el hilo principal.

La regla de oro: optimiza por el campo, depura por el laboratorio. Perseguir un bonito cien en Lighthouse sin tener en cuenta a los usuarios reales es un trabajo hecho para una captura de pantalla, no para el negocio.

LCP: qué cubre y cómo mejorarlo

LCP es generalmente lo que la gente quiere decir cuando dice que el sitio tarda una eternidad en cargar. Mejorarlo significa mostrar el elemento principal de la primera pantalla antes. Desglosemos esto en partes.

De qué está hecho el LCP

El LCP tiene cuatro ingredientes: el tiempo de respuesta del servidor (TTFB), un retraso antes de que el recurso comience a cargarse, el tiempo de carga del recurso en sí y el tiempo de renderizado. Cualquiera de ellos puede ser el cuello de botella, por lo que el tratamiento comienza con un diagnóstico, no con suposiciones.

Qué acelera realmente el LCP

• Una respuesta rápida del servidor.Mantén el TTFB bajo: caché del lado del servidor, alojamiento adecuado y pocas consultas pesadas a la base de datos al generar la primera pantalla.
• Prioridad para el recurso principal.La imagen LCP o la fuente del encabezado deben cargarse con alta prioridad (preload), no en la cola general.
• Sin carga diferida para la primera pantalla.Un error clásico es poner carga diferida en el banner superior. Guarda la carga diferida para lo que está debajo del pliegue.
• Un elemento LCP ligero y correctamente comprimido.Un héroe PNG gigante de 2 MB arruinará la métrica incluso en un servidor rápido.

Una palabra sobre el bloqueo de renderizado. Si el navegador debe descargar y ejecutar CSS y JavaScript pesados antes de mostrar la primera pantalla, el LCP se retrasa exactamente ese tiempo. Por eso el CSS crítico está en línea mientras que los scripts secundarios se posponen y se diferencian.

INP y CLS: capacidad de respuesta y estabilidad

Si el LCP se trata de ver, el INP y el CLS se refieren a la sensación de calidad después de la carga. A menudo se subestiman, y eso es un error: son exactamente lo que hace que un sitio se sienta cuidadosamente construido.

Cómo mejorar el INP

Un mal INP casi siempre significa que el hilo principal del navegador está ocupado con JavaScript pesado. El usuario toca — pero en ese momento el hilo está procesando análisis, moviendo un control deslizante o renderizando un widget, y la reacción se retrasa. Lo que ayuda:

• Divide las tareas largas en tareas cortas, dando al navegador pausas para manejar los clics.
• Elimina o difiere scripts de terceros que se ejecutan en segundo plano.
• Evita controladores pesados en cada movimiento y pulsación de tecla.
• Mueve cálculos opcionales fuera del momento de interacción.

Cómo eliminar los cambios de diseño (CLS)

El CLS se cura con disciplina en el marcado. Las reglas principales:

1. Siempre establece el ancho y la altura (o la relación de aspecto) en imágenes y videos para que se reserve espacio de antemano.
2. Reserva espacio para banners, widgets y espacios publicitarios en lugar de permitir que empujen el contenido cuando aparecen.
3. Carga fuentes de manera que el cambio de la fuente del sistema a una personalizada no mueva el texto (métricas correctas de font-display y fallback).
4. Nunca insertes contenido por encima de lo que el usuario ya ve, solo por debajo.

Los pagos y formularios son un punto de dolor especial. En nuestro proyecto de servicio de pago Payora observamos la estabilidad de la primera pantalla especialmente de cerca: cuando hay dinero involucrado, un diseño que salta y una respuesta lenta del botón reducen directamente la confianza y el número de transacciones completadas.

Las principales causas de un sitio lento

Buenas noticias: los sitios lentos tienen pocas causas, y son sorprendentemente típicas. En nueve de cada diez casos, alguien de esta lista es el culpable.

Imágenes pesadas

El peso pesado absoluto del tamaño de la página. Fotos en resolución completa, capturas de pantalla en PNG de varios megabytes, imágenes que el navegador reduce a un tamaño pequeño pero descarga en su totalidad. A menudo, la imagen también es el elemento LCP, por lo que es un doble golpe.

Fuentes

Varios pesos en formatos pesados, cargados desde un dominio externo, sin precarga, y el texto parpadea o aparece tarde, desplazando el diseño a medida que avanza.

CSS y JavaScript bloqueantes

Paquetes gigantes que deben ser descargados y ejecutados antes de la primera pintura. Los frameworks pesados son especialmente derrochadores donde un par de líneas de código serían suficientes.

Scripts de terceros

Chats, píxeles, una docena de etiquetas de análisis, widgets sociales, pruebas A/B. Cada uno es ligero por sí solo, pero juntos consumen el hilo principal y arruinan el INP. Esta es la categoría más subestimada.

Alojamiento lento y alto TTFB

Si el servidor piensa por un segundo antes de responder, ninguna magia del front-end lo oculta completamente. Alojamiento barato sobrecargado, sin caché de servidor, consultas pesadas a la base de datos: todo esto está en la base de LCP.

La conclusión práctica: no te apresures a arreglar todo de una vez. Mide primero, encuentra tu principal fuente de pérdida — y ataca eso.

Optimización de imágenes: formatos y carga diferida

Dado que las imágenes son las más pesadas, la optimización de velocidad casi siempre comienza allí. Esta es la victoria más rápida y visible con el menor riesgo.

Formatos modernos

Cambiar a WebP, y donde sea posible a AVIF. Con calidad comparable pesan notablemente menos que los clásicos JPEG y PNG. Para íconos y gráficos simples usa SVG: es vectorial, sin peso y perfectamente nítido en cualquier pantalla.

Tamaño y capacidad de respuesta correctos

Nunca sirvas una imagen más ancha de lo que realmente se muestra. Prepara varios tamaños y conéctalos a través de srcset para que un teléfono obtenga una versión compacta y un escritorio una grande. Un héroe de 4000 píxeles en un contenedor de 800 píxeles son megabytes y segundos desperdiciados.

Carga perezosa — pero sabiamente

• Agregar loading="lazy" a imágenes por debajo de la primera pantalla para que no interfieran con la pintura inicial.
• Pero carga la imagen LCP de la primera pantalla de inmediato y con prioridad — la carga perezosa solo perjudica aquí.
• Siempre establece dimensiones para que la carga perezosa no cause cambios en el diseño (ese mismo CLS).

Y no olvides la compresión. Pasar los activos a través de un optimizador decente a menudo reduce el peso en un 40–70% sin pérdida de calidad visible. Para los sitios de contenido, esos son literalmente segundos gratis.

Fuentes, CSS crítico y JavaScript excesivo

Después de las imágenes, la segunda zona más importante es el código que el navegador debe procesar antes de mostrar la página. La mayoría de los problemas de bloqueo de renderizado se ocultan aquí.

Fuentes

• Mantén el número mínimo de pesos: dos a menudo son suficientes.
• Usa woff2 y sirve fuentes desde tu propio dominio.
• Precarga la fuente clave de la primera pantalla.
• Establece font-display: swap para que el texto sea legible de inmediato en lugar de esperar a que se cargue la fuente.

CSS crítico

La idea es simple: los estilos necesarios para la primera pantalla están en línea directamente en el HTML, y el resto del CSS se carga más tarde. De esa manera, el navegador pinta la parte superior de la página sin esperar a toda la hoja de estilos. También elimina las reglas muertas: a lo largo de los años, un sitio acumula muchas de ellas.

Menos JavaScript

La optimización más honesta es no cargar lo que puedes hacer sin. Verifica si estás cargando un marco pesado para un par de efectos. Retrasa los scripts secundarios con defer y async, divide el paquete y carga el código bajo demanda. Audita por separado los widgets de terceros: cada chat, píxel y etiqueta debe justificar su lugar en el presupuesto de rendimiento. Cubrimos cómo esto se ajusta a los sitios multilingües sin inflar la página en nuestro artículo sobre el sitio multilingüe y SEO.

Caché, CDN, HTTP/2 y alojamiento

La optimización del front-end alcanza un límite si la base — el servidor y la entrega — es lenta. Estos elementos rinden en cada página a la vez.

Caché

Funciona en dos niveles.Caché del servidor evita regenerar una página pesada repetidamente y reduce directamente el TTFB.Caché del navegador (encabezados Cache-Control correctos para activos estáticos) significa que en visitas de retorno, las imágenes, fuentes y scripts no se descargan de nuevo.

CDN

Una red de entrega de contenido sirve activos estáticos desde el servidor más cercano al usuario geográficamente. Cuanto más lejos esté tu audiencia del origen, más fuerte será el efecto: la latencia disminuye y el primer byte llega más rápido.

HTTP/2, HTTP/3 y compresión

• Habilita un protocolo moderno (HTTP/2 o HTTP/3) — carga docenas de archivos pequeños en paralelo de manera más eficiente.
• Habilitar la compresión de recursos de texto (Brotli o gzip) en el servidor.
• Minificar HTML, CSS y JS, eliminando espacios en blanco y comentarios.

Alojamiento y TTFB

Un servidor adecuado no es un lujo, sino una base. En el concurrido proyecto del mercado 24freelance alcanzamos exactamente la capa del servidor: sin caché y optimización de consultas, el primer byte tardó en llegar, y ninguna cantidad de trabajo con imágenes alcanzó los números objetivo hasta que pusimos en orden el backend.

Velocidad en dispositivos móviles

Una verdad importante de 2026: Google evalúa tu sitio principalmente por su versión móvil, y la mayor parte del tráfico proviene de teléfonos. Y un teléfono significa un procesador más débil, una red menos estable y menos paciencia por parte del usuario.

Por qué lo móvil es más exigente

Lo que se ejecuta instantáneamente en un portátil potente tarda varias veces más en un smartphone promedio. JavaScript pesado afecta especialmente a INP en móvil precisamente porque el procesador es más débil y tarda más en procesar cada tarea.

Qué hacer

• Prueba con un dispositivo limitado y una emulación de red lenta, no solo en tu dispositivo insignia.
• Haz los controles lo suficientemente grandes y reserva espacio con anticipación para evitar toques y desplazamientos accidentales.
• Corta los scripts de terceros especialmente duro: su costo en móvil es varias veces más alto.
• Sirve imágenes en tamaño móvil, no las de escritorio reducidas por el navegador.

La buena noticia: si un sitio funciona bien en un teléfono promedio sobre una red mediocre, casi seguramente será rápido en escritorio. Así que optimiza para el peor escenario realista, no para tu monitor de trabajo.

Monitoreo y control continuo

La velocidad no es un proyecto puntual, sino una forma de higiene. Un sitio vive: se añade contenido, llegan nuevos widgets y banners, se actualiza el código, y el rendimiento se degrada silenciosamente. Sin monitoreo, te enteras de un problema por la caída de ventas, no por un informe.

Cómo mantener el pulso

• Revisa regularmente los Core Web Vitals de campo en Google Search Console: muestra la tendencia real para tu audiencia.
• Configura verificaciones automatizadas de plantillas clave para detectar regresiones justo después de un lanzamiento, no un mes después.
• Establece un presupuesto de rendimiento: un límite de peso de página y conteo de scripts que el equipo no puede exceder.
• Trata cada nuevo script de terceros como una decisión separada: lo que aporta al negocio y lo que cuesta en velocidad.

¿Quién lo supervisa?

En la práctica, ayuda hacer que una persona sea responsable de la velocidad; de lo contrario, la métrica se convierte en de nadie y se deteriora primero. Si no tienes a alguien así en el equipo, el rol puede ser externalizado: nosotros, por ejemplo, realizamos auditorías periódicas y soporte de rendimiento, lo cual es más fácil de organizar a través de nuestro formulario de contacto..

La idea principal: medir antes y después de cada cambio importante. La afirmación de que las cosas se volvieron más rápidas debe ser probada, no solo sentida.

Una lista de verificación práctica de velocidad del sitio

Reunamos todo en una lista aplicada. Trabaja en ella de arriba a abajo: los elementos están aproximadamente ordenados por la relación efecto-esfuerzo. No tienes que hacer todo de una vez, pero cada punto vale la pena revisarlo.

Mide y prioriza

1. Mide tus plantillas clave en PageSpeed Insights (móvil y escritorio) y registra los Core Web Vitals actuales.
2. Encuentra el elemento LCP de cada plantilla importante y su principal cuello de botella.

Imágenes

1. Convierte imágenes a WebP o AVIF, y iconos a SVG.
2. Sirve tamaños responsivos a través de srcset, nunca más grandes que el contenedor.
3. Habilita la carga diferida por debajo de la primera pantalla; carga la imagen LCP con prioridad.
4. Establece dimensiones de imagen para que no haya cambios de diseño.

Código y fuentes

1. Incorpora el CSS crítico y carga el resto más tarde.
2. Reduce los pesos de las fuentes, añade preload y font-display: swap.
3. Diferir scripts con defer/async y eliminar CSS y JS no utilizados.
4. Auditar widgets de terceros y eliminar cualquier cosa superflua.

Servidor y entrega

1. Habilitar caché del servidor y reducir TTFB.
2. Configurar caché del navegador para activos estáticos y compresión Brotli/gzip.
3. Agregar un CDN y un protocolo moderno, HTTP/2 o HTTP/3.
4. Minificar HTML, CSS y JS.

Control

1. Verificar el resultado en una emulación de dispositivo móvil con limitación.
2. Configurar monitoreo de métricas de campo y un presupuesto de rendimiento.
3. Vuelve a medir antes y después: registra la victoria en números.

Trabaja a través de esta lista de verificación honestamente y obtendrás no solo una buena puntuación, sino un sitio más rápido, más estable y más rentable. Y eso, al final, es el objetivo.

Preguntas frecuentes