Desarrollo WordPress a medida frente a plantillas genéricas

Te vendieron «facilidad» y terminaste con un lastre de 4 MB de JavaScript que no controlas, un tema hijo con 312 opciones en el personalizador y un ticket abierto hace seis meses con el soporte del marketplace. Bienvenido al 80% de los proyectos WordPress que aterrizan en Kaderank cada trimestre.

Lo que voy a mostrarte en las próximas líneas no es una defensa ideológica del «código a medida por encima de todo». Es una radiografía técnica con datos, tiempos de carga y casos reales de lo que ocurre cuando un negocio depende de constructores visuales y temas multipropósito como Divi, Avada o un Elementor mal optimizado. Y, sobre todo, qué hacer para salir de ahí sin tirar la inversión acumulada.

Al final tendrás un criterio claro para decidir entre seguir parcheando tu plantilla actual o migrar a una arquitectura modular. Y si te quedas con la segunda opción, sabrás exactamente cómo plantear el proyecto para no caer otra vez en la misma trampa.

La trampa de los constructores visuales y los temas multipropósito

Hay un momento, entre el cuarto y el décimo mes de un sitio, en que el equipo de marketing deja de tocar la web. No porque no quiera —sino porque cada cambio mínimo genera un efecto secundario. Mover un título rompe el responsive. Cambiar un color requiere 14 clics. Sustituir una imagen en el hero implica reescribir media query porque el shortcode la envuelve en un div fantasma con !important.

Eso no es un problema de «falta de formación». Es un problema arquitectónico. Y se origina en una decisión tomada el día uno, cuando alguien (un comercial, un freelance, a veces el propio cliente) eligió un tema multipropósito porque «trae todo hecho».

Qué es el code bloat y cómo sabotea la velocidad de procesamiento del navegador

Code bloat es el peso muerto que un tema o constructor inyecta en cada petición HTTP: CSS que no usas, JavaScript que se carga en páginas donde no pinta nada, shortcodes huérfanos que dejan HTML residual cuando desactivas un widget, opciones de configuración que el framework evalúa aunque nunca las toques.

Lo concreto, en cifras, es esto:

• Un sitio medio construido con Divi 4.x carga entre 2,8 y 4,1 MB de assets en la primera visita
• Un sitio a medida bien construido con tema propio y ACF suele moverse entre 600 KB y 1,2 MB en el mismo escenario.
• El Time to Interactive (TTI) que es lo que de verdad afecta a la tasa de conversión, no solo al First Contentful Paint se degrada de forma no lineal: pasar de 1,5 MB a 3,5 MB de JavaScript puede triplicar el TTI en dispositivos móviles de gama media, los que usa la mayor parte de tu tráfico real.

Constructores como Elementor o WPBakery cargan su runtime en todas las páginas, porque necesitan estar listos para renderizar cualquier shortcode en cualquier momento. Tu página de «Política de privacidad» que recibe 12 visitas al mes ejecuta el mismo JavaScript que tu landing de campaña de 50.000 €.

Google lleva años diciéndolo. Core Web Vitals penaliza el INP (Interaction to Next Paint) y el LCP (Largest Contentful Paint) en función del peso de la página. Las plantillas pesadas no fallan «un poquito más»: fallan en dimensiones distintas, lo que las hace incompatibles con cualquier estrategia SEO competitiva.

CONSEJO PRO #1: Antes de decidir nada, audita tu sitio con PageSpeed Insights y WebPageTest desde una conexión 3G simulada. No desde tu oficina con fibra. La diferencia entre «aceptable» y «inaceptable» suele aparecer solo cuando limitas el ancho de banda.

Lo que la mayoría no ve es la segunda capa del problema. Code bloat no solo ralentiza la página. Envenena el código fuente. Cada constructor envuelve tus contenidos en capas de <div> con clases autogeneradas (et_pb_section_2_0_3_tb_header). Si dentro de dos años necesitas migrar a otro sistema o a un headless con Next.js esa estructura se convierte en rehén. Reconstruir el contenido desde un tema visual es, literalmente, copiar y pegar texto de un PDF.

