¿Qué hay en una URL de AMP?
En la web, mucho: las URL y los orígenes representan, hasta cierto punto, la confianza y la propiedad del contenido. Cuando estás leyendo un artículo del New York Times, un rápido vistazo a la URL te da un nivel de confianza de que lo que estás leyendo representa la voz del New York Times. La atribución, la marca y la propiedad son claras.AMP en la Búsqueda de Google ha borrado un poco esta línea. En esta publicación, primero intentaré explicar el razonamiento detrás de algunas de las decisiones técnicas que se han tomado y dar sentido a los diferentes tipos de URL de AMP que existen. A continuación, describiré los cambios que se han estado realizando para abordar las preocupaciones sobre las URL.
Para empezar, los documentos AMP tienen tres tipos diferentes de URL:
URL original: el documento del editor escrito en formato AMP. http://www.example.com/amp/doc.html
URL de caché de AMP: el documento servido a través de un caché de AMP (por ejemplo, todos los AMP servidos por Google se sirven a través de Google AMP Cache ). La mayoría de los usuarios nunca verán esta URL. https://www-example-com.cdn.ampproject.org/c/www.example.com/amp/doc.html
URL de Google AMP Viewer: el documento que se muestra en un visor de AMP (por ejemplo, cuando se representa en la página de resultados de búsqueda). https://www.google.com/amp/www.example.com/amp.doc.html
Aunque tener tres URL diferentes con orígenes diferentes para esencialmente el mismo contenido puede ser confuso, existen dos razones principales por las que existen estas diferentes URL: el almacenamiento en memoria caché y la pre representación. Ambos son grandes contribuyentes a la velocidad de AMP, pero requieren nuevas URL y me extenderé sobre por qué es así.
AMP Cache URLs
Comencemos con las URL de caché de AMP. Paul Bakaus, un Defensor de Desarrolladores de Google para AMP, tiene una excelente publicación que describe por qué existen los cachés de AMP. La publicación de Paul entra en gran detalle describiendo los beneficios de AMP Caches, pero no responde completamente a la pregunta de por qué requieren nuevas URL. La respuesta a esta pregunta se reduce a uno de los principios de diseño de AMP: compilar para una fácil adopción. AMP intenta resolver algunos de los problemas de la web móvil a escala, por lo que sus componentes deben ser fáciles de usar para todos.
Hay una variedad de opciones para obtener validación, proximidad a los usuarios y otros beneficios provistos por AMP Caches. Sin embargo, para un sitio pequeño que no gestiona sus propias entradas DNS, no tiene recursos de ingeniería para enviar contenido a través de API complicadas, o no puede pagar redes de distribución de contenido, muchas de estas tecnologías son inaccesibles.
Por este motivo, Google AMP Cache funciona mediante una simple "transformación" de URL. Un webmaster solo tiene que hacer que su contenido esté disponible en alguna URL y el caché de AMP de Google puede almacenar y servir el contenido a través de la infraestructura mundial de Google a través de una nueva URL que refleja y transforma el original. Es tan simple como eso. Aprovechar un caché de AMP utilizando la URL original, por otro lado, requeriría que el webmaster modifique sus registros DNS o reconfigure sus servidores de nombres. Si bien algunos sitios hacen precisamente eso, el enfoque basado en URL es más fácil de usar para la gran mayoría de los sitios.
URL de AMP Viewer
En la sección anterior, aprendimos sobre las URL de caché de Google AMP: URL que apuntan a la versión almacenada en caché de un documento de AMP. Pero, ¿qué pasa con las www.google.com/ampURL? ¿Por qué son necesarios? Estas son URL de "AMP Viewer" y existen debido a la pre representación.
El soporte integrado de AMP para la privacidad y el preescrito con conciencia de recursos rara vez se menciona y, a menudo, se malinterpreta. Los documentos de AMP se pueden preprocesar sin activar una cascada de recuperaciones de recursos, sin acaparar la CPU y la memoria de los usuarios, y sin ejecutar ningún código de análisis sensible a la privacidad. Esto funciona independientemente de si la aplicación de inserción es una página web móvil o una aplicación nativa. La necesidad de nuevas URL, sin embargo, proviene principalmente de implementaciones web móviles, entonces estoy usando Google'
¿Cómo funciona la pre representación?
Cuando un usuario realiza una búsqueda en Google que devuelve resultados habilitados para AMP, algunos de estos resultados se renderizan previamente detrás de escena. Cuando el usuario hace clic en un resultado preprocesado, la página de AMP se carga instantáneamente.
La preprocesamiento funciona cargando un iframe oculto en la página de incrustación (la página de resultados de búsqueda) con el contenido de la página de AMP y un parámetro adicional que indica que el documento de AMP solo se está preprocesando. El componente de JavaScript que maneja el ciclo de vida de estos iframes se llama "AMP Viewer".
El navegador del usuario carga el documento y el tiempo de ejecución AMP y comienza a renderizar la página AMP. Como todos los demás recursos, como imágenes e incrustaciones, son administrados por el tiempo de ejecución de AMP, no se carga nada más en este punto. El tiempo de ejecución de AMP puede decidir buscar algunos recursos, pero lo hará de una manera sensible a los recursos y la privacidad.
Cuando un usuario hace clic en el resultado, todo lo que AMP Viewer debe hacer es mostrar el iframe que el navegador ya ha procesado y dejar que el tiempo de ejecución de AMP sepa que el documento de AMP ahora está visible.
Como puede ver, esta operación es increíblemente barata: no hay actividad de red o navegación difícil en una página nueva. Esto lleva a una experiencia de carga casi instantánea del resultado.
¿De dónde provienen las URL de google.com/amp?
Todo lo anterior ocurre mientras el usuario todavía está en la página original (en nuestro ejemplo, esa es la página de resultados de búsqueda). En otras palabras, el usuario no ha ido a una página diferente; acaban de ver un iframe en la misma página y, por lo tanto, el navegador no cambia la URL.
Todavía queremos que la URL en el navegador refleje la página que se muestra en la pantalla y facilite el enlace de los usuarios. Cuando los usuarios presionan Actualizar en su navegador, esperan que aparezca el mismo documento y no la página de resultados de búsqueda subyacente. Entonces el espectador de AMP tiene que actualizar manualmente esta URL. Esto sucede usando la API de historial. Esta API permite que AMP Viewer actualice la barra de URL del navegador sin realizar una navegación difícil.
La pregunta es a qué URL debe actualizarse el navegador. Idealmente, esta sería la URL del resultado en sí (por ejemplo, www.example.com/amp/doc.html); o la URL de caché de AMP (por ejemplo, www-example-com.cdn.ampproject.org/www.example.com/amp/doc.html). Lamentablemente, no puede ser ninguno de esos. Una de las principales restricciones de la API de historial es que la nueva URL debe tener el mismo origen que la URL original ( referencia ). Esto es reforzado por los navegadores (por razones de seguridad ), pero significa que en la Búsqueda de Google, esta URL debe estar en www.google.com de origen.
¿Por qué se muestra una barra de encabezado?
La sección anterior explicaba las restricciones en las URL que un AMP Viewer debe manejar. Estas URL, sin embargo, pueden ser confusas y engañosas. Pueden abrir las puertas a los ataques de phishing. Si una página de AMP mostraba una página de inicio de sesión que se parece a la de Google y dice la barra de URL www.google.com, ¿cómo sabría un usuario que esta página no es en realidad la de Google? Ahí es donde entra la necesidad de una atribución adicional.
Para proporcionar la atribución adecuada del contenido, cada AMP Viewer debe dejar en claro a los usuarios de dónde proviene el contenido que están buscando. Y una forma de lograr esto es agregar una barra de encabezado que muestre el origen "verdadero" de una página.
¿Qué sigue?
Espero que las secciones anteriores aclaren por qué existen estas diferentes URL y por qué debe haber un encabezado en cada visor de AMP. Hemos escuchado cómo se siente acerca de este enfoque y la importancia de las URL. Entonces, ¿qué sigue?
Desde el lanzamiento de AMP en la Búsqueda de Google en febrero de 2016, se a seguido los siguientes pasos:
Todas las URL de Google (es decir, la URL caché de Google AMP y la dirección URL del visor Google AMP) reflejan la fuente original del contenido de la mejor manera posible: . www.google.com/amp/www.example.com/amp/doc.html
Cuando los usuarios se desplazan hacia abajo de la página para leer un documento, la barra de encabezado del visor de AMP se esconde, liberando el valioso espacio de la pantalla.
Cuando los usuarios visitan una URL de visor de Google AMP en una plataforma donde el visor no está disponible, se redirige a la página canónica del documento.
Comentarios
Disqus comments:
Facebook comments: