Optimizar APIs REST para headless significa quitarle peso a cada respuesta y reducir el tiempo de ida y vuelta entre WordPress y el frontend. Si hoy tu API devuelve más datos de los que necesitas, cada petición puede arrastrar decenas o cientos de campos inútiles, multiplicando latencia y carga del servidor.
Optimizar la API REST de WordPress para un frontend headless consiste en reducir datos innecesarios, crear endpoints específicos, cachear respuestas y proteger el acceso a la API. Con ajustes como _fields, _embed, paginación, compresión, ETags y CDN, puedes acelerar la entrega, bajar carga del servidor y mejorar seguridad sin complicar el frontend.
Resumen del proceso
- Mide qué endpoints pesan más y cuánto tardan antes de tocar nada.
- Reduce el tamaño de cada respuesta con
_fields, _embed y una paginación sensata.
- Crea endpoints personalizados para lo que el frontend pide una y otra vez.
- Añade caché con ETags, CDN y reglas claras de invalidación.
- Cierra la superficie de ataque con auth, rate limiting y CORS.
- Revisa métricas y repite el ajuste donde haya más coste.
Flujo práctico: medir, recortar, agrupar, cachear y proteger. Si saltas el orden, acabarás arreglando síntomas y no la causa.
Mide peso y latencia
Abre primero la API y mira qué responde cada ruta.
Empieza con tres pruebas: tiempo de respuesta, tamaño de la respuesta y número de llamadas por página.
Qué debes revisar
Mira el contenido de X-Response-Time, el peso en bytes y si la ruta devuelve campos que el frontend no usa.
Define una base de comparación
Toma una muestra antes de tocar nada. Guarda la URL, el tiempo medio y el tamaño aproximado de la respuesta.
Haz la prueba desde la misma red y con la misma ruta.
Reduce datos con campos y embebidos
Usa _fields para pedir solo los campos que el frontend necesita.
Aplica _fields con criterio
Prueba primero en listados, tarjetas y portadas.
Ejemplo útil: ?_fields=id,date,title,excerpt,link para listados.
Controla _embed y la paginación
_embed trae recursos relacionados dentro de la misma respuesta, como autores o imágenes.
Reducir el peso de la respuesta no consiste solo en pedir menos campos; también conviene pensar en cómo consume el frontend cada tipo de dato. En una home headless, por ejemplo, una ruta que devuelve 20 posts completos puede ser innecesaria si solo se usan id, title, slug, imagen destacada y fecha. Con _fields puedes recortar muchísimo el JSON, y con una paginación bien ajustada evitas que una pantalla de listado arrastre demasiados elementos a la vez.
Además, si una sección necesita autor o miniatura, _embed puede ser útil, pero solo cuando el coste de traer esos recursos compensa frente a hacer peticiones separadas. En proyectos con WordPress headless, esta disciplina suele bajar la latencia percibida y mejora el rendimiento web sin tocar el diseño del frontend.
Crea endpoints más ligeros
Crea endpoints personalizados cuando el frontend repita la misma mezcla de datos una y otra vez.
Cuándo merece la pena
Haz un endpoint propio si la misma combinación de datos se repite en muchas pantallas.
Devuelve solo lo que pintas
Diseña la respuesta como si fueras a pasarla a una tarjeta visual.
Un endpoint bien hecho no debe parecer una copia completa de WordPress, sino una caja pequeña con lo justo para una pantalla.
Pon caché que se pueda vaciar
Añade caché de respuesta, pero con una regla clara para vaciarla cuando cambie el contenido.
Genera ETags para endpoints que cambian poco.
Aplica stale-while-revalidate
stale-while-revalidate significa servir una copia un poco vieja mientras se prepara la nueva en segundo plano.
Vacía por evento, no por intuición
La mejor invalidación suele ser por evento: publicar, actualizar, borrar o cambiar un producto.
La caché de respuesta funciona de verdad cuando no se limita a almacenar y servir, sino que también se invalida con precisión. En una API REST de WordPress, ETags ayudan a devolver 304 cuando el contenido no ha cambiado, mientras que una CDN reduce la distancia física entre el usuario y la API, especialmente en sitios con tráfico internacional. Si además aplicas stale-while-revalidate, puedes servir una versión reciente aunque no sea la última durante unos segundos, y refrescarla en segundo plano sin bloquear la experiencia.
Este enfoque es especialmente útil en páginas de noticias, catálogos o landing pages que reciben muchas visitas y pocas ediciones por minuto, porque mejora la velocidad sin disparar el coste de servidor.
Cierra acceso y abuso
Protege la API como protegerías una puerta de almacén.
JWT frente a cookies
Usa JWT si el frontend vive fuera de WordPress y necesitas llamadas seguras desde otra app.
Rate limiting y allowlist
Limita cuántas peticiones puede hacer una IP o un origen por minuto.
CORS y datos sensibles
Configura CORS solo para los orígenes que usas de verdad.
Revisa métricas y coste
Mira siempre tiempo de respuesta, tamaño medio, número de llamadas por página y porcentaje de respuestas cacheadas.
Qué mirar primero
Empieza por las rutas más visitadas.
Costes ocultos en WooCommerce
En ecommerce, cada dato extra tiene un precio.
Para saber si la optimización funciona, hace falta una auditoría mínima y repetible. Una lista útil incluye latencia media y p95, tamaño promedio de respuesta, número de peticiones por pantalla, porcentaje de acierto de caché y tiempo de regeneración tras invalidar. Por ejemplo, si una ruta baja de 180 KB a 35 KB pero el tiempo p95 sigue alto, quizá el problema esté en consultas internas, en la serialización o en demasiadas llamadas encadenadas desde el frontend.
También conviene revisar rutas públicas, endpoints personalizados y consumo desde móvil, porque el impacto real cambia según la red y el dispositivo. Con estas métricas puedes detectar qué endpoint merece optimización primero y evitar cambios que solo mejoran la sensación, pero no la performance real.
Errores que arruinan el resultado
El error más frecuente en este punto es tocar la caché antes de reducir la respuesta.
Lo que debes evitar
No consumas rutas genéricas cuando el frontend necesita una mezcla fija de datos.
Cuándo no usar este método
Este enfoque no es prioritario si WordPress no funciona como frontend headless.
Si tu cuello de botella está en el hosting, en la consulta SQL o en el tema, optimizar la API solo te dará una mejora parcial. En ese caso, revisa primero servidor, base de datos y recursos multimedia.
Preguntas y respuestas
¿Qué es WordPress headless?
WordPress headless es usar WordPress solo como gestor de contenido y separar el frontend en otra tecnología. Así, la API REST entrega datos y otra app los pinta.
Funciona bien cuando quieres más control visual o más velocidad en el frontend. Si no necesitas esa separación, quizá no te compense.
¿Cuál es la diferencia entre REST y GraphQL en
REST suele ser más directo y fácil de mantener en WordPress. GraphQL permite pedir justo lo que quieres, pero añade otra capa técnica.
Para empezar, REST suele ser más simple de operar. Si el proyecto crece mucho y el frontend hace consultas muy complejas, GraphQL puede tener sentido.
¿Cómo empiezo a optimizar una API REST?
Empieza midiendo peso, tiempo y número de llamadas. Luego aplica _fields, revisa _embed y reduce la paginación.
Después añade caché con invalidación por evento. Si todo sigue lento, crea endpoints propios para las pantallas más usadas.
¿Conviene usar WooCommerce en headless?
Sí, pero con cuidado. WooCommerce cambia stock, precios y variantes, y eso hace más delicada la caché.
Si vendes mucho y el catálogo cambia a menudo, la invalidación debe estar muy bien pensada. Si no, mostrarás datos viejos o gastarás demasiados recursos.
¿La API REST de WordPress es segura por defecto?
No, no basta con asumir que lo es. Hay rutas públicas, campos sensibles y formas de abuso si no limitas el acceso.
Debes revisar CORS, permisos, autenticación y rate limiting. En proyectos con datos personales, esto también toca RGPD, LOPDGDD y LSSI-CE.
¿JWT es mejor que cookies para headless?
JWT es mejor cuando el frontend está separado y necesita autenticarse sin sesión clásica. Cookies encajan mejor cuando el navegador y WordPress comparten un flujo más cerrado.
La elección depende de tu arquitectura, no de una moda técnica. En sitios con muchos permisos y varias apps, JWT suele dar más control.
¿Qué métrica me dice si la API va bien?
Mira tiempo medio, tamaño de respuesta, llamadas por página y porcentaje de acierto de caché. Si una ruta baja de peso y mantiene tiempo estable, vas por buen camino.
No te fíes de una sola cifra. Una API puede ser rápida pero costosa, o ligera pero mal cacheada.
Si quieres revisar tu API REST de WordPress con una mirada técnica y práctica, en Josu Barrios podemos ayudarte a medir, recortar y dejar una estrategia de caché y seguridad que aguante producción de verdad.
