Tu agencia predica rendimiento, pero tu propio sitio WordPress se arrastra. El nuestro también lo hacía — 3.2 segundos hasta Interactive, Lighthouse atrapado en 58, una pila de plugins que teníamos miedo de actualizar. Cada demostración de cliente significaba abrir devtools en su sitio estático vertiginoso, rezando para que no pidieran ver el nuestro. Somos socialanimal.dev — construimos experiencias sub-segundo con Next.js y Astro para marcas SaaS. Así que reconstruimos nuestro sitio en Astro, eliminamos WordPress por completo, y logramos 100s perfectos en todas las categorías de Lighthouse. Time to Interactive bajó a 0.4 segundos. Tamaño total del bundle: 47 KB. Sin plugins, sin consultas a base de datos, sin vergüenza. Este es el manual de migración exacto que utilizamos — el cambio de hosting, el pipeline de contenido, el sistema de optimización de imágenes, y la característica de Astro que eliminó completamente nuestra capa de caché.

Así que lo derribamos y lo reconstruimos con Astro. El resultado: 100s perfectos en las cuatro categorías de Lighthouse — Performance, Accessibility, Best Practices, y SEO. No en una sola página. En cada página. Esta es la historia de cómo llegamos allí, qué se rompió en el camino, y qué haríamos diferente.

Tabla de Contenidos

WordPress a Astro: Cómo Logramos Lighthouse 100 en Nuestra Reconstrucción

Por Qué Dejamos WordPress

Mira, WordPress alimenta aproximadamente el 43% de la web. No es una plataforma mala. Hemos construido muchos sitios WordPress para clientes y continuaremos haciéndolo cuando sea el ajuste correcto. Pero para nuestro propio sitio de agencia — un sitio de marketing en su mayoría estático con un blog — WordPress era excesivo de la peor manera.

Así es como se veía nuestra configuración de WordPress:

  • Tema: Tema personalizado construido en Sage (Roots.io)
  • Plugins: 14 plugins activos incluyendo Yoast SEO, WP Rocket, Advanced Custom Fields Pro, Gravity Forms, y algunos otros
  • Hosting: Plan WP Engine Professional a $60/mes
  • CDN: Cloudflare Pro a $20/mes
  • Complejidad de compilación: Plantillas PHP, Webpack para assets, base de datos MySQL

Incluso con WP Rocket realizando almacenamiento en caché agresivo, nuestros Core Web Vitals eran mediocres. El Largest Contentful Paint (LCP) era de 2.4 segundos en móvil. Cumulative Layout Shift (CLS) era 0.12 — no terrible, pero no bueno. Y cada vez que actualizábamos un plugin, había una probabilidad distinta de cero de que algo se rompiera.

¿El golpe real? Estábamos pagando $80/mes en costos de hosting por un sitio que obtenía quizás 3,000 visitas al mes. Eso no es mucho tráfico, y es mucho dinero por lo que era esencialmente un sitio folleto con un blog.

El Punto de Quiebre

La gota que derramó el vaso llegó en enero de 2025. Una actualización del núcleo de WordPress rompió nuestros bloques personalizados de Gutenberg. Arreglarlo requería actualizar ACF Pro, que requería actualizar la compatibilidad de la versión de PHP del tema, que requería actualizar el entorno de hosting. Lo que debería haber sido una actualización rutinaria se convirtió en un día completo de trabajo.

Miré a nuestro equipo y dije: "Les decimos a los clientes que pasen a headless. ¿Por qué no estamos comiendo nuestra propia comida?"

Por Qué Elegimos Astro

Evaluamos cuatro opciones para la reconstrucción:

