Mejora de URL para páginas AMP


Estamos haciendo cambios en cómo funciona AMP en plataformas como la Búsqueda de Google que permitirá que las páginas enlazadas aparezcan en las URL de los editores en lugar del espacio URL de google.com/amp mientras se mantienen los beneficios de rendimiento y privacidad de la memoria caché de AMP. .

Cuando lanzamos AMP en la Búsqueda de Google, hicimos una gran compensación: para lograr la experiencia del usuario que los usuarios nos decían que querían, carga instantánea, necesitábamos comenzar a cargar la página antes de que el usuario hiciera clic. Como detallamos en una publicación de blog profunda el año pasado, las razones de privacidad hacen que sea básicamente imposible cargar la página desde el servidor del editor. Los editores no deberían saber qué les interesa a las personas hasta que accedan activamente a sus páginas. En cambio, las páginas de AMP se cargan desde Google AMP Cache, pero con ese comportamiento las URL se cambiaron para incluir el prefijo de la URL google.com/amp/.

Somos grandes admiradores de URL significativas y reconocemos que esto no es ideal. Muchos de ustedes están de acuerdo. Sin duda es la pieza número 1 de comentarios que escuchamos sobre AMP. Intentamos asegurarnos de que estas URL aparezcan en el menor número de lugares posible. Con el tiempo, nuestras aplicaciones nativas de Búsqueda de Google en Android e iOS comenzaron a mostrar de manera predeterminada las URL de los editores y trabajamos con los proveedores de los navegadores para compartir la URL del editor de un artículo siempre que fuera posible. Sin embargo, no pudimos corregir el estado de las URL donde más importa: en la web y en la barra de URL del navegador.

Nos embarcamos en un esfuerzo prolongado de varios meses, y hoy por fin confiamos en que encontramos una solución: como recomienda el W3C TAG, tenemos la intención de implementar una nueva versión de AMP Cache basada en el estándar emergente de Web Packaging.. Basado en este estándar web, las navegaciones de AMP de la Búsqueda de Google pueden aprovechar la precarga y el rendimiento de los servidores de Google, mientras que las URL permanecen como pretendía el editor y el contexto de seguridad principal de la web, el origen, permanece intacto. Hemos creado un prototipo basado en el navegador Chrome y una versión experimental de la Búsqueda de Google para asegurarnos de que realmente ofrece tanto el UX deseado como el rendimiento en casos de uso real. Este paso nos da la confianza de que tenemos una solución prometedora para este problema difícil y que pronto se convertirá en la forma en que los usuarios se encontrarán con el contenido de AMP en la web.

Los siguientes pasos se están moviendo hacia la implementación completa del nuevo estándar web en los navegadores web y en Google AMP Cache. Nuestro objetivo es que Web Packaging esté disponible en tantos navegadores como sea posible (después de todo, Web Packaging tiene casos de uso interesantes más allá de AMP, como páginas fuera de línea, carga de módulo ES6 y agrupación de recursos). En particular, pretendemos ampliar el trabajo existente en WebKit para incluir la implementación de Web Packaging y la implementación del equipo de Google Chrome está comenzando.

Estamos muy entusiasmados con la puesta en marcha de este trabajo y esperamos que los cambios lleguen a los usuarios por primera vez en la segunda mitad de 2018. Gracias por todos sus comentarios sobre el asunto y los mantendremos informados sobre el progreso aquí en este ¡Blog!

Malte Ubl , Tech Lead para el Proyecto AMP en Google.

Este artículo fue tomado del siguiente enlace: https://www.ampproject.org/latest/blog/improving-urls-for-amp-pages/



Share:

Related post

Disqus

Disqus comments:


Facebook

Facebook comments: