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

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

Hay páginas que pesan como una biblioteca mudándose en camión y aun así sus dueños se preguntan, con sincera inocencia, por qué Google PageSpeed Insights les devuelve un 43 en móvil. El rendimiento web no es magia negra: es arquitectura, poda, criterio y una pizca de humildad técnica. Alcanzar un 100/100 en Google PageSpeed es posible en muchos casos, pero exige entender qué se mide, qué estorba y qué decisiones conviene tomar antes de instalar “un plugin más”, ese ritual moderno que a veces cura y a veces agrava la fiebre.

Optimizar HTML, CSS y JavaScript no consiste solo en minificar archivos. Eso sería como limpiar el parabrisas de un coche sin motor. La verdadera mejora aparece cuando el navegador recibe menos trabajo, en el orden correcto y con menos interrupciones. Un sitio rápido no grita; respira. Carga lo esencial, difiere lo accesorio y no obliga al usuario a esperar mientras media docena de scripts de seguimiento discuten entre ellos en la sala de máquinas.

Contenido de esta guía

1. Qué mide realmente Google PageSpeed Insights
2. Diagnóstico profesional antes de tocar código
3. Optimización avanzada de HTML
4. Optimización de CSS: critical CSS, CSS no usado y renderizado
5. Optimización de JavaScript: menos bloqueo, más intención
6. Caso WordPress: cómo evitar que el CMS se convierta en lastre
7. Core Web Vitals y métricas clave
8. Checklist final para acercarte al 100/100

Qué mide realmente Google PageSpeed Insights 🔍

Antes de perseguir el famoso número verde, conviene mirar el termómetro. Google PageSpeed Insights combina datos de laboratorio obtenidos mediante Lighthouse con, cuando existen, datos de campo procedentes del Chrome User Experience Report, conocido como CrUX. Es decir: una cosa es cómo se comporta tu página en una simulación controlada y otra, más incómoda y real, cómo la sufren o disfrutan los usuarios con móviles modestos, redes irregulares y navegadores cargados de vida.

La puntuación de Lighthouse se calcula principalmente con métricas de rendimiento. Estas han cambiado con el tiempo, y precisamente ahí reside una paradoja interesante: el 100/100 de ayer puede no ser el 100/100 de mañana. La web avanza como una marea; quien optimiza solo para pasar un test termina construyendo castillos en la arena.

Dato importante: desde marzo de 2024, INP sustituyó a FID como Core Web Vital de interacción. Si una guía actual todavía insiste en FID como métrica principal, quizá también recomiende optimizar para Internet Explorer con mirada nostálgica. Encantador, sí. Útil, no tanto.

Diagnóstico profesional antes de tocar código 🧪

Optimizar sin medir es decorar una habitación a oscuras. Puede salir bien, pero no conviene presumir de método. Antes de cambiar HTML, CSS o JavaScript, realiza una auditoría seria con varias herramientas, porque PageSpeed Insights no es un oráculo: es una linterna. Ilumina mucho, pero no todo.

Herramientas recomendadas

• PageSpeed Insights: útil para Lighthouse y datos CrUX si hay suficiente tráfico.
• Chrome DevTools: imprescindible para revisar Performance, Network, Coverage y Lighthouse local.
• WebPageTest: excelente para probar ubicaciones, velocidades de red, waterfalls y filmstrips.
• GTmetrix: práctico para explicar problemas a clientes o equipos no técnicos.
• Query Monitor en WordPress: útil para detectar consultas lentas, hooks pesados y scripts cargados por plugins.

Una mañana, hace años, vi una página corporativa cargar 37 archivos CSS. Treinta y siete. La home tenía tres párrafos, dos botones y una foto del equipo sonriendo como si no supieran nada. La explicación era sencilla: cada plugin había traído su pequeña maleta de estilos, y nadie revisó el equipaje. Aquello me recordó a esas bodas donde todos quieren dar un discurso y al final el postre llega frío.