Framework Ventajas Desventajas Nuestro Veredicto
Next.js Lo conocemos bien, excelente ecosistema Excesivo para un sitio de contenido, requiere servidor o tiempo de ejecución edge Demasiado pesado
Astro Enfocado en contenido, envía cero JS por defecto, arquitectura island Ecosistema más pequeño, más nuevo Ajuste perfecto
Eleventy Simple, compilaciones rápidas, maduro Modelo de componentes limitado, DX menos moderno Segundo lugar cercano
Hugo Compilaciones increíblemente rápidas, binario único El templating de Go es doloroso, flexibilidad limitada No para nosotros

Construimos muchos proyectos de Next.js para clientes, y es nuestro favorito para cualquier cosa con funcionalidad dinámica. Pero ¿para un sitio de marketing con mucho contenido? Next.js envía un tiempo de ejecución de JavaScript al navegador tanto si lo necesitas como si no. Incluso con exportación estática, estás enviando React al navegador.

La filosofía de Astro resonó con nosotros: envía HTML, agrega JavaScript solo donde lo necesites. Su arquitectura island significa que puedes tener un componente React completamente interactivo sentado junto a HTML completamente estático, y las partes estáticas envían cero JavaScript. Eso es exactamente lo que necesitábamos.

También habíamos estado haciendo más trabajo de desarrollo con Astro para clientes en años recientes, así que el equipo era cómodo con el framework. No era un ejercicio de aprendizaje — era una herramienta en la que ya confiábamos.

La Pregunta de la Capa de Contenido

Una decisión que tomamos temprano: no íbamos a usar un CMS headless para nuestro propio sitio. Para proyectos de clientes, a menudo recomendamos configuraciones de CMS headless con Contentful, Sanity, o Storyblok. Pero para nuestro blog, donde cada autor es un desarrollador cómodo con Markdown y Git? Content Collections en Astro con archivos MDX comprometidos con el repositorio era más simple y rápido.

Sin llamadas API en tiempo de compilación. Sin red de entrega de contenido para contenido. Sin servicio extra para administrar o pagar. Solo archivos en una carpeta.

La Estrategia de Migración

No hicimos una migración de big-bang. Aquí está nuestro enfoque por fases:

Fase 1: Auditoría de Contenido (1 semana) Exportamos todo el contenido de WordPress usando wp-cli y convertimos posts a MDX usando un script personalizado construido con turndown (convertidor de HTML a Markdown) más limpieza de expresiones regulares. Teníamos 47 posts de blog en ese momento. Aproximadamente 12 de ellos estaban desactualizados o con bajo rendimiento, así que redirigimos esos a contenido relevante más nuevo y no los migramos.

Fase 2: Sistema de Diseño en Astro (2 semanas) Reconstruimos nuestra librería de componentes como componentes de Astro. Botones, tarjetas, layouts de secciones, navegación — todos como archivos .astro. Sin framework necesario para ninguno de ellos. HTML y CSS puros con estilos con alcance.

Fase 3: Compilación de Página (2 semanas) Página de inicio, páginas de capacidades, acerca de, contacto, listado de blog, posts de blog individuales, 404. Construimos todas ellas como páginas de Astro con nuestra librería de componentes.

Fase 4: Ajuste de Rendimiento (1 semana) Aquí es donde realmente sucedió el trabajo de Lighthouse 100. Más abajo sobre esto.

Fase 5: Lanzamiento y Redirección (2 días) Configuramos redirecciones 301 apropiadas para cada URL antigua, verificamos con Screaming Frog que nada estaba roto, enviamos el nuevo sitemap a Google Search Console, e invertimos DNS.

Cronograma total: aproximadamente 6 semanas de trabajo a tiempo parcial junto con proyectos de clientes.

WordPress a Astro: Cómo Logramos Lighthouse 100 en Nuestra Reconstrucción - arquitectura

Decisiones de Arquitectura Que Marcaron la Diferencia

Cero JavaScript por Defecto

Nuestro sitio completo se envía con aproximadamente 2KB de JavaScript en total. Eso no es una errata. Dos kilobytes. Y la mayoría de eso es un pequeño script para el toggle de navegación móvil y análisis.

