Cómo Mejorar la Velocidad de tu Web (12 Fixes)

Fix 1: Cambia a hosting LiteSpeed o NVMe

El hosting es el techo de todo lo demás. Si el servidor tarda más de 200 ms en responder (TTFB), ningún plugin de caché lo compensa. En 2026 el estándar mínimo para una web de negocio es un servidor con discos NVMe y, preferiblemente, servidor web LiteSpeed en lugar de Apache o Nginx.

LiteSpeed tiene caché nativa a nivel de servidor (LSCache), maneja HTTP/3 de serie y comprime con Brotli sin configuración extra. Un VPS NVMe de entrada (6-10 €/mes) supera a la mayoría de compartidos de gama media en TTFB.

Cómo verificarlo: herramienta Pingdom Tools → columna «Wait» en la cascada. Si supera 300 ms de forma consistente, el problema está en el servidor, no en el código.

En nuestro servicio de mantenimiento web incluimos migración a hosting rápido cuando detectamos que el cuello de botella es el servidor.

Fix 2: Plugin de caché — WP Rocket (49 €) o LiteSpeed Cache (gratis)

La caché convierte páginas dinámicas de WordPress en archivos HTML estáticos que el servidor sirve sin ejecutar PHP ni consultar la base de datos. La diferencia entre tener o no tener caché bien configurada puede ser de 2-4 segundos en el Time to First Byte.

LiteSpeed Cache es la opción gratuita más potente si tu hosting corre LiteSpeed. Incluye optimización de imágenes, minificación de CSS/JS, caché de objetos Redis y preload automático.

WP Rocket (49 €/año, 1 web) es la solución premium más fácil de configurar en cualquier hosting. Su modo «recomendado» activa en un clic caché de páginas, minificación, lazy load, preload y delay de JavaScript. Recuperas la inversión con la primera venta que no se pierde por lentitud.

Configuración mínima que debes activar en cualquiera de los dos: caché de páginas habilitada, caché para usuarios móviles separada, preload del sitemap y combinación de CSS/JS crítico.

Fix 3: Imágenes en WebP automáticas con ShortPixel

Las imágenes representan entre el 50 % y el 80 % del peso de una página media. Pasar de JPEG/PNG a WebP reduce ese peso un 25-35 % sin pérdida de calidad visible. En 2025 todos los navegadores relevantes soportan WebP y AVIF.

ShortPixel es el plugin que mejor equilibra calidad, velocidad de conversión y precio. Su plan gratuito incluye 100 imágenes/mes; el de pago comienza en 4,99 €/mes para 5.000 imágenes. Convierte en lote la biblioteca existente y procesa automáticamente cada imagen nueva que subas.

Pasos: instalar ShortPixel → ajuste «Lossy» para fotos, «Lossless» para logos y PNG con transparencia → activar conversión a WebP → lanzar optimización masiva de biblioteca → verificar que el plugin sirve WebP via etiqueta <picture> con fallback JPEG.

Alternativa sin plugin: Cloudflare Polish (plan Pro, 20 $/mes) convierte a WebP en el CDN sin tocar el servidor.

Fix 4: Lazy load nativo para imágenes e iframes

El lazy load retrasa la carga de imágenes e iframes que están fuera del viewport inicial. El navegador solo descarga lo que el usuario va a ver, reduciendo el peso inicial de la página y mejorando el LCP (Largest Contentful Paint).

Desde HTML5.3 el atributo loading="lazy" es nativo y no requiere JavaScript. WordPress lo aplica automáticamente desde la versión 5.5 a todas las imágenes insertadas con el editor.

Lo que debes revisar: que la imagen hero (LCP) tenga explícitamente loading="eager" o directamente no tenga el atributo lazy, porque cargarla tarde penaliza el LCP. Usa el atributo fetchpriority="high" en esa imagen para decirle al navegador que la priorice.

Para iframes de YouTube, usa la técnica de facade: mostrar una miniatura estática y cargar el iframe solo al hacer clic. El plugin WP YouTube Lyte o la librería lite-youtube-embed lo hacen automáticamente.

