¿Cómo optimizar el código HTML, CSS y JS para alcanzar un 100/100 en Google PageSpeed?

Un sitio web lento tiene algo de teatro absurdo: invertimos en diseño, fotografías impecables, animaciones seductoras y textos trabajados… para luego obligar al visitante a esperar frente a una pantalla en blanco. Es como recibir a alguien en una mansión y hacerlo entrar por el sótano.

Google PageSpeed Insights no es un juez perfecto, conviene decirlo pronto. A veces parece un profesor severo que resta puntos porque el lápiz no está alineado con el borde del pupitre. Pero sus advertencias suelen apuntar a problemas reales: JavaScript excesivo, CSS bloqueante, HTML hinchado, fuentes pesadas, imágenes sin optimizar, plugins que cargan media civilización grecorromana para mostrar un botón.

Alcanzar un 100/100 en Google PageSpeed es posible en muchos proyectos, especialmente en páginas estáticas, landing pages bien construidas y sitios WordPress disciplinados. Pero no debería convertirse en una religión. El objetivo serio es otro: hacer que la web sea rápida, estable, segura y agradable para personas reales. El 100 es la medalla; la experiencia del usuario es la batalla.

📌 Mapa de ruta

1. Qué mide realmente Google PageSpeed
2. Cómo auditar antes de tocar código
3. Optimización avanzada de HTML
4. Optimización de CSS: menos bloqueo, más velocidad
5. Optimización de JavaScript: el gran sospechoso
6. Estrategia específica para WordPress
7. Fuentes, imágenes y recursos críticos
8. Servidor, caché, CDN y compresión
9. Checklist profesional para acercarte al 100/100

1. Qué mide realmente Google PageSpeed Insights 🧭

Google PageSpeed Insights combina datos de laboratorio y, cuando existen suficientes visitas, datos de campo procedentes del Chrome User Experience Report. Esta diferencia importa mucho. El laboratorio es una maqueta controlada; el campo es la calle con lluvia, tráfico, móviles antiguos y WiFi de cafetería.

La puntuación que ves en PageSpeed se basa en Lighthouse, una herramienta automatizada que simula la carga de una página, normalmente con condiciones exigentes en móvil. No evalúa “lo bonita” que es tu web. Evalúa cuánto tarda en ofrecer contenido útil, cuánto se mueve la página mientras carga, cuánto bloquea el hilo principal y cómo responde ante la interacción del usuario.

LCP recomendado
≤ 2,5 s

Largest Contentful Paint: cuándo aparece el contenido principal visible.

INP recomendado
≤ 200 ms

Interaction to Next Paint: capacidad de respuesta ante clics, toques y teclas.

CLS recomendado
≤ 0,1

Cumulative Layout Shift: estabilidad visual durante la carga.

TTFB orientativo
< 800 ms

Time to First Byte: rapidez con la que el servidor empieza a responder.

Desde marzo de 2024, INP sustituyó a FID como métrica oficial de Core Web Vitals. No es un detalle decorativo: antes se medía la primera interacción; ahora se observa la capacidad general de respuesta. Es una diferencia parecida a juzgar a un camarero por el primer saludo o por todo el servicio de la cena.

Importante: un 100/100 no garantiza automáticamente mejores posiciones SEO. La velocidad influye, sí, especialmente a través de Core Web Vitals y experiencia de usuario, pero el posicionamiento depende también de contenido, intención de búsqueda, autoridad, arquitectura, enlazado interno, rastreabilidad, semántica, reputación y otros factores. El rendimiento abre la puerta; no escribe el libro entero.

2. Antes de optimizar: mide como cirujano, no como adivino 🔬

El pecado original de muchas optimizaciones web es empezar instalando un plugin de caché “a ver si mejora”. A veces mejora. A veces rompe el menú, oculta el carrito y convierte la web en una ruleta rusa con favicon. Qué elegante forma de ahorrar tiempo perdiéndolo todo.

