Por qué no usamos temas comerciales en WordPress (y qué hacemos en su lugar)

Cuando un proyecto WordPress tiene requisitos de rendimiento, lo primero que descartamos es el tema multipropósito comercial con un maquetador visual pesado. En este artículo te contamos por qué, qué usamos en su lugar (tema propio ligero, tema de bloques, starter themes y campos con ACF) y cuándo tiene sentido dar el salto a una arquitectura headless y cuándo no. Y repasamos errores típicos: elegir tema por la demo, medir solo en laboratorio, fiarlo todo a la caché o irse a headless por el motivo equivocado.

No es un ataque a ningún producto: hay temas comerciales bien hechos. Es nuestro criterio, con sus pros y sus contras.

El problema no es pagar por un tema, es el modelo multipropósito

Un tema multipropósito está diseñado para venderse a miles de proyectos distintos: tiendas, restaurantes, portfolios, blogs. Para que la demo de cada nicho funcione, el tema incluye de serie todo lo que cualquiera de esos proyectos podría necesitar. Tu web usa una fracción, pero el coste de lo demás suele seguir ahí:

• CSS y JavaScript que no usas. Hojas de estilo globales con reglas para decenas de componentes, sliders, animaciones e iconografías cargados en todas las páginas. La pestaña Coverage de DevTools lo muestra enseguida.
• DOM profundo. Los maquetadores envuelven cada elemento en varias capas de contenedores. Un DOM grande encarece el cálculo de estilos y el layout, y eso pesa en la interactividad. Lo explicamos en detalle en cómo reducir el tamaño excesivo del DOM.
• JavaScript en el hilo principal. Desde marzo de 2024, INP (Interaction to Next Paint) sustituye a FID como métrica de interactividad de Core Web Vitals, y mide todas las interacciones, no solo la primera. Los scripts de efectos, menús y constructores que se ejecutan en cada página son los que más suelen penalizarlo.
• Dependencia del proveedor. Las actualizaciones de seguridad y de compatibilidad con nuevas versiones de WordPress y PHP dependen de un tercero. Y si trae plugins empaquetados, también los suyos.
• Contenido atrapado. Si las páginas se maquetan con shortcodes o con el formato propio de un maquetador, el contenido queda ligado a él. Cambiar de tema significa rehacer páginas.

Error típico: elegir por la demo y arreglarlo con un plugin de caché

La demo de un tema se ve rápida porque suele estar en un servidor optimizado y con contenido mínimo. Con contenido real, plugins y analítica, la cosa cambia. Y una caché de página reduce el tiempo de respuesta del servidor (TTFB), pero no reduce el CSS, el JavaScript ni el DOM que el navegador tiene que procesar. La caché es imprescindible, pero no compensa un front sobredimensionado.

Cómo lo comprobamos antes de opinar

Antes de descartar o aceptar un tema medimos con contenido realista. Lo mínimo:

• Datos de campo frente a laboratorio. PageSpeed Insights muestra los datos reales de usuarios de Chrome (CrUX) cuando el sitio tiene tráfico suficiente, además de la prueba de Lighthouse. Las decisiones las tomamos con LCP, INP y CLS de campo; el laboratorio sirve para diagnosticar.
• Coverage y Performance en DevTools para ver cuánto CSS y JS no se usa y qué tareas largas bloquean el hilo principal.
• Query Monitor en el back para ver consultas, hooks y qué assets encola cada plugin y el tema.

Un truco rápido para saber qué está encolando realmente una página: registrar los handles de estilos y scripts al final de la carga, solo en un entorno de desarrollo.

<?php
// mu-plugins/debug-assets.php (solo en desarrollo)
add_action( 'wp_print_footer_scripts', function () {
    if ( wp_get_environment_type() !== 'local' ) {
        return;
    }
    global $wp_styles, $wp_scripts;
    error_log( 'CSS: ' . implode( ', ', $wp_styles->done ) );
    error_log( 'JS: ' . implode( ', ', $wp_scripts->done ) );
}, 999 );

Qué usamos en su lugar

Nuestra opción por defecto es un tema propio, ligero, construido para el proyecto concreto. Según el proyecto, toma una de estas formas.

1. Tema de bloques con theme.json

WordPress introdujo theme.json en la versión 5.8 y los temas de bloques (edición completa del sitio) en la 5.9. Un tema de bloques define tipografías, colores, espaciados y plantillas de forma declarativa, y el editor respeta esas restricciones. Para el equipo de contenido es lo más parecido a un maquetador visual, pero sobre el formato nativo: si se cambia de tema, los bloques siguen siendo bloques.

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "settings": {
    "appearanceTools": true,
    "color": {
      "custom": false,
      "palette": [
        { "slug": "base", "color": "#ffffff", "name": "Base" },
        { "slug": "contrast", "color": "#111111", "name": "Contraste" }
      ]
    },
    "typography": { "customFontSize": false }
  }
}

Desactivar colores y tamaños libres (custom, customFontSize) es intencionado: limita lo que se puede hacer desde el editor para que el diseño no se degrade con el tiempo.

2. Cargar solo el CSS de los bloques que se usan

Por defecto, WordPress carga la hoja wp-block-library con los estilos de todos los bloques del núcleo. Con este filtro, disponible desde la 5.8, los estilos de cada bloque se cargan solo cuando el bloque aparece en la página:

<?php
add_filter( 'should_load_separate_core_block_assets', '__return_true' );

Comprueba el resultado en tu instalación: el comportamiento con bloques de terceros ha variado entre versiones.

3. Starter themes y frameworks ligeros