Qué revisar en el waterfall

• Tiempo hasta el primer byte: si el servidor responde tarde, el frontend empieza tarde.
• Recursos render-blocking: CSS y JS que bloquean el primer renderizado.
• Tamaño total transferido: especialmente JavaScript, fuentes e imágenes.
• Número de solicitudes: HTTP/2 y HTTP/3 toleran más peticiones, pero no convierten el caos en virtud.
• Scripts de terceros: analytics, mapas, chatbots, píxeles, embeds sociales y publicidad.

Regla práctica: si una optimización no mejora una métrica relevante o la experiencia percibida, no es optimización; es gimnasia técnica. Bonita para quien la ejecuta, invisible para quien navega.

Optimización avanzada de HTML 🧱

El HTML es el esqueleto de la página. Si llega limpio, semántico y ligero, el navegador trabaja con la serenidad de un bibliotecario ante estantes bien ordenados. Si llega inflado, duplicado y lleno de envoltorios innecesarios, cada renderizado se convierte en una pequeña excavación arqueológica.

1. Reduce el DOM: menos nodos, menos fatiga

Un DOM excesivo afecta al cálculo de estilos, al layout y a la interacción. PageSpeed suele advertirlo con mensajes como “Avoid an excessive DOM size”. No hay una cifra universal, pero Lighthouse suele señalar páginas con demasiados nodos, demasiada profundidad o demasiados hijos por nodo.

En constructores visuales de WordPress, este problema es habitual. Una simple tarjeta puede terminar envuelta en cinco divs, tres contenedores, dos wrappers y una promesa de diseño “sin código”. La antítesis es cruel: herramientas pensadas para simplificar la edición pueden complicar brutalmente el renderizado.

Buenas prácticas para un DOM más eficiente

• Elimina contenedores sin función visual, semántica o técnica.
• Usa etiquetas semánticas: <header>, <main>, <nav>, <article>, <section>, <footer>.
• Evita listas, columnas y grids generados con estructuras innecesariamente profundas.
• No dupliques bloques para móvil y escritorio si puedes resolverlo con CSS responsive.
• Revisa componentes repetidos: sliders, mega menús, acordeones y testimonios suelen multiplicar nodos sin piedad.

2. Minifica HTML, pero sin convertirlo en fetiche

La minificación elimina espacios, saltos de línea y comentarios. Ayuda, sí, aunque normalmente su impacto es menor que reducir JavaScript o CSS. Minificar HTML es como doblar bien la ropa en una maleta; útil, pero no sirve de mucho si intentas viajar con un piano.

<!-- Antes -->
<section>
  <h1>Servicios de mantenimiento web</h1>
  <p>Optimizamos velocidad, seguridad y rendimiento.</p>
</section>

<!-- Después de minificar -->
<section><h1>Servicios de mantenimiento web</h1><p>Optimizamos velocidad, seguridad y rendimiento.</p></section>

3. Prioriza recursos críticos desde el HTML

El navegador descubre recursos conforme parsea el documento. Si una imagen LCP aparece tarde en el HTML o está escondida detrás de JavaScript, cargará tarde. Y PageSpeed, que no suele tener compasión estética, lo notará.

Para recursos realmente importantes, utiliza preload, fetchpriority y dimensiones explícitas. Pero con moderación: si todo es prioritario, nada lo es. El navegador no necesita un director de orquesta histérico.

<link rel="preload" as="image" href="/img/hero.webp" fetchpriority="high">

<img
  src="/img/hero.webp"
  width="1440"
  height="720"
  alt="Panel de optimización web"
  fetchpriority="high"
  decoding="async">

4. Evita HTML generado por JavaScript cuando no sea necesario

Una SPA puede ser magnífica para aplicaciones complejas, pero no toda página corporativa necesita comportarse como si fuera el panel de control de una nave espacial. Si el contenido principal depende de JavaScript para aparecer, el navegador debe descargar, parsear y ejecutar código antes de mostrar algo útil. En SEO y rendimiento, eso puede ser una cuesta arriba.

Para sitios de contenido, tiendas pequeñas, blogs, landings y páginas de servicios, suele ser mejor entregar HTML renderizado desde el servidor o usar generación estática. El viejo HTML, ese abuelo discreto, sigue ganando carreras mientras frameworks modernos se atan los cordones.

Optimización de CSS: critical CSS, CSS no usado y renderizado 🎨

El CSS tiene una peculiaridad: bloquea el renderizado por defecto. El navegador no quiere pintar una página para tener que repintarla un instante después con estilos definitivos. Es prudente, casi educado. Pero si le entregamos 300 KB de CSS para mostrar una cabecera, una frase y un botón, la prudencia se vuelve atasco.

1. Identifica y elimina CSS no utilizado

Chrome DevTools incluye una pestaña llamada Coverage que muestra cuánto CSS y JavaScript se usa realmente durante la carga. Es común encontrar hojas de estilo con 70%, 80% o incluso 95% de código no utilizado en la página inicial.

Esto ocurre mucho con frameworks CSS completos, temas multipropósito y plugins que cargan estilos globales aunque solo se usen en una página. El resultado es una ironía doméstica: instalamos herramientas para “ahorrar tiempo” y luego gastamos horas quitando lo que trajeron.

Cómo reducir CSS no usado

• Divide CSS por plantilla o componente: no cargues estilos de tienda en una entrada de blog si no son necesarios.
• Usa PurgeCSS, Lightning CSS o herramientas equivalentes: especialmente en proyectos con Tailwind, Bootstrap o CSS acumulado.
• Desactiva assets por página en WordPress: plugins como Perfmatters, Asset CleanUp o soluciones personalizadas con wp_dequeue_style pueden ayudar.
• Revisa constructores visuales: algunos permiten generar CSS optimizado por página.

2. Extrae el Critical CSS

El Critical CSS es el conjunto mínimo de estilos necesarios para renderizar la parte visible inicial, conocida como above the fold. Incluirlo en línea dentro del <head> permite pintar antes el contenido principal, mientras el resto del CSS se carga de forma diferida.

