Cómo mejorar la velocidad de WordPress sin romper la web

Hay una escena que se repite bastante. El cliente abre PageSpeed Insights o GTmetrix, ve una puntuación baja y piensa que entraremos en WordPress, tocaremos cuatro cosas, instalaremos un plugin y dejaremos la web corriendo como si acabara de salir de boxes.

Y sí, muchas páginas pueden mejorar bastante con una buena revisión. A veces hay imágenes enormes, caché mal configurada, plugins duplicados o códigos que llevan años cargándose sin que nadie recuerde para qué servían.

Pero otras veces el problema está en el alojamiento, en el tema, en el constructor visual, en una tienda compleja o en decisiones tomadas durante la creación de la web. Ahí ya no estamos ante cuatro casillas mal marcadas.

Mejorar la velocidad de WordPress consiste en detectar qué está frenando cada página, priorizar los cambios que realmente aportan y comprobar que la web sigue funcionando después.

No hay soluciones automágicas. Hay diagnóstico, pruebas, decisiones y algo que se menciona bastante menos: mantenimiento posterior.

Lo que debes tener claro antes de optimizar WordPress

La mayoría de las guías empieza recomendando caché, WebP y una CDN. Son herramientas útiles, pero llegan demasiado pronto.

Antes de instalar nada conviene saber qué web tenemos delante, qué necesita cargar, qué funciones no podemos romper y cuánto lastre forma parte de su propia construcción.

No existe un plugin capaz de arreglar cualquier WordPress

Un plugin de optimización puede:

• Crear caché de páginas.
• Minificar determinados archivos.
• Retrasar algunos scripts.
• Aplicar carga diferida a imágenes.
• Limpiar ciertos datos.
• Gestionar precargas.

Lo que no puede hacer por sí solo es:

• Convertir un alojamiento saturado en un servidor potente.
• Reprogramar un tema mal construido.
• Eliminar funciones que la empresa necesita.
• Corregir consultas complejas de un plugin.
• Rehacer una tienda con cientos de problemas acumulados.
• Decidir qué código puede retrasarse sin romper la web.

Puede ayudar mucho. Pero no lleva una varita mágica escondida en el menú de ajustes.

Cada web tiene un suelo y un techo de rendimiento

El suelo de rendimiento es el coste mínimo de todo lo que la página necesita para funcionar:

• Respuesta del servidor.
• HTML.
• CSS.
• JavaScript.
• Imágenes.
• Fuentes.
• Formularios.
• Medición.
• Funciones propias del negocio.

El techo de optimización es la mejor mejora razonable que podemos alcanzar sin cambiar elementos importantes de la web.

Para superar ese techo quizá haya que:

• Cambiar de hosting.
• Sustituir el tema.
• Reducir el constructor visual.
• Reemplazar plugins.
• Eliminar servicios externos.
• Rehacer una plantilla.
• Reconstruir partes de la instalación.

Una landing sencilla no se compara con una tienda

Una página corporativa con texto, imágenes y un formulario puede ser bastante ligera.

Una tienda online puede necesitar:

• Sesiones de usuario.
• Carrito.
• Stock.
• Filtros.
• Variaciones.
• Pasarelas de pago.
• Cálculo de impuestos.
• Envíos.
• Acciones programadas.
• Consultas de productos.

Exigir las mismas cifras a ambas páginas no es una comparación justa. Una bicicleta pesa menos que una furgoneta, pero tampoco entrega cien paquetes.

Una puntuación no vale más que una web que funciona

Podemos mejorar una nota retrasando JavaScript. El problema aparece cuando ese JavaScript controlaba el menú, el formulario, la cesta o el consentimiento de cookies.

Podemos retirar Analytics y ganar algo de velocidad. El problema aparece cuando la empresa necesita medir campañas y conversiones.

La meta no es conseguir una captura verde. La meta es lograr una web suficientemente rápida, estable y útil sin desmontar lo que necesita el negocio.

La optimización no es una vacuna para toda la vida

Este es uno de los puntos que más cuesta explicar: optimizar WordPress no es tocar una vez la web y dejarla protegida de la lentitud para siempre.

