--- title: "Cronología crítica de cómo (y por qué) Google está estrechando el margen de la web abierta" description: "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, vist..." url: https://revistacloud.com/cronologia-critica-de-como-y-por-que-google-esta-estrechando-el-margen-de-la-web-abierta/ date: 2025-09-05 modified: 2025-09-05 author: "Silvia A. Feliz" image: https://revistacloud.com/wp-content/uploads/2025/09/google-wall-web-scaled.jpg categories: ["Análisis y opinión"] tags: ["google", "web abierta"] type: post lang: es --- # Cronología crítica de cómo (y por qué) Google está estrechando el margen de la web abierta 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, `` 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 ``.** 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 `` 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: 1. **La plataforma web hoy es más potente** que nunca (gráficos, multimedia, tipografía, WebGPU, PWAs, privacidad avanzada en navegadores alternativos). 2. **El control efectivo** sobre qué se prioriza y qué cae de la mesa **está concentrado**. Cuando caen piezas como XSLT, `` 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](https://wok.oblomov.eu/tecnologia/google-killing-open-web/) y [SEOcretos](https://seocretos.com/cronologia-de-como-google-esta-matando-la-web-abierta/).