Antes de tocar HTML, CSS o JavaScript, crea una fotografía del estado actual:

• PageSpeed Insights: útil para diagnóstico general, métricas Core Web Vitals y oportunidades de mejora.
• Lighthouse en Chrome DevTools: permite pruebas locales, modo incógnito y comparación tras cambios concretos.
• WebPageTest: excelente para analizar cascadas de carga, TTFB, CDN, geolocalización y video de renderizado.
• Chrome DevTools Performance: imprescindible para detectar tareas largas de JavaScript, bloqueo del hilo principal y problemas de interacción.
• Coverage en DevTools: muestra CSS y JS no utilizados, esa especie de polvo digital que se acumula sin hacer ruido.
• Query Monitor en WordPress: ayuda a localizar consultas lentas, hooks costosos, plantillas pesadas y plugins problemáticos.

Qué debes registrar antes de empezar

Trabaja siempre en staging si el sitio es importante. Haz copia de seguridad. Documenta cambios. Optimizar sin método es como podar un bonsái con una motosierra: algo quedará más pequeño, desde luego, pero quizá no más bello.

3. Optimización HTML: la estructura invisible que decide mucho 🧱

El HTML suele ser el pariente tranquilo del rendimiento web. No grita como JavaScript ni bloquea con la solemnidad del CSS, pero una estructura deficiente puede multiplicar nodos, retrasar el renderizado, confundir al navegador y dificultar la accesibilidad.

3.1 Reduce el HTML innecesario

Muchos sitios modernos generan capas y capas de contenedores: <div> dentro de <div> dentro de <div>, como muñecas rusas fabricadas por un comité cansado. En constructores visuales de WordPress esto es frecuente: Elementor, WPBakery, Divi o ciertos temas multipropósito pueden producir HTML abundante incluso para secciones simples.

No se trata de perseguir un número mágico de nodos, sino de evitar árboles DOM enormes. Un DOM demasiado grande puede aumentar el coste de estilos, layouts y scripts.

• Elimina contenedores que no aportan diseño, semántica ni comportamiento.
• Usa etiquetas semánticas: <header>, <main>, <section>, <article>, <nav>, <footer>.
• Evita menús gigantes cargados en todas las páginas si no son necesarios.
• No insertes shortcodes pesados en zonas globales si solo se necesitan en una plantilla.
• Revisa widgets de redes sociales, iframes y bloques de terceros.

3.2 Prioriza el contenido visible

El navegador lee el documento de arriba abajo. Lo que coloques en el <head> y al inicio del <body> afecta directamente a la percepción de velocidad. Tu objetivo es que el contenido principal —normalmente el título, el texto inicial y la imagen hero— aparezca pronto.

<!-- Bien: estructura clara y contenido principal temprano -->
<body>
  <header>...</header>

  <main>
    <section>
      <h1>Servicio profesional de mantenimiento WordPress</h1>
      <p>Soporte, seguridad y optimización para sitios empresariales.</p>
      <img
        src="/img/mantenimiento-wordpress.webp"
        width="1200"
        height="675"
        alt="Panel de administración de WordPress optimizado"
        fetchpriority="high">
    </section>
  </main>
</body>

El atributo fetchpriority="high" puede ayudar cuando la imagen principal es el elemento LCP. Úsalo con moderación. Si todo es urgente, nada lo es; una lección que también serviría para algunos grupos de WhatsApp laborales.

3.3 Evita saltos de diseño con dimensiones explícitas

Una causa habitual de CLS es cargar imágenes, vídeos, iframes o anuncios sin reservar espacio. El navegador no es vidente. Si no conoce el tamaño, pinta una cosa y luego la recoloca. Para el usuario, la página salta como una liebre asustada.

<img
  src="/imagenes/consultoria-seo.webp"
  width="960"
  height="540"
  alt="Auditoría SEO técnica en una pantalla"
  loading="lazy"
  decoding="async">