Podemos dejar una instalación ordenada, con buena caché, imágenes razonables, plugins revisados y una carga mucho más ligera.

Pero la web sigue viva.

Se añaden páginas, fotografías, productos, campañas, códigos, plugins y funciones. También cambian el tema, WordPress, PHP, WooCommerce y las herramientas externas.

Si después de optimizar:

• subes cinco imágenes de 4 MB;
• instalas doce plugins;
• añades un chat;
• incorporas Google Ads y Meta Pixel;
• incrustas tres vídeos;
• cambias el banner de cookies;
• instalas un sistema de reservas;

la web no conserva la velocidad por respeto al trabajo realizado meses atrás.

Vuelve a cargar todo lo nuevo. Si lo nuevo pesa, consulta demasiado o bloquea el navegador, el rendimiento vuelve a caer.

Cambio posterior	Cómo puede empeorar la web
Subir imágenes sin comprimir	Aumenta el peso transferido y puede retrasar el contenido principal.
Instalar plugins	Pueden añadir CSS, JavaScript, consultas, tareas y llamadas externas.
Cambiar el tema	Puede cargar nuevas librerías, estilos y funciones globales.
Añadir seguimiento	Analytics, Ads, Meta, chats o mapas incorporan conexiones y ejecución.
Actualizar plugins	Una actualización puede cambiar archivos, consultas o compatibilidades.
Aumentar productos o contenido	Crece la base de datos y algunas búsquedas pueden requerir más trabajo.
Modificar la caché	Puede perderse una configuración que estaba reduciendo carga del servidor.
Añadir vídeos, mapas o sliders	Aumentan las solicitudes y el trabajo inicial del navegador.

No hace falta analizar la web todas las mañanas antes del café. Sí conviene volver a medir:

• Después de cambios importantes.
• Al instalar o sustituir plugins.
• Después de un rediseño.
• Al incorporar campañas o etiquetas.
• Cuando cambia el hosting.
• Si aparecen quejas de lentitud.
• De forma periódica aunque aparentemente todo funcione.

En webs corporativas estables puede tener sentido una revisión cada tres o seis meses. En tiendas, medios o páginas que cambian mucho, conviene revisar con mayor frecuencia.

No es una norma universal. Es una forma razonable de detectar pequeñas regresiones antes de que vuelvan a convertirse en un problema grande.

Antes de mejorar la velocidad, averigua dónde está el problema

Una web lenta no siempre tiene una única causa. Es habitual encontrar una mezcla de pequeños problemas que terminan empujándose entre sí.

Antes de tocar nada necesitamos una referencia.

Mide varias páginas

No te limites a la portada. Comprueba:

• Home.
• Página de servicio.
• Artículo del blog.
• Página de contacto.
• Producto.
• Categoría.
• Carrito y checkout, cuando proceda.

Cada plantilla puede cargar recursos distintos.

Prueba móvil y escritorio

Una conexión rápida y un ordenador potente pueden ocultar problemas que se notan mucho más en un móvil normal.

El rendimiento real cambia según el dispositivo, la conexión, el navegador y la ubicación del usuario.

Haz varias mediciones comparables

No tomes decisiones con una sola prueba.

Utiliza las mismas condiciones y repite el análisis. El estado de la caché, la carga del servidor o una herramienta externa pueden cambiar el resultado.

Conserva la prueba inicial

Sin una referencia anterior no sabrás si el cambio ha servido.

Puedes analizar la web con GTmetrix y guardar los datos principales antes de empezar.

Por qué WordPress puede ir lento

WordPress no tiene por qué ser lento. Tampoco es rápido por el simple hecho de estar instalado correctamente.

Su rendimiento depende de todo el ecosistema que se construye alrededor.

Capa	Problemas habituales
Hosting	Pocos recursos, servidor saturado, PHP, base de datos o caché insuficiente.
Tema y constructor	CSS y JavaScript global, módulos, animaciones y librerías que no se utilizan.
Plugins	Consultas, scripts, tareas, duplicidades y llamadas externas.
Contenido	Imágenes pesadas, vídeos, fuentes y páginas excesivamente complejas.
Base de datos	Opciones autoload, transients, revisiones, tablas antiguas y consultas lentas.
Servicios externos	Analytics, Ads, Meta, reCAPTCHA, mapas, vídeos, chat y cookies.
WooCommerce	Sesiones, filtros, tareas programadas, stock, pedidos y extensiones.

El hosting es el primer tiempo de carga

Antes de descargar imágenes o ejecutar JavaScript, el navegador necesita recibir una respuesta del servidor.

Si esa respuesta tarda, todo lo demás empieza tarde.

Un tiempo inicial alto puede estar relacionado con:

• Servidor compartido saturado.
• Pocos recursos de CPU o memoria.
• PHP lento o desactualizado.
• Base de datos sobrecargada.
• Procesos internos.
• Falta de caché de página.
• Ausencia de caché de objetos.
• Distancia entre servidor y usuarios.

Qué puede mejorar la caché

WordPress genera páginas utilizando PHP y la base de datos. La caché puede guardar una versión preparada y entregarla sin repetir todo ese trabajo en cada visita.

En páginas relativamente estáticas puede producir una mejora muy visible.

Qué no puede arreglar la caché

No corrige:

• Imágenes enormes.
• JavaScript pesado en el navegador.
• Mapas y vídeos externos.
• Un tema excesivo.
• Funciones que realizan llamadas después de cargar la página.
• Un servidor que no tiene recursos suficientes.

Puede reducir trabajo. No convierte un servidor pequeño en una máquina mucho más potente.

Cuándo valorar un cambio de alojamiento

Puede tener sentido cuando:

• La respuesta sigue siendo lenta tras revisar WordPress.
• Los recursos asignados se quedan cortos.
• El proveedor limita procesos necesarios.
• La base de datos responde mal.
• La tienda crece y el plan ya no encaja.
• El soporte no ayuda a investigar.

Cambiar de hosting sin revisar la web tampoco arregla todo. Trasladar veinte plugins pesados a un servidor mejor puede disimular el problema, no eliminarlo.

El tema y el constructor pueden marcar el techo

Un tema no se ocupa únicamente de los colores y el aspecto. También decide buena parte del código que carga la página.

Puede incorporar:

• Hojas de estilo generales.
• Librerías JavaScript.
• Iconos.
• Animaciones.
• Sliders.
• Funciones para módulos que no utilizas.
• Compatibilidades con plugins.
• Recursos del constructor visual.

Divi, Elementor y otros constructores no son automáticamente malos

Un constructor puede facilitar mucho la edición, reducir costes de desarrollo y hacer posible que el cliente gestione contenidos.

También añade una capa de código y recursos.

El problema no es únicamente la herramienta. Importa cómo se ha usado:

• Número de módulos.
• Animaciones.
• Filas y contenedores anidados.
• Plugins adicionales para el constructor.
• Plantillas globales.
• Funciones duplicadas.

Una página sencilla bien construida con un maquetador puede funcionar correctamente. Una portada con quince efectos, tres carruseles y seis extensiones puede no hacerlo.

Cuándo seguir optimizando deja de compensar

Si cada mejora necesita exclusiones, parches y pruebas interminables, quizá el problema no sea la configuración.

Puede resultar más sensato:

• Rehacer la plantilla principal.
• Simplificar el diseño.
• Sustituir módulos.
• Eliminar extensiones del constructor.
• Migrar a una base más ligera.

Los plugins: importa más lo que hacen que la cantidad

Se repite mucho que hay que utilizar pocos plugins. Es una orientación sencilla, pero incompleta.

Diez plugins pequeños y bien programados pueden dar menos problemas que uno solo que:

• realiza consultas pesadas;
• carga recursos en todas las páginas;
• ejecuta tareas cada pocos minutos;
• llama a servicios externos;
• guarda demasiados datos;
• genera errores;
• duplica funciones del tema.

Qué conviene revisar

• Si el plugin sigue utilizándose.
• En qué páginas carga sus archivos.
• Qué consultas genera.
• Qué tareas programadas añade.
• Si contacta con servidores externos.
• Si existe otro plugin haciendo lo mismo.
• Si continúa recibiendo mantenimiento.

Desactivar no siempre limpia lo que dejó

Algunos plugins mantienen tablas, opciones, tareas o datos después de desinstalarlos.

