Miércoles, 9 de noviembre del 2016
Las aplicaciones web progresivas (PWAs) aprovechan las nuevas tecnologías para ofrecer a los usuarios lo mejor de los sitios web móviles y las aplicaciones nativas, y son una de las ideas más prometedoras en la Web. Sin embargo, para que tengan un impacto real, es importante que estas aplicaciones puedan indexarse y enlazarse. Todas las recomendaciones que se ofrecen en este artículo son prácticas recomendadas de indexaibilidad, independientemente de si compilas una aplicación web progresiva o un sitio web estático sencillo. No obstante, hemos reunido estas prácticas recomendadas para ofrecerte una lista de comprobación que te sirva de guía:
Permitir el rastreo del contenido
¿Por qué? Desde siempre, los sitios web han generado y renderizado el HTML en el servidor, ya que es la forma más simple de que el contenido pueda enlazarse directamente. Las aplicaciones web han popularizado el concepto del renderizado por parte del cliente, donde el contenido se actualiza de forma dinámica en la página a medida que el usuario navega por ella, sin necesidad de volver a cargarla.
El método actual consiste en el renderizado híbrido: el servidor renderiza el contenido cuando el usuario accede a la URL correspondiente de forma directa, pero es el cliente el que lo renderiza una vez cargada la página para gestionar la navegación y las solicitudes asíncronas tras la carga.
Nuestro ejemplo de PWA de servidor demuestra cómo se realiza el renderizado únicamente por parte del servidor. En cambio, nuestro ejemplo de PWA híbrida demuestra este método combinado.
Si no conoces bien la terminología relacionada con el renderizado del servidor y de cliente, consulta estos artículos sobre el renderizado de servidor y de cliente y el renderizado de servidor en React y Node.js.
Prácticas recomendadas
Utiliza el renderizado de servidor o híbrido para que los usuarios reciban el contenido en la carga útil inicial de su solicitud web.
Permite siempre que se pueda acceder a tus URL de forma independiente usando direcciones URL como la siguiente:
https://www.example.com/product/25/
El enlace anterior es un enlace profundo que dirige al usuario al recurso en cuestión.
Si tu aplicación web progresiva no admite el renderizado híbrido o de servidor y decides usar el renderizado de cliente, te recomendamos que utilices la herramienta "Explorar como Google" de Google Search Console para verificar que tu contenido se procesa correctamente para nuestro rastreador de la Búsqueda.
No redirijas a los usuarios que acceden a tu aplicación web mediante enlaces profundos de vuelta a la página principal de tu aplicación web.
Tampoco muestres una página con un mensaje de error a tus usuarios en lugar de dirigirlos a una página específica.
Proporcionar URL simples
¿Por qué? El uso de identificadores de fragmento (#user/24601/ o #!user/24601/) era una solución eficaz que permitía a los navegadores usar AJAX en contenido nuevo procedente de un servidor sin volver a cargar la página.
Este tipo de diseño se basa en el procesamiento de cliente.
Sin embargo, la sintaxis de los identificadores de fragmento no es compatible con algunas herramientas, frameworks y protocolos de la Web, como el protocolo Open Graph de Facebook.
La API History permite actualizar la URL sin usar identificadores de fragmento y, al mismo tiempo, obtener los recursos de forma asíncrona, lo que evita que la página se cargue de nuevo. Antes, era lógico utilizar el esquema de rastreo AJAX (con sus URLs de #! o fragmentos de escape), pero ya no se recomienda.
Nuestros ejemplos de PWA híbrida y PWA de cliente demuestran cómo funciona la API History.
Prácticas recomendadas
Proporciona URLs claras sin identificadores de fragmento (# o #!), como:
https://www.example.com/product/25/
Si usas el procesamiento de cliente o el híbrido, permite la navegación con la API History.
Qué debes evitar:
Evita la estructura de URL #! con URLs únicas, como en este ejemplo:
https://www.example.com/#!product/25/
Era la solución ideal antes de que existiera la API History. Se considera un patrón independiente con respecto a la estructura de URL # única.
No uses la estructura de URL # sin el signo !, como en el caso siguiente, que es incompatible:
https://www.example.com/#producto/25/
Esta estructura de URL ya se usa en la Web con enlaces profundos que dirigen a contenido en una página específica.
Especificar URL canónicas
¿Por qué? El mejor modo de evitar confusiones a la hora de indexar contenido disponible en varias URLs (dentro del mismo dominio o fuera de este) es marcar una página como canónica y que todas las demás páginas que dupliquen el contenido hagan referencia a ella.
Prácticas recomendadas
Incluye la siguiente etiqueta en todas las páginas con el mismo fragmento de contenido:
<link rel="canonical" href="https://www.example.com/your-url/" />
Si admites Accelerated Mobile Pages, utiliza también la instrucción equivalente rel="amphtml".
Qué debes evitar:
Evita duplicar contenido a propósito en varias URLs sin utilizar el elemento de enlace rel="canonical".
Por ejemplo, el elemento de enlace rel="canonical" puede reducir la ambigüedad entre URLs con parámetros de seguimiento.
No crees referencias canónicas conflictivas entre tus páginas.
Diseñar para varios dispositivos
¿Por qué? Es importante que todos los usuarios obtengan la mejor experiencia posible cuando visiten tu sitio web, independientemente del dispositivo que utilicen.
Crea sitios con diseño adaptable. Es decir, las fuentes, los márgenes, los rellenos, los botones y el diseño del sitio en general deberían adaptar su tamaño de forma dinámica en función de la resolución de la pantalla y del viewport del dispositivo.
Las imágenes pequeñas que se agrandan para mostrarse en ordenadores o en tablets empeoran la experiencia de usuario, así como las imágenes con una resolución muy alta, ya que tardan mucho en cargarse en teléfonos móviles y pueden afectar al rendimiento del desplazamiento en estos dispositivos.
Más información sobre la experiencia de usuario para PWAs
Prácticas recomendadas
Usa el atributo srcset para obtener imágenes de distintas resoluciones para diferentes densidades de pantalla y evitar que se descarguen imágenes más grandes de las que puede mostrar la pantalla del dispositivo.
Ajusta el tamaño de la fuente y el alto de línea para asegurarte de que el texto se pueda leer sin importar el tamaño del dispositivo. Del mismo modo, asegúrate de que el espacio de relleno y los márgenes de los elementos también se ajusten de forma razonable.
Prueba varias resoluciones de pantalla con el modo Dispositivo de la herramienta para desarrolladores de Chrome y con la herramienta de prueba de optimización para móviles.
No muestres a los usuarios contenido diferente del que muestras a Google. Si usas redirecciones o la detección de user-agents (también llamados "sniffing de navegadores" o "publicación dinámica") para modificar el diseño de tu sitio en diferentes dispositivos, es importante que el contenido siga siendo el mismo.
Usa la herramienta "Explorar como Google" de Search Console para verificar que el contenido que obtiene Google coincide con el que ven los usuarios.
Por motivos de usabilidad, evita usar fuentes de tamaño fijo.
Desarrollar de forma iterativa
¿Por qué? Una de las formas más seguras de añadir funciones a una aplicación web es aplicar cambios de forma iterativa. Si añades funciones de una en una, puedes ver el impacto de cada cambio.
Del mismo modo, muchos desarrolladores consideran su aplicación web progresiva como una oportunidad de reformar su sitio web móvil en un solo paso. Es decir, desarrollan la nueva aplicación web en un entorno independiente y, cuando esté lista, sustituyen el sitio web por la aplicación.
Cuando desarrolles funciones de forma iterativa, trata de dividir los cambios en distintos pasos. Por ejemplo, si quieres cambiar del renderizado de servidor al híbrido, considera este cambio como una sola iteración, sin añadir otras funciones.
Este planteamiento tiene sus pros y sus contras. La iteración reduce la complejidad que conlleva la indexabilidad, ya que la transición es continua. Sin embargo, este método puede hacer que el desarrollo sea más lento, y la actualización menos innovadora, ya que no se empieza desde el principio.
En cualquier caso, los dos aspectos más importantes que deberías tener en cuenta son tus URLs canónicas y la configuración del archivo robots.txt de tu sitio.
Prácticas recomendadas
Añade funciones en tu sitio web mediante iteraciones, poco a poco.
Por ejemplo, si tu sitio aún no es compatible con HTTPS, empieza migrando a un sitio seguro.
Qué debes evitar:
Si has desarrollado tu aplicación web progresiva en un entorno independiente, evita ejecutarla sin comprobar que los enlaces rel-canonical y el archivo robots.txt se han configurado correctamente.
Comprueba que los enlaces rel-canonical dirijan al sitio real y que la configuración del archivo robots.txt permita a los rastreadores rastrear el sitio nuevo.
Es lógico impedir que los rastreadores indexen tu sitio en desarrollo antes de su lanzamiento, pero no olvides habilitar el rastreo cuando lo publiques.
Aplicar mejoras progresivas
¿Por qué? Siempre que sea posible, es importante detectar las funciones del navegador antes de usarlas. La detección de funciones también es mejor que probar los navegadores que crees que admiten una función determinada.
Antes era habitual habilitar o inhabilitar funciones según el navegador que tenía el usuario. Sin embargo, dado que las funciones de los navegadores cambian continuamente, se desaconseja esta práctica.
Service worker es una tecnología relativamente nueva, y es importante no sacrificar la compatibilidad por progreso, ya que es un ejemplo perfecto de cuándo usar la mejora progresiva.
Prácticas recomendadas
Antes de registrarte con Service Worker, comprueba que su API esté disponible.
if ('serviceWorker' in navigator) {
...
Usa un método de detección de APIs para todas las funciones de tu sitio web.
No utilices nunca el user-agent del navegador para habilitar o inhabilitar funciones en tu aplicación web. Comprueba siempre que la API de la función esté disponible y cambia a una versión inferior si no está disponible.
Evita actualizar o publicar tu sitio web sin probarlo en varios navegadores. Comprueba los análisis del sitio para saber qué navegadores son los más utilizados por tus usuarios.
Hacer pruebas en Search Console
¿Por qué? Es importante conocer cómo aparece el contenido de tu sitio en la Búsqueda de Google. Puedes usar Search Console para obtener URLs concretas de tu sitio y ver cómo aparecen en la Búsqueda de Google con la función "Rastreo > Explorar como Google". Search Console procesará tu JavaScript y mostrará la página si se ha seleccionado esa opción. De lo contrario, solo se mostrará el HTML sin procesar.
Google Search Console también analiza el contenido de tu página de varias formas; por ejemplo, detectando la presencia de datos estructurados, tarjetas enriquecidas, enlaces de sitio y páginas de Accelerated Mobile Pages.
Prácticas recomendadas
Supervisa tu sitio con Search Console y consulta las distintas funciones, como Explorar como Google.
Proporciona un sitemap a través de Search Console con la opción Rastreo > Sitemaps. Puede ser una forma eficaz de que la Búsqueda de Google detecte todas las páginas de tu sitio.
Añadir anotaciones con los datos estructurados de Schema.org
¿Por qué? Los datos estructurados de Schema.org proporcionan un vocabulario flexible que resume las secciones más importantes de tu página como datos que pueden procesarse automáticamente. Puede ofrecer información general indicando, por ejemplo, que una página determinada es un NewsArticle. También puede ofrecer información detallada, como el nombre de un grupo musical, en qué lugar y en qué sala toca y quién vende las entradas; o bien puede resumir los ingredientes de una receta y los distintos pasos para su elaboración.
Es posible que no sea lógico usar estos metadatos en cada página de tu aplicación web, pero se recomienda usarlos en los casos en que sea útil. Google los extraerá después de renderizar la página.
Hay varios tipos de datos, como NewsArticle, Recipe y Product, por nombrar algunos. También puedes consultar todos los tipos de datos admitidos.
Prácticas recomendadas
Comprueba que los metadatos de Schema.org sean correctos con la Herramienta de prueba de datos estructurados de Google.
Comprueba que los datos facilitados se muestren y que no haya errores.
Evita utilizar tipos de datos que no encajen con el contenido real de la página. Por ejemplo, no uses Recipe si vendes camisetas. En vez de eso, utiliza Product.
Añadir anotaciones con Open Graph y tarjetas de Twitter
¿Por qué? Además de usar metadatos de Schema.org, puede ser útil permitir el uso del protocolo Open Graph de Facebook y de las tarjetas enriquecidas de Twitter.
Estos formatos de metadatos mejoran la experiencia de usuario cuando se comparte tu contenido en las redes sociales correspondientes.
Si el sitio o la aplicación web actual utilizan estos formatos, es importante incluirlos en la aplicación web progresiva, lo que a su vez les otorgará una viralidad óptima.
Prácticas recomendadas
Prueba las etiquetas de Open Graph con la herramienta de depuración de objetos de Facebook.
Familiarízate con el formato de metadatos de Twitter.
No olvides incluir estos formatos si tu sitio actual los admite.
Hacer pruebas con varios navegadores
¿Por qué? Desde el punto de vista del usuario, es importante que un sitio web se comporte del mismo modo en todos los navegadores. Si bien puede adaptarse a distintos tamaños de pantalla, se espera que un sitio web móvil funcione del mismo modo en dispositivos con tamaños similares, ya sea un teléfono iPhone o un Android.
Aunque la Web parezca estar fragmentada dada la gran cantidad de navegadores que se usan en todo el mundo, esta variedad y competición forman parte de lo que hace que sea una plataforma tan innovadora. Los estándares web nunca se han aplicado de forma tan eficaz como hoy en día, y las herramientas actuales permiten a los desarrolladores crear sitios web con muchas funciones compatibles con varios navegadores.
Prácticas recomendadas
Usa herramientas de prueba en distintos navegadores, como BrowserStack.com, Browserling.com o BrowserShots.org para asegurarte de que tu PWA es compatible con varios navegadores.
Medir el tiempo de carga de las páginas
¿Por qué? Cuanto más rápido se cargue un sitio web, mejor será la experiencia de usuario. Es bastante frecuente optimizar la velocidad de carga de las páginas, pero cuando se desarrolla una nueva versión de un sitio, esta optimización no es prioritaria.
Al desarrollar una aplicación web progresiva, recomendamos medir el tiempo de carga de las páginas y optimizar la velocidad antes de publicar un sitio.
Prácticas recomendadas
Usa herramientas como PageSpeed Insights y Web Page Test para medir el rendimiento de carga de las páginas de tu sitio. Aunque el robot de Google tiene algo más de paciencia a la hora de renderizar las páginas, los estudios han demostrado que el 40 % de los consumidores abandonan las páginas que tardan más de tres segundos en cargarse.
Procura no dejar la optimización para después del lanzamiento de una aplicación web. Si antes de la migración a la aplicación web progresiva, el contenido del sitio web ya se carga rápido, es importante no revertir las optimizaciones.
Esperamos que esta lista te resulte útil y que te sirva de guía para desarrollar tus aplicaciones web progresivas teniendo en cuenta la indexabilidad.
Cuando empieces, consulta nuestros ejemplos de indexabilidad de aplicaciones web progresivas, que demuestran el renderizado de cliente y el de servidor, así como el híbrido. Como siempre, si tienes alguna duda, visita nuestros foros para webmasters.