En imágenes bajo el primer pantallazo, loading="lazy" suele ser recomendable. En la imagen hero, no. Cargar perezosamente el elemento principal visible puede empeorar el LCP, una ironía bastante fina: intentas acelerar la web retrasando justo lo que más necesitas mostrar.

3.4 Limpia el head

El <head> de algunas webs parece un trastero con etiquetas meta duplicadas, scripts de campañas antiguas, verificaciones olvidadas y hojas de estilo de plugins que ya no existen. Revisa:

• Etiquetas meta duplicadas o generadas por varios plugins SEO.
• Scripts de tracking no utilizados.
• Preloads obsoletos.
• Fuentes externas repetidas.
• CSS de plugins cargado globalmente.
• Fragmentos de herramientas de marketing retiradas.

Menos basura en el head significa menos bloqueo, menos DNS lookup, menos posibilidades de conflicto y una auditoría más limpia.

4. Optimización CSS: el arte de pintar rápido sin mancharlo todo 🎨

El CSS es render-blocking por naturaleza: el navegador necesita entender los estilos antes de pintar correctamente la página. Esto tiene sentido. Nadie quiere ver una web desnuda durante medio segundo y luego vestida de gala, aunque a veces ocurra con una sinceridad casi conmovedora.

4.1 Extrae CSS crítico

El CSS crítico es el conjunto mínimo de estilos necesarios para renderizar la parte visible inicial de una página. Si el navegador debe descargar un archivo CSS enorme antes de mostrar el hero, el menú y el título, el LCP puede sufrir.

Una estrategia habitual:

1. Insertar inline el CSS crítico del primer pantallazo.
2. Cargar el CSS completo de forma eficiente.
3. Eliminar reglas no utilizadas por plantilla.

<style>
  body { margin: 0; font-family: system-ui, sans-serif; }
  .hero { padding: 64px 6vw; background: #0f172a; color: #fff; }
  .hero h1 { font-size: clamp(2rem, 5vw, 4.5rem); line-height: 1.05; }
</style>

<link rel="preload" href="/css/app.min.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/css/app.min.css"></noscript>

Esta técnica debe probarse bien. Si se implementa mal, puede provocar FOUC —Flash of Unstyled Content—, ese instante en que la web aparece sin peinar, como quien abre la puerta al cartero en pijama.

4.2 Elimina CSS no utilizado

Frameworks, temas comerciales y librerías de componentes suelen incluir mucho más CSS del que una página necesita. Bootstrap completo para usar una rejilla y dos botones. Tailwind sin purgado. Icon libraries enteras para mostrar tres iconos. Maravilloso progreso: enviamos una enciclopedia para decir “hola”.

Acciones recomendadas:

• Usa PurgeCSS, Tailwind content scanning o herramientas equivalentes en procesos de build.
• Divide CSS por plantilla: home, blog, producto, checkout, área privada.
• Evita cargar estilos de sliders, galerías o formularios en páginas donde no existen.
• Reemplaza librerías grandes por CSS nativo cuando sea razonable.
• Audita con la pestaña Coverage de Chrome DevTools.

4.3 Minifica, pero no confundas minificar con optimizar

Minificar CSS elimina espacios, saltos de línea y comentarios. Es útil. Pero si tu archivo pesa 400 KB porque contiene media tienda de disfraces estilísticos, minificarlo no resuelve el problema de fondo. Lo hace más pequeño, sí, como comprimir una maleta sin preguntarse por qué llevas seis abrigos al Caribe.

4.4 Usa CSS moderno con criterio

CSS moderno permite hacer hoy lo que antes requería JavaScript: acordeones simples, sticky headers, scroll snapping, grids complejos, animaciones ligeras. Cada comportamiento que puedas resolver con CSS en lugar de JS reduce trabajo del hilo principal.

/* Evita animar propiedades costosas como width, height, top o left */
.card {
  transition: transform 180ms ease, opacity 180ms ease;
}

.card:hover {
  transform: translateY(-4px);
}

/* Respeta usuarios que prefieren menos movimiento */
@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.001ms !important;
    transition-duration: 0.001ms !important;
  }
}