Fix 5: Defer de JavaScript y CSS no crítico

El render-blocking ocurre cuando el navegador se detiene a descargar y ejecutar un archivo JS o CSS antes de pintar la página. Cada recurso bloqueante añade cientos de milisegundos al FCP (First Contentful Paint).

La solución es diferir la carga de scripts no críticos con el atributo defer o async, y cargar el CSS no crítico de forma asíncrona.

WP Rocket lo hace desde «Optimización de archivos»: activar «Cargar JS de forma diferida» y excluir manualmente los scripts que necesitan ejecutarse antes del render (jQuery si algún plugin lo requiere, scripts de chat en vivo, etc.).

Para CSS: el enfoque correcto es generar el CSS crítico (above-the-fold) inline en el <head> y cargar el resto de forma asíncrona. WP Rocket tiene esta opción en «Eliminar CSS no utilizado». Prueba primero en staging: el riesgo de romper estilos existe si el tema no está bien estructurado.

Fix 6: Audita y elimina plugins lentos

Cada plugin activo en WordPress añade carga al ciclo de arranque de PHP, aunque no se use en la página que el usuario visita. Una instalación con 35 plugins puede tardar 800 ms solo en arrancar, antes de ejecutar ninguna lógica de negocio.

Herramienta: Query Monitor (gratuito) → pestaña «PHP Errors» y «Hooks» → filtra por tiempo de carga. Identifica qué plugin consume más tiempo en cada petición.

Método de eliminación: desactiva plugins de 5 en 5, mide en PageSpeed Insights cada vez. Los candidatos habituales a eliminar o reemplazar: constructores de página que cargan CSS/JS en todas las páginas aunque no se usen (Elementor carga sus assets en todo el sitio por defecto), plugins de redes sociales con scripts externos, sliders con librerías JS pesadas (Slider Revolution puede añadir 400 KB), y plugins de seguridad con escaneos en tiempo real.

Objetivo: menos de 20 plugins activos en producción.

Fix 7: Fuentes web con subset y preload

Google Fonts cargadas de forma estándar generan dos problemas: una petición DNS extra a googleapis.com y un posible FOUT (Flash of Unstyled Text) que afecta al CLS (Cumulative Layout Shift).

La solución óptima en 2026 es alojar las fuentes en tu propio servidor:

1. Genera el subset de la fuente con solo los caracteres que necesitas en google-webfonts-helper: para español selecciona Latin + Latin Extended.
2. Descarga los archivos WOFF2 (el formato más ligero) y súbelos a tu servidor.
3. Declara la fuente con @font-face y añade font-display: swap para evitar texto invisible.
4. Añade en el <head> un preload: <link rel="preload" as="font" type="font/woff2" href="/fonts/tu-fuente.woff2" crossorigin>

Plugin alternativo: OMGF (Optimize My Google Fonts) automatiza este proceso desde el panel de WordPress.

Resultado esperado: eliminación de 1-2 peticiones externas y mejora del FCP entre 100-300 ms.

Fix 8: CDN Cloudflare gratuito

Un CDN (Content Delivery Network) sirve los assets estáticos de tu web (imágenes, CSS, JS, fuentes) desde el servidor más cercano al usuario. Cloudflare tiene puntos de presencia en más de 300 ciudades; un usuario en Madrid no descarga desde tu servidor en Ámsterdam sino desde el nodo de Madrid.

El plan gratuito de Cloudflare incluye: CDN global, protección DDoS básica, SSL automático, caché de assets estáticos y reglas de caché personalizables. Es suficiente para la mayoría de webs de negocio.

Configuración recomendada: SSL/TLS en modo «Full (strict)», reglas de caché para archivos estáticos con TTL de 30 días, activar «Auto Minify» para HTML/CSS/JS, y activar «Brotli» en la sección Speed.

Un aviso importante: si usas WooCommerce o tienes páginas con sesión de usuario, excluye esas URLs del caché de Cloudflare para evitar que usuarios vean datos de otros.

Fix 9: HTTP/3 y compresión Brotli