Aquí está nuestra navegación móvil — sin framework, sin dependencias:

---
// MobileNav.astro
---
<button id="menu-toggle" aria-expanded="false" aria-controls="mobile-menu">
  <span class="sr-only">Toggle menu</span>
  <svg><!-- hamburger icon --></svg>
</button>
<nav id="mobile-menu" hidden>
  <slot />
</nav>

<script>
  const toggle = document.getElementById('menu-toggle');
  const menu = document.getElementById('mobile-menu');
  
  toggle?.addEventListener('click', () => {
    const expanded = toggle.getAttribute('aria-expanded') === 'true';
    toggle.setAttribute('aria-expanded', String(!expanded));
    menu?.toggleAttribute('hidden');
  });
</script>

Ese tag <script> en un componente de Astro se agrupa y deduplica automáticamente. Es diminuto, es JavaScript vanilla, y funciona en todas partes.

Estrategia CSS: Estilos con Alcance + Una Capa Global Mínima

Usamos CSS con alcance incorporado de Astro para estilos a nivel de componente y una única hoja de estilos global (aproximadamente 8KB minificados) para tipografía, reset, propiedades personalizadas, y clases de utilidad. Sin Tailwind. Opinión controvertida, lo sé.

Amamos Tailwind para aplicaciones más grandes y proyectos de clientes. Pero para un sitio de este tamaño, añadía complejidad de compilación y tamaño de archivo que no necesitábamos. Nuestro CSS escrito a mano es más pequeño que la salida de Tailwind habría sido, incluso con purga.

/* Propiedades personalizadas globales */
:root {
  --color-text: #1a1a2e;
  --color-bg: #ffffff;
  --color-accent: #e94560;
  --color-accent-dark: #c81e45;
  --font-body: 'Inter', system-ui, sans-serif;
  --font-heading: 'Cal Sans', var(--font-body);
  --max-width: 72rem;
  --space-unit: 0.25rem;
}

Generación Estática con Precarga Inteligente

Cada página se genera estáticamente en tiempo de compilación. Usamos la integración prefetch incorporada de Astro para precargar enlaces al pasar el mouse, haciendo que la navegación se sienta instantánea:

// astro.config.mjs
import { defineConfig } from 'astro/config';
import mdx from '@astrojs/mdx';
import sitemap from '@astrojs/sitemap';

export default defineConfig({
  site: 'https://socialanimal.dev',
  integrations: [mdx(), sitemap()],
  prefetch: {
    prefetchAll: false,
    defaultStrategy: 'hover',
  },
  build: {
    inlineStylesheets: 'auto',
  },
});

Profundización en Optimizaciones de Rendimiento

Llegar a Lighthouse 100 no es solo elegir el framework correcto. Astro te da una ventaja de inicio, pero los últimos 10-15 puntos requieren esfuerzo deliberado. Aquí está lo que hicimos.

Optimización de Imágenes

El componente <Image /> incorporado de Astro maneja imágenes responsivas con conversión automática de formato (WebP/AVIF), lazy loading, y atributos width/height apropiados para prevenir CLS.

---
import { Image } from 'astro:assets';
import heroImage from '../assets/hero.jpg';
---
<Image 
  src={heroImage} 
  alt="Equipo de desarrollo de Social Animal trabajando en arquitectura headless"
  widths={[400, 800, 1200]}
  sizes="(max-width: 600px) 400px, (max-width: 900px) 800px, 1200px"
  format="avif"
  fallbackFormat="webp"
  quality={80}
  loading="eager"
/>

Para la imagen hero específicamente, usamos loading="eager" ya que está arriba del pliegue. Todo lo demás obtiene loading="lazy" por defecto.

También pasamos por cada imagen en el sitio y preguntamos: "¿Esta necesita ser una imagen?" Varios elementos decorativos se convirtieron en gradientes CSS o SVGs en su lugar. Nuestro fondo de sección hero, por ejemplo, es un gradiente CSS con una textura de ruido sutil aplicada vía un pequeño SVG en línea.