Anima transform y opacity siempre que puedas. Evita animaciones que fuerzan layout y repintado constante. La diferencia entre una animación fluida y una torpe es como la diferencia entre seda y papel de lija: ambas se sienten, pero una no pide disculpas.

5. Optimización JavaScript: domar al animal que más muerde 🐉

Si HTML es estructura y CSS es pintura, JavaScript es maquinaria. Puede convertir una página en una aplicación brillante o en un tractor cruzando una biblioteca. Gran parte de los problemas de PageSpeed, especialmente en móvil, proviene de JavaScript excesivo, mal diferido o innecesario.

5.1 Comprende async, defer y type=»module»

Uno de los errores más comunes es cargar scripts en el <head> sin estrategia. El navegador se detiene, descarga, ejecuta y solo entonces continúa. Es como si el camarero dejara de atender a todos para leer el manual de la cafetera en mitad del desayuno.

<!-- Recomendado para scripts propios -->
<script src="/js/main.min.js" defer></script>

<!-- Recomendado para scripts independientes de terceros -->
<script src="https://www.googletagmanager.com/gtag/js?id=G-XXXX" async></script>

<!-- JavaScript moderno por módulos -->
<script type="module" src="/js/app.js"></script>

5.2 Reduce el coste del hilo principal

El navegador tiene un hilo principal donde ocurren tareas cruciales: parsear HTML, calcular estilos, ejecutar JavaScript, diseñar layout y pintar. Cuando JavaScript ocupa ese hilo durante demasiado tiempo, el usuario toca un botón y nada responde. La web parece viva, pero no escucha. Una estatua con formulario de contacto.

Para mejorar INP y reducir Total Blocking Time en Lighthouse:

• Divide tareas largas en tareas pequeñas.
• Retrasa lógica no esencial hasta después de la carga inicial.
• Usa requestIdleCallback para trabajos de baja prioridad, con fallback.
• Evita listeners excesivos; delega eventos cuando sea posible.
• No recalcules layout en bucles leyendo y escribiendo propiedades del DOM alternadamente.
• Considera Web Workers para cálculos pesados.

// Evita ejecutar tareas no críticas durante la carga inicial
function runWhenIdle(callback) {
  if ("requestIdleCallback" in window) {
    requestIdleCallback(callback, { timeout: 2000 });
  } else {
    setTimeout(callback, 1200);
  }
}

runWhenIdle(() => {
  // Cargar chat, mapas, widgets secundarios o personalización no crítica
  initNonCriticalWidgets();
});

5.3 Carga JavaScript solo donde se necesita

Una página de “Sobre nosotros” no necesita el JavaScript del checkout. Un artículo de blog no necesita el slider de la home. Un formulario de contacto no debería cargar scripts de una galería que vive tres clics más allá. Parece obvio, hasta que uno abre DevTools y descubre que la página más simple del sitio transporta equipaje para una mudanza.

En proyectos modernos, aplica:

• Code splitting: dividir el bundle en fragmentos por ruta o componente.
• Tree shaking: eliminar código importado que no se usa.
• Dynamic imports: cargar módulos solo cuando hacen falta.
• Lazy hydration: hidratar componentes interactivos cuando entran en viewport o cuando el usuario interactúa.
• Islas de interactividad: HTML estático por defecto, JavaScript solo en zonas necesarias.

const button = document.querySelector("[data-open-gallery]");

button?.addEventListener("click", async () => {
  const { initGallery } = await import("./gallery.js");
  initGallery();
});

5.4 Cuidado con las dependencias

Cada librería debe defender su presencia. jQuery no es pecado, pero cargarlo para alternar una clase CSS en 2026 tiene algo de procesión barroca para cambiar una bombilla. Lo mismo ocurre con carruseles, animaciones, popups, selectores personalizados y frameworks completos para interfaces mínimas.

Preguntas saludables antes de añadir una dependencia:

• ¿Cuánto pesa minificada y comprimida?
• ¿Cuánto tarda en parsearse y ejecutarse en móvil?
• ¿Se carga en todas las páginas o solo donde se usa?
• ¿Existe una alternativa nativa?
• ¿La dependencia está mantenida y no introduce riesgos de seguridad?

5.5 Scripts de terceros: el enemigo cordial

Analytics, chat, píxeles publicitarios, mapas, vídeos incrustados, herramientas A/B testing, CRM, heatmaps. Todos prometen conocimiento. Todos cobran en rendimiento. Los scripts de terceros son como invitados con maletas: alguno aporta conversación; demasiados ocupan el salón.

Medidas recomendadas:

• Carga scripts de marketing tras consentimiento si aplica normativa de privacidad.
• Retrasa chat y widgets no esenciales hasta interacción o varios segundos después del LCP.
• Usa fachadas para YouTube, Google Maps o embeds pesados.
• Elimina herramientas duplicadas: dos analytics, tres píxeles, cuatro heatmaps… el museo del seguimiento.
• Define un proceso interno: ningún script externo entra sin responsable, objetivo y fecha de revisión.

<button data-youtube-id="abc123">
  ▶ Ver vídeo
</button>

<script defer>
document.addEventListener("click", event => {
  const button = event.target.closest("[data-youtube-id]");
  if (!button) return;

  const iframe = document.createElement("iframe");
  iframe.src = `https://www.youtube.com/embed/${button.dataset.youtubeId}?autoplay=1`;
  iframe.width = "560";
  iframe.height = "315";
  iframe.loading = "lazy";
  iframe.allow = "accelerometer; autoplay; encrypted-media; picture-in-picture";
  iframe.allowFullscreen = true;

  button.replaceWith(iframe);
});
</script>

6. WordPress: rendimiento real sin romper el sitio 🛠️

WordPress puede ser rápido. Muy rápido. Pero también puede transformarse en una ciudad medieval donde cada plugin construye una muralla, abre un mercado y convoca una feria. La diferencia no está solo en WordPress; está en cómo se mantiene.

6.1 Elige bien tema, constructor y plugins

Para lograr un buen PageSpeed en WordPress, el punto de partida pesa más de lo que se admite en reuniones comerciales. Un tema ligero como GeneratePress, Astra, Blocksy o un tema a medida bien hecho suele partir con ventaja frente a temas multipropósito cargados de demos, sliders, icon packs y opciones que jamás usarás.

• Evita instalar plugins para funciones triviales que pueden resolverse con pocas líneas de código.
• Desactiva y elimina plugins inactivos.
• Audita plugins que cargan CSS/JS globalmente.
• Comprueba compatibilidad con PHP actualizado.
• No uses varios plugins que hagan lo mismo: caché, SEO, seguridad, optimización de imágenes, formularios.

6.2 Descarga assets por condición

En WordPress puedes evitar que un plugin cargue archivos donde no debe. Por ejemplo, Contact Form 7 no necesita cargar su CSS y JS en todas las páginas si el formulario solo aparece en “Contacto”.

// functions.php o plugin personalizado
add_action('wp_enqueue_scripts', function () {
  if (!is_page('contacto')) {
    wp_dequeue_style('contact-form-7');
    wp_dequeue_script('contact-form-7');
  }
}, 99);

La clave es identificar correctamente los handles de cada script o estilo. Herramientas como Query Monitor, Asset CleanUp o Perfmatters pueden ayudar. Eso sí: prueba formularios, carritos, popups y áreas privadas después. Optimizar rompiendo conversiones es una forma bastante cara de ganar puntos.

6.3 Usa caché de página y caché de objeto

Para sitios WordPress, la caché suele marcar una diferencia enorme en TTFB. Una página servida desde caché evita repetir consultas, renderizado PHP y trabajo innecesario.

