¿Picos de tráfico que tiran la web tras una migración a PWA? Muchas migraciones fracasan porque el caché, el CDN y el service worker quedan mal configurados: caídas, contenido obsoleto, pérdida de posiciones en buscadores y usuarios que no vuelven. Un responsable técnico o fundador necesita un plan secuencial, tareas delegables y métricas claras para supervisar la transición.
Optimización y migración a PWA para periódicos y blogs de alto tráfico mejora velocidad, engagement y retención, pero exige plan SEO: SSR/híbrido para indexabilidad, service workers con estrategia de caché, configuración CDN/edge y pruebas de carga. Incluye checklist cronológico con tiempos y responsables, configuraciones reproducibles (Cloudflare Workers, Fastly, Cloud CDN) e invalidaciones para noticias para preservar métricas clave.
Resumen del proceso
Aquí va la lista breve y accionable para un despliegue seguro y medible.
- Auditoría técnica y prototipo SSR (1–2 semanas).
- App Shell y Service Worker básico (2 semanas).
- Configuración CDN/edge y políticas de caché (2 semanas).
- Pipelines CI/CD, pruebas de carga y despliegue canario (2–4 semanas).
- Rollout progresivo y monitorización continua (2–4 semanas).
Un ejemplo operativo aplicado en redacciones con alto tráfico muestra cómo repartir responsabilidades y plazos para minimizar riesgo:
- auditoría técnica (1–2 semanas) dirigida por el CTO y el equipo SEO, con soporte del responsable de infraestructura (SRE) para logs y Core Web Vitals
- prototipo SSR (1–2 semanas) desarrollado por el equipo frontend/engineers con revisión SEO
- App Shell y Service Worker (2 semanas) liderados por frontend y QA, e incluyendo pruebas de network-first vs cache-first
- configuración CDN/edge y políticas de caché (2 semanas) gestionadas por DevOps/SRE, integrando webhooks del CMS
- CI/CD, despliegue canario y pruebas de carga (2–4 semanas) ejecutadas por DevOps con un owner de despliegue
- rollout progresivo y monitorización continua (2–4 semanas) coordinado por SRE y el responsable editorial para validar experiencia de usuario
Este reparto facilita decisiones rápidas sobre purge CDN, rollback y comunicación editorial durante picos de tráfico.
Paso 1: auditoría y prototipo SSR
La auditoría detecta cuellos de botella y riesgos SEO antes de tocar producción.
Debe incluir análisis de Core Web Vitals, logs de crawling y mapeo de URLs prioritarias.
Qué revisar primero
Listar páginas críticas por tráfico y por importancia editorial.
Priorizar portada, secciones, landing de breaking news y template de artículo.
Prototipo SSR mínimo
Hacer un prototipo SSR que entregue HTML completo para artículos.
El prototipo debe pasar una comprobación de render de Googlebot y Lighthouse.
Google confirmó que Core Web Vitals influye en la evaluación de la experiencia de página.
Paso 2: service worker y app shell
El App Shell mejora la sensación de velocidad al cargar la interfaz desde el edge.
El Service Worker debe cachear assets, gestionar versiones y respetar la frescura del contenido.
Estrategia de cache inicial
Usar cache-first para assets estáticos y network-first para artículos recientes.
Versionar las cachés con claves que incluyan fecha o número de release.
Ciclo de vida del service worker
Controlar instalación, activación y skipWaiting para actualizaciones predecibles.
Evitar un SW que sirva contenido obsoleto sin comprobación de versión.
Una buena práctica es: "La caché incluye la versión del release para evitar servir noticias obsoletas".
Paso 3: CDN/Edge y políticas de caché
Configurar el CDN para priorizar TTFB y LCP es esencial para medios de alto tráfico.
Definir surrogate-keys y TTL distintos por tipo de contenido para evitar errores editoriales.
Reglas de TTL por sección
Breaking news: TTL 0–30 segundos con network-first.
Artículos evergreen: TTL de minutos a horas (por ejemplo 5 minutos a 24 horas según la frecuencia de actualización) con stale-while-revalidate y purges puntuales por surrogate-key cuando haya correcciones editoriales; los artículos verdaderamente estáticos pueden permitir TTL de varias horas o días mientras que las piezas que ocasionalmente reciben correcciones usan purges selectivos para evitar servir versiones obsoletas.
Purgado y webhooks
El CMS debe disparar un webhook al CDN al publicar o editar.
El webhook purga por surrogate-key y registra el resultado en logs.
La clave práctica: "Purge automático desde CMS evita servir noticias corregidas".
1
Auditoría
Mapear URLs críticas y Core Web Vitals.
2
SSR + App Shell
HTML render en servidor y Shell servido desde edge.
3
CDN/Edge
TTL por sección y purges desde CMS.
4
CI/CD
Canary, tests de carga y rollback automático.
En entornos editoriales de alta rotación es habitual combinar varias técnicas de caché e invalidación para evitar servir contenido obsoleto: usar surrogate-keys por artículo y sección en las cabeceras del CDN para purges selectivos al publicar, mantener ETag/Last-Modified en el origen para permitir conditional GET, aplicar stale-while-revalidate en páginas evergreen y stale-if-error para tolerancia ante fallos, y optar por network-first en Service Worker para breaking news mientras se usa cache-first para assets estáticos. Además, versionar claves de caché y añadir un campo de versión en la clave del Service Worker evita stale caches tras deploys.
En conjunto, estas medidas coordinan CDN, SW y origen para reducir TTFB y mejorar LCP sin sacrificar frescura.
Tabla comparativa CDN
| Proveedor |
TTFB y LCP |
Purge latency |
Integración edge |
Coste orientativo |
| Cloudflare |
Muy bueno |
Baja (segundos) |
Workers + KV |
Bajo-medio |
| Fastly |
Excelente |
Muy baja (segundos) |
VCL y edge compute |
Medio-alto |
| Google Cloud CDN |
Bueno |
Medio (minutos) |
Cloud Run / Edge |
Medio |
Paso 4: CI/CD, despliegue y rollback
Un pipeline bien diseñado evita errores humanos y permite rollback rápido.
Crear stages para pruebas de render, rendimiento y despliegue canario es esencial.
Plantilla de pipeline
Archivo mínimo: lint, build, lighthouse, deploy canary y promote.
El job de Lighthouse debería generar alertas cuando LCP empeore más del 20% en comparativas controladas, pero convertir esa alerta en un fallo obligatorio del pipeline debe estar contextualizado por tipo de página (home, artículo, sección), rango de variación aceptable y tamaño de la muestra; thresholds efectivos se definen por grupo y se validan con monitorización real y pruebas de carga.
Yaml
name: PWA Deploy
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Install
run: npm ci
- name: Build SSR
run: npm run build:ssr
lighthouse:
runs-on: ubuntu-latest
needs: build
steps:
- name: Run Lighthouse CI
run: npx @lhci/cli autorun --upload.target=temporary-public-storage
deploy-canary:
runs-on: ubuntu-latest
needs: lighthouse
steps:
- name: Deploy Canary
run: ./scripts/deploy_canary.sh
Script de rollback y purge
Un script sencillo revierte la release y purga CDN con clave de versión.
El script debe autenticar y confirmar antes de ejecutar cambios.
Bash
RELEASE=${1:-previous}
echo "Reverting to $RELEASE"
git checkout $RELEASE && git push origin HEAD:refs/heads/main
curl -X POST "https://api.cdn.example/purge" -H "Authorization: Bearer $CDN_TOKEN" -d '{"key":"site_v1234"}'
Opinión medida sobre CI/CD y despliegue
La estrategia canaria funciona bien si hay pipelines y monitorización.
Funciona mal cuando no hay métricas en tiempo real o no se purgan caches.
La recomendación es tener pruebas automáticas y un rollback probado semanalmente.
Errores que arruinan el resultado
El error más frecuente es confiar solo en renderizado cliente y perder indexación.
Eso provoca caída de tráfico orgánico y problemas de rastreo por Googlebot.
Caché agresivo sin invalidación
Configurar TTL largos sin purges automáticos ocasiona noticias obsoletas en la PWA.
La consecuencia puede ser retirada de contenido o que se publique información incorrecta.
Desplegar sin pruebas de carga
Lanzar sin simular picos provoca fallos en origen y en el CDN.
La falta de rollback extiende la caída y hace difícil recuperar tráfico.
Caso habitual anónimo
Un caso habitual: periódico mediano lanza PWA con cache por defecto a 10 minutos.
Tras una corrección editorial, los usuarios siguieron viendo la versión antigua durante horas.
Un caso real orientativo: un diario nacional con ~20M PV/mes migró a un prototipo SSR + PWA y afinó CDN y purges automáticos. Antes del cambio la página de artículo mostraba TTFB medio 800 ms y LCP 3,8 s; tras implantar SSR en edge, ajustar TTLs y aplicar stale-while-revalidate con purges por surrogate-key, TTFB bajó a 120–160 ms y LCP a 1,4–1,7 s en medianas de prueba. En seguimiento a 30 días, el tráfico orgánico mostró un aumento intermensual del 9–13% en sesiones de búsqueda y la CTR por snippet subió 6 puntos, mientras que la tasa de rebote en móviles se redujo un 8%.
Estos valores ilustran cómo la combinación de SSR, CDN tuning, service worker y CI/CD con despliegue canario impacta métricas Core Web Vitals y negocio.
Cuándo no funciona este método / alternativas
Ver la "Excepción técnica" al final del artículo para casos donde no aplicar la migración.
Preguntas frecuentes
¿Pierde indexación al pasar a PWA?
No necesariamente.
Si se usa SSR o pre-rendering, los buscadores reciben HTML completo.
La técnica clave es servir contenido indexable desde el servidor.
¿Cómo evitar que la PWA muestre noticias antiguas?
Usar short‑TTL para breaking y purges automáticos desde el CMS.
Incluir surrogate-key por artículo y verificar que el webhook del CMS autentica.
¿Qué herramientas automatizan pruebas de rendimiento?
Lighthouse, WebPageTest y PageSpeed Insights permiten pruebas automatizadas.
Para carga real usar k6 o Locust y comparar métricas LCP y TTFB.
¿Qué plugins ayudan en WordPress/Newspack?
Plugins de PWA y Workbox facilitan SW y manifest.
Para Newspack, preferir soluciones headless o módulos oficiales que mantengan sitemaps de noticias.
¿Cómo medir si la migración mejoró tráfico y métricas?
Medir LCP, TTFB, INP, tasa de rebote y conversiones antes y después.
Comparar períodos de 14 y 30 días para mitigar ruido editorial.
¿Qué hacer si la PWA baja retención?
Revisar Service Worker, errores JS y políticas de caché.
Hacer A/B entre versión CSR y SSR para aislar la causa.
¿Se puede reemplazar AMP por PWA?
Sí en muchos casos, siempre que la PWA mantenga tiempos de carga comparables.
Para noticias rápidas, AMP sigue siendo útil donde se necesite entrega ultra-rápida.
Para validar este plan con el equipo técnico, se recomienda pedir una auditoría técnica que aplique esta checklist y arranque el prototipo en 2 semanas.
Referencias y recursos
La evidencia técnica y guías oficiales ayudan en la implementación.
Para detalles prácticos sobre PWA y Service Workers ver web.dev.
Google actualizó el peso de Core Web Vitals en la evaluación de páginas.
Recientemente muchas redacciones españolas incorporaron workflow de purge desde el CMS para breaking news.
PageSpeed Insights y Lighthouse siguen siendo la referencia para medir LCP y TTI.
Excepción técnica: no aplicar la migración si la plataforma bloquea el control de cabeceras o Service Workers, o si no existen recursos para pruebas de carga, pipelines y monitorización continua.