No significa que haya que borrar manualmente todo lo que encontremos en la base de datos. Primero hay que identificarlo y confirmar que no lo utiliza otra función.

La limpieza a ciegas es una forma bastante rápida de pasar de una web lenta a una web que ya no abre.

Configurar la caché sin convertirla en una ruleta

No existe una única caché.

Caché de página

Guarda una versión preparada del HTML para evitar generar la página en cada visita.

Caché del navegador

Indica cuánto tiempo pueden conservarse imágenes, fuentes, CSS y otros archivos en el dispositivo del usuario.

Caché de objetos

Guarda resultados de consultas y operaciones para evitar repetir determinados cálculos.

Caché del servidor

Puede funcionar en una capa anterior a WordPress y reducir el trabajo que llega a PHP.

CDN

Distribuye archivos desde distintos puntos geográficos y puede reducir la distancia hasta el visitante.

Una CDN no arregla una consulta lenta de la base de datos. Tampoco vuelve pequeña una imagen de cinco megabytes. Entrega el archivo desde otro lugar; el archivo sigue pesando lo mismo.

Optimizar imágenes sin estropear su calidad

Las imágenes suelen ofrecer mejoras claras porque combinan tres problemas habituales:

• Dimensiones excesivas.
• Peso elevado.
• Formato poco apropiado.

Usa dimensiones cercanas al tamaño real

No tiene sentido cargar una imagen de 4000 píxeles para mostrarla a 600.

WordPress genera varios tamaños, pero el tema o constructor debe servir uno adecuado.

Comprime antes o durante la subida

Una fotografía puede reducir mucho su peso sin que el usuario aprecie una pérdida seria de calidad.

La compresión debe ajustarse al tipo de imagen. Un producto, una ilustración y una fotografía de fondo no necesitan exactamente el mismo tratamiento.

Utiliza WebP o AVIF cuando encaje

Estos formatos pueden reducir el peso frente a JPEG o PNG, aunque conviene comprobar:

• Calidad visual.
• Compatibilidad.
• Generación de tamaños.
• Entrega correcta al navegador.

No apliques lazy load a todo

La carga diferida es útil para imágenes que están por debajo de la zona visible.

Aplicarla a la imagen principal puede retrasar el elemento que el visitante necesita ver primero.

La imagen del hero o el elemento LCP suele necesitar un tratamiento distinto al resto de la galería.

Controla lo que se sube después

Esta parte es menos técnica y mucho más importante de lo que parece.

Podemos optimizar toda la biblioteca actual. Si el equipo continúa subiendo imágenes directamente desde una cámara o un móvil, el problema regresará.

Hace falta una regla interna:

• Dimensiones máximas.
• Peso aproximado.
• Formato recomendado.
• Responsable de revisar.

CSS y JavaScript: donde empiezan los problemas delicados

CSS controla la presentación. JavaScript controla buena parte de la interacción.

Ambos pueden ralentizar la carga, pero no conviene tratarlos como basura que sobra.

Minificar no significa eliminar

Minificar quita espacios, comentarios y caracteres innecesarios.

Reduce algo el peso, pero el navegador sigue descargando y procesando el código.

Un archivo enorme minificado sigue siendo un archivo grande, solo que mejor doblado dentro de la maleta.

Combinar archivos no siempre ayuda

Agrupar CSS o JavaScript podía resultar útil cuando cada petición tenía un coste mayor.

Con protocolos modernos puede no aportar tanto y, en determinados casos, dificulta que el navegador guarde o actualice únicamente lo necesario.

No se aplica por sistema. Se prueba.

Retrasar JavaScript puede romper funciones

Algunos scripts pueden esperar hasta que exista interacción del usuario.

Otros controlan:

• Menús.
• Formularios.
• Carritos.
• Filtros.
• Consentimiento de cookies.
• Galerías.
• Reservas.

Retrasar todo puede mejorar una prueba de laboratorio y empeorar el funcionamiento.

Eliminar JavaScript no utilizado requiere entender el origen

Una herramienta puede indicar que parte del archivo no se ha utilizado durante la prueba.

Eso no significa que podamos abrirlo y borrar líneas. Puede contener funciones que aparecen:

• Después de pulsar.
• Al abrir un menú.
• En otra página.
• Durante el pago.
• Cuando aparece un error.

Las soluciones reales pueden ser:

• Evitar que el archivo cargue donde no hace falta.
• Dividir el código.
• Retrasar una parte.
• Sustituir el plugin.
• Reprogramar el módulo.

A partir de ahí ya estamos entrando en terreno de desarrollo.

CSS crítico y CSS no utilizado

El CSS crítico intenta entregar primero los estilos necesarios para la parte visible.

Puede ayudar, pero una configuración incorrecta puede producir:

• Contenido sin estilos durante unos instantes.
• Saltos visuales.
• Elementos ocultos.
• Ventanas emergentes mal presentadas.

No es una casilla inocente. Es una técnica que necesita pruebas.

Fuentes: pocos archivos pueden pesar mucho

Una tipografía puede tener:

• Varias familias.
• Distintos pesos.
• Cursivas.
• Versiones para diferentes alfabetos.

Una web puede terminar descargando ocho o diez archivos para mostrar dos titulares y varios párrafos.

Qué revisar

• Cuántas familias se utilizan.
• Qué pesos aparecen realmente.
• Si se cargan desde un proveedor externo.
• Si conviene alojarlas localmente.
• Qué fuente aparece en el primer contenido visible.
• Si una fuente del sistema sería suficiente.

Precargar una fuente útil puede ayudar. Precargar todas obliga al navegador a tratar como prioritarios archivos que quizá no lo sean.

Los scripts externos también cuentan

Una parte de la lentitud puede venir de servicios que no están alojados en tu WordPress.

Por ejemplo:

• Google Analytics.
• Google Tag Manager.
• Google Ads.
• Meta Pixel.
• reCAPTCHA.
• Google Maps.
• YouTube.
• Chats.
• Banners de cookies.
• Hotjar o Microsoft Clarity.

Cada uno puede añadir:

• Nuevas conexiones.
• JavaScript.
• Fuentes.
• Peticiones de medición.
• Trabajo del navegador.

No siempre podemos controlar cómo responde el servidor externo. Sí podemos decidir:

• Si la herramienta sigue siendo necesaria.
• En qué páginas debe cargar.
• Cuándo debe ejecutarse.
• Si está duplicada.
• Si existe una alternativa más ligera.

La base de datos y los procesos que no ves

Una página puede parecer sencilla por fuera y estar realizando bastante trabajo por dentro.

Opciones cargadas automáticamente

WordPress guarda configuraciones en la tabla de opciones. Algunas se cargan automáticamente en muchas solicitudes.

Si plugins y temas acumulan demasiados datos en este grupo, cada página puede arrastrar información que no necesita.

No se deben borrar opciones solo porque ocupen espacio. Primero hay que identificar:

• Quién las creó.
• Si siguen utilizándose.
• Si deben cargarse siempre.
• Qué ocurrirá al modificarlas.

WP-Cron y tareas programadas

WordPress utiliza WP-Cron para ejecutar tareas como:

• Comprobar actualizaciones.
• Publicar entradas programadas.
• Enviar correos.
• Limpiar datos.
• Ejecutar procesos de plugins.

WP-Cron suele activarse con las visitas. En webs con poco tráfico las tareas pueden retrasarse. En webs con mucho tráfico, una configuración incorrecta puede generar trabajo repetido.

Transients

Los transients guardan datos temporales para evitar repetir determinadas operaciones.

Son útiles. También pueden acumularse o configurarse mal.

No conviene vaciarlos continuamente sin entender para qué se utilizan, porque obligaríamos a la web a volver a generar datos que precisamente se habían guardado para ahorrar trabajo.

Revisiones y residuos

Las revisiones de contenido, tablas de plugins eliminados y datos antiguos pueden aumentar el tamaño de la base de datos.

Una base grande no es automáticamente lenta. Lo importante es cómo se consulta, qué índices tiene y qué información se carga en cada petición.

WooCommerce necesita una revisión propia

WooCommerce añade procesos que una web corporativa no necesita.

Entre ellos:

• Sesiones.
• Carrito.
• Pedidos.
• Stock.
• Impuestos.
• Envíos.
• Cupones.
• Variaciones.
• Filtros.
• Acciones programadas.

Acciones programadas

WooCommerce y sus extensiones utilizan colas para ejecutar trabajos en segundo plano.

Conviene revisar si existen:

• Miles de acciones pendientes.
• Tareas fallidas.
• Procesos que se repiten.
• Plugins que llenan la cola.
• Problemas con WP-Cron.

Filtros y búsquedas

Un filtro de productos puede realizar consultas complejas. Si el catálogo crece y la estructura no está preparada, el rendimiento puede empeorar.

Carrito y checkout

Estas páginas no deben tratarse como contenido completamente estático. Necesitan sesiones y datos actualizados.

Una caché aplicada sin criterio puede mostrar carritos incorrectos, sesiones mezcladas o información desactualizada.

Extensiones

Cada extensión puede añadir scripts, consultas y tareas. Una tienda con veinte complementos no debe optimizarse únicamente activando más caché.

Un plan razonable para mejorar la velocidad de WordPress

1. Haz una copia completa

Antes de tocar caché, código o base de datos necesitas una copia que incluya archivos y base de datos.

2. Guarda una prueba inicial

Anota:

• URL analizada.
• Dispositivo.
• Ubicación.
• Métricas principales.
• Peso.
• Número de solicitudes.

3. Localiza el problema principal

No empieces por el aviso más fácil de corregir si el servidor tarda dos segundos en responder.

Busca primero el cuello de botella que más condiciona el resto.

4. Prioriza por mejora, coste y riesgo

Tipo de mejora	Ejemplo	Prioridad habitual
Gran mejora y poco riesgo	Comprimir una imagen enorme.	Alta.
Gran mejora y riesgo medio	Configurar caché o retrasar un script probado.	Alta, con copia y comprobaciones.
Mejora pequeña y mucho riesgo	Modificar JavaScript crítico para ganar unos puntos.	Baja.
Problema estructural	Tema pesado o servidor insuficiente.	Requiere decisión y presupuesto.

5. Cambia una cosa cada vez

Después de cada modificación vuelve a probar.

6. Comprueba las funciones

• Menú.
• Formularios.
• Buscador.
• Cookies.
• Vídeos.
• Carrito.
• Pago.
• Analítica.
• Versión móvil.

7. Documenta lo que has hecho

Apunta:

• Plugin utilizado.
• Opciones activadas.
• Exclusiones.
• Scripts retrasados.
• Resultados.
• Problemas detectados.

Dentro de seis meses agradecerás no depender de la memoria.

8. Vuelve a comprobar después

La web cambia. El seguimiento forma parte del trabajo.

Qué puedes intentar y cuándo conviene detenerte

Nivel	Tareas habituales	Riesgo
Usuario cuidadoso	Comprimir imágenes, eliminar plugins sin uso, reducir fuentes y revisar servicios innecesarios.	Bajo con copia y comprobación.
Conocimientos de WordPress	Caché, CDN, lazy load, precargas, limpieza controlada y retraso de scripts.	Medio.
Desarrollo o servidor	Consultas, autoload, PHP, código del tema, JavaScript, CSS crítico y tareas de WooCommerce.	Alto.

Detente cuando:

• No sabes qué función controla un archivo.
• Los cambios rompen formularios.
• WooCommerce deja de actualizar el carrito.
• La caché muestra información incorrecta.
• El servidor sigue respondiendo lentamente.
• Cada mejora necesita nuevas excepciones.
• La base de datos requiere consultas manuales.

Cuándo dejar de optimizar y empezar a reconstruir

No todas las webs necesitan rehacerse. Tampoco todas merecen seguir recibiendo parches.

Conviene valorar una reconstrucción parcial o completa cuando:

• El tema está abandonado o genera demasiado código.
• El constructor se ha utilizado de forma desordenada.
• Hay funcionalidades duplicadas.
• Los plugins importantes son incompatibles.
• La web depende de una cadena de parches.
• Cada actualización rompe algo.
• El coste de optimizar supera al de rehacer.
• La estructura ya no responde a las necesidades del negocio.