<style>
  body{margin:0;font-family:system-ui,sans-serif;color:#111}
  .hero{padding:64px 24px;background:#f4f7fb}
  .hero h1{font-size:clamp(2rem,5vw,4rem);line-height:1.1;margin:0}
  .hero p{font-size:1.25rem;max-width:720px}
</style>

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

Cuidado: insertar demasiado CSS crítico en línea puede inflar el HTML y perjudicar el cacheo. El objetivo no es meter toda la casa en la mochila, sino llevar las llaves, el mapa y una linterna.

3. Evita @import en CSS

Usar @import dentro de hojas CSS puede retrasar el descubrimiento de recursos, porque el navegador debe descargar un archivo para descubrir que necesita otro. Es una conversación burocrática entre archivos: “vaya a la ventanilla B”. Mejor enlazar los estilos directamente desde el HTML.

/* Evitar */
@import url("/css/fonts.css");
@import url("/css/components.css");

/* Mejor: enlazar desde el HTML */
<link rel="stylesheet" href="/css/fonts.css">
<link rel="stylesheet" href="/css/components.css">

4. Optimiza fuentes web

Aunque el título hable de HTML, CSS y JS, las fuentes merecen silla en la mesa. Una tipografía externa mal cargada puede retrasar texto visible y afectar LCP o CLS. Usa formatos modernos como WOFF2, limita variantes y declara font-display: swap para evitar texto invisible.

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

5. Usa CSS moderno para reducir JavaScript

Muchas interacciones que antes requerían JavaScript hoy pueden resolverse con CSS: menús sencillos, acordeones con <details>, animaciones discretas, layouts complejos con Grid y estilos condicionales con :has() en navegadores modernos. Menos JavaScript significa menos parseo, menos ejecución y menos bloqueo del hilo principal.

<details>
  <summary>¿PageSpeed afecta al SEO?</summary>
  <p>Sí, especialmente a través de la experiencia de página y Core Web Vitals, aunque el contenido y la intención de búsqueda siguen siendo fundamentales.</p>
</details>

Optimización de JavaScript: menos bloqueo, más intención 🧠

JavaScript es poderoso. También es caro. Cada kilobyte debe descargarse, parsearse, compilarse y ejecutarse. El navegador no mastica JS como quien come aire; lo procesa como una máquina fina a la que le hemos pedido tocar violín mientras levanta pesas.

En la mayoría de auditorías de PageSpeed, JavaScript es el principal sospechoso detrás de advertencias como “Reduce unused JavaScript”, “Minimize main-thread work”, “Avoid long main-thread tasks” y “Eliminate render-blocking resources”.

1. Usa defer y async con criterio

Los scripts clásicos bloquean el parseo del HTML si se cargan sin atributos. Para evitarlo, se utilizan defer o async. Parecen primos, pero no son iguales.

<script src="/js/app.js" defer></script>
<script src="https://www.googletagmanager.com/gtag/js?id=XXXX" async></script>

2. Divide el código: code splitting

No todas las páginas necesitan todo el JavaScript de tu sitio. La página de contacto no debería cargar el carrusel de testimonios, el configurador de producto y el módulo de checkout si no los usa. El code splitting permite dividir bundles y cargar solo lo necesario.

// Ejemplo con import dinámico
document.querySelectorAll("[data-gallery]").forEach(async (gallery) => {
  const { initGallery } = await import("./gallery.js");
  initGallery(gallery);
});

Esta técnica mejora especialmente el Total Blocking Time y el INP, porque reduce el trabajo inicial del hilo principal. La página se vuelve más ágil, menos teatral. No intenta desplegar todo el escenario antes de que el espectador se siente.

3. Elimina JavaScript no usado

El código muerto es una forma elegante de llamar a lo que nadie usa pero todos cargan. Puede venir de librerías enteras importadas para usar una función diminuta, plugins antiguos, polyfills innecesarios o funcionalidades desactivadas que siguen viajando en producción como fantasmas con contrato indefinido.

• Importa funciones específicas en lugar de librerías completas.
• Usa tree shaking con bundlers modernos como Vite, Rollup, esbuild o Webpack bien configurado.
• Retira polyfills para navegadores que ya no forman parte de tu soporte real.
• Sustituye librerías pesadas por APIs nativas cuando sea viable.
• Audita dependencias con herramientas como Bundle Analyzer.

// Evitar si solo necesitas una función
import _ from "lodash";
const items = _.uniq(lista);

// Mejor
import uniq from "lodash/uniq";
const items = uniq(lista);

// O incluso mejor si basta JS nativo
const items = [...new Set(lista)];

4. Retrasa scripts de terceros

Los scripts de terceros son los invitados que llegan con amigos. Chatbots, mapas, píxeles publicitarios, embeds de redes sociales, herramientas de mapas de calor, gestores de consentimiento y sistemas de reseñas pueden degradar PageSpeed de manera severa. No porque sean malvados, sino porque no viven bajo tu techo.

Un enfoque profesional consiste en retrasar su carga hasta que exista interacción, consentimiento o necesidad visual real.

function loadScript(src) {
  const script = document.createElement("script");
  script.src = src;
  script.async = true;
  document.head.appendChild(script);
}

["mousemove", "scroll", "keydown", "touchstart"].forEach((event) => {
  window.addEventListener(event, () => {
    loadScript("https://example.com/widget.js");
  }, { once: true, passive: true });
});

Nota legal y técnica: si trabajas con scripts de analítica, publicidad o remarketing, coordina la carga diferida con el banner de consentimiento y la normativa aplicable, como RGPD en la Unión Europea. La velocidad no justifica atropellar la privacidad; bastante hemos aprendido ya, o eso queremos creer.

5. Rompe tareas largas

Una tarea larga en el hilo principal puede bloquear la interacción. Para mejorar INP y TBT, divide procesos pesados en fragmentos más pequeños, usa requestIdleCallback cuando sea apropiado o traslada cálculos complejos a Web Workers.

// Evita bloquear el hilo principal con grandes lotes
function processItems(items) {
  const chunk = items.splice(0, 100);

  chunk.forEach(processItem);

  if (items.length > 0) {
    setTimeout(() => processItems(items), 0);
  }
}

6. Minifica, comprime y sirve JS moderno

La minificación reduce el tamaño del archivo. La compresión Brotli o Gzip reduce el tamaño transferido. Pero además conviene servir JavaScript moderno a navegadores modernos, evitando transformaciones excesivas que inflan el código.

<script type="module" src="/js/app.modern.js"></script>
<script nomodule src="/js/app.legacy.js" defer></script>

El atributo type="module" implica comportamiento diferido por defecto. Es una pequeña cortesía del estándar, como si el navegador dijera: “tranquilo, esto lo ejecuto cuando corresponda”.

Caso WordPress: cómo evitar que el CMS se convierta en lastre 🛠️

WordPress puede ser rápido. Muy rápido. También puede convertirse en una criatura barroca hecha de plugins duplicados, temas gigantes y sliders que nadie mira. El contraste es magnífico: el mismo CMS que impulsa proyectos editoriales ágiles puede arrastrar una landing de tres secciones como si fuera un elefante cruzando un puente de madera.

1. Elige un tema ligero

La optimización empieza antes de escribir código. Temas como GeneratePress, Astra, Blocksy o Kadence pueden funcionar muy bien si se configuran con sobriedad. Un tema multipropósito con decenas de demos, sliders integrados, icon packs, animaciones y constructores embebidos puede ser cómodo al principio y caro después.

2. Desactiva scripts y estilos por página

WordPress permite retirar assets con wp_dequeue_script y wp_dequeue_style. Esto requiere conocer bien las dependencias, pero ofrece un control fino.

add_action('wp_enqueue_scripts', function() {
  if (!is_contact_page()) {
    wp_dequeue_script('contact-form-7');
    wp_dequeue_style('contact-form-7');
  }
}, 100);

También puedes usar plugins especializados para gestionar assets sin tocar código. Eso sí, prueba cada cambio: desactivar un script incorrecto puede romper formularios, menús o carritos de compra. La velocidad no sirve de mucho si el botón de compra queda como estatua decorativa.

3. Optimiza el editor de bloques y constructores

• Evita bloques con animaciones innecesarias above the fold.
• No uses sliders hero si una imagen estática comunica lo mismo.
• Reduce columnas anidadas y wrappers generados por el constructor.
• Activa generación de CSS por página si tu builder lo permite.
• Desactiva icon libraries completas si solo usas dos iconos SVG.

4. Caché, compresión y servidor

Aunque esta guía se centra en HTML, CSS y JavaScript, sería poco honesto ignorar el servidor. Un frontend pulcro sobre un hosting lento es como poner neumáticos de Fórmula 1 a una carreta. Para PageSpeed, el TTFB importa.

• Usa caché de página completa para contenido público.
• Activa Object Cache con Redis o Memcached en sitios dinámicos.
• Sirve recursos estáticos con CDN cuando tenga sentido geográfico.
• Activa Brotli si el servidor o CDN lo soporta.
• Usa HTTP/2 o HTTP/3.
• Mantén PHP actualizado: PHP 8.x ofrece mejoras relevantes frente a versiones antiguas.

5. WooCommerce: el caso delicado

Optimizar una tienda online exige más cautela. Carrito, checkout, sesiones, fragmentos AJAX y pasarelas de pago no deben tocarse con alegría quirúrgica. En WooCommerce, conviene desactivar scripts del carrito solo en páginas donde no sean necesarios y mantener intactos procesos críticos.

add_action('wp_enqueue_scripts', function() {
  if (!is_cart() && !is_checkout() && !is_product()) {
    wp_dequeue_script('wc-cart-fragments');
  }
}, 100);

Recomendación profesional: prueba cualquier optimización de WooCommerce en staging antes de producción. El 100/100 pierde encanto si la tienda deja de vender. Nadie imprime facturas con capturas de PageSpeed.

Core Web Vitals: el número verde no lo es todo 📊

El objetivo no debería ser únicamente “sacar 100”, sino mejorar la experiencia real del usuario. PageSpeed es una medición de laboratorio; los Core Web Vitals de campo reflejan condiciones reales. Una web puede obtener 98 en Lighthouse y fallar en usuarios reales por culpa de redes lentas, dispositivos modestos o scripts cargados tras consentimiento.

Valores de referencia recomendados por Google

Cómo mejorar LCP desde HTML, CSS y JS

• Coloca el elemento LCP pronto en el HTML.
• Evita que el hero dependa de JavaScript para renderizarse.
• Precarga la imagen principal si es realmente prioritaria.
• Reduce CSS bloqueante y extrae Critical CSS.
• Optimiza fuentes para que el texto principal aparezca rápido.
• No uses lazy loading en la imagen LCP above the fold.

Cómo mejorar INP

• Reduce JavaScript inicial y elimina tareas largas.
• Difiere scripts no críticos.
• Evita listeners excesivos o costosos en scroll, resize y input.
• Usa delegación de eventos cuando sea apropiado.
• Optimiza componentes interactivos: menús, filtros, buscadores, carritos y formularios.

Cómo mejorar CLS

• Define width y height en imágenes y vídeos.
• Reserva espacio para banners, iframes y anuncios.
• Evita insertar contenido above the fold después de la carga.
• Controla el comportamiento de fuentes para reducir saltos visuales.
• No cambies dimensiones de componentes al hidratar JavaScript.

Presupuesto de rendimiento: la disciplina que evita recaídas 💼

Una web optimizada puede deteriorarse en silencio. Hoy tiene 100/100; mañana alguien instala un chat, pasado mañana se añade un mapa interactivo, la semana siguiente entra un píxel publicitario “imprescindible”, y al mes la página carga como un barco con el ancla echada. La degradación rara vez llega con trompetas. Llega en reuniones.

Por eso conviene establecer un performance budget, es decir, límites técnicos aceptados por el equipo.

Estos números no son mandamientos grabados en piedra. Dependen del proyecto. Una aplicación SaaS no tiene el mismo presupuesto que una página de captación local. Pero tener límites cambia la conversación: ya no se pregunta “¿podemos añadir esto?”, sino “¿qué coste tendrá y qué retiramos a cambio?”. Esa pregunta, aunque parezca pequeña, separa una web mantenible de un trastero digital.

Ejemplo de estrategia completa para una página de servicios 🚀

Imaginemos una página de servicios profesionales en WordPress. Tiene cabecera, hero con imagen, tres bloques de servicios, testimonios, formulario de contacto y footer. Quiere mejorar PageSpeed móvil, reducir recursos bloqueantes y acercarse al 100/100.

Plan de optimización

1. Auditar: ejecutar PageSpeed, WebPageTest y DevTools Coverage.
2. HTML: reducir wrappers del constructor, dejar el H1 y texto principal renderizados desde servidor.
3. Imagen LCP: convertir a WebP o AVIF, definir dimensiones, usar fetchpriority="high" y evitar lazy loading.
4. CSS: generar Critical CSS, eliminar estilos de WooCommerce si no hay tienda en esa URL, desactivar CSS de plugins no usados.
5. JS: aplicar defer a scripts propios, retrasar chat y mapas hasta interacción.
6. Formulario: cargar scripts del formulario solo en páginas con formulario.
7. Fuentes: alojar localmente una variable font en WOFF2 con font-display: swap.
8. Caché: activar caché de página, Brotli y CDN si el tráfico es internacional.
9. Verificar: repetir pruebas en incógnito, móvil simulado y dispositivo real.

Resultado esperable

En casos típicos, estos cambios pueden reducir cientos de kilobytes, eliminar bloqueos de renderizado y mejorar notablemente LCP y TBT. ¿Garantiza un 100/100? No siempre. Depende del hosting, del tema, de terceros, del diseño y del contenido. Pero sí coloca la web en el terreno donde el 100 deja de ser fantasía y se vuelve posibilidad técnica.

Checklist final para alcanzar 100/100 en Google PageSpeed ✅

HTML

• DOM reducido y estructura semántica.
• Contenido principal visible sin depender de JS.
• Imagen LCP ubicada pronto en el documento.
• Dimensiones declaradas en imágenes, vídeos e iframes.
• HTML minificado en producción.

CSS

• Critical CSS inline bien calculado.
• CSS no usado eliminado o separado por página.
• Hojas de estilo minificadas.
• Sin @import bloqueante.
• Fuentes optimizadas con WOFF2 y font-display.

JavaScript

• Scripts propios con defer.
• Terceros con async, retraso o carga bajo consentimiento.
• Code splitting aplicado cuando sea necesario.
• JavaScript no usado eliminado.
• Tareas largas divididas o enviadas a Web Workers.

WordPress

• Tema ligero y plugins auditados.
• Assets desactivados por página.
• Caché de página activa.
• Base de datos limpia y PHP actualizado.
• Pruebas en staging antes de producción.

Errores frecuentes que impiden llegar al 100/100 🧯

• Optimizar solo escritorio: PageSpeed móvil suele ser más exigente y más representativo del usuario común.
• Instalar plugins de rendimiento sin configuración: algunos duplican funciones, generan conflictos o rompen scripts críticos.
• Usar lazy loading indiscriminado: aplicarlo a la imagen principal puede empeorar LCP.
• Ignorar scripts de terceros: muchas veces son el verdadero peso muerto.
• No reservar espacio para elementos dinámicos: causa CLS y una experiencia visual inestable.
• Perseguir el 100 sacrificando funcionalidad: una web rápida pero inútil es una bicicleta sin ruedas: ligera, desde luego.

¿Vale la pena obsesionarse con el 100/100? 🎯

Sí y no. Qué cómoda respuesta, lo sé. Un 100/100 en PageSpeed puede ser un excelente indicador de disciplina técnica, especialmente en páginas estáticas, blogs optimizados, landings sencillas y sitios corporativos bien construidos. Pero en proyectos complejos, con personalización, comercio electrónico, mapas, sistemas de reserva o marketing avanzado, quizá el objetivo sensato sea mantener Core Web Vitals en verde, reducir fricción y proteger conversiones.

La diferencia entre 96 y 100 puede consumir horas que aportarían más valor mejorando contenido, accesibilidad, seguridad o arquitectura de información. La excelencia no siempre está en exprimir cuatro puntos, sino en saber cuándo detener la lima antes de romper la pieza.

Aun así, apuntar alto tiene virtud. Obliga a cuestionarlo todo: cada dependencia, cada animación, cada plugin, cada kilobyte. Y esa mirada crítica mejora la web incluso cuando el marcador no alcanza la perfección redonda. Porque el verdadero premio no es complacer a Lighthouse, sino entregar una experiencia veloz, estable y clara. Una página que aparece sin drama, responde sin pereza y deja al usuario avanzar como agua por piedra pulida.

En síntesis práctica: para acercarte al 100/100 en Google PageSpeed, reduce el DOM, entrega HTML útil desde el inicio, extrae Critical CSS, elimina CSS y JavaScript no usados, difiere lo no esencial, controla terceros, optimiza fuentes y mide cada cambio. La velocidad web no nace de un truco aislado, sino de una suma de decisiones pequeñas, persistentes y bien defendidas.