HTTP/3 usa el protocolo QUIC sobre UDP en lugar de TCP, lo que elimina el problema de «head-of-line blocking» de HTTP/2 y reduce la latencia en conexiones móviles o con pérdida de paquetes. En redes 4G/5G la mejora es perceptible.

Para activarlo necesitas que tu hosting lo soporte: LiteSpeed lo activa por defecto, Nginx requiere compilación con el módulo ngx_http_v3, Apache necesita el módulo mod_http2 y configuración adicional. Cloudflare activa HTTP/3 en un toggle en «Network».

Brotli comprime texto (HTML, CSS, JS) entre un 15-25 % mejor que gzip. En LiteSpeed se activa desde el panel. En Nginx: directiva brotli on; con el módulo ngx_brotli. En Cloudflare: toggle en «Speed > Optimization».

Verificación: en Chrome DevTools → Network → cabecera de respuesta content-encoding: br confirma Brotli activo. alt-svc: h3 confirma HTTP/3.

Fix 10: Limpieza de base de datos WordPress

Con el tiempo la base de datos de WordPress acumula revisiones de entradas (cada guardado automático crea una), transientes expirados, datos huérfanos de plugins desinstalados, sesiones caducadas y metadatos obsoletos. Una tabla wp_options con 50.000 filas puede añadir 200-400 ms a cada carga de página.

Limpieza recomendada con WP-Optimize (gratuito):

• Eliminar revisiones de entradas (mantener las últimas 3 como máximo)
• Eliminar comentarios spam y papelera
• Limpiar transientes expirados
• Optimizar tablas (equivalente a OPTIMIZE TABLE en MySQL)

Configuración preventiva: en WP Rocket → «Base de datos» → programar limpieza semanal automática. En wp-config.php añade define('WP_POST_REVISIONS', 3); para limitar revisiones futuras.

Importante: haz backup antes de cualquier limpieza de base de datos. Aunque es poco probable, la eliminación de transientes puede afectar a plugins que los usan como caché temporal.

Fix 11: Elimina recursos render-blocking

PageSpeed Insights señala en «Eliminar recursos que bloquean el renderizado» exactamente qué archivos retrasan el FCP. El objetivo es que el navegador pinte algo visible en menos de 1,8 segundos (umbral «bueno» de LCP según Google).

Checklist de recursos render-blocking habituales en WordPress:

• jQuery cargado en el <head> sin defer: muchos temas lo cargan así por compatibilidad antigua. Si tus plugins lo permiten, muévelo al footer o añade defer.
• CSS de plugins inactivos en la página: Contact Form 7 carga su CSS en todas las páginas aunque no haya ningún formulario. Usa el plugin Asset CleanUp para deshabilitar assets por URL.
• Scripts de terceros síncronos: Google Tag Manager, Hotjar, Intercom. Cárgalos con estrategia de retardo (WP Rocket → «Delay JS execution»).
• Web fonts en el head sin preload: resuelto en el Fix 7.

Meta: menos de 3 recursos render-blocking en el análisis de PageSpeed.

Fix 12: Monitoriza PageSpeed de forma continua

Una web rápida hoy puede ser lenta en seis meses si se instala un plugin nuevo, se actualiza el tema o se sube una imagen sin comprimir. La velocidad necesita monitorización continua, no una optimización puntual.

Herramientas gratuitas para monitorizar:

• Google Search Console → «Experiencia de página» → Core Web Vitals. Muestra datos reales de usuarios (campo), no solo lab data. Alerta cuando URLs pasan a «Necesita mejora».
• PageSpeed Insights con la API: automatiza chequeos semanales con un script que llame a la API y notifique si la puntuación baja de 85.
• WebPageTest: análisis más detallado con cascada de waterfall, comparativa antes/después de cambios.
• SpeedVitals (gratuito básico): monitorización programada con alertas por email.

En nuestro mantenimiento web mensual incluimos chequeo de Core Web Vitals con informe y correcciones si la puntuación cae. Es parte del tiempo de carga que debería tener tu web para no perder posicionamiento.