La versión corta
X ha sustituido tres servidores web distintos por una sola app que renderiza cada página para personas, rastreadores de búsqueda y bots de vista previa de enlaces. El principal engineer Yagiz Nizipli explicó el 4 de noviembre de 2026 que un perfil muestra ahora su primer post en 2.7 segundos en una conexión lenta, frente a más de 22. Para las empresas que planean el desarrollo de aplicaciones web o la reconstrucción de una single-page app pesada, el paso de X muestra cuánta velocidad y coherencia de SEO puede aportar una única ruta de renderizado en servidor con streaming.
¿Qué ha reconstruido X exactamente?
Durante la mayor parte de la última década, X.com funcionó con rweb, una app de React renderizada en el cliente que nació de la progressive web app Twitter Lite de 2017. Con el tiempo, X añadió dos servidores más a su lado: rweb SSR, que renderizaba páginas para los rastreadores de búsqueda, y Jetfuel SSR, un sitio aparte renderizado en servidor para páginas indexables sin sesión iniciada, como eventos, Communities, Trends y la búsqueda. Así, una misma URL de X.com podía construirse de tres maneras distintas.
El artículo de Nizipli enumera los costes de esa configuración. Los servidores se fueron distanciando, de modo que una corrección de SEO podía llegar a uno y no a los demás. Los visitantes sin sesión iniciada recibían la ruta más lenta: su navegador descargaba un shell de la aplicación, después el JavaScript, lo ejecutaba, llamaba a la API GraphQL y solo entonces renderizaba el perfil. «Los bots salían ganando», escribió. La nueva app atiende a todas las audiencias desde un solo servidor, con tres comportamientos decididos en cada petición:
| Visitante | Qué envía el nuevo servidor |
|---|---|
| Personas en un navegador | HTML con streaming: primero el shell de la página y después cada sección a medida que llegan sus datos, con las respuestas GraphQL incrustadas una sola vez para que el navegador las reutilice |
| Rastreadores de búsqueda verificados | Un documento completo con datos estructurados, todos los límites de Suspense resueltos y sin bundle de cliente; los rastreadores se identifican por IP verificada en el edge, no por User-Agent |
| Bots de vista previa de enlaces | Solo el título, la descripción y la imagen de la tarjeta; el cuerpo de la página se omite |
X mantuvo sus URL y redirecciones existentes, trasladó las reglas de limpieza de URL de rweb SSR y reconstruyó como componentes compartidos los datos estructurados, las alternativas de idioma y las páginas 404 reales de Jetfuel. Jetfuel SSR se retiró el 1 de agosto de 2026 y rweb SSR se apagó a principios de septiembre, lo que eliminó casi 36,000 líneas de la base de código antigua.
¿Cuánto más rápida es la nueva aplicación web de X?
En una grabación de laboratorio realizada el 3 de noviembre de 2026 con el perfil Slow 4G de Lighthouse, la nueva app mostró el primer post de un perfil a los 2.7 segundos. La app antigua mostraba su pantalla de bienvenida a los 1.0 segundos y la mantenía hasta que el primer post aparecía a los 23.9 segundos. En pruebas separadas con sesión iniciada y una CPU ralentizada, los perfiles y los posts aparecieron entre 8 y 13 veces antes. El timeline de Inicio, que todavía se renderiza solo en el navegador, fue lo que menos mejoró: 14.1 segundos frente a 24.6.
Varias de las correcciones las pueden reutilizar directamente otros equipos:
- Menos archivos de arranque. El chunking por defecto generaba 754 archivos de arranque para la entrada con sesión iniciada. Agrupar los módulos compartidos en tres chunks lo redujo a 182, y la entrada sin sesión pasó de 582 archivos a 10.
- HTML para rastreadores por debajo de 2 MB. Los hilos largos generaban 2.2–3.5 MB de HTML, por encima de los 2 MB que lee Googlebot. Un sprite de iconos y unos datos estructurados más ligeros recuperaron un 13–14 % en las páginas grandes.
- Primero la hoja de estilos. Retrasar el JavaScript hasta que cargara el CSS redujo el first contentful paint de un post sin sesión de 7,216 ms a 1,804 ms en las pruebas de laboratorio.
- Menos infraestructura. A medida que se movía el tráfico, X redujo a la mitad la flota de rweb sin sesión, de 1,400 a 700 instancias por centro de datos.
X subraya que son cifras de laboratorio y que los dispositivos y las redes reales variarán. La empresa también señala una contrapartida: el nuevo servidor hace más trabajo antes de responder, por lo que el tiempo hasta el primer byte es algo mayor que en la app antigua.
¿Cómo lo lanzó tan rápido un equipo pequeño?
X afirma que menos de cinco ingenieros, trabajando con agentes de programación con IA, construyeron la primera versión en menos de seis meses; más de 20 personas han hecho commits en la app desde finales de septiembre. Los ingenieros definieron la arquitectura y revisaron cada cambio, mientras que los agentes trasladaron el comportamiento de los servidores antiguos, convirtieron páginas y escribieron pruebas. Tres controles hicieron fiable ese resultado: un archivo AGENTS.md compartido con reglas de programación, más de 25 «skills» de flujo de trabajo guardadas en el repositorio y reglas de lint propias, entre ellas un plugin «anti-slop» que rechaza los patrones que suelen producir los agentes. Los servidores antiguos sirvieron de especificación funcional, y un script de paridad comparó página a página lo que Googlebot veía en los servidores antiguos y en los nuevos.
Qué significa para los equipos de software de EE. UU. y la UE
La lección más clara no es «reescribirlo todo». Es que tener rutas de renderizado separadas para usuarios, bots y vistas previas multiplica en silencio los errores de SEO y el coste de mantenimiento. Muchas empresas de EE. UU. y la UE funcionan exactamente con ese patrón: una app renderizada en el cliente para los usuarios, un servicio de prerenderizado o un sitio de marketing aparte para los rastreadores y soluciones improvisadas para las vistas previas en redes sociales. Si sus etiquetas title, canonicals, hreflang o páginas 404 se corrigen en un sitio y siguen rotas en otro, la experiencia de X indica que la consolidación se amortiza sola.
En segundo lugar, el renderizado en servidor con streaming es ya una respuesta habitual a las redes móviles lentas. Frameworks como Next.js, Remix y React Router ya ofrecen streaming y Suspense, así que la mayoría de los equipos puede obtener buena parte de la mejora de X sin construir un servidor propio. El trabajo a medida de X, la detección de rastreadores verificada en el edge y el recorte del payload para el límite de 2 MB de Googlebot, importa sobre todo a muy gran escala o en páginas con contenido largo y cargado de datos, como marketplaces, foros y catálogos.
En tercer lugar, la forma en que X usó los agentes de IA es una plantilla para la modernización de sistemas heredados: mantener el sistema antiguo en marcha como especificación, migrar el tráfico de forma gradual tras feature switches y convertir las convenciones del equipo en reglas de lint para que el resultado de los agentes pueda comprobarse automáticamente. Eso reduce el riesgo clásico de una reescritura completa, sin eliminar la necesidad de que ingenieros sénior se responsabilicen de la arquitectura y la revisión. Qué significa para el mercado español: muchas tiendas online, marketplaces y portales de contenido de España mantienen esa misma división entre una single-page app para los usuarios y un servicio de prerenderizado para los buscadores. Unificar la ruta de renderizado simplifica el SEO multilingüe (castellano, catalán, euskera o gallego) y la gestión de hreflang, porque cada versión de idioma sale del mismo código. Y si la migración toca formularios o etiquetas de analítica, conviene comprobar en cada cambio que el aviso de cookies y el consentimiento siguen las pautas de la AEPD.
¿Cómo deberían revisar los equipos su propia aplicación web ahora?
- Cuente sus rutas de renderizado. Enumere cada servicio que genera HTML para usuarios, rastreadores y vistas previas, y compruebe si las meta etiquetas, los datos estructurados y los códigos de estado salen de una sola fuente.
- Pruebe con un perfil lento. Mida el tiempo hasta el primer contenido útil en Slow 4G con la caché vacía, no solo las puntuaciones de Lighthouse en la wifi rápida de la oficina.
- Revise el tamaño del HTML para rastreadores. Asegúrese de que sus páginas más grandes quedan muy por debajo de 2 MB de HTML para que los buscadores vean todo el contenido.
- Audite las peticiones de arranque. Cuente los archivos JavaScript que necesita una página antes de ser interactiva; cientos de chunks pequeños cuestan viajes de ida y vuelta en el móvil.
- Migre de forma gradual. Si reconstruye, enrute el tráfico por ruta y audiencia en el edge para poder mover a los usuarios hacia la nueva versión y de vuelta sin un lanzamiento de golpe.
Preguntas frecuentes
¿Qué ha cambiado X en su aplicación web?
El 4 de noviembre de 2026, el principal engineer de X Yagiz Nizipli describió una nueva aplicación web que sustituye por uno solo los tres servidores que X tenía para personas, rastreadores de búsqueda y vistas previas de enlaces. Ya sirve X.com sin sesión iniciada y las páginas que rastrean los buscadores, y los usuarios con sesión iniciada se están migrando país por país.
¿Cuánto más rápida es la nueva aplicación web de X?
En la grabación de laboratorio de X con un perfil Slow 4G limitado, el primer post de un perfil apareció a los 2.7 segundos en la nueva app frente a 23.9 segundos en la antigua. Las pruebas de X con sesión iniciada mostraron perfiles y posts que aparecían entre 8 y 13 veces antes en una conexión lenta, mientras que el timeline de Inicio fue lo que menos mejoró, unas 1.7 veces. X afirma que son resultados de laboratorio y que en dispositivos reales variarán.
¿Qué stack tecnológico usa la nueva aplicación web de X?
Según el blog de ingeniería de X, la app está construida con Vite y Rolldown, React con renderizado en servidor con streaming y Suspense, Fastify, Platformatic Watt sobre Node.js, Relay con GraphQL, TypeScript, Tailwind CSS y una nueva biblioteca de componentes propia. Las imágenes de las tarjetas de vista previa de enlaces las genera ahora un servicio en Rust.
¿Por qué importa para el SEO un único servidor de renderizado?
Con tres servidores, según X, una corrección de una meta description, de los datos estructurados o del comportamiento 404 podía tener que aplicarse en tres bases de código, y los servidores se fueron distanciando. Con un solo servidor, una corrección de SEO se aplica una vez. X también recortó el HTML para rastreadores de los hilos largos, que había crecido hasta 2.2–3.5 MB, para volver por debajo de los 2 MB que lee Googlebot.
¿Usó X agentes de programación con IA para la reescritura?
Sí. X afirma que menos de cinco ingenieros, trabajando con agentes de programación con IA, construyeron la primera versión en menos de seis meses. Los ingenieros definieron la arquitectura y revisaron cada cambio, mientras que los agentes hicieron buena parte de la migración, las pruebas y las correcciones, guiados por un archivo AGENTS.md compartido, más de 25 skills del repositorio y reglas de lint propias.
Fuentes
X Engineering — Rebuilding the global town square from scratch, de Yagiz Nizipli (en inglés; fuente primaria, 4 de noviembre de 2026)
The Verge — X says its updated web app is way faster (en inglés; 5 de noviembre de 2026)