• Caché de página: WP Rocket, LiteSpeed Cache, FlyingPress, Cache Enabler o soluciones del hosting.
• Caché de objeto: Redis o Memcached, especialmente en WooCommerce, membresías o sitios con consultas frecuentes.
• OPcache: recomendable en PHP para mejorar ejecución.
• CDN: útil para servir recursos estáticos cerca del usuario.

6.4 WooCommerce: caso especial

WooCommerce merece trato delicado. No puedes cachear carrito, checkout o cuenta como si fueran páginas estáticas. Tampoco deberías retrasar scripts esenciales de compra. Aquí hay antítesis pura: quieres velocidad de escaparate y precisión de caja registradora.

Recomendaciones:

• Excluye carrito, checkout y mi cuenta de caché de página.
• Optimiza fragmentos de carrito si generan llamadas AJAX costosas.
• Carga scripts de pasarelas de pago solo en checkout cuando sea posible.
• Revisa plugins de filtros, variaciones y búsqueda; pueden ser pesados.
• Usa hosting preparado para consultas dinámicas y tráfico concurrente.

6.5 Seguridad y rendimiento van juntos

Un sitio infectado, con spam SEO, redirecciones ocultas o scripts inyectados no va a rendir bien. Además, un WordPress desactualizado puede cargar código malicioso que PageSpeed no te explicará con ternura. Te mostrará síntomas; el diagnóstico forense lo tendrás que hacer tú.

• Mantén WordPress, temas y plugins actualizados.
• Elimina extensiones abandonadas.
• Usa permisos correctos en archivos y carpetas.
• Activa WAF si el proyecto lo requiere.
• Implementa cabeceras de seguridad como CSP, X-Content-Type-Options y Referrer-Policy con cuidado.
• Monitoriza cambios de archivos y usuarios administradores.

7. Fuentes, imágenes y recursos críticos: aunque el título diga HTML, CSS y JS 🖼️

Sería cómodo hablar solo de código, pero PageSpeed no vive en una isla. Imágenes, fuentes y servidor influyen tanto que ignorarlos sería como afinar un violín mientras el barco se hunde.

7.1 Optimiza imágenes para LCP

La imagen principal suele ser el elemento LCP en páginas comerciales, blogs visuales y tiendas online. Optimizarla puede dar más resultado que discutir durante dos horas si un archivo JS debería pesar 27 o 31 KB.

• Usa formatos modernos: AVIF cuando sea viable, WebP como opción muy compatible.
• Sirve tamaños adaptados con srcset y sizes.
• Comprime sin destruir la calidad perceptual.
• No apliques lazy loading a la imagen LCP.
• Define width y height.
• Usa CDN de imágenes si gestionas mucho contenido visual.

<picture>
  <source
    type="image/avif"
    srcset="/img/hero-640.avif 640w, /img/hero-1280.avif 1280w, /img/hero-1920.avif 1920w">
  <source
    type="image/webp"
    srcset="/img/hero-640.webp 640w, /img/hero-1280.webp 1280w, /img/hero-1920.webp 1920w">
  <img
    src="/img/hero-1280.webp"
    width="1280"
    height="720"
    alt="Equipo técnico optimizando el rendimiento de un sitio web"
    fetchpriority="high"
    decoding="async">
</picture>

7.2 Fuentes web: belleza con factura

Las fuentes personalizadas aportan identidad, pero también pueden retrasar el renderizado. Una tipografía cargada desde un dominio externo añade DNS, conexión TLS y descarga. No es tragedia, pero tampoco magia gratis.

Buenas prácticas:

• Usa formatos WOFF2.
• Limita pesos y estilos: regular, semibold y bold suelen bastar.
• Aloja fuentes localmente cuando sea conveniente.
• Aplica font-display: swap o estrategias similares.
• Preload solo de la fuente crítica realmente usada en el primer pantallazo.

<link
  rel="preload"
  href="/fonts/inter-var.woff2"
  as="font"
  type="font/woff2"
  crossorigin>

<style>
@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-var.woff2") format("woff2");
  font-weight: 100 900;
  font-display: swap;
}
</style>