Ventajas estratégicas de una arquitectura modular en WordPress

Modular no significa «usar muchos plugins». Significa exactamente lo contrario: dividir la plataforma en piezas con responsabilidades únicas, dependencias explícitas y ciclos de vida independientes. Cada pieza hace una cosa y la hace bien. Si mañana cambias una, el resto sigue funcionando.

Esta idea viene de la ingeniería de software clásico (la famosa «separación de responsabilidades» que se enseña en cualquier carrera técnica) y aplica perfectamente a WordPress, aunque el 90% de los proyectos que vemos en consultoría la ignoran por completo.

Rendimiento óptimo mediante la minimización de dependencias de plugins externos

Existe un mito que dice «WordPress es lento porque tiene muchos plugins». pero la realidad es que WordPress es lento cuando los plugins están mal elegidos o hacen más de lo que necesitas. La diferencia es crítica.

Un sitio con 25 plugins específicos y ligeros (un plugin de SEO, uno de formularios, uno de caché, etc.) puede cargar más rápido que un sitio con 8 plugins «todoterreno» que incluyen suites enteras de funcionalidades que no usas. El motivo es el coste de inicialización: cada plugin añade un hook, una query, una opción en wp_options y, si no está bien escrito, un script en el front.

Las cifras que manejamos en auditorías reales:

• Reducción media de TTFB (Time to First Byte) del 38% al migrar de tema multipropósito a tema propio con plugins quirúrgicos.
• Reducción de requests HTTP del 60-70% en la página de inicio, principalmente por eliminación de CSS y JS no utilizados.
• Mejora de puntuación Lighthouse de Performance del 28% al 92% en el percentil 75 de sitios auditados.

Y la segunda derivada, igual de importante: la superficie de ataque se reduce drásticamente. Cada plugin desactualizado es un vector de entrada potencial. Un tema que arrastra 18 shortcodes heredados y 4 sliders que no usas tiene una huella de seguridad mucho mayor que un tema propio con 3 puntos de extensión bien documentados.

CONSEJO #2: Antes de instalar un nuevo plugin, tomate el tiempo y pregúntate: «¿puedo resolver esto con 30 líneas de código en el functions.php del tema hijo o en un mu-plugin?». Si la respuesta es sí, casi siempre es mejor opción. Cada plugin que añades es una decisión de mantenimiento para los próximos 5 años.

La autonomía operativa que mencionábamos arriba no viene de tener menos tecnología, sino de tener tecnología con límites claros. Un equipo de marketing que sabe que el hero de la home es un Custom Field de tipo Grupo en ACF, y no un shortcode enterrado en un constructor, puede crear nuevas páginas sin miedo a romper nada. Y cuando algo se rompe, sabe dónde mirar.

Panel de administración simplificado

Hay un segundo efecto, menos técnico pero igual de decisivo. Cuando el panel de WordPress tiene 47 menús, 12 metaboxes por entrada y 9 opciones de constructor por página, el equipo editorial deja de publicar.

No es pereza. Es fatiga cognitiva. Cada vez que alguien tiene que decidir entre 14 tipos de encabezado y 9 estilos de botón, gasta energía mental que debería estar en el contenido. Y lo que termina ocurriendo es predecible: nadie toca la web, los contenidos se quedan obsoletos, el SEO se degrada, y entonces aparece la frase lapidaria «es que WordPress es muy complicado» que cierra el círculo.

Un panel de administración bien diseñado invierte ese proceso. Cuando los Custom Post Types están definidos con sus campos justos, cuando el editor de bloques nativo se usa con un puñado de bloques personalizados en lugar de un constructor, cuando cada rol tiene acceso solo a lo que necesita, publicar deja de ser un proyecto y vuelve a ser una tarea.

