Cómo acelerar un sitio web usando Core Web Vitals y datos reales

A menudo se acelera un sitio web en el orden equivocado: alguien instala un plugin de optimización, activa todas las opciones y después busca por qué el formulario ha dejado de funcionar. El orden correcto es medir, plantear una hipótesis, hacer un cambio, comprobar el funcionamiento y volver a medir.

En una versión anterior también describí enfoques que ya no recomiendo, como poner localmente los scripts de terceros o desplegar AMP y PWA de forma generalizada. Aportaban mejoras parciales en laboratorio, pero añadían riesgo por código obsoleto, actualizaciones rotas y un mantenimiento más complicado. Un sitio web moderno debe ser rápido en su versión principal.

Qué medir hoy

Para Core Web Vitals, Google utiliza tres métricas estables:

• LCP: carga del contenido principal; un buen valor es de hasta 2.5 segundos.
• INP: respuesta a las interacciones; un buen valor es inferior a 200 milisegundos.
• CLS: cambios inesperados en el diseño; un buen valor es como máximo 0.1.

Los umbrales se aplican al percentil 75 y se resumen en la visión general oficial de Core Web Vitals para la Búsqueda de Google. Los resultados de visitantes reales en Search Console o CrUX tienen prioridad sobre una única prueba de laboratorio en mi portátil.

Las herramientas de laboratorio siguen siendo importantes: muestran la cascada, el hilo principal, el código sin usar y candidatos concretos para la reparación. Los datos de campo indican que existe un problema; el laboratorio ayuda a explicar por qué.

Define primero el alcance del problema

1. Compara móvil y escritorio.
2. Separa las plantillas: página de inicio, artículo, servicio, listado, formulario y tienda online.
3. Comprueba los países, dispositivos y fuentes de tráfico rápidos y lentos.
4. Encuentra los grupos de URL con malos datos de campo.
5. Captura una traza de laboratorio repetible para una página representativa.

Una página de inicio rápida no significa que el sitio web sea rápido. Una visita lenta desde un teléfono antiguo no significa que haya que reescribir todo el sistema.

Intervenciones con mayor impacto habitual

1. Servidor y HTML

Mide el tiempo hasta el primer byte y divídelo en DNS, conexión, espera del servidor y redirecciones. Las esperas largas pueden deberse al alojamiento, la base de datos, una página sin caché, una API lenta o cadenas de redirecciones. Activa una caché de página adecuada para el contenido público y una caché de objetos cuando tenga sentido. Excluye correctamente de la caché a los usuarios conectados, los carritos y la personalización.

2. Imagen principal

A menudo, el LCP es la imagen principal. Sirve un tamaño que se ajuste a su visualización, utiliza srcset, compresión y WebP o AVIF modernos con una alternativa razonable. No cargues de forma diferida la imagen principal; carga así las imágenes que estén por debajo de la primera ventana gráfica. Define el ancho y el alto de las imágenes para que el navegador reserve espacio y el CLS se mantenga bajo.

3. CSS y fuentes

Elimina los estilos sin usar con cuidado y mantén pequeño el CSS crítico. Limita las fuentes a los pesos y conjuntos de caracteres necesarios, almacena los archivos locales en caché durante mucho tiempo y precarga solo una fuente que realmente se necesite al principio. Precargar diez fuentes solo crea otra cola.

4. JavaScript e interacción

Divide los paquetes grandes, aplaza el código no crítico y carga terceros solo cuando sea necesario y el consentimiento lo permita. async y defer no son magia; prueba el orden y las dependencias de los scripts. Divide las tareas largas del hilo principal y no hagas que un clic espere a la analítica.

5. Terceros

Los chats, mapas de calor, píxeles publicitarios, vídeos y herramientas de pruebas A/B añaden solicitudes de red y trabajo del procesador. Cada script necesita un responsable y una razón de negocio. No lo cargues de forma síncrona en la cabecera solo porque la guía de instalación sea más corta. La analítica puede gestionarse mediante Google Tag Manager, pero el propio contenedor no puede solucionar el rendimiento.

WordPress: menos capas, más control

La documentación de WordPress recomienda abordar el rendimiento mediante el alojamiento, la cantidad y calidad de los plugins, las imágenes, la caché y una red de distribución. Lee su visión general de la optimización y su explicación independiente de la caché.

• Actualiza primero WordPress, PHP, el tema y los plugins en staging.
• Elimina los plugins sin usar y las herramientas de caché o minificación que se solapen.
• Analiza las consultas de la base de datos y las llamadas externas lentas.
• Planifica el mantenimiento de la base de datos, pero no borres revisiones ni metadatos a ciegas.
• Después de cada optimización, prueba los formularios, la búsqueda, el inicio de sesión y el proceso de compra.

Comento la selección razonable de complementos en los mejores plugins de WordPress.

Qué no hacer

• No descargues los scripts de analítica o publicidad de terceros a tu servidor solo para conseguir una puntuación; podrías perder actualizaciones de seguridad y funcionalidad.
• No establezcas una caché de un año para un archivo que cambia sin versionar su nombre.
• No elimines CSS ni JavaScript de un informe automatizado sin probar todas las plantillas.
• No juzgues el éxito solo por Lighthouse. Google afirma explícitamente que unos Core Web Vitals buenos por sí solos no garantizan posiciones altas ni una gran experiencia de usuario.
• No aceleres un sitio web ocultando contenido o una función que el cliente necesita.

Un plan de cuatro semanas

1. Semana 1: línea base de datos de campo, mediciones de laboratorio y lista de plantillas.
2. Semana 2: servidor, caché, redirecciones y los recursos LCP más grandes.
3. Semana 3: imágenes, fuentes, CSS, JavaScript y terceros.
4. Semana 4: prueba de regresión, nuevas mediciones, supervisión y documentación.

Para cada cambio, registra la fecha, la URL, la métrica antes y después, el impacto funcional y la opción de reversión. Haz un seguimiento también de la tasa de conversión, la finalización de formularios y los errores; una página más rápida que vende menos no es una optimización terminada.

Empieza comprobando los fundamentos técnicos y la analítica del sitio web mediante una auditoría técnica y GA4. Si necesitas priorizar las reparaciones por impacto y coste, contacta conmigo a través de contacto.