La acusación es contundente: Google estaría desmantelando pieza a pieza la web abierta, no con un único golpe, sino mediante una secuencia de decisiones técnicas, comerciales y de gobernanza que, vistas en conjunto, dibujan una estrategia coherente. El ensayo “Google is killing the open web” —publicado en el blog de Oblomov— recompone esa cronología y la conecta con un hilo conductor: la progresiva sustitución de estándares abiertos y multiproveedor por mecanismos y APIs que favorecen un ecosistema más centralizado, instrumental para el negocio de publicidad y datos del gigante de Mountain View.
Este reportaje amplía esa tesis, contrasta los hitos más significativos, añade contexto técnico y recoge también objeciones y matices de quienes ven en buena parte de esos cambios una evolución razonable de la plataforma web. El resultado no es un veredicto sumario, sino una radiografía realista de un proceso de más de una década que hoy condiciona cómo se desarrolla, publica y consume la web.
Un punto de partida necesario: estándares, navegadores y poder de facto
La web nació como un terreno de estándares abiertos (HTTP, HTML, CSS, DNS) gobernados por organismos como el W3C y la IETF. La primera “guerra de navegadores” (años 90) enseñó que cuando un actor con posición dominante “extiende” la web con tecnologías propias, el resultado es fragmentación y dependencia. Chrome emergió en 2008 en un contexto distinto: explosión del móvil, auge de servicios centralizados y debilitamiento de Internet Explorer. Sobre esa ola, Google impulsó un ciclo de innovación rápida (motor V8, ciclo de releases, APIs modernas) canalizado a menudo a través de WHATWG, foro de especificación donde los navegadores —con Google en cabeza— coordinan la evolución de HTML y afines. Para sus críticos, aquí nace un “poder de facto” que desplaza al W3C y reduce contrapesos. Para sus defensores, es la forma de evitar parálisis y llevar a la web donde están los usuarios.
2013, año bisagra: RSS, XMPP, MathML y el primer pulso a XSLT/XML
El ensayo sitúa en 2013 el “giro de guion”:
- Cierre de Google Reader. No fue solo matar un producto; supuso debilitar el descubrimiento de contenidos vía RSS/Atom, combustible de blogs, medios y, más tarde, podcasts. La versión oficial fue la caída de uso. El efecto real: el consumo informativo se desplazó todavía más a algoritmos opacos en plataformas.
- Fin de la federación XMPP en Google Chat (Facebook siguió con Messenger en 2014). La mensajería interoperable se encogió, ganando terreno los jardines vallados.
- MathML salió de Chrome. Una década después regresó gracias a trabajo externo. Para aulas y accesibilidad, representar matemáticas sin depender de imágenes o JavaScript era y es relevante.
- Primer intento serio contra XSLT/XML en el navegador. XSLT permite transformar documentos (por ejemplo, un RSS) en HTML sin JavaScript. Para los críticos, desincentivar XSLT aumenta la dependencia de JS y del lado servidor.
Lectura realista. Ninguno de estos hechos por sí solo “mata” la web abierta. Juntos, sí mueven el centro de gravedad: menos estándares de presentación de datos en cliente, más lógica en JS y backend, más control en capas donde Google es fuerte.
2015, el año de AMP, <keygen> y el arranque del “modo app”
- AMP (Accelerated Mobile Pages). Prometía velocidad móvil. La crítica sostiene que el “milagro” era cargar menos basura y cachear en CDNs de terceros (Google a la cabeza). Ganó visibilidad en buscador, empujando a muchos medios a duplicar esfuerzos y ceder control.
- Deprecación de
<keygen>. Elemento HTML para generar pares de claves y facilitar autenticación mutua sin terceros. Voces como Tim Berners-Lee lamentaron perder un mecanismo que daba más soberanía al usuario. - SMIL en el punto de mira. Las animaciones declarativas en SVG quedaron relegadas. Desde entonces, casi todo pasa por CSS+JS, reforzando la lógica en cliente (y, por tanto, la dependencia de toolchains JS).
Balance. AMP ya no tiene el brillo de 2016, pero dejó una inercia: el rendimiento móvil se resolvió en torno a las preferencias de Google. Y la salida de <keygen> cerró una puerta a identidades más distribuidas.
2018–2020: RSS cae del navegador y las URLs pierden protagonismo
Firefox retiró el soporte nativo de RSS (“Live Bookmarks”), empujando a extensiones. Chrome nunca fue cálido con los feeds. El usuario medio dejó de ver RSS como primera clase en el navegador. Paralelamente, Chrome tanteó ocultar URLs por “usabilidad”. Los críticos lo vieron como otro paso para que el sitio importe más que la dirección (y, por tanto, la capacidad de evaluar origen y autenticidad).
2019–2023: Manifest V3, Web Integrity y el caso JPEG XL
- Manifest V3 cambió el modelo de extensiones en Chrome “por seguridad”. Para observadores y desarrolladores, limitó ad blockers al recortar capacidades de filtrado. Google niega intención anti-adblock; la percepción pública vio un beneficio directo para el negocio publicitario.
- Web Environment Integrity (WEI). Presentado como antitrampas/antifraude, muchos lo leyeron como “DRM del navegador”: el servidor preguntaría si tu cliente es “confiable”. La comunidad reaccionó y el plan se enfrió, pero la idea dejó huella.
- JPEG XL. Formato abierto con mejor compresión (con y sin pérdida), progresivo, transparencia y animación. Chrome lo eliminó pese a ensayos positivos. Para críticos, una oportunidad perdida de bajar costes de ancho de banda para toda la web. Google alegó falta de adopción y beneficios insuficientes frente a AVIF/WebP.
2024–2025: RSS fuera de Google News y la nueva ofensiva contra XSLT
En 2024, Google dejó de aceptar feeds para inclusión en Google News. Descubrir medios y artículos queda aún más supeditado a motores internos.
En 2025, se reabrió con fuerza el debate de eliminar XSLT del navegador —esta vez desde el WHATWG—. Críticos señalan que desde 2007 (XSLT 2.0) y 2017 (XSLT 3.0) existen versiones modernas, incluso con JSON como dato de entrada. La tesis es incómoda: si llevas años no manteniendo una función, su “baja adopción” acaba volviéndose profecía autocumplida.
Por qué XSLT/XML y RSS importan (incluso si nunca los usaste)
- Presentación sin JS. XSLT es un templating declarativo: transforma árboles de nodos (XML/HTML/SVG) en otros árboles, con validación estructural implícita. Menos superficie de ataque que concatenar strings.
- Costes y simplicidad. Un sitio puede servir XML+XSLT (feeds, sitemaps, catálogos, datos tabulares) y dejar que el navegador renderice. Menos CPU en servidor, menos bytes si se optimiza bien.
- Soberanía y portabilidad. RSS/Atom permiten suscribirse y migrar entre clientes sin pedir permiso. Es el músculo que sostiene podcasts y muchos flujos federados.
- Accesibilidad y ciencia. MathML y TEI/XML en humanidades son ejemplos donde el cliente debería poder visualizar sin toolchains pesados.
¿Todo esto puede hacerse con JS? Sí. Pero la pregunta es otra: ¿por qué eliminar opciones abiertas y maduras que diversifican la forma de construir web?
Los argumentos de Google (y compañía) y por qué no convencen a todo el mundo
- “Seguridad y coste de mantenimiento.” Mantener parsers XML/XSLT viejos es caro y puede traer CVEs. La réplica: si el problema es la implementación antigua, actualiza (XSLT 3.0, librerías modernas) o sustituye la dependencia, no borres la función de la especificación.
- “Baja adopción.” Métrica circular: años sin invertir generan menos uso. Además, XSLT 1.0 nunca pasó a 2.0/3.0 en navegadores, dejando fuera muchas capacidades.
- “Simplificar el código del navegador.” Válido en abstracto, pero choca con la realidad de nuevas APIs de JS añadidas cada ciclo. Para la comunidad, el problema no es “recortar”, sino qué se recorta: casi siempre lo que otorga autonomía al usuario.
Una visión más amplia: no todo es Google, pero Google pesa más
Sería injusto convertir esto en una fábula de “villano único”. Apple limita Web APIs en iOS; Mozilla ha tomado decisiones polémicas (RSS, integraciones varias); Microsoft ha pivotado a Chromium y prioriza su plataforma. La diferencia es de escala: con la cuota de Chrome y la posición en búsqueda, lo que decide Google se convierte en norma para gran parte de la web. Por eso, incluso “pequeños” cambios arrastran al resto.
¿Es “matar la web abierta”? Una lectura sobria
Lo realista es admitir dos verdades a la vez:
- La plataforma web hoy es más potente que nunca (gráficos, multimedia, tipografía, WebGPU, PWAs, privacidad avanzada en navegadores alternativos).
- El control efectivo sobre qué se prioriza y qué cae de la mesa está concentrado. Cuando caen piezas como XSLT,
<keygen>o JPEG XL, pierden diversidad los caminos para publicar, autenticar y distribuir.
No es un apocalipsis. Es una erosión constante que estrecha las rutas que no pasan por JavaScript de gran calado, servicios centralizados o APIs bendecidas por quienes dirigen el roadmap.
Qué pueden hacer usuarios, medios y desarrolladores (sin ingenuidad)
- Mantener feeds (RSS/Atom) visibles. Si publicas, exponlos. Si lees, usa lectores.
- Servir XML con XSLT en casos claros (sitemaps “legibles”, listados, catálogos, documentación). Si el navegador del usuario no lo soporta, haz server-side transform o añade un polyfill (SaxonJS) como degradación progresiva.
- Privacidad y pluralidad. No todo tiene que ejecutarse en el cliente: evalúa islas (HTMX/Alpine), SSR y rendidos estáticos. Menos JS donde no aporta.
- Extensiones y navegadores alternativos. Diversificar reduce el poder de agenda.
- Participar en los issue trackers. La presión técnica y educada modifica prioridades (ya pasó con varias APIs polémicas).
- Formación y documentación. Enseñar qué hace qué (XSLT, MathML, certificados de cliente, etc.) evita que decisiones “por defecto” pasen sin debate.
Lo que viene: escenarios en 12–24 meses
- XSLT en el navegador. Si se elimina, veremos más transformación en servidor y polyfills puntuales. Algunas comunidades (humanidades digitales, documentación técnica) podrían moverse a toolchains propias.
- Imágenes. A falta de JPEG XL, AVIF/WebP seguirán creciendo. Parte de la industria pedirá mejor tooling y perfiles estables para evitar “guerra de códecs” eterna.
- Extensiones. Manifest V3 ya es realidad; la presión mantendrá ciertas capacidades de filtrado, pero el modelo de bloqueo a nivel de red se desplazará fuera del navegador (DNS/routers).
- Integridad del entorno. La tentación de nuevos “verificadores” no desaparecerá. La clave será acotar casos de fraude y evitar atajos que conviertan el navegador en policía del usuario.
Conclusión: la importancia de conservar múltiples caminos
Una web saludable no es la que adopta “lo nuevo” sin mirar atrás, sino la que suma sin excluir rutas que otorgan autonomía y portabilidad. RSS, XSLT, MathML o certificados de cliente no son reliquias; son caminos alternativos que reequilibran el poder entre publicadores, lectores y plataformas.
Cuando un actor con peso sistémico apaga esas luces, el mapa se empobrece. No es el fin de la web abierta, pero sí menos web y menos abierta. Y eso merece debate, presión informada y, sobre todo, construcción de alternativas.
Preguntas frecuentes (FAQ)
1) ¿De verdad XSLT sigue teniendo sentido en 2025?
Sí, en escenarios donde conviene separar datos y presentación, reducir JS y validar estructuras (feeds, sitemaps, catálogos, documentación). XSLT 3.0, además, opera sobre JSON. Si el soporte nativo cae, se puede renderizar en servidor o usar polyfills.
2) ¿Por qué tanta insistencia con RSS si “ya nadie lo usa”?
RSS/Atom sostienen podcasts, sindican millones de sitios (WordPress lo expone por defecto) y devuelven agencia al lector: eliges fuentes sin algoritmos. Es una pieza baja fricción y abierta; si desaparece del ecosistema de productos, no es por inutilidad, sino por prioridades.
3) ¿No son válidos los argumentos de seguridad de Google?
La seguridad importa. El desacuerdo está en la terapia: actualizar implementaciones y mantener estándares vs. retirar funciones que reducen diversidad de enfoques. El “coste de mantenimiento” existe, pero qué se mantiene es una decisión política tanto como técnica.
4) ¿Qué alternativa hay a depender de grandes plataformas?
No hay bala de plata. Diversificar (navegadores, hosting, clientes RSS), minimizar JS donde no aporta, apostar por estándares (Web, DNS, correo interoperable), y documentar prácticas reproducibles. La independencia no es absoluta, pero sí gradual y acumulativa.
vía: wok.oblomov.eu y SEOcretos.