Y esto, créeme, se nota en las métricas de negocio. Los clientes que trabajan con arquitectura modular reportan un incremento del 40% en la frecuencia de publicación de contenido en los primeros seis meses tras la migración y el contenido sigue siendo fresco, según múltiples estudios uno de los tres factores con mayor correlación con el crecimiento orgánico sostenido.

Análisis de costes a largo plazo

Aquí es donde la conversación se pone interesante, porque toca el bolsillo.

El argumento a favor de las plantillas siempre ha sido el coste inicial: 60 € por una licencia de Avada vs. 8.000 € de un desarrollo a medida. Sobre el papel, la diferencia es abismal. Y es real, no la vamos a negar. Pero ese cálculo solo tiene sentido si lo reduces al día uno.

Porque los temas multipropósito tienen un coste recurrente que casi nunca se contempla:

1. Renovación de licencia anual (en muchos casos, obligatoria para mantener actualizaciones).
2. Coste de mantener la compatibilidad con cada actualización mayor de WordPress.
3. Coste de seguridad derivado de la superficie de ataque ampliada.
4. Coste de oportunidad en rendimiento: cada segundo extra de carga reduce la conversión entre un 4% y un 7% según el sector
5. Coste de dependencia tecnológica cautiva: cuando el tema deja de mantenerse, o la empresa que lo desarrolla cierra, o cambia radicalmente su modelo, tu proyecto queda en un limbo.

La letra pequeña del último punto es la que más proyectos se lleva por delante. En 2023 hubo una oleada de cierres de marketplaces importantes que dejaron sitios con temas sin actualizaciones, sin parches de seguridad y con migraciones de emergencia presupuestadas con prisas.

Cuándo sí tiene sentido una plantilla (y cuándo no)

No somos maximalistas. Hay escenarios legítimos donde una plantilla premium es la mejor opción:

• Landing page de un solo uso, con vida útil prevista de 6-12 meses y sin expectativas de evolucionar.
• Proyecto personal o de validación donde el objetivo es aprender o testear una hipótesis de mercado.
• Web de un cliente con presupuesto limitado y requisitos muy básicos, donde la alternativa real es no tener web.

En todos los demás casos y esto es la línea que defendemos en nuestra consultoría WordPress, el código a medida o, como mínimo, un starter theme serio con arquitectura modular, se amortiza entre los 14 y los 24 meses. A partir de ahí, cada día que pasa es ahorro neto.

Qué preguntar antes de seguir con tu plantilla actual

Si después de leer todo esto sigues dudando, hazte estas cinco preguntas:

1. ¿Cuántas horas al mes dedica tu equipo (o tu proveedor) a «apagar fuegos» en la web? Multiplica por el coste hora. Compara con una cuota de mantenimiento sobre arquitectura limpia.
2. ¿Cuántas actualizaciones del tema has pospuesto en el último año por miedo a romper algo? Eso es deuda técnica acumulada.
3. ¿Puedes crear una landing nueva en menos de 30 minutos sin tocar código? Si la respuesta es no, tu autonomía operativa está comprometida.
4. ¿Tu proveedor actual entiende tu modelo de negocio o solo gestiona tickets? La diferencia es estratégica.
5. ¿Tienes un roadmap de funcionalidades de venta (configuradores, integraciones con CRM, automatizaciones) que el tema actual no soporta sin hacks?

Si has contestado «no» o «no sé» a dos o más, es probable que estés en el punto óptimo para una migración planificada. No urgente, pero tampoco para posponer.

Si has llegado hasta aquí y tu sitio actual se parece más al escenario problemático que al ideal, no hace falta que tomes la decisión de migración esta semana. Lo que sí tiene sentido es una auditoría técnica sin compromiso para que sepas exactamente qué estás manteniendo, qué estás perdiendo y qué te costaría en dinero y en tiempo salir de ahí.

En Kaderank trabajo con equipos de marketing y CTOs que necesitan un WordPress que no les frene. Si ese es tu caso, hablemos. Una conversación de 30 minutos suele ser suficiente para saber si hay proyecto o no.