Miércoles, 9 de noviembre de 2016
Las apps web progresivas (AWP) aprovechan las nuevas tecnologías para ofrecer a los usuarios lo mejor de los sitios móviles y las aplicaciones nativas. Además, son una de las nuevas ideas más interesantes de la Web. Sin embargo, para tener un impacto real, es importante que se puedan indexar y vincular. Cada recomendación que se presenta en este artículo es una práctica recomendada existente para la indexabilidad, sin importar si compilas una app web progresiva o un sitio web estático simple. Sin embargo, recopilamos estas prácticas recomendadas para proporcionar una lista de tareas que te orienten:
Haz que tu contenido pueda rastrearse
¿Por qué? Históricamente, los sitios web siempre generaban o procesaban su código HTML en el servidor, que era la forma más sencilla de asegurarse de que tu contenido pudiera vincularse directamente. Las aplicaciones web popularizaron el concepto de renderización del cliente, en el que el contenido se actualiza de forma dinámica en la página mientras los usuarios navegan sin necesidad de que la página se vuelva a cargar.
El enfoque moderno es el de renderización híbrida, en el que la renderización del servidor se usa cuando un usuario navega directamente a una URL y la renderización del cliente se usa después de la carga inicial de la página para la navegación posterior y las solicitudes asíncronas.
Nuestra muestra de AWP del servidor demuestra una renderización pura del servidor, mientras que nuestra muestra de AWP híbrida muestra el enfoque combinado.
Si no conoces la terminología de renderización del servidor y del cliente, consulta estos artículos sobre renderización del cliente y del servidor, y renderización del servidor en React y node.js.
Prácticas recomendadas:
Usa la renderización híbrida o del servidor para que los usuarios reciban el contenido en la carga útil inicial de su solicitud web.
Asegúrate siempre de que puedas acceder a tus URLs de manera independiente:
https://www.example.com/product/25/
Lo anterior debe contener un vínculo directo a ese recurso en particular.
Si no puedes admitir la renderización híbrida o del servidor para tu app web progresiva y decides usar la renderización del cliente, te recomendamos usar la herramienta "Explorar como Google" de Google Search Console para verificar que tu contenido se renderice correctamente para nuestro rastreador de la Búsqueda.
No redirecciones a los usuarios que acceden a vínculos directos a la página principal de tu app web.
Además, se debe evitar mostrar una página de error a los usuarios en lugar de usar vínculos directos.
Proporciona URLs limpias
¿Por qué? Los identificadores de fragmentos (#user/24601/ o #!user/24601/) fueron una solución efectiva para que los navegadores usaran AJAX en contenido nuevo desde un servidor sin volver a cargar la página.
Este diseño se conoce como renderización del cliente.
Sin embargo, la sintaxis del identificador de fragmentos no es compatible con algunas herramientas web, frameworks y protocolos, como el protocolo Open Graph de Facebook.
La API de History nos permite actualizar la URL sin identificadores de fragmentos y, al mismo tiempo, recuperar recursos de forma asíncrona y evitar las recargas de páginas. Es lo mejor de ambos mundos. El esquema de rastreo AJAX (con sus URLs de #! o fragmentos de escape) tenía sentido en ese momento, pero ya no se recomienda.
Nuestras muestras de AWP híbridas y del cliente demuestran la API de History.
Prácticas recomendadas:
Proporciona URLs limpias sin identificadores de fragmentos (# o #!), como los siguientes:
https://www.example.com/product/25/
Si usas la renderización del cliente o híbrida, asegúrate de admitir la navegación en el navegador con la API de History.
Qué debes evitar:
No se recomienda utilizar la estructura de URL #! para generar URLs únicas:
https://www.example.com/#!product/25/
Se introdujo como una solución alternativa antes de la aparición de la API de History. Se considera un patrón independiente de la estructura de URL puramente #.
No se admite el uso de la estructura de URL # sin el símbolo ! adjunto:
https://www.example.com/#product/25/
Esta estructura de URL ya es un concepto en la Web y se relaciona con la vinculación directa a contenido de una página en particular.
Especifica URLs canónicas
¿Por qué? La mejor forma de eliminar la confusión para indexar cuando el mismo contenido está disponible en varias URLs (ya sean los mismos dominios o dominios diferentes) es marcar una página como la canónica y todas las demás páginas que dupliquen ese contenido como referencias a ella.
Prácticas recomendadas:
Incluye la siguiente etiqueta en todas las páginas que dupliquen un contenido en particular:
<link rel="canonical" href="https://www.example.com/your-url/" />
Si ofreces compatibilidad con Accelerated Mobile Pages, asegúrate también de usar de forma correcta su instrucción equivalente rel="amphtml".
Qué debes evitar:
Evita duplicar contenido intencionalmente en varias URLs y no uses el elemento de vínculo rel="canonical".
Por ejemplo, el elemento de vínculo rel="canonical" puede reducir la ambigüedad de las URLs con parámetros de seguimiento.
Evita crear referencias canónicas en conflicto entre tus páginas.
Diseño para múltiples dispositivos
¿Por qué? Es importante que todos los usuarios obtengan la mejor experiencia posible cuando vean tu sitio web, independientemente del dispositivo que usen.
Haz que tu sitio tenga un diseño responsivo. Las fuentes, los márgenes, los rellenos, los botones y el diseño general del sitio deben adaptarse de forma dinámica según las resoluciones de pantalla y los viewports de los dispositivos.
Las imágenes pequeñas ampliadas para computadoras de escritorio o tablets brindan una experiencia deficiente. En cambio, las imágenes de superalta resolución tardan mucho tiempo en descargarse en teléfonos celulares y pueden afectar el rendimiento del desplazamiento.
Obtén más información sobre la UX para AWP.
Prácticas recomendadas:
Usa el atributo srcset para recuperar imágenes de diferentes resoluciones para distintas densidades de pantalla y evitar que se descarguen imágenes más grandes que las que puede mostrar la pantalla del dispositivo.
Ajusta el tamaño de la fuente y la altura de la línea para asegurarte de que el texto sea legible, sin importar el tamaño del dispositivo. De manera similar, asegúrate de que el relleno y los márgenes de los elementos también se escalen de manera razonable.
Prueba varias resoluciones de pantalla con la función Modo de dispositivo de la herramienta para desarrolladores de Chrome y la Herramienta para evaluar optimización para dispositivos móviles.
No muestres a los usuarios contenido diferente del que muestras a Google. Si usas redireccionamientos o la detección de usuarios-agentes (también llamados reconocimiento 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 recupera Google coincida con el que ve un usuario.
Por motivos de usabilidad, evita utilizar fuentes de tamaño fijo.
Desarrolla de forma iterativa
¿Por qué? Una de las rutas más seguras que se deben tomar cuando se agregan funciones a una aplicación web es realizar cambios de manera iterativa. Si agregas funciones de a una, puedes observar el impacto de cada cambio individual.
Como alternativa, muchos desarrolladores prefieren ver su aplicación web progresiva como una oportunidad para renovar su sitio móvil de una sola vez: desarrollar la app web nueva en un entorno aislado y, luego, intercambiarla con su sitio móvil existente una vez que esté listo.
Cuando desarrolles funciones de forma iterativa, trata de dividir los cambios en partes separadas. Por ejemplo, si deseas pasar de la renderización del servidor a la híbrida, aborda ese cambio como una sola iteración, en lugar de combinarlo con otras funciones.
Ambos enfoques tienen sus propias ventajas y desventajas. La iteración reduce la complejidad de trabajar con la indexabilidad de la búsqueda, ya que la transición es continua. Sin embargo, puede generar un proceso de desarrollo más lento y, tal vez, una renovación menos innovadora si el desarrollo no comienza desde cero.
En cualquier caso, las áreas más sensibles que debes tener en cuenta son las URLs canónicas y la configuración de robots.txt de tu sitio.
Prácticas recomendadas:
Itera en tu sitio web de forma incremental agregando nuevas funciones de a una por vez.
Por ejemplo, si aún no admite HTTPS, comienza por migrar a un sitio seguro.
Qué debes evitar:
Si desarrollaste tu app web progresiva en un entorno aislado, evita iniciarla sin verificar que los vínculos rel-canonical y el archivo robots.txt estén configurados correctamente.
Asegúrate de que los vínculos rel-canonical dirijan al sitio real y que la configuración de robots.txt permita que los rastreadores rastreen el sitio nuevo.
Es lógico evitar que los rastreadores indexen tu sitio en desarrollo antes del lanzamiento, pero no olvides desbloquearlos cuando accedan al sitio nuevo cuando lo lances.
Usa la mejora progresiva
¿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.
Una práctica no recomendada común era habilitar o inhabilitar funciones probando qué navegador tenía el usuario. Sin embargo, debido a que los navegadores evolucionan todo el tiempo con las funciones, no se recomienda esta técnica.
El service worker es una tecnología relativamente nueva. Es importante no romper la compatibilidad con el fin de progresar. Es un ejemplo perfecto de cuándo usar la mejora progresiva.
Prácticas recomendadas:
Antes de registrar un service worker, comprueba la disponibilidad de su API:
if ('serviceWorker' in navigator) {
...
Úsalo por método de detección de API para todas las funciones de tu sitio web.
Nunca uses el usuario-agente del navegador para habilitar o inhabilitar funciones en tu app web. Siempre comprueba si la API de la función está disponible y, si no lo está, realiza una degradación elegante.
Evita actualizar o lanzar tu sitio sin hacer pruebas en varios navegadores. Consulta las estadísticas del sitio para saber qué navegadores son los más populares en la base de usuarios.
Realiza pruebas con Search Console
¿Por qué? Es importante comprender cómo la Búsqueda de Google ve el contenido de tu sitio. Puedes usar Search Console para recuperar URLs individuales de tu sitio y consultar cómo las ve la Búsqueda de Google con la opción "Rastreo > Explorar como Google". Search Console procesará el código JavaScript y renderizará la página cuando se seleccione esa opción. De lo contrario, solo se mostrará la respuesta HTML sin procesar.
Google Search Console también analiza el contenido de tu página de varias maneras, lo que incluye detectar la presencia de datos estructurados, tarjetas enriquecidas, vínculos a sitios y Accelerated Mobile Pages.
Prácticas recomendadas:
Supervisa tu sitio con Search Console y explora sus funciones, incluida Explorar como Google.
Proporciona un mapa del sitio a través de Rastreo > Mapas de sitios de Search Console. Puede ser una manera eficaz de garantizar que la Búsqueda de Google conozca todas las páginas de tu sitio.
Haz anotaciones con datos estructurados de Schema.org
¿Por qué? Los datos estructurados de Schema.org constituyen un vocabulario flexible que resume las partes más importantes de la página como datos que se pueden procesar de forma automática. Esto puede ser tan general como decir simplemente que una página es un NewsArticle o tan específico como detallar la ubicación, el nombre de la banda, el lugar y el proveedor de entradas de la banda de la gira, o resumir los ingredientes y pasos de una receta.
Es posible que el uso de estos metadatos no tenga sentido para todas las páginas de tu aplicación web, pero se recomienda cuando sea razonable. Google los extrae después de que se renderiza la página.
Hay una variedad de tipos de datos, incluidos NewsArticle, Recipe y Product, entre otros. También puedes explorar todos los tipos de datos compatibles aquí.
Prácticas recomendadas:
Verifica que tus metadatos de Schema.org sean correctos con la Herramienta de prueba de datos estructurados de Google.
Verifica que los datos que proporcionaste aparezcan y que no haya errores.
Evita usar un tipo de datos que no coincida con el contenido real de tu página. Por ejemplo, no uses
Recipe para una camiseta que vendes; utiliza Product.
Haz anotaciones con tarjetas de Open Graph y Twitter
¿Por qué? Además de los metadatos de Schema.org, puede ser útil agregar compatibilidad con el protocolo Open Graph de Facebook y las tarjetas enriquecidas de Twitter.
Estos formatos de metadatos mejoran la experiencia del usuario cuando tu contenido se comparte en sus redes sociales correspondientes.
Si tu sitio o aplicación web existente utiliza estos formatos, es importante que te asegures de que se incluyan en tu aplicación web progresiva para lograr una viralidad óptima.
Prácticas recomendadas:
Prueba el lenguaje de marcado 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.
Realiza pruebas con varios navegadores
¿Por qué? Desde la perspectiva del usuario, es importante que el sitio web se comporte de la misma manera en todos los navegadores. Si bien la experiencia puede adaptarse para diferentes tamaños de pantalla, todos esperamos que un sitio móvil funcione de la misma manera en dispositivos de tamaños similares, ya sea un iPhone o un teléfono celular Android.
Si bien se puede percibir que la Web está fragmentada debido a la cantidad de navegadores que se usan en todo el mundo, esta variedad y competencia forman parte de lo que hace que la Web sea una plataforma tan innovadora. Afortunadamente, los estándares web nunca fueron tan evolucionados como ahora, y las herramientas modernas permiten a los desarrolladores crear sitios web enriquecidos y compatibles con varios navegadores con confianza.
Prácticas recomendadas:
Usa herramientas de prueba entre navegadores, como BrowserStack.com, Browserling.com o BrowserShots.org para asegurarte de que tu AWP sea compatible con todos los navegadores.
Mide el rendimiento de carga de la página
¿Por qué? Cuanto más rápido cargue un sitio web para un usuario, mejor será su experiencia. La optimización para mejorar la velocidad de las páginas ya es un enfoque muy conocido en el desarrollo web, pero, a veces, cuando se desarrolla una versión nueva de un sitio, las optimizaciones necesarias no se consideran una prioridad alta.
Cuando desarrolles una aplicación web progresiva, te recomendamos que midas el rendimiento de la velocidad de carga de la página y que realices optimizaciones antes de lanzar el sitio para obtener los mejores resultados.
Prácticas recomendadas:
Usa herramientas como PageSpeed Insights y Web Page Test para medir el rendimiento de carga de la página de tu sitio. Si bien Googlebot tiene un poco más de paciencia en la renderización, la investigación demostró que el 40% de los consumidores abandonará una página que tarde más de tres segundos en cargarse.
Obtén más información sobre nuestras recomendaciones de rendimiento para las páginas web y la ruta de renderización crítica aquí.
Evita dejar la optimización como un paso posterior al lanzamiento. Si el contenido de tu sitio web se carga rápidamente antes de migrar a una nueva aplicación web progresiva, es importante no revertir tus optimizaciones.
Esperamos que la lista de tareas anterior sea útil y proporcione la guía adecuada para ayudarte a desarrollar tus aplicaciones web progresivas con la indexabilidad en mente.
Cuando comiences, asegúrate de consultar las muestras de indexabilidad de apps web progresivas que demuestran la renderización híbrida, del servidor y del cliente. Como siempre, si tienes alguna pregunta, comunícate con nosotros en los Foros para webmasters.