Una optimización puede alargar la vida de una buena base. No convierte cualquier instalación antigua en una plataforma preparada para crecer durante otros diez años.

Cómo trabajamos la optimización de WordPress en ideaWeb

En ideaWeb no prometemos una puntuación concreta antes de revisar la web.

Primero analizamos:

• Alojamiento y respuesta inicial.
• WordPress, tema y constructor.
• Plugins.
• Caché.
• Imágenes y fuentes.
• CSS y JavaScript.
• Scripts externos.
• Base de datos.
• WooCommerce, cuando existe.

Después ordenamos las mejoras por:

• Beneficio esperable.
• Tiempo necesario.
• Riesgo de romper funciones.
• Importancia para el negocio.

La optimización se realiza mediante nuestro servicio de mantenimiento y optimización WordPress.

También podemos volver a revisar la web después de cambios, actualizaciones o incorporación de nuevas herramientas. Porque dejarla bien una vez está muy bien; evitar que vuelva a cargarse de lastre está bastante mejor.

Lo importante para mantener WordPress rápido

Mejorar la velocidad de WordPress no consiste en instalar un plugin y esperar.

Consiste en entender qué está cargando la web, qué parte puede aligerarse, qué funciones necesita conservar y qué límites marca la base técnica.

En algunas páginas bastará con ordenar caché, imágenes y plugins. En otras tocará revisar el servidor, modificar código, sustituir herramientas o rehacer partes.

Y cuando el trabajo termine, todavía queda una última responsabilidad: no volver a llenar la web de peso sin comprobarlo.

Una optimización bien hecha mejora la base. Las revisiones posteriores impiden que el problema regrese mientras nadie mira.

Preguntas frecuentes sobre la velocidad de WordPress

¿Por qué WordPress carga lento?

Puede deberse al hosting, al tema, a los plugins, a imágenes pesadas, a una caché incorrecta, a la base de datos o a scripts externos. Normalmente hay que medir antes de decidir.

¿Se puede acelerar WordPress instalando un plugin?

Un plugin de caché u optimización puede ayudar, pero no corrige cualquier problema. No arregla por sí solo un servidor lento, un tema pesado o una tienda mal planteada.

¿Cuántos plugins son demasiados?

No existe un número universal. Importa qué hace cada plugin, qué recursos carga, qué consultas realiza y si duplica funciones.

¿La caché puede romper WordPress?

Una configuración incorrecta puede causar problemas de estilos, JavaScript, sesiones, formularios o carritos. Conviene activar opciones progresivamente y probar la web.

¿Qué imágenes debo optimizar?

Especialmente las que tienen dimensiones excesivas, mucho peso o aparecen en la parte inicial de la página. También conviene establecer reglas para las imágenes que se suban después.

¿Debo retrasar todo el JavaScript?

No. Algunos archivos pueden esperar, pero otros controlan menús, formularios, carritos, reservas o consentimiento. Hay que comprobar cada caso.

¿Un hosting mejor hará que WordPress cargue más rápido?

Puede mejorar la respuesta y aportar más recursos, pero no elimina imágenes pesadas, código innecesario ni servicios externos.

¿WooCommerce siempre es más lento?

Una tienda realiza más tareas que una web corporativa: sesiones, carrito, productos, pedidos y acciones programadas. Necesita una configuración y unos recursos acordes.

¿La optimización dura para siempre?

No. Nuevas imágenes, plugins, campañas, actualizaciones y cambios de contenido pueden volver a empeorar el rendimiento. Conviene revisar después de cambios y periódicamente.

¿Cada cuánto tiempo debería revisar la velocidad?

Depende del ritmo de cambios. En una web estable puede bastar cada tres o seis meses. Una tienda o una web muy activa puede necesitar comprobaciones más frecuentes.

¿Es necesario conseguir 100 en PageSpeed?

No. El objetivo debe ser ofrecer una experiencia rápida y estable sin eliminar funciones necesarias ni dedicar muchas horas a mejoras mínimas.

¿Cuánto cuesta optimizar WordPress?

Depende del problema y del estado de la instalación. En ideaWeb una revisión inicial de dos horas cuesta 98 € + IVA. Después explicamos si hace falta más trabajo.