7.3 Preconnect y DNS-prefetch

Cuando dependes de recursos externos críticos —fuentes, CDN, APIs— puedes adelantar conexiones con preconnect. Úsalo para pocos orígenes verdaderamente importantes. Si llenas el head de preconnects, vuelves al punto de partida: demasiadas urgencias compitiendo por la puerta.

<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="dns-prefetch" href="//www.googletagmanager.com">

8. Servidor, caché, CDN y compresión: el código no corre en el vacío 🌐

Una web puede tener HTML impecable, CSS minimalista y JavaScript casi monástico. Si el servidor tarda dos segundos en responder, PageSpeed levantará la ceja. Y con razón.

8.1 Mejora TTFB

El Time to First Byte depende de hosting, DNS, proximidad geográfica, caché, base de datos, PHP, plugins, tema y carga del servidor. En WordPress, un TTFB alto suele venir de consultas lentas, ausencia de caché, hosting saturado o plugins que ejecutan demasiado trabajo en cada visita.

• Usa hosting con recursos reales, no solo promesas con foto de cohete.
• Activa caché de página.
• Actualiza a una versión moderna y soportada de PHP.
• Optimiza base de datos: autoload excesivo, transients vencidos, tablas enormes.
• Reduce llamadas externas en el renderizado inicial.
• Implementa CDN si tienes audiencia distribuida geográficamente.

8.2 Brotli, Gzip y cabeceras de caché

HTML, CSS y JS deben servirse comprimidos. Brotli suele ofrecer mejores ratios que Gzip en muchos casos, especialmente para texto, aunque depende del servidor y configuración. La compresión es una de esas mejoras discretas que no hacen ruido, como un buen editor corrigiendo una frase antes de que nadie la vea.

# Ejemplo orientativo para Nginx: caché de archivos estáticos
location ~* \.(css|js|jpg|jpeg|png|webp|avif|gif|svg|woff2)$ {
  expires 1y;
  add_header Cache-Control "public, max-age=31536000, immutable";
}

La estrategia immutable funciona bien si versionas archivos, por ejemplo app.8f3a2c.css. Si no versionas, puedes dejar a usuarios con archivos antiguos tras cambios importantes. El rendimiento exige memoria; la caché, además, exige disciplina.

8.3 HTTP/2 y HTTP/3

HTTP/2 permite multiplexación: varias solicitudes sobre una misma conexión. HTTP/3, basado en QUIC, puede mejorar rendimiento en redes inestables y reducir costes de reconexión. No sustituyen a una buena optimización, pero cambian ciertas decisiones antiguas.

Por ejemplo, en HTTP/1.1 era común combinar todos los archivos para reducir solicitudes. En HTTP/2, dividir por funcionalidad puede ser razonable si se cachea bien. Antiguo dogma: “un solo archivo para todo”. Nueva prudencia: “los archivos justos, bien priorizados y cacheables”.

9. Estrategia práctica para llegar a 100/100 sin perseguir fantasmas 🎯

Un 100/100 en Google PageSpeed suele requerir una combinación de pequeñas mejoras y algunas decisiones valientes. No basta con minificar. No basta con instalar caché. No basta con culpar al hosting, aunque a veces el hosting haga méritos con entusiasmo.

Orden recomendado de trabajo

1. Audita: PageSpeed, Lighthouse, DevTools, WebPageTest.
2. Resuelve servidor y TTFB: caché, hosting, PHP, base de datos.
3. Optimiza el LCP: imagen hero, CSS crítico, preload correcto, HTML inicial limpio.
4. Reduce JavaScript: elimina, divide, difiere, retrasa terceros.
5. Reduce CSS: crítico, purgado, división por plantilla.
6. Controla CLS: dimensiones, espacios reservados, fuentes, banners, anuncios.
7. Optimiza imágenes y fuentes: formatos modernos, tamaños correctos, font-display.
8. Repite medición: compara antes/después y revisa en móvil.
9. Monitoriza datos de campo: Search Console y CrUX necesitan tiempo para reflejar cambios.

