Mercredi 9 novembre 2016
Les progressive web apps (PWA) utilisent les nouvelles technologies pour offrir aux utilisateurs le meilleur des sites pour mobile et des applications natives. Elles comptent parmi les nouvelles idées les plus prometteuses du Web. Toutefois, pour avoir un impact réel, il est important qu'elles puissent être indexées et accessibles via des liens. Chaque recommandation présentée dans cet article constitue une bonne pratique d'indexation existante, que vous développiez une progressive web app ou un simple site Web statique. Nous avons néanmoins réuni les bonnes pratiques suivantes pour vous guider :
Permettre l'exploration de votre contenu
Pourquoi ? Traditionnellement, les sites Web génèrent ou affichent leur code HTML sur le serveur. C'est le moyen le plus simple de s'assurer que votre contenu est directement accessible via des liens. Les applications Web ont popularisé le concept de rendu côté client. Le contenu est ainsi mis à jour dynamiquement sur la page consultée par l'internaute, sans avoir besoin d'être rechargé.
La tendance actuelle est au rendu hybride. Le rendu côté serveur est utilisé lorsqu'un internaute accède directement à une URL et le rendu côté client est utilisé après le chargement initial de la page pour faciliter la navigation ultérieure et les requêtes asynchrones.
Notre exemple de PWA côté serveur illustre un rendu 100 % côté serveur, tandis que notre exemple de PWA hybride témoigne de l'approche combinée.
Si vous ne connaissez pas la terminologie des rendus côté serveur et côté client, consultez ces articles sur lerendu côté client et côté serveur et le rendu côté serveur dans React et Node.js.
Bonnes pratiques :
Utilisez le rendu hybride ou côté serveur afin que les internautes aient accès au contenu dès le traitement de la charge utile initiale de leur demande Web.
Assurez-vous que vos URL sont toujours accessibles indépendamment :
https://www.example.com/product/25/
L'élément ci-dessus devrait rediriger vers cette ressource particulière par le biais d'un lien profond.
Si vous ne pouvez pas utiliser le rendu hybride ou côté serveur pour votre progressive web app et que vous décidez d'utiliser le rendu côté client, nous vous recommandons d'utiliser l'outil "Explorer comme Google" de la Google Search Console pour vérifier que votre contenu s'affiche correctement pour notre robot d'exploration de recherche.
Ne redirigez pas les internautes accédant à des liens profonds vers la page d'accueil de votre application Web.
De plus, il est préférable d'éviter d'afficher une page d'erreur au lieu de liens profonds.
Fournir des URL "propres"
Pourquoi ? Les identificateurs de fragments (#user/24601/ ou #!user/24601/) constituaient une technique de contournement efficace permettant aux navigateurs d'explorer via AJAX le nouveau contenu d'un serveur sans avoir à recharger la page.
Cette conception est connue sous le nom de rendu côté client.
Cependant, la syntaxe de l'identificateur de fragments n'est pas compatible avec certains protocoles, cadres et outils Web, tels que le protocole Open Graph de Facebook.
L'API History nous permet de mettre à jour l'URL sans identificateurs de fragments tout en récupérant quand même les ressources de façon asynchrone et en évitant ainsi les nouveaux chargements de pages. C'est le compromis idéal. Le processus d'exploration AJAX (avec ses URL à la syntaxe de type #! /) était pertinent à l'époque, mais n'est plus recommandé.
Nos exemples de PWA côté client et hybride utilisent l'API History.
Bonnes pratiques :
Fournissez des URL propres sans identificateurs de fragments (# ou #!), telles que :
https://www.example.com/product/25/
Si vous utilisez le rendu hybride ou côté client, assurez-vous de la compatibilité entre le navigateur et l'API History.
À éviter :
Nous vous déconseillons d'utiliser la structure d'URL #! dans les URL uniques :
https://www.example.com/#!product/25/
Il s'agissait d'une solution proposée avant la création de l'API History. On considère qu'il s'agit d'un schéma distinct de la structure d'URL # simple.
Il est impossible d'utiliser la structure d'URL # sans le symbole ! qui l'accompagne traditionnellement :
https://www.example.com/#produit/25/
Cette structure d'URL renvoie à un autre concept du Web : les liens profonds vers le contenu d'une page particulière.
Indiquer des URL canoniques
Pourquoi ? Le meilleur moyen d'indexer efficacement un même contenu disponible sur plusieurs URL (que ce soit des domaines identiques ou différents) consiste à définir une page canonique, et à configurer toutes les autres pages similaires pour qu'elles pointent vers la page canonique. Cela permet d'éliminer toute confusion lors de l'indexation.
Bonnes pratiques :
Placez la balise suivante dans toutes les pages qui mettent en miroir un contenu particulier :
<link rel="canonical" href="https://www.example.com/your-url/" />
Si vous acceptez les pages Accelerated Mobile Pages, assurez-vous d'utiliser correctement l'instruction homologue rel="amphtml" également.
À éviter :
Évitez de dupliquer délibérément un contenu sur plusieurs URL sans utiliser l'élément link rel="canonical".
Par exemple, l'élément link rel="canonical" peut réduire l'ambiguïté pour les URL avec des paramètres de suivi.
Évitez de créer des références canoniques contradictoires entre vos pages.
Concevoir une application pour plusieurs appareils
Pourquoi ? Il est important que tous les internautes aient la meilleure expérience possible en consultant votre site Web, quel que soit leur appareil.
Créez un site responsive : les polices, les marges, les marges intérieures, les boutons et la conception générale de votre site doivent s'adapter dynamiquement en fonction de la résolution de l'écran et de la fenêtre d'affichage de l'appareil.
Les petites images redimensionnées pour les ordinateurs ou les tablettes ne sont pas souhaitables. À l'inverse, le téléchargement d'images ultra haute résolution est très long sur les téléphones mobiles et peut nuire aux performances de défilement sur mobile.
En savoir plus sur l'expérience utilisateur pour les PWA
Bonnes pratiques :
Utilisez l'attribut srcset pour récupérer des images de résolution différentes pour différents écrans de densité, et empêcher ainsi le téléchargement d'images plus grandes que l'écran de l'appareil.
Ajustez la taille de police et la hauteur de ligne pour vous assurer que votre texte est lisible quelle que soit la taille de l'appareil. De même, assurez-vous que la marge intérieure et les marges des éléments évoluent judicieusement.
Testez plusieurs résolutions d'écran à l'aide du mode Appareil de l'outil pour les développeurs Chrome et de l'outil de test d'optimisation mobile.
Le contenu que vous montrez aux utilisateurs doit être identique à celui que vous montrez à Google. Si vous utilisez des redirections ou la détection des user-agents (également appelée reniflage du navigateur ou diffusion dynamique) afin de modifier la conception de votre site pour différents appareils, le contenu doit impérativement rester le même.
Utilisez l'outil "Explorer comme Google" de la Search Console pour vérifier que le contenu exploré par Google correspond à celui qu'un utilisateur voit.
Pour des raisons de facilité d'utilisation, évitez d'utiliser des polices à taille fixe.
Développer de manière itérative
Pourquoi ? L'un des moyens les plus sûrs d'ajouter des fonctionnalités à une application Web est de faire des changements de manière itérative. Si vous ajoutez des fonctionnalités une à une, vous pouvez observer l'impact de chaque modification.
Toutefois, de nombreux développeurs préfèrent voir leur progressive web app comme une occasion de remanier du même coup leur site mobile, en développant la nouvelle application Web dans un environnement isolé et en l'échangeant par la suite avec leur site mobile actuel.
Lorsque vous développez des fonctionnalités de manière itérative, essayez de morceler les changements. Par exemple, si vous avez l'intention de passer du rendu côté serveur au rendu hybride, abordez cela comme une seule itération, plutôt que de combiner ce changement avec d'autres fonctionnalités.
Les deux approches ont leurs avantages et leurs inconvénients. L'itération réduit la complexité d'indexation dans la recherche Google, car la transition est continue. Cependant, l'itération peut aboutir à un processus de développement plus lent et à une refonte potentiellement moins innovante si le développement n'est pas repris de zéro.
Dans les deux cas, les points les plus sensibles à suivre de près sont vos URL canoniques et la configuration du fichier robots.txt de votre site.
Bonnes pratiques :
Ajoutez de nouvelles fonctionnalités à votre site progressivement, une à une.
Par exemple, si vous ne prenez pas encore en charge le HTTPS, commencez par migrer vers un site sécurisé.
À éviter :
Si vous avez développé votre progressive web app dans un environnement isolé, évitez de la lancer sans vérifier que les liens rel="canonical" et le fichier robots.txt sont correctement configurés.
Assurez-vous que vos liens rel="canonical" redirigent vers le site réel et que la configuration de votre fichier robots.txt permet aux robots d'exploration d'explorer votre nouveau site.
Il est logique d'empêcher les robots d'exploration d'indexer votre site en développement avant son lancement, mais n'oubliez pas de permettre aux robots d'exploration d'accéder à votre nouveau site une fois qu'il est lancé.
Utiliser l'amélioration progressive
Pourquoi ? Dans la mesure du possible, il est important de détecter les fonctionnalités du navigateur avant de les utiliser. La détection de fonctionnalités est également préférable à l'identification des navigateurs que vous jugez compatibles avec une fonctionnalité donnée.
Une mauvaise pratique fréquente par le passé consistait à activer ou à désactiver les fonctionnalités en fonction du navigateur de l'internaute. Toutefois, comme les fonctionnalités des navigateurs sont en constante évolution, cette technique est fortement déconseillée.
Les service workers sont une technologie relativement récente, et il est important de ne pas nuire à la compatibilité dans notre recherche du progrès. C'est un exemple parfait d'utilisation de l'amélioration progressive.
Bonnes pratiques :
Avant d'enregistrer un service worker, vérifiez la disponibilité de son API :
if ('serviceWorker' in navigator) {
...
Utilisez la méthode de détection par API pour toutes les fonctionnalités de votre site Web.
N'utilisez jamais le user-agent du navigateur pour activer ou désactiver des fonctionnalités dans votre application Web. Vérifiez toujours si l'API de la fonctionnalité est disponible et effectuez une dégradation élégante si cela n'est pas le cas.
Évitez de mettre à jour ou de lancer votre site sans le tester sur plusieurs navigateurs. Vérifiez les statistiques relatives à votre site pour savoir quels navigateurs sont les plus populaires parmi votre base d'utilisateurs.
Tester avec la Search Console
Pourquoi ? Il est important de comprendre comment la recherche Google voit le contenu de votre site. Vous pouvez utiliser la Search Console pour explorer des URL individuelles de votre site et découvrir comment la recherche Google les voit à l'aide de la fonctionnalité "Explorer > Explorer comme Google". La Search Console traite votre code JavaScript et affiche la page lorsque cette option est sélectionnée. Dans le cas contraire, seule la réponse HTML brute est affichée.
La Google Search Console analyse également le contenu de votre page de diverses façons, y compris en détectant la présence de données structurées, de cartes enrichies, de liens sitelink et de pages Accelerated Mobile Pages.
Bonnes pratiques :
Surveillez votre site à l'aide de la Search Console et découvrez ses fonctionnalités, y compris Explorer comme Google.
Fournissez un sitemap via Exploration > Sitemaps dans la Search Console. C'est un bon moyen de vous assurer que la recherche Google connaît toutes les pages de votre site.
Annoter avec des données structurées Schema.org
Pourquoi ? Les données structurées Shema.org constituent un vocabulaire flexible qui résume les parties les plus importantes de votre page sous forme de données pouvant être traitées par ordinateur. Il peut s'agir de généralités, par exemple indiquer simplement qu'une page est un NewsArticle, mais il est possible d'apporter plus de précisions : lieu, nom d'un groupe de musique, salle, billetterie pour la tournée d'un artiste, ou résumé des ingrédients et des étapes d'une recette.
L'utilisation de ces métadonnées n'est pas forcément pertinente pour chaque page de votre application Web, mais il est recommandé de les utiliser si elles ont lieu d'être. Google les récupère une fois le rendu de la page effectué.
Il existe différents types de données, comme NewsArticle, Recipe et Product, pour n'en citer que quelques-uns. Vous pouvez également explorer tous les types de données acceptés ici.
Bonnes pratiques :
Vérifiez que vos métadonnées Schema.org sont correctes à l'aide de l'outil de test des données structurées de Google.
Vérifiez que les données que vous avez fournies s'affichent bien et ne comportent pas d'erreurs.
Évitez d'utiliser un type de données qui ne correspond pas au contenu réel de votre page. Par exemple, n'utilisez pas Recipe pour un T-shirt à vendre. Utilisez plutôt Product.
Annoter avec Open Graph et les cartes Twitter
Pourquoi ? En plus des métadonnées Schema.org, il peut être utile d'accepter le protocole Open Graph de Facebook, ainsi que les cartes enrichies de Twitter.
Ces formats de métadonnées améliorent l'expérience utilisateur lorsque votre contenu est partagé sur leurs réseaux sociaux correspondants.
Si votre site ou votre application Web utilisent ces formats, il est important de vous assurer qu'ils figurent dans votre progressive web app, pour garantir une viralité optimale.
Bonnes pratiques :
Testez votre balisage Open Graph à l'aide du débogueur d'objets Facebook.
Familiarisez-vous avec le format de métadonnées de Twitter.
N'oubliez pas d'inclure ces formats si votre site les accepte.
Tester dans plusieurs navigateurs
Pourquoi ? Il est clair que du point de vue de l'internaute, il est important qu'un site Web se comporte de la même façon dans tous les navigateurs. Même si le contenu s'adapte aux différentes tailles d'écran, nous nous attendons tous à ce qu'un site pour mobile fonctionne de la même manière sur des appareils de taille similaire, que ce soit sur un iPhone ou sur un téléphone mobile Android.
Le Web peut être perçu comme fragmenté, en raison du nombre de navigateurs utilisés dans le monde. Toutefois, cette diversité et cette concurrence contribuent à faire du Web une plate-forme aussi innovante. Fort heureusement, les normes Web ont atteint un niveau de maturité sans précédent. Les outils modernes permettent aux développeurs de créer en toute confiance des sites Web riches et compatibles avec tous les navigateurs.
Bonnes pratiques :
Utilisez des outils de test sur plusieurs navigateurs, tels que BrowserStack.com, Browserling.com ou BrowserShots.org pour vous assurer votre PWA est compatible avec tous les navigateurs.
Mesurer les performances de chargement des pages
Pourquoi ? Plus le chargement d'un site Web est rapide, meilleure est l'expérience utilisateur. L'optimisation de la vitesse des pages est déjà une préoccupation clé des développeurs Web, mais parfois, lors de l'élaboration d'une nouvelle version d'un site, les optimisations nécessaires ne sont pas considérées comme prioritaires.
Lors du développement d'une PWA, nous vous conseillons de mesurer la vitesse de chargement de vos pages et d'optimiser le site avant de le lancer.
Bonnes pratiques :
Utilisez des outils tels que Page Speed Insights et Web Page Test pour mesurer les performances de chargement des pages de votre site. Bien que Googlebot soit un peu plus patient en matière d'affichage, les recherches ont montré que 40 % des consommateurs abandonnent une page qui met plus de trois secondes à se charger.
Pour en savoir plus sur nos recommandations en matière de performances des pages et sur le chemin critique du rendu, cliquez ici.
Évitez de considérer l'optimisation comme une étape post-lancement. Si le contenu de votre site Web se chargeait rapidement avant sa migration vers une nouvelle PWA, il est important de ne pas régresser dans vos optimisations.
Nous espérons que la checklist ci-dessus vous sera utile pour vous aider à développer vos PWA sans perdre de vue l'indexation.
Avant de commencer, veillez à consulter nos exemples d'indexation de progressive web apps qui illustrent le rendu côté client, côté serveur et hybride. Comme toujours, si vous avez des questions, n'hésitez pas à les poser sur nos forums pour les webmasters.