Cuando el proyecto pide un tema clásico o híbrido, partimos de una base mínima en lugar de un tema completo. Opciones habituales en el ecosistema son Underscores (_s), Sage (plantillas Blade y un flujo de compilación moderno) o Timber (plantillas Twig). Un starter theme no es un tema que se configura, es código que se convierte en tu tema.

Para elegir uno aplicamos los mismos criterios que a cualquier dependencia:

• Mantenimiento activo: fecha del último release, issues abiertas y compatibilidad con la versión actual de WordPress y PHP.
• Lo que carga por defecto en el front: idealmente casi nada; lo demás se añade cuando hace falta.
• Curva de aprendizaje del equipo: un framework que solo entiende una persona es un riesgo de mantenimiento.
• Documentación y licencia adecuadas.

4. Campos y bloques a medida con ACF

Para contenido estructurado (fichas, equipos, casos, módulos repetibles) usamos Advanced Custom Fields. Desde ACF 6.0 (función de la versión Pro) los bloques de ACF se registran con block.json, el mismo mecanismo que usa el núcleo, de modo que cada bloque declara sus propios estilos y scripts:

{
  "name": "acme/destacado",
  "title": "Destacado",
  "category": "design",
  "style": "file:./destacado.css",
  "acf": {
    "mode": "preview",
    "renderTemplate": "destacado.php"
  }
}

<?php
add_action( 'init', function () {
    register_block_type( get_template_directory() . '/blocks/destacado' );
} );

Así el editor trabaja con bloques con campos acotados, sin columnas ni márgenes libres, y el CSS del bloque viaja con el bloque. Lo desarrollamos más en cómo estructurar y cargar selectivamente componentes con ACF.

Lo que cuesta este enfoque

Sería deshonesto venderlo como gratis:

• Más trabajo inicial. Un tema propio requiere diseño y desarrollo; un tema comercial se instala en minutos.
• Menos libertad para el editor. Quien espera arrastrar y soltar cualquier cosa en cualquier sitio verá límites. Para nosotros es una ventaja (el diseño no se rompe), pero hay que explicarlo y acordarlo.
• El mantenimiento es tuyo. No hay proveedor que publique actualizaciones: el tema hay que mantenerlo compatible con WordPress y PHP.

Por eso no decimos que un tema comercial nunca tenga sentido. Para una web pequeña, con presupuesto mínimo y sin requisitos estrictos de rendimiento, puede ser razonable. En ese caso, elige uno ligero y sin maquetador incluido, revisa su historial de actualizaciones y mide con contenido real antes de comprometerte.

Headless: cuándo sí y cuándo no

El siguiente escalón es separar WordPress del front: WordPress solo como gestor de contenido y un framework de JavaScript (Gatsby, Astro, Next.js…) que genera las páginas, a menudo como HTML estático servido desde una CDN. Si te lo planteas por primera vez, empieza por usar WordPress como headless CMS y por qué encaja con Jamstack.

Nuestro caso: este blog

Este blog funciona así: WordPress headless como back y Gatsby como front, desplegado en Netlify. Nos ha dado un front estático, rápido y con muy poca superficie expuesta, pero también nos ha enseñado el riesgo de atarse a un framework. Netlify adquirió Gatsby en febrero de 2023 y desde entonces su desarrollo se ha ralentizado mucho. Por eso estamos evaluando Astro, que con su Content Layer API (estable desde Astro 5) permite cargar contenido de WordPress, por ejemplo vía WPGraphQL, en colecciones tipadas.

Cuándo tiene sentido

• El front tiene requisitos que un tema PHP resuelve mal: una aplicación interactiva, un diseño muy a medida o contenido que se sirve a varios canales (web, app, otros sistemas).
• El contenido cambia con poca frecuencia y se puede publicar como estático, con reconstrucciones al publicar.
• Quieres reducir la superficie de ataque del front: el WordPress puede quedar fuera del acceso público. Lo tratamos en cómo usar un headless CMS para una web muy segura.
• El equipo domina el framework de front y puede mantener dos piezas a largo plazo.

Cuándo no

• Si el motivo es solo el tráfico. Un WordPress bien hecho con caché de página y CDN aguanta mucho tráfico. El tráfico alto no justifica por sí solo duplicar la arquitectura.
• Si el sitio depende de plugins que tocan el front. Formularios, SEO, multidioma, membresías o WooCommerce dejan de funcionar «solos»: hay que exponer sus datos por API y reimplementar su parte visual.
• Si el equipo editorial necesita previsualización fiel e inmediata. Se puede resolver, pero requiere trabajo extra y en un sitio estático cada cambio implica una reconstrucción.
• Si no hay quien mantenga el front. Pasas de mantener un sistema a mantener dos, más el pipeline de despliegue y las dependencias de npm.

Para la mayoría de webs corporativas, un tema propio ligero bien optimizado da un rendimiento excelente sin esta complejidad. Headless es una decisión de arquitectura, no un truco de velocidad.

Resumen

• El problema de los temas multipropósito y los maquetadores pesados es estructural: código, DOM y JavaScript pensados para todos los casos posibles.
• Medimos con datos de campo (LCP, INP, CLS) antes de decidir; la caché de página no compensa un front sobredimensionado.
• Nuestra opción por defecto es un tema propio ligero: de bloques con theme.json o a partir de un starter theme, con bloques y campos de ACF registrados con block.json.
• Tiene costes reales (desarrollo inicial, menos libertad del editor, mantenimiento propio) y hay casos en los que un tema comercial ligero es razonable.
• Headless aporta mucho cuando el front lo pide, pero añade complejidad y dependencia del framework, como nos ha recordado Gatsby.