Cuando enseño un informe de PageSpeed con todo en verde —100 en escritorio, las métricas que de verdad cuentan en su sitio— la reacción habitual es: "qué suerte, te ha salido bien". Y no. Eso no sale solo. Sale de tomar cinco decisiones técnicas concretas antes de escribir la primera línea de código, y de no renunciar a ninguna por el camino.
Te las cuento todas. Sin tecnicismos donde no hacen falta, y con el detalle técnico donde sí, por si lo tuyo es mirar debajo del capó.
Antes de empezar: qué mide de verdad ese 100
Aquí va lo que casi nadie te cuenta, y conviene saberlo antes de seguir.
El 100 de PageSpeed (la parte de Lighthouse) es una medición de laboratorio: una simulación en condiciones controladas. Útil, pero no es la nota que Google usa para posicionarte. Esa nota viene de los Core Web Vitals — datos de usuarios reales recogidos por Chrome, de gente entrando a tu web con su móvil y su conexión, no con una fibra de 1 giga.
Son tres métricas, y en 2026 los umbrales para estar "bien" son estos:
- LCP (lo que tarda en verse el contenido principal): menos de 2,5 segundos.
- INP (lo que tarda la web en responder cuando tocas algo): menos de 200 milisegundos.
- CLS (que las cosas no se muevan solas mientras carga): menos de 0,1.
¿Por qué te lo cuento si el post va del 100? Porque las cinco decisiones que vienen no persiguen el número bonito. Persiguen que esas tres métricas estén en verde con usuarios reales. El 100 de Lighthouse llega de propina cuando lo otro está bien hecho. Al revés no funciona.
Un dato de 2026 para que veas que esto no es estética: el INP es la métrica que más webs suspenden — casi la mitad de los sitios no llega al umbral. Y no se arregla comprimiendo una imagen. Se arregla en la arquitectura, que es justo de lo que van las decisiones que siguen.
Decisión 1 · Generar el HTML antes, no en el navegador del usuario
La primera decisión es la más invisible y la que más pesa.
Hay dos formas de construir una web. Una manda al navegador del usuario un montón de JavaScript y le dice "ahí te apañas, monta tú la página". La otra genera la página entera de antemano, ya hecha, y al usuario solo le llega HTML listo para mostrar. Yo trabajo siempre con la segunda cuando el proyecto lo permite — una web de servicios casi siempre lo permite.
La diferencia para el usuario es brutal: en vez de esperar a que su móvil haga el trabajo, recibe la página terminada. El contenido principal aparece de inmediato (eso es el LCP en verde) y no hay un montón de código ejecutándose que bloquee la respuesta a sus toques (eso ayuda al INP).
El detalle técnico: trabajo con Astro en modo generación estática (SSG). Cada página se construye en el momento del despliegue y se sirve como HTML plano. Cero renderizado en cliente para el contenido que importa. El servidor responde rápido porque no tiene que calcular nada en cada visita: el archivo ya existe.
Decisión 2 · Cero JavaScript por defecto
Esta es la decisión que más gente se salta, y la que más caro paga.
La mayoría de webs cargan JavaScript que no necesitan. Librerías enteras para un menú, frameworks completos para una página que es texto y un formulario. Todo ese código tiene que descargarse, leerse y ejecutarse en el móvil del usuario antes de que la web responda bien. Es el principal motivo de un INP malo.
Mi regla es al revés: una web no lleva JavaScript salvo que una pieza concreta lo necesite de verdad. Y cuando lo necesita, solo carga esa pieza, no toda la maquinaria.
El detalle técnico: Astro envía cero JS al cliente por defecto. La interactividad se añade por "islas" — componentes que se hidratan de forma aislada y solo cuando hacen falta (un carrusel, un mapa, el embed de reservas). El resto de la página sigue siendo HTML estático. El hilo principal del navegador queda libre, que es exactamente lo que el INP premia.
Decisión 3 · Imágenes que no frenan la carga
Las imágenes son, de lejos, lo que más pesa en una web normal. Y son la causa número uno de un LCP lento, sobre todo en la home y en los posts del blog.
Una foto sin optimizar puede pesar dos megas. La misma foto, bien tratada, pesa una décima parte y se ve igual. Multiplica eso por todas las imágenes de la página y entiendes por qué muchas webs tardan una eternidad en el primer pintado.
Aquí no hay un truco, hay disciplina en cuatro frentes:
- Formatos modernos (AVIF o WebP) que pesan mucho menos que el JPG de toda la vida.
- Tamaños adaptados: el móvil no descarga la imagen pensada para una pantalla grande. Recibe la versión justa para su pantalla.
- Dimensiones declaradas en cada imagen, para que el navegador reserve el hueco y no se mueva nada al cargar (eso mantiene el CLS en cero).
- Carga diferida de lo que está más abajo: solo se descarga lo que el usuario va a ver.
El detalle técnico: uso el componente de imagen de Astro, que genera los formatos y tamaños en el build y emite el srcset con las dimensiones ya puestas. La imagen destacada de cada página, que suele ser el elemento LCP, se marca para que cargue con prioridad. El resto, diferido.
Un caso real de esto, porque es de los problemas que más cuestan de diagnosticar. En la web de Inmopatitas el rendimiento en móvil se quedaba clavado en 76, y un 76 es un suspenso. La causa no era obvia: la imagen de portada se servía desde el gestor de contenido, que vive en otro dominio, y esa llamada extra penalizaba el momento en que el usuario ve el contenido. En vez de parchear a ciegas o sacrificar el diseño, localicé la causa exacta y apliqué la solución justa: precargar esa imagen con prioridad alta desde la cabecera. El móvil saltó de 76 a 94, sin tocar el diseño ni complicar la arquitectura. Eso es lo que diferencia hacer una web de hacerla bien: saber dónde está el cuello de botella y resolverlo sin romper otra cosa.
Decisión 4 · El CSS justo, y en el momento justo
El CSS es el código que da estilo a la web. Y tiene una trampa: el navegador no pinta nada hasta que ha procesado el CSS que necesita. Si ese archivo es enorme o llega tarde, el usuario mira una pantalla en blanco mientras espera.
La decisión aquí es doble: que haya poco CSS, y que el imprescindible para lo primero que se ve llegue de inmediato.
El detalle técnico: el CSS crítico — el que pinta lo que se ve sin hacer scroll — va incrustado directamente en el HTML, así que no hay que esperar a descargar ningún archivo para empezar a pintar. El resto se carga sin bloquear. Y al ser un proyecto a medida, no arrastro hojas de estilo de una plantilla con miles de reglas que no uso. Solo está lo que la web realmente necesita.
Esto es justo lo contrario de coger una plantilla de WordPress: ahí heredas el CSS y el JS de un tema pensado para servir a todo el mundo, y acabas cargando peso para funciones que tu web ni usa.
Decisión 5 · Tipografías que no bloquean ni saltan
Las fuentes parecen un detalle menor y son un sospechoso habitual de dos problemas a la vez: frenan el pintado y provocan saltos de texto.
Si la web pide la fuente a un servidor externo (lo típico con Google Fonts enlazado), suma una conexión más que esperar. Y si el texto aparece primero con una fuente del sistema y luego cambia a la definitiva, ves un salto incómodo: eso penaliza el CLS.
La decisión: la fuente vive en mi propio servidor, se precarga, y se le dice al navegador que muestre texto desde el primer momento.
El detalle técnico: tipografías auto-alojadas (self-hosted), con preload de los pesos que se usan arriba del todo y font-display: swap para que nunca haya texto invisible esperando. Sin llamadas a dominios externos, una conexión menos que negociar. El texto se ve ya, y no salta.
Lo que de verdad significa el 100
Llegar al 100 no es el objetivo. Es la señal de que las decisiones de debajo están bien tomadas.
Y lo que hay debajo sí importa para tu negocio, no solo para tener el número en verde:
- Google usa el rendimiento real como factor de posicionamiento, y en 2026 pesa más que hace un año. Una web rápida parte con ventaja.
- Una web que carga en menos de dos segundos retiene mucha más gente que una que tarda cinco. Cada segundo de más se traduce en visitas que se van antes de leerte.
- Y una web cuidada en lo técnico transmite, sin decir nada, que detrás hay alguien que sabe lo que hace. Eso también vende.
Lo importante: nada de esto sale de un plugin que activas el último día. Sale de decisiones tomadas desde el principio, cuando aún no hay ni una página hecha. Por eso una web a medida llega a estos números sin despeinarse y una plantilla genérica, por mucho que la optimices después, casi nunca lo consigue del todo.
Y una última cosa, que va con cómo entiendo yo esto. El número no es un dogma. En el porfolio de ytantos, un estudio de diseño, lo automático habría sido generar recortes de cada imagen para exprimir el rendimiento. Pero esos recortes deformaban las piezas, y en una web cuyo contenido es diseño, eso no se negocia. Así que serví cada imagen a su tamaño real. La web sigue en 100 de escritorio, pero la decisión fue saber qué optimizar y qué no tocar. Perseguir el número a ciegas y cargarte lo que importa es justo lo contrario de hacer las cosas bien.
Si quieres ver cómo se traduce todo esto en proyectos reales, aquí tienes dos:
- Inmopatitas — de un WordPress lento a una web propia y rápida en una semana → [enlace al caso] · inmopatitas.es
- ytantos — de años sin web a un porfolio bilingüe y autogestionable, en 4 días → [enlace al caso] · ytantos.com
¿Tu web va lenta y no sabes por dónde empezar? Es justo el tipo de cosa que miro en un diagnóstico. Cualquier cosa que necesites, ya sabes dónde estoy.