Miércoles, 9 de noviembre de 2016
Progressive Web Apps
(PWA) aprovechan las nuevas tecnologías para ofrecer a los usuarios lo mejor de los sitios móviles y las aplicaciones nativas, y son una de las ideas más interesantes de la web. Pero para que realmente tengan impacto, es importante que sean indexables y enlazables. Cada recomendación presentada en este artículo es una práctica recomendada existente para la indexabilidad, independientemente de si está creando una Progressive Web App o un sitio web estático simple. No obstante, hemos recopilado estas prácticas recomendadas para proporcionar una lista de verificación que le sirva de guía:
Haga que su contenido sea rastreable
¿Por qué? Históricamente, los sitios web siempre generaban o renderizaban su HTML en el servidor, que es la forma más sencilla de garantizar que su contenido sea directamente enlazable. Las aplicaciones web popularizaron el concepto de renderizado del lado del cliente, en el que el contenido se actualiza dinámicamente en la página a medida que el usuario navega sin necesidad de recargar la página.
El enfoque moderno es el renderizado híbrido, en el que se utiliza el renderizado del lado del servidor cuando un usuario navega directamente a una URL y el renderizado del lado del cliente se utiliza después de la carga inicial de la página para la navegación posterior y las solicitudes asíncronas.
Nuestra
muestra de PWA del lado del servidor
demuestra el renderizado puro del lado del servidor, mientras que nuestra
muestra de PWA híbrida
demuestra el enfoque combinado.
Si no está familiarizado con la terminología de renderizado del lado del servidor y del lado del cliente ,
consulte estos artículos sobrerenderizado del lado del cliente y del servidor
, y
renderizado del lado del servidor en react y node.js.
Prácticas recomendadas:
Utilice renderizado del lado del servidor o híbrido para que los usuarios reciban el contenido en la carga inicial de su solicitud web.
Asegúrese siempre de que sus URL sean accesibles de forma independiente:
Lo anterior debería enlazar profundamente a ese recurso en particular.
Si no puede admitir el renderizado del lado del servidor o híbrido para su Progressive Web App y decide utilizar el renderizado del lado del cliente, le recomendamos utilizar la herramienta “Explorar como Google” de Google Search Console para verificar que su contenido se renderice correctamente para nuestro rastreador de búsqueda.
No redirija a los usuarios que acceden a enlaces profundos a la página de inicio de su aplicación web.
Además, también debe evitarse mostrar una página de error a los usuarios en lugar de un enlace profundo.
Proporcione URL limpias ¿Por qué?Los identificadores de fragmento ( #user/24601/ o#!user/24601/
) eran una solución eficaz para que los navegadores obtuvieran nuevo contenido de un servidor mediante AJAX sin recargar la página. Este diseño se conoce como renderizado del lado del cliente. Sin embargo, la sintaxis del identificador de fragmento no es compatible con algunas herramientas, marcos y protocolos web, como.
el protocolo Open Graph de Facebook La History API #! nos permite actualizar la URL sin identificadores de fragmento mientras seguimos obteniendo recursos de forma asíncrona y, por lo tanto, evitando recargas de página: es lo mejor de ambos mundos. El esquema de rastreo AJAX
(con sus #! URL de fragmento escapado) tenía sentido en su momento, pero ya no se recomienda.
Nuestras
muestras de PWA híbrida y PWA del lado del cliente
demuestran la History API.# Prácticas recomendadas: #!Proporcione URL limpias sin identificadores de fragmento (
o
) como:
Si utiliza renderizado del lado del cliente o híbrido, asegúrese de admitir la navegación del navegador con la History API. #! Evite:
Se desaconseja el uso de la # estructura de URL para dirigir URL únicas:
Se introdujo como una solución antes de la llegada de la History API. Se considera un patrón # separado de la estructura de URL pura. ! 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 el enlace profundo a contenido en una página en particular. Especifique URL canónicas
¿Por qué?
La mejor manera de eliminar la confusión para la indexación cuando el mismo contenido está disponible bajo múltiples URL (ya sean dominios iguales o diferentes) es marcar una página como canónica y hacer que todas las demás páginas que duplican ese contenido hagan referencia a ella.
Prácticas recomendadas:
Incluya la siguiente etiqueta en todas las páginas que reflejen una pieza de contenido en particular: Si admite Accelerated Mobile Pages, asegúrese de utilizar también correctamente su contraparte
rel=”amphtml”
instrucción.
Evite: Evite duplicar contenido intencionalmente en múltiples URL y no utilizar el
rel=”canonical” elemento de enlace. Por ejemplo, el
rel=”canonical”
elemento de enlace puede reducir la ambigüedad para URL con parámetros de seguimiento.
Evite crear referencias canónicas conflictivas entre sus páginas. Diseñe para múltiples dispositivos
¿Por qué?
Es importante que todos sus usuarios obtengan la mejor experiencia posible al ver su sitio web, independientemente de su dispositivo. Haga que su sitio sea
—las fuentes, los márgenes, los rellenos, los botones y el diseño general de su sitio deben escalarse dinámicamente según las resoluciones de pantalla y los viewports de los dispositivos.
Las imágenes pequeñas escaladas para dispositivos de escritorio o tabletas ofrecen una mala experiencia. Por el contrario, las imágenes de resolución súper alta tardan mucho en descargarse en los teléfonos móviles y pueden afectar el rendimiento del desplazamiento móvil.
Leer más sobre
UX para PWA.
Mejores prácticas:
Use el
atributo srcset
para obtener imágenes de diferente resolución para pantallas de diferente densidad y evitar descargar imágenes más grandes de lo que la pantalla del dispositivo es capaz de mostrar.
Escale el tamaño de su fuente y la altura de línea para asegurarse de que su texto sea legible sin importar el tamaño del dispositivo. De manera similar, asegúrese de que el relleno y los márgenes de los elementos también se escalen de manera sensata.
Pruebe
varias resoluciones de pantalla
usando la
función de modo de dispositivo de las herramientas para desarrolladores de Chrome
y la
herramienta de prueba de optimización para móviles.
No muestre contenido diferente a los usuarios del que muestra a Google. Si utiliza
redirecciones o detección de agente de usuario
(también conocido como rastreo de navegador o
servicio dinámico) para alterar el diseño de su sitio para diferentes dispositivos, es importante que el contenido en sí siga siendo el mismo.
Utilice la herramienta “Explorar como Google” de Search Console para verificar que el contenido obtenido por Google coincida con el contenido que ve un usuario.
Por razones de usabilidad, evite el uso de fuentes de tamaño fijo.
Desarrolle de forma iterativa
¿Por qué? Uno de los caminos más seguros a seguir al agregar funciones a una aplicación web es realizar cambios de forma iterativa. Si agrega funciones una a la vez, puede observar el impacto de cada cambio individual.
Alternativamente, muchos desarrolladores prefieren ver su aplicación web progresiva como una oportunidad para renovar su sitio móvil de una sola vez: desarrollando la nueva aplicación web en un entorno aislado y cambiándola por su sitio móvil existente una vez que esté lista.
Al desarrollar funciones de forma iterativa, intente dividir los cambios en partes separadas. Por ejemplo, si tiene la intención de pasar de la renderización del lado del servidor a la renderización híbrida, abórdelo como una sola iteración, en lugar de combinarlo con otras funciones.
Ambos enfoques tienen sus pros y sus contras. La iteración reduce la complejidad de lidiar con la indexabilidad de búsqueda, ya que la transición es continua. Sin embargo, la iteración podría resultar en un proceso de desarrollo más lento y potencialmente en una renovación menos innovadora si el desarrollo no comienza desde cero.
En cualquier caso, las áreas más sensibles a vigilar son sus URL canónicas y la configuración robots.txt de su sitio.
Mejores prácticas:
Itere en su sitio web de forma incremental agregando nuevas funciones pieza por pieza.
Por ejemplo, si aún no admite HTTPS, comience migrando a un sitio seguro.
Evite:
Si ha desarrollado su aplicación web progresiva en un entorno aislado, evite lanzarla sin verificar que los enlaces rel-canonical y robots.txt estén configurados correctamente.
Asegúrese de que sus enlaces rel-canonical apunten al sitio real y que su configuración robots.txt permita a los rastreadores rastrear su nuevo sitio.
Es lógico evitar que los rastreadores indexen su sitio en desarrollo antes del lanzamiento, pero no olvide desbloquear el acceso de los rastreadores a su nuevo sitio cuando lo lance.
Utilice 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 cree que admiten una función determinada.
Una mala práctica común en el pasado era habilitar o deshabilitar funciones probando qué navegador tenía el usuario. Sin embargo, como los navegadores evolucionan constantemente con funciones, esta técnica no se recomienda en absoluto.
Service Worker es una tecnología relativamente nueva y es importante no romper la compatibilidad en la búsqueda del progreso: es un ejemplo perfecto de cuándo usar la mejora progresiva.
Mejores prácticas:
Antes de registrar un Service Worker, verifique la disponibilidad de su API:
Utilice el método de detección por API para todas las funciones de su sitio web.
Nunca utilice el agente de usuario del navegador para habilitar o deshabilitar funciones en su aplicación web. Siempre verifique si la API de la función está disponible y degrádela con elegancia si no está disponible.
¡Evite actualizar o lanzar su sitio sin probarlo en varios navegadores! Consulte los análisis de su sitio para saber qué navegadores son los más populares entre su base de usuarios.
Pruebe con Search Console
¿Por qué? Es importante comprender cómo ve la Búsqueda de Google el contenido de su sitio. Puede usar
Search Console para
obtener URL individuales de su sitio
y ver cómo las ve la Búsqueda de Google usando la función “Rastreo > Explorar como Google”. Search Console procesará su JavaScript y renderizará la página cuando se seleccione esa opción; de lo contrario, solo se muestra la respuesta HTML sin procesar.
Google Search Console también analiza el contenido de su página de diversas formas, incluida la detección de la presencia de datos estructurados, tarjetas enriquecidas, enlaces de sitio y páginas móviles aceleradas.
Mejores prácticas:
Supervise su sitio usando Search Console y explore sus funciones, incluida la de Explorar como Google.
Proporcione un mapa del sitio a través de Search Console Rastrear > Mapas del sitio. Puede ser una forma eficaz de garantizar que la Búsqueda de Google conozca todas las páginas de su sitio.
Anotar con datos estructurados de Schema.org
¿Por qué? Schema.org los datos estructurados son un vocabulario flexible para resumir las partes más importantes de su página como datos procesables por máquina. Esto puede ser tan general como simplemente decir que una página es un NewsArticleo tan específico como detallar la ubicación, el nombre de la banda, el lugar y el proveedor de boletos para una banda de gira, o resumir los ingredientes y los pasos para una receta.
El uso de estos metadatos puede no tener sentido para todas las páginas de su aplicación web, pero se recomienda donde sea sensato. Google los extrae después de que la página se renderiza.
Hay una variedad de tipos de datos, incluidos NewsArticle, Recipey
Product por nombrar algunos. También puede explorar todos los
tipos de datos admitidos aquí.
Mejores prácticas:
Verifique que sus metadatos de Schema.org sean correctos usando la
Herramienta de prueba de datos estructurados.
de Google. Compruebe que los datos que proporcionó aparecen y que no hay errores presentes. Evite usar un tipo de datos que no coincida con el contenido real de su página. Por ejemplo, no use
fr
Receta para una camiseta que estás vendiendo—usa Producto en su lugar.
Anota con Open Graph y Twitter Cards
¿Por qué? Además de los metadatos de Schema.org, puede ser útil añadir soporte para el protocolo Open Graph de Facebook y las Twitter rich cards también.
Estos formatos de metadatos mejoran la experiencia del usuario cuando tu contenido se comparte en sus redes sociales correspondientes.
Si tu sitio web o aplicación web existente utiliza estos formatos, es importante asegurarse de que también se incluyan en tu progressive web application para una viralidad óptima.
Mejores prácticas:
Prueba tu marcado Open Graph con la
Facebook Object Debugger Tool.
Familiarízate con
el formato de metadatos de Twitter.
No olvides incluir estos formatos si tu sitio existente los admite.
Prueba con varios navegadores
¿Por qué? Claramente, desde la perspectiva del usuario, es importante que un sitio web se comporte igual en todos los navegadores. Si bien la experiencia puede adaptarse a diferentes tamaños de pantalla, todos esperamos que un sitio móvil funcione igual en dispositivos de tamaño similar, ya sea un iPhone o un teléfono móvil Android.
Aunque la web puede percibirse como fragmentada debido a la cantidad de navegadores en uso en todo el mundo, esta variedad y competencia es parte de lo que hace de la web una plataforma tan innovadora. Afortunadamente, los estándares web nunca han sido tan maduros como ahora y las herramientas modernas permiten a los desarrolladores crear sitios web ricos y compatibles con varios navegadores con confianza.
Mejores prácticas:
Utiliza herramientas de prueba entre navegadores como
BrowserStack.com,
Browserling.com o
BrowserShots.org para asegurar que tu PWA sea
compatible entre navegadores.
Mide el rendimiento de carga de la página ¿Por qué?
Cuanto más rápido se cargue un sitio web para un usuario, mejor será su experiencia de usuario. La optimización de la velocidad de la página ya es un enfoque bien conocido en el desarrollo web, pero a veces, al desarrollar una nueva versión de un sitio, las optimizaciones necesarias no se consideran una alta prioridad.
Al desarrollar una progressive web application, recomendamos medir el rendimiento de la velocidad de carga de tu página y optimizar antes de lanzar el sitio para obtener los mejores resultados.
Mejores prácticas:
Utiliza herramientas como Page Speed Insights
y
Web Page Test
para medir el rendimiento de carga de la página de tu sitio. Aunque Googlebot tiene un poco más de paciencia al renderizar,
las investigaciones han demostrado
que el 40% de los consumidores abandonará una página que tarda más de tres segundos en cargarse.
Lee más sobre nuestras recomendaciones de rendimiento de páginas web y el.
camino de renderizado crítico 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 progressive web application, es importante no retroceder en tus optimizaciones.
Esperamos que la lista de verificación anterior sea útil y proporcione la orientación correcta para ayudarte a desarrollar tus Progressive Web Applications teniendo en cuenta la indexabilidad.
A medida que comiences, asegúrate de revisar nuestros
ejemplos de indexabilidad de Progressive Web App
que demuestran el renderizado del lado del servidor, del lado del cliente y el híbrido. Como siempre, si tienes alguna pregunta, por favor comunícate en nuestros.
Cómo lo aplicamos
We archive Search Central announcements because client questions often trace back to a change that was announced years ago. Reading the original is faster than reconstructing it from second-hand summaries.
Servicios relacionados