Hicimos que Shadow Reader sea más rápido y simple para los motores de búsqueda!

Creamos Shadow Reader para demostrar la forma en que se pueden usar las páginas AMP dentro de una app web progresiva (AWP) (lee nuestra publicación de anuncios para obtener más información). El sitio convierte los artículos existentes de The Guardian en una experiencia inmersiva de lectura de noticias. Es mucho más que una demostración; está pensado para ser un sitio completamente funcional. Contiene el código integral que se necesita para combinar de manera eficaz AMP y AWP, ¡y está listo para la producción!


SEO para contenido generado con JS


Como en cualquier aplicación respetable de una sola página, la carga útil de HTML inicial de Shadow Reader es pequeña. Es un shell de app delgado que se carga de manera rápida y ofrece al usuario algo para observar mientras JavaScript carga el contenido principal. Este enfoque ofrece una buena experiencia de usuario.

Desafortunadamente, también puede representar un desafío para los motores de búsqueda. Google intentará ejecutar JavaScript para indexar lo que se muestra al usuario en última instancia, no solo el HTML inicial. Sin embargo, muchos motores de búsqueda no lo hacen o lo hacen de manera poco confiable. En otros términos, no es seguro depender de un motor de búsqueda para ejecutar con éxito tu JavaScript. Y si un motor de búsqueda solo detecta un shell de la app, menos la mayoría o todo el contenido, no podrá indexar de modo apropiado la página.

¿No sería positivo que las páginas de artículos de Shadow Reader ofrecieran motores de búsqueda con texto incluido directamente en HTML?  ¿No sería genial si ese proceso no retardara la representación sino más bien nos brindara una alternativa para presentar esas páginas a los usuarios nuevos en menos de un segundo?

Resulta que podemos hacer ambas cosas presentando la versión de AMP de artículos a los usuarios nuevos.  Después de todo, un rastreador web aparece como un usuario nuevo para un servidor. ¿Cómo lo logramos?


AMP⇒AWP


Lo hicimos implementando un patrón AMP⇒AWP. Aquí te mostramos cómo funciona.

Para un usuario nuevo:
  • Cuando un usuario nuevo visita una página de artículos, presentamos la versión AMP del artículo.
  • La AMP usa <amp-install-serviceworker> para cargar e instalar el service worker.
  • El service worker carga y almacena en caché el shell de la app.
  • En la navegación de la página siguiente, el service worker tiene el control y dirige sutilmente al usuario a la AWP de esa página.

Para un usuario existente, simplemente presentamos la AWP.

Esta es la diferencia de tratamiento que nuestro sitio ofrece a los usuarios nuevos y existentes en la misma URL. Para los usuarios existentes, el service worker está instalado. Cuando el service worker detecta la URL de un artículo, presenta su versión almacenada en caché de la AWP.

¿Cómo se ejecuta esto en Shadow Reader?  Digamos que un usuario primero visita esta página de artículos:
https://amp.cards/theguardian/us/amazing_article

Al ver la URL de un artículo, el servidor muestra la versión AMP de este, pero esta instala un service worker cuando el artículo se carga. El service worker, que usa la biblioteca de Workbox, contiene esta línea:
workboxSW.router.registerNavigationRoute('index.html')

Esto significa que, cada vez que el usuario navega hasta una URL nueva en este dominio, el service worker detecta esta solicitud y en lugar de pasarla al servidor simplemente presenta su versión almacenada en caché de index.html. Es nuestra AWP.

Por ello, si el usuario hace clic en un vínculo a
https://amp.cards/theguardian/us/another_article

el service worker presenta el HTML de AWP en caché. ¡Pero la URL no se modifica!  De esta manera, cuando la AWP observa la URL para analizar el artículo que se solicita, detecta el vínculo que solicitó el usuario y puede cargar el artículo correcto en la AWP.

Posteriormente, cada vez que el usuario solicite un vínculo de Shadow Reader, el service worker estará instalado y presentará la AWP almacenada en caché.

Debido a que un rastreador web no nos permite instalar un service worker, siempre recibe el artículo AMP.



A continuación, se muestra ese flujo en un bonito diagrama:



Para un usuario nuevo:
  1. El navegador solicita la URL de un artículo desde el servidor. El servidor muestra una versión de AMP del artículo que incluye <amp-install-serviceworker>.
  2. JS del serviceworker de AMP hace que el navegador solicite el service worker. El servidor envía JS del service worker al navegador. El navegador instala el service worker y lo inicia.
  3. El service worker envía al servidor una solicitud para el shell de la app AWP. El servidor envía esos recursos al service worker, que los almacena en caché.

Para un usuario existente:
  1. El navegador envía una solicitud de una URL de artículo. Esta solicitud es interceptada por el service worker. El service worker muestra la AWP almacenada en caché al navegador.
  2. La AWP solicita el artículo de AMP. Esta solicitud alcanza el servidor, que muestra el artículo de AMP a la AWP. La AWP procesa y muestra ese artículo.

Recuerda que un rastreador web siempre es un usuario nuevo.


Lo que viene


Ahora que Shadow Reader tiene su propio servidor, tenemos algunas COSAS POR HACER:
  • En el futuro, podríamos renunciar a YQL usando simplemente el feed de RSS de Guardian de forma directa.
  • También debemos reemplazar los principales vínculos de navegación de Guardian por los vínculos de Shadow Reader.
  • Solicitamos al caché de AMP que descargue y ejecute por completo Shadow Reader en un iframe: <amp-install-serviceworker data-iframe-src=”https://amp.cards/index.html“>. Puede ser mejor para el usuario ocasional especificar una página más pequeña como alternativa.
  • Backend.js ahora se usa en el servidor al igual que el front end, y el modo en el que lo hacemos es un poco rústico. ¿Tal vez debamos refactorizar nuestro código para usar los módulos ECMAScript?

Prueba esto, consulta el código en github y trasmítenos tu opinión.  Queremos saber cómo estás probando los patrones AMP y AWP en tu propio sitio y nos encantaría conocer tus ideas para mejorar Shadow Reader.



Publicado por Ben Morss, representante de desarrolladores, Google

Shadow Reader mejorado