Estrategia de Carga de Fuentes

Las fuentes son un asesino de Lighthouse. Aquí está nuestro enfoque:

  1. Aloja todo uno mismo. Sin CDN de Google Fonts. Descargamos Inter y Cal Sans y los servimos desde nuestro propio dominio. Eso elimina una búsqueda DNS, conexión TCP, y apretón de manos TLS a fonts.googleapis.com.

  2. Subconjunto agresivamente. Usamos glyphhanger para analizar qué caracteres realmente usamos, luego subconjuntamos nuestras fuentes con pyftsubset. Nuestro Inter Regular WOFF2 bajó de 96KB a 18KB.

  3. Usa font-display: swap con un fallback de fuente del sistema cuidadosamente elegido que coincida estrechamente con métricas, minimizando cambio de layout durante intercambio.

  4. Precarga los archivos de fuente críticos:

<link rel="preload" href="/fonts/inter-latin-400.woff2" as="font" type="font/woff2" crossorigin />
<link rel="preload" href="/fonts/cal-sans-latin-600.woff2" as="font" type="font/woff2" crossorigin />

Hosting: Cloudflare Pages

Nos mudamos de WP Engine ($60/mes) a Cloudflare Pages (plan gratuito). Sí, gratuito. Nuestro sitio está bien dentro de los límites del plan gratuito de Cloudflare — 500 compilaciones por mes, ancho de banda ilimitado, solicitudes ilimitadas.

Cloudflare Pages se despliega desde un push de Git, sirve desde su red edge global, y maneja encabezados de caché automáticamente. Los tiempos de compilación promedian 22 segundos para nuestro sitio completo. Compara eso con nuestra configuración de WordPress donde una purga de caché podría tomar más tiempo.

El costo de hosting mensual pasó de $80 a $0.

Incorporación de CSS Crítico

Astro incorpora automáticamente hojas de estilos pequeñas cuando estableces build.inlineStylesheets: 'auto'. Para nuestras páginas, cada estilo crítico está incorporado en el <head>, significando que hay cero solicitudes de CSS que bloquean el render. El navegador puede comenzar a pintar inmediatamente.

Disciplina de Script de Terceros

Aquí es donde la mayoría de sitios pierden sus puntuaciones perfectas. Cada script de terceros es un desastre potencial de rendimiento. Limitamos los nuestros despiadadamente:

  • Análisis: Cambiamos de Google Analytics (70KB+ de JavaScript) a Plausible Analytics (< script 1KB, cargado async). Pagamos $9/mes por Plausible, y la calidad de datos es honestamente mejor para nuestras necesidades.
  • Formularios: Nuestro formulario de contacto en /contact usa un formulario HTML simple con manejo del lado del servidor vía Cloudflare Pages Functions. Sin librería de formularios JavaScript.
  • Sin widgets de chat. Sin incrustaciones de redes sociales. Sin banners de consentimiento de cookies (no usamos cookies que requieran consentimiento).

El Scorecard Lighthouse 100

Aquí están nuestras puntuaciones reales de Lighthouse a partir de mayo de 2025, medidas usando Chrome DevTools en una conexión acelerada (simulación móvil predeterminada de Lighthouse):

Métrica Puntuación
Performance 100
Accessibility 100
Best Practices 100
SEO 100
First Contentful Paint 0.6s
Largest Contentful Paint 0.8s
Total Blocking Time 0ms
Cumulative Layout Shift 0
Speed Index 0.8s

El Total Blocking Time de 0ms es mi estadística favorita. Cero. Esencialmente no hay JavaScript bloqueando el hilo principal. Nunca.

Antes y Después: Los Números

