Medimos la migración de Finca Flichman: qué gana un sitio al dejar WordPress por Next.js
Cuando migramos Finca Flichman de WordPress a Next.js, dijimos que el sitio iba a quedar más rápido. Un año después decidimos dejar de decirlo y medirlo: restauramos el WordPress original, lo levantamos tal cual estaba y lo pasamos por Lighthouse contra la versión que está hoy en producción.
Este artículo es ese experimento. Los números son reproducibles y la metodología está abajo.
Cómo lo medimos
No comparamos contra un recuerdo ni contra una captura de pantalla vieja. Restauramos el sitio completo:
- El backup de cPanel de la cuenta original: los archivos de WordPress, el tema, los plugins y la biblioteca de medios enteros.
- La base de datos exportada del servidor de producción, importada sin tocar el contenido.
- Todo levantado en Docker con Apache y PHP, con las URLs reescritas al host local con WP-CLI para que el sitio se comportara igual que en producción.
El resultado es el mismo WordPress que veían los visitantes: WordPress 6.9, tema Salient, WPBakery Page Builder y WPML para el multiidioma.
Contra eso medimos flichman.com.ar tal como está hoy, en producción.
Las mediciones son la mediana de tres corridas de Lighthouse en perfil mobile, que es el que Google usa para posicionar. Lighthouse simula la red —una conexión móvil lenta— para las dos, así que lo que se compara es el código y el peso de cada sitio, no dónde está alojado cada uno.
Lo que WordPress arrastraba en cada visita
Antes de mirar los tiempos vale la pena ver el inventario. Para pintar la portada, el WordPress de Flichman pedía:
- 16 archivos CSS distintos. Uno del tema base, otro de la grilla, otro del header, otro de los elementos, otro de responsive, otro de Flickity, otro de Select2, otro de FancyBox, otro de FontAwesome, otro de WPBakery… cada plugin y cada módulo del tema sumaba su hoja de estilos, y el navegador tenía que bajarlas todas antes de pintar.
- 21 archivos JavaScript, incluidos jQuery, jquery-migrate, FancyBox, Select2 y un
init.jsdel tema de 82 KB. - 96 KB sólo de FontAwesome, una tipografía de íconos completa para usar un puñado de íconos.
- 10 pedidos a servidores de terceros para traer las fuentes desde Google Fonts, cada uno con su propio DNS, su propio TLS y su propia latencia.
- Y en cada visita, PHP consultando MySQL para armar una página que casi nunca cambia.
Ese es el costo real de la arquitectura de plugins: nadie eligió cargar dieciséis hojas de estilo. Se acumularon.
Los resultados
Lo primero que ve un visitante es lo primero que cambió:
Lighthouse mobile, mediana de tres corridas:
| Métrica | WordPress | Next.js | Diferencia |
|---|---|---|---|
| First Contentful Paint | 3.003 ms | 1.351 ms | −55% |
| Speed Index | 3.003 ms | 1.630 ms | −46% |
| Respuesta del servidor | 105 ms | 7 ms | −93% |
| CSS transferido | 93 KB | 13 KB | −86% |
| Archivos CSS | 16 | 6 | −62% |
| Archivos JavaScript | 21 | 11 | −48% |
| Fuentes | 265 KB | 125 KB | −53% |
| Pedidos a terceros | 10 | 0 | −100% |
| Trabajo en el hilo principal | 889 ms | 819 ms | −8% |
La diferencia más grande está en lo que el navegador tiene que bajar antes de poder pintar:
En desktop la tendencia se repite: el primer pintado pasa de 643 ms a 362 ms (−44%) y la respuesta del servidor de 97 ms a 6 ms (−94%).
Los puntajes de calidad de Lighthouse también se movieron:
| Categoría | WordPress | Next.js |
|---|---|---|
| SEO | 92 | 100 |
| Best practices | 77 | 100 |
| Accesibilidad | 84 | 91 |
Los 100 de best practices no son cosmética: significan que el sitio dejó de arrastrar librerías con vulnerabilidades conocidas, errores de consola y APIs obsoletas que venían con el ecosistema de plugins.
Por qué se hizo más rápido
Tres cambios de arquitectura explican casi todo.
El HTML deja de fabricarse en cada visita. WordPress arranca PHP, consulta MySQL, ejecuta el tema y los plugins, y recién ahí manda el primer byte. Next.js genera las páginas una sola vez, en el momento de compilar, y las sirve como archivos estáticos desde el borde de la red. De ahí que la respuesta del servidor pase de 105 ms a 7 ms: no hay nada que calcular, sólo algo que entregar.
El CSS pasa de ser una acumulación a ser una decisión. Con Tailwind, la hoja de estilos final contiene únicamente las clases que el sitio realmente usa. No hay estilos de un plugin que se instaló y no se sacó, ni una tipografía de íconos entera por cinco íconos. 93 KB en dieciséis archivos se convirtieron en 13 KB en seis.
Los terceros desaparecen del camino crítico. Las fuentes ahora se sirven desde el mismo dominio que el resto del sitio, autoalojadas y con font-display: swap. Diez pedidos a servidores ajenos —con su DNS, su handshake TLS y su latencia— se convirtieron en cero. Además de rapidez, eso es una ventaja de privacidad: la IP del visitante ya no viaja a un tercero sólo para leer la página.
Lo que se lleva el negocio
La velocidad de la primera impresión no es una métrica de vanidad. En mobile, con la red que tiene la mayoría de la gente, la diferencia entre ver contenido a los 3 segundos o al 1,3 es la diferencia entre quedarse y volver atrás. Y desde 2021 los Core Web Vitals son una señal de posicionamiento declarada por Google: un sitio que responde en 7 ms y entrega menos bytes compite mejor por las mismas búsquedas.
Para Flichman eso también significó bajar la superficie de mantenimiento. Sin plugins que actualizar cada semana, sin parches de seguridad urgentes, sin un panel administrativo expuesto a internet.
¿Tenés un WordPress que se volvió lento y caro de mantener? En Lykos hacemos exactamente este trabajo: medimos primero, migramos después y volvemos a medir. Hablemos.