El rendimiento no es una puntuación de Lighthouse que se luce con orgullo una vez. Es una disciplina. Aquí van tres palancas que aplicamos sistemáticamente — qué aportan, por qué, dónde van, y cómo las usamos.
1. AVIF: dividir el peso de las imágenes
Qué aporta. AVIF deriva del códec de vídeo AV1. A igual calidad, produce archivos entre un 30 y un 50% más ligeros que el WebP, y mucho más frente al JPEG. En una página, suele ser el ahorro n.º 1.
Por qué importa. Las imágenes representan la mayor parte del peso de una página. Reducir ese peso significa, mecánicamente, una página más rápida, un mejor LCP y una factura más ligera. En 2026, AVIF está soportado por ~93–95% de los navegadores (Chrome, Firefox, Edge, Opera, Safari 16+, iOS 16+).
<picture>
<source type="image/avif" srcset="photo.avif">
<source type="image/webp" srcset="photo.webp">
<img src="photo.jpg" loading="lazy" decoding="async" alt="…">
</picture>La trampa. La codificación AVIF es lenta: la hacemos en la subida o en el build (nunca al vuelo), generamos varios tamaños y cacheamos el resultado. Es exactamente lo que hace nuestro ImageProcessor.
El futuro de las imágenes: JPEG XL
JPEG XL (norma ISO desde 2022) ha tenido un recorrido caótico: añadido a Chrome tras un flag en 2021, retirado en 2023, luego reintroducido en Chrome 145 a principios de 2026 (aún tras un flag, decodificador en Rust). Safari lo soporta por defecto desde la 17; en total, ~16% de soporte nativo.
Su baza definitiva: la recompresión JPEG sin pérdida — reducir un JPEG en torno a un 20% de forma reversible. Pero en 2026 no servimos JXL solo: la estrategia sigue siendo AVIF como principal, WebP/JPEG como repliegue, y preparamos JXL para más adelante.
| Format | Soporte 2026 | Compresión | Cuándo usarlo |
|---|---|---|---|
| WebP | ~97 % | −25–35 % vs JPG | Repliegue seguro |
| AVIF | ~93–95 % | −30–50 % vs WebP | Formato principal hoy |
| JPEG XL | ~16% (Safari, Chrome tras un flag) | ≈ AVIF + recompresión JPEG sin pérdida | Preparar para mañana |
2. Redis: la caché que lo cambia todo
Qué aporta. Redis es un almacén clave-valor en memoria. Todo lo que es costoso pero estable — configuraciones, menús, fragmentos, agregados — se guarda ahí y vuelve en milisegundos. Sirve también para las sesiones y las colas.
Por qué importa. Sin caché, cada visita vuelve a golpear la base. Con Redis, la base respira y las páginas responden al instante. La única dificultad real: la invalidación — vaciar la clave correcta en el momento correcto.
// CodeIgniter 4 — memorizar un agregado pesado 5 min
$key = "stats:dashboard:{$userId}";
$data = cache($key);
if ($data === null) {
$data = $this->statsModel->heavyAggregate($userId);
cache()->save($key, $data, 300);
}
return $data;El futuro de Redis: Valkey
En marzo de 2024, Redis abandonó su licencia open source BSD por un modelo source-available (RSALv2/SSPL). En respuesta, la Linux Foundation (AWS, Google, Oracle, Ericsson…) creó Valkey, un fork open source de Redis 7.2.4 bajo licencia BSD. Redis 8 ha vuelto desde entonces a AGPL, pero Valkey sigue creciendo.
En la práctica, Valkey es compatible a nivel de protocolo: reemplazo directo, sin cambio de código. Como Redis 7.2 está en fin de vida (febrero de 2026), para autoalojamiento (OVH/Plesk) Valkey es la apuesta open source más tranquila.
3. Lazy-load: cargar solo lo visible
Qué aporta. El lazy-load aplaza la carga de las imágenes e iframes fuera de pantalla: menos bytes en el primer render, un time-to-interactive más corto. Hoy es nativo con loading="lazy", soportado en todas partes.
El matiz. No aplicamos lazy-load a la imagen más importante de la parte superior (el LCP): al contrario, le damos prioridad con fetchpriority="high". Para el ajuste fino, lo completamos con vanilla-lazyload.
<!-- Imagen a pantalla completa (LCP): priorizada, no lazy -->
<img src="hero.avif" fetchpriority="high" decoding="async" alt="…">
<!-- El resto: diferido -->
<img src="carte.avif" loading="lazy" decoding="async" alt="…">El hilo conductor: medir, no adivinar
Estas tres palancas solo valen si las verificas. Perfilamos (Lighthouse, WebPageTest), vigilamos los Core Web Vitals (LCP, INP, CLS), cazamos las consultas N+1 y los assets bloqueantes. El rendimiento se gana con hechos, no con corazonadas.
La web sobria no es una pose ecológica de fachada: una página ligera es una página rápida, más barata de servir, y accesible incluso con una caprichosa conexión bretona.