Métrica WordPress (Antes) Astro (Después) Mejora
Lighthouse Performance 58 100 +72%
LCP (móvil) 2.4s 0.8s 3x más rápido
CLS 0.12 0 Eliminado
TBT 380ms 0ms Eliminado
Peso de página (inicio) 1.8MB 142KB 92% más pequeño
Solicitudes HTTP 47 6 87% menos
JavaScript enviado 340KB 2KB 99.4% menos
Costo de hosting mensual $80 $9 (solo Plausible) 89% más barato
Tiempo de compilación/despliegue 3-5 min 22 sec ~10x más rápido
Time to First Byte 420ms 18ms 23x más rápido

La reducción del peso de la página es vertiginosa incluso para nosotros. 1.8MB hasta 142KB. Eso es lo que sucede cuando dejas de enviar jQuery, React, cargador de scripts de WP Rocket, inyector de marcado de esquema de Yoast, y catorce hojas de estilos de plugins.

Qué Hicimos Mal en el Camino

No fue todo un viaje suave. Momento de honestidad.

Error 1: Casi Sobre-Ingenierizamos la Gestión de Contenido

Nuestro primer instinto fue configurar Sanity como un CMS headless para el blog. Pasamos dos días configurando esquemas y configurando Sanity Studio antes de retroceder y preguntar: "¿Quién va a usar esto realmente?" La respuesta fue... nosotros. Desarrolladores. Quienes estamos perfectamente contentos escribiendo MDX en VS Code. Arrancamos Sanity y fuimos con Astro Content Collections. Ahorró costos continuos y complejidad.

Error 2: El Subconjunto de Fuentes Rompió Caracteres Especiales

Nuestro subconjunto de fuentes inicial era demasiado agresivo. Despojamos caracteres que pensábamos que nunca usaríamos, luego publicamos un post de blog con un em dash y algunas comillas rizadas que se renderizaban como cajas. Lección: prueba tus subconjuntos con contenido real, no solo "ABCDEFG."

Error 3: Olvidamos Sobre Imágenes OpenGraph

Nos lanzamos sin imágenes OG dinámicas. Cuando alguien compartía un post de blog en Twitter/X o LinkedIn, mostraba un fallback genérico. Tuvimos que volver atrás y construir un pipeline de generación de imágenes OG usando @astrojs/og (que usa Satori bajo el capó). Debería haber estado en el alcance original.

Error 4: El Mapa de Redirección 301 Tenía Brechas

A pesar de usar Screaming Frog para mapear URLs antiguas, nos perdimos un puñado de URLs de imagen que sitios externos estaban redirigiendo a través de enlaces. Detectamos estos en los análisis de Cloudflare aproximadamente una semana después del lanzamiento y añadimos las redirecciones faltantes. Siempre verifica tus registros de servidor después de una migración — Google Search Console no atrapará todo.

Lecciones para Tu Propia Migración

Si estás considerando moverte de WordPress a un framework enfocado en estático, aquí está lo que te diría:

  1. Audita antes de migrar. Mata contenido que no esté funcionando. Una migración es una gran oportunidad para podar.

  2. Haz coincidir la herramienta con el trabajo. Astro fue perfecto para nosotros porque somos principalmente contenido. Si necesitas mucha interactividad, Next.js o un framework similar podría ser la mejor llamada.

  3. No hagas cargo-cult de tu arquitectura anterior. No intentamos replicar nuestra configuración de WordPress en Astro. Repensamos todo desde cero. ¿Realmente necesitamos un plugin de formulario? No, un elemento <form> con una función serverless funciona bien.

  4. Mide antes, mide después, mide continuamente. Configuramos un trabajo de Lighthouse CI en GitHub Actions que se ejecuta en cada pull request. Si un PR reduce cualquier puntuación por debajo de 95, falla la verificación.

  5. Presupuesta para el "último 5%." Llegar de Lighthouse 85 a 95 es sencillo. Llegar de 95 a 100 requiere subconjunto de fuentes, análisis de CSS crítico, optimización de formato de imagen, y auditoría de scripts de terceros. Planifica tiempo para ello.

  6. Tus costos de hosting deberían avergonzar tu configuración anterior. Si estás sirviendo archivos estáticos y aún pagando tarifas de hosting significativas, algo está mal. El hosting estático es una commodity ahora.