Consejo de mantenimiento: no optimices una vez y desaparezcas. Cada plugin nuevo, campaña de marketing, píxel publicitario, banner legal o rediseño puede degradar Core Web Vitals. El rendimiento web no es una estatua; es un jardín. Si no lo cuidas, crece maleza.

Errores frecuentes que impiden el 100/100

• Cargar varias familias tipográficas con muchos pesos.
• Usar sliders pesados como elemento principal de la home.
• Lazy load aplicado a la imagen LCP.
• JavaScript de chat cargado antes del contenido principal.
• CSS de todo el sitio en cada página.
• Plugins WordPress duplicados o abandonados.
• Imágenes subidas directamente desde cámara o banco de imágenes sin redimensionar.
• No reservar espacio para banners, iframes o anuncios.
• Precargar demasiados recursos.
• Confundir puntuación de laboratorio con experiencia real de usuarios.

10. Checklist profesional de optimización HTML, CSS y JS ✅

HTML

• DOM limpio, sin contenedores innecesarios.
• Contenido principal aparece temprano en el documento.
• Imágenes con width, height y atributos adecuados.
• Head sin scripts, metadatos o preloads obsoletos.
• Uso correcto de semántica y accesibilidad.

CSS

• CSS crítico inline para above the fold cuando proceda.
• CSS no utilizado eliminado o reducido.
• Archivos minificados y comprimidos.
• Estilos divididos por plantilla o componente.
• Animaciones basadas en transform y opacity.

JavaScript

• Scripts propios con defer o módulos.
• Scripts independientes con async cuando corresponda.
• Code splitting y carga condicional.
• Terceros retrasados, auditados y justificados.
• Tareas largas divididas para mejorar INP.

WordPress

• Tema ligero o desarrollo a medida bien estructurado.
• Plugins auditados y sin duplicidades.
• Caché de página activa.
• Assets descargados solo donde se usan.
• Base de datos revisada y PHP actualizado.

Recursos y servidor

• Imágenes WebP/AVIF con tamaños responsivos.
• Fuentes WOFF2, pocas variantes y font-display adecuado.
• Brotli o Gzip activo.
• Cabeceras de caché correctas.
• CDN configurado si el público es geográficamente amplio.

11. ¿Cuándo no merece la pena perseguir el 100? 🧠

Hay páginas donde lograr 100/100 exige sacrificar funcionalidades valiosas: personalización, analítica crítica, pruebas A/B, chat comercial, mapas interactivos, publicidad o componentes de aplicación. En esos casos conviene pensar con madurez. Un 96 con buena conversión puede ser mejor que un 100 ascético que no vende, no mide y no ayuda.

La antítesis es clara: velocidad sin utilidad es vacío; utilidad sin velocidad es frustración. La web excelente vive entre ambos extremos.

Me viene a la cabeza una pequeña anécdota. Hace años, en una cafetería diminuta, vi a un barista preparar un espresso con una calma casi religiosa mientras la fila crecía hasta la puerta. El café era magnífico. La espera, no tanto. Muchas webs hacen eso: entregan algo bueno demasiado tarde. Y en internet, la paciencia no se evapora lentamente; cae como una copa al suelo.

Por eso, la pregunta no es solo “¿cómo alcanzo 100/100 en Google PageSpeed?”. La pregunta más útil es: ¿qué necesita ver, sentir y hacer mi usuario en los primeros segundos? A partir de ahí, el código se vuelve estrategia. HTML más claro. CSS menos obstructivo. JavaScript más humilde. Servidor más atento. WordPress más sobrio.

12. Plan de acción de 7 días para mejorar PageSpeed 🚀

Después, espera. Los datos de campo no cambian al instante. Google necesita recopilar información de usuarios reales durante días o semanas. Lighthouse puede felicitarte hoy; CrUX tardará en asentir. La paciencia, por una vez, también forma parte de la optimización.