Allá por diciembre de 2010 publicamos esta entrada original probando mod_pagespeed, el módulo de Apache que Google había liberado para optimizar páginas web sin tocar el código. Lo combinamos con memcached en un servidor virtual con Apache 2.2, PHP 5.3 y MySQL 5, y la web corporativa de Colorvivo ganó velocidad de forma evidente en aquellos test de Pingdom y GTmetrix.
Quince años después tiene sentido releer aquel post. Mod_pagespeed dejó de mantenerse oficialmente el 3 de abril de 2020, Apache ya no es la opción mayoritaria entre las agencias WordPress y el listón de rendimiento lo marcan los Core Web Vitals de Google. Aun así, las decisiones que tomamos en 2010 (compresión, caché de objetos, optimizar lo que tarda) siguen siendo la base de cómo hacemos las cosas hoy.
Lo que era mod_pagespeed y por qué nos enganchó en 2010
Mod_pagespeed (publicado por Google en noviembre de 2010, semanas antes del post original) automatizaba decenas de optimizaciones del lado del servidor: minificar HTML, CSS y JavaScript, combinar archivos, posponer la carga de imágenes, reescribir URLs estáticas con cache busting y aplicar compresión adicional. Todo sin tocar la plantilla de WordPress ni la configuración del theme.
Para una agencia que entonces gestionaba decenas de instalaciones WordPress sobre Apache, aquello era oro. Editabas el archivo pagespeed.conf, activabas los filtros que tenían sentido (rewrite_images, combine_css, extend_cache) y veías mejorar tiempos de carga sin pedir cambios al cliente.
Por qué desapareció (y qué quedó del intento)
Google retiró el soporte de mod_pagespeed y su gemelo ngx_pagespeed en abril de 2020. La razón oficial fue que el ecosistema había madurado: HTTP/2 primero y HTTP/3 después se llevaban por delante muchas optimizaciones que mod_pagespeed hacía a mano (combinar archivos, por ejemplo, dejó de aportar con multiplexado). Brotli sustituyó a gzip como compresión por defecto, los CDN integraron la mayor parte de los filtros y los navegadores empezaron a cargar imágenes en formatos modernos como WebP y AVIF.
Lo curioso es que muchas ideas de mod_pagespeed se infiltraron en el stack moderno: cache busting automático lo hace cualquier plugin de caché serio, la reescritura de imágenes la asume el propio CDN y la minificación está dentro del bundler del theme. El módulo murió, pero las prácticas se quedaron.
Memcached, en cambio, sigue vivo (y bien acompañado)
El otro protagonista del post de 2010, memcached, sí ha aguantado el paso del tiempo. Sigue siendo un sistema válido para cachear objetos en memoria, aunque hoy Redis le ha comido buena parte del terreno por su gestión de tipos de datos, persistencia opcional y replicación nativa.
En WordPress, la pieza que conecta el CMS con esos sistemas se llama object cache. Plugins como Redis Object Cache o Memcached Object Cache reemplazan el caché transitorio que WordPress guarda en la base de datos por uno en memoria, lo que reduce drásticamente las consultas a MySQL en sitios con tráfico medio o alto. En proyectos con catálogos grandes o muchas consultas personalizadas, este cambio explica buena parte del salto de rendimiento que cuentan los equipos al migrar.
Si te interesa cómo afinar las consultas detrás del object cache, escribimos hace un tiempo sobre optimización de WP_Query en sitios de alto tráfico, donde entramos en cómo evitar las llamadas costosas que ningún caché va a salvarte si están mal escritas.
Cómo optimizamos hoy WordPress en Colorvivo
El planteamiento de fondo no ha cambiado tanto: mover lo que se pueda fuera del proceso PHP, servir archivos comprimidos, evitar consultas repetidas y medir antes y después. Lo que ha cambiado son las piezas que usamos.
- Servidor web: NGINX en la mayoría de los proyectos, con Apache solo cuando el cliente tiene una restricción concreta. NGINX se lleva muy bien con FastCGI cache, que es como una versión ligera de lo que mod_pagespeed intentaba.
- PHP: 8.2 o 8.3 con OPcache afinado. Solo el salto de PHP 7.4 a 8.2 supone entre un 15% y un 25% más de peticiones por segundo según pruebas públicas de Kinsta y los benchmarks que repetimos internamente.
- Caché de página: FastCGI cache a nivel de NGINX o plugin tipo WP Rocket, W3 Total Cache o Cache Enabler para entornos compartidos.
- Caché de objetos: Redis Object Cache cuando hay panel para configurarlo, memcached en hostings más conservadores.
- Compresión: Brotli activado en CDN o en el propio servidor, con gzip como fallback.
- Imágenes: WebP o AVIF servidos por el CDN según navegador, lazy loading nativo y dimensiones declaradas para evitar saltos de layout (CLS).
- JavaScript: cargas diferidas, eliminación de scripts que el theme no usa y revisión periódica del bundle.
Cuando entra un proyecto nuevo, lo primero que medimos son los Core Web Vitals: LCP, INP (que sustituyó a FID en marzo de 2024) y CLS. Esas tres métricas son el lenguaje común con Google y con el cliente. A partir de ahí decidimos si el cuello de botella está en el servidor, en la base de datos, en el theme o en scripts de terceros.
Lo que sigue siendo verdad desde 2010
Releyendo el post original, hay tres ideas que aguantan tal cual:
- El servidor importa, y mucho. Por bien escrito que esté el theme, si la pila de servidor es lenta, no hay plugin que la salve. En 2010 era Apache vs Apache+mod_pagespeed; en 2026 es hosting compartido vs VPS bien configurado vs cloud gestionado.
- Caché de objetos cambia las reglas del juego. Memcached entonces, Redis ahora. La idea es la misma: no le pidas a MySQL lo que ya tienes en memoria.
- Optimizar sin tocar código tiene un techo. Mod_pagespeed lo intentó y por eso fue tan tentador. Hoy lo hemos asumido: la velocidad real se gana revisando theme, plugins y consultas, no solo activando filtros.
Por eso uno de los servicios que más nos piden es la auditoría de rendimiento sobre instalaciones existentes. No es solo medir: es decidir qué se conserva, qué se reescribe y qué se tira. Lo contábamos con datos en este otro artículo sobre cómo evitar el bloat en WordPress, que es la otra cara de la moneda: por mucha caché que pongas, si el backend está saturado de plugins zombi y opciones autoload, el sitio no va a volar.
Y la pregunta de 2010 sobre el hosting compartido
El post original cerraba con una pregunta que envejeció bien: cuándo iban los proveedores a ofrecer mod_pagespeed y memcached en hosting compartido. La respuesta corta es que mod_pagespeed nunca llegó a ser la norma en compartido (la sobrecarga de CPU lo hizo poco viable para hosters con miles de cuentas), pero sí ocurrió algo equivalente: los hostings WordPress especializados como Raiola, SiteGround, Webempresa o Kinsta llevan caché de página, object cache y CDN integrados como característica básica, no como extra.
Quien quiera profundizar en cómo nos hemos planteado nosotros la infraestructura, lo contamos en su momento al desplegar la nueva infraestructura de Colorvivo: por qué movimos servicios, qué medimos antes y después, y qué decisiones nos ahorraron problemas posteriores.
Preguntas frecuentes
¿Sigue siendo posible instalar mod_pagespeed en 2026?
Técnicamente puedes compilarlo a partir del código liberado por Google, pero no recibirá actualizaciones de seguridad y la mayoría de distribuciones lo han retirado de sus repositorios desde 2021. En un proyecto en producción no compensa: cualquier configuración moderna de NGINX con FastCGI cache cubre los mismos casos con menos riesgo.
¿Memcached o Redis para el object cache de WordPress?
Para un sitio WordPress estándar, los dos funcionan. Redis ofrece más flexibilidad si vas a usar el caché para colas, sesiones o estructuras de datos que no son simples pares clave-valor. Memcached sigue teniendo sentido cuando el hosting solo lo soporta a él o cuando se busca la configuración más sencilla posible.
¿Cuánto mejora la velocidad un object cache en WordPress?
Depende del tipo de sitio. En blogs sencillos con caché de página activa, la diferencia es pequeña porque el HTML ya viene servido del caché. En tiendas WooCommerce, intranets o sitios con mucho contenido dinámico (filtros, búsqueda interna, áreas de cliente), un object cache bien configurado puede reducir el tiempo medio de respuesta entre un 30% y un 60% según los casos que medimos en proyectos del último año.
¿Y los Core Web Vitals: dónde encajan en este puzle?
Los Core Web Vitals son la métrica con la que Google evalúa la experiencia. LCP mide cuándo se ve el contenido principal, INP mide la respuesta a la interacción y CLS mide la estabilidad visual. La caché del servidor ayuda al LCP, la calidad del JavaScript ayuda al INP y la maquetación cuidada ayuda al CLS. Optimizar uno solo no basta: hay que mirar los tres juntos, que es lo que hacemos en cualquier auditoría.
¿Tiene sentido cambiar de hosting para ganar velocidad?
En proyectos serios, sí: el salto de un compartido genérico a un hosting WordPress especializado o a un VPS bien configurado suele notarse en TTFB y en LCP desde el primer día. Antes de migrar, conviene medir en qué punto está el cuello de botella. A veces lo que pesa no es el servidor, sino un theme inflado o un plugin que carga 800 KB de CSS en cada página.