Si te interesa cómo se vería una migración como esta para tu proyecto, consulta nuestra página de precios o ponte en contacto. Hemos hecho esta ruta de migración para varios clientes ahora, y las ganancias de rendimiento son consistentemente dramáticas.

Preguntas Frecuentes

¿Cuánto tiempo tarda migrar un sitio de WordPress a Astro? Para nuestro sitio (aproximadamente 50 páginas incluyendo posts de blog), tomó aproximadamente 6 semanas de trabajo a tiempo parcial. Un sitio más grande con cientos de posts y tipos de posts personalizados complejos podría tomar 8-12 semanas. El desarrollo real generalmente es más rápido que la auditoría de contenido y el mapeo de redirecciones.

¿Puedes obtener Lighthouse 100 con Next.js en lugar de Astro? Es posible pero significativamente más difícil. Next.js envía un tiempo de ejecución de JavaScript al navegador incluso para páginas estáticas (la capa de hidratación de React). Puedes acercarte — puntuaciones de 95-99 son alcanzables con cuidadosa optimización. Pero el enfoque zero-JS-by-default de Astro hace que las puntuaciones perfectas sean mucho más alcanzables para sitios de contenido.

¿Qué hay sobre funciones de WordPress como formularios de contacto y búsqueda? Los formularios de contacto funcionan bien con formularios HTML simples y un backend de función serverless (Cloudflare Pages Functions, Netlify Functions, etc.). Para búsqueda, usamos una búsqueda del lado del cliente con Pagefind, que construye un índice de búsqueda en tiempo de compilación y envía solo 5KB de JavaScript. Es rápido y funciona offline.

¿Migrar de WordPress a Astro daña el SEO? No si lo manejas apropiadamente. Configuramos redirecciones 301 para cada URL, mantuvimos nuestra estructura de URL donde fue posible, enviamos un nuevo sitemap, y mantuvimos todos nuestros datos estructurados. Nuestro tráfico orgánico realmente aumentó 23% en los tres meses después de la migración, probablemente debido al mejoramiento de Core Web Vitals.

¿Cómo manejas contenido dinámico como comentarios en un sitio de Astro? No tenemos comentarios en nuestro blog — eran principalmente spam en WordPress de todas formas. Si necesitas comentarios, servicios como Giscus (basado en GitHub Discussions) o Hyvor Talk funcionan bien como componentes incrustados. Se cargan como islands de Astro, así que no afectan la carga de página inicial.

¿Es Astro listo para producción para sitios grandes? Absolutamente. Astro 5.x (lanzado a finales de 2024) es maduro y estable. Empresas como Porsche, Google, Microsoft, y Netlify lo usan en producción. El rendimiento de compilación también escala bien — sitios con miles de páginas se compilan en menos de un minuto con la configuración correcta.

¿Cómo es el mantenimiento continuado comparado con WordPress? Dramáticamente menos. Sin actualizaciones de plugins, sin mantenimiento de base de datos, sin parches de seguridad para PHP. Actualizamos Astro y sus dependencias quizás una vez al mes vía pull requests de Dependabot. Cada actualización toma aproximadamente 5 minutos para revisar y fusionar. Compara eso con la cinta de correr de actualización de WordPress.

¿Pueden miembros del equipo no técnicos aún editar contenido en un sitio de Astro? Con nuestra configuración (archivos MDX en Git), necesitas estar cómodo con Markdown y flujos de trabajo básicos de Git. Para equipos con editores no técnicos, recomendamos emparejar Astro con un CMS headless como Sanity, Contentful, o Storyblok. Los editores obtienen una interfaz visual, y aún obtienen todos los beneficios de rendimiento de generación estática.