Mercredi 9 novembre 2016
Progressive Web Apps
(PWA) tirent parti des nouvelles technologies pour offrir aux utilisateurs le meilleur des sites mobiles et des applications natives – et elles constituent l’une des idées les plus passionnantes du Web. Mais pour avoir un réel impact, il est important qu’elles soient indexables et liables. Chaque recommandation présentée dans cet article est une bonne pratique existante pour l’indexabilité, que vous construisiez une Progressive Web App ou un simple site Web statique. Néanmoins, nous avons compilé ces bonnes pratiques pour vous fournir une liste de contrôle pour vous guider :
Rendez votre contenu explorable
Pourquoi ? Historiquement, les sites Web généraient ou rendaient toujours leur HTML sur le serveur, ce qui est le moyen le plus simple de garantir que votre contenu est directement liable. Les applications Web ont popularisé le concept de rendu côté client, dans lequel le contenu est mis à jour dynamiquement sur la page au fur et à mesure que l’utilisateur navigue sans avoir besoin de recharger la page.
L’approche moderne est le rendu hybride, dans lequel le rendu côté serveur est utilisé lorsqu’un utilisateur navigue directement vers une URL et le rendu côté client est utilisé après le chargement initial de la page pour la navigation ultérieure et les requêtes asynchrones.
Notre
exemple de PWA côté serveur
démontre un rendu purement côté serveur, tandis que notre
exemple de PWA hybride
démontre l’approche combinée.
Si vous n’êtes pas familier avec la terminologie du rendu côté serveur et côté client ,
consultez ces articles surle rendu côté client et côté serveur
, et
le rendu côté serveur dans react et node.js.
Bonnes pratiques :
Utilisez le rendu côté serveur ou hybride afin que les utilisateurs reçoivent le contenu lors du chargement initial de leur requête Web.
Assurez-vous toujours que vos URL sont accessibles indépendamment :
Ce qui précède devrait créer un lien profond vers cette ressource particulière.
Si vous ne pouvez pas prendre en charge le rendu côté serveur ou hybride 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 utilisateurs accédant à des liens profonds vers la page d’accueil de votre application Web.
De plus, il faut également éviter de servir une page d’erreur aux utilisateurs au lieu d’un lien profond.
Fournissez des URL propres Pourquoi ?Les identifiants de fragment ( #user/24601/ ou#!user/24601/
) étaient une solution de contournement efficace pour que les navigateurs récupèrent du nouveau contenu à partir d’un serveur via AJAX sans recharger la page. Cette conception est connue sous le nom de rendu côté client. Cependant, la syntaxe de l’identifiant de fragment n’est pas compatible avec certains outils, frameworks et protocoles Web, tels que.
le protocole Open Graph de Facebook La History API #! nous permet de mettre à jour l’URL sans identifiants de fragment tout en récupérant les ressources de manière asynchrone et en évitant ainsi les rechargements de page – c’est le meilleur des deux mondes. Le schéma d’exploration AJAX
(avec ses #! URL de fragment échappé) avait du sens à son époque, mais n’est plus recommandé aujourd’hui.
Nos
exemples de PWA hybride et de PWA côté client
démontrent l’History API.# Bonnes pratiques : #!Fournissez des URL propres sans identifiants de fragment (
ou
) telles que :
Si vous utilisez le rendu côté client ou hybride, assurez-vous de prendre en charge la navigation par navigateur avec l’History API. #! Évitez :
L’utilisation de la # structure d’URL pour piloter des URL uniques est déconseillée :
Elle a été introduite comme solution de contournement avant l’avènement de l’History API. Elle est considérée comme un modèle # distinct de la structure d’URL pure. ! L’utilisation de la
structure d’URL sans le
symbole accompagnateur n’est pas prise en charge :
https://www.example.com/#product/25/
Cette structure d’URL est déjà un concept sur le Web et se rapporte aux liens profonds vers du contenu sur une page particulière. Spécifiez des URL canoniques
Pourquoi ?
Le meilleur moyen d’éliminer la confusion pour l’indexation lorsque le même contenu est disponible sous plusieurs URL (qu’il s’agisse de domaines identiques ou différents) est de marquer une page comme canonique et de faire en sorte que toutes les autres pages qui dupliquent ce contenu y fassent référence.
Bonnes pratiques :
Incluez la balise suivante sur toutes les pages reflétant un élément de contenu particulier : Si vous prenez en charge les Accelerated Mobile Pages, assurez-vous d’utiliser également correctement son homologue
rel=”amphtml”
instruction.
Évitez : Évitez de dupliquer intentionnellement du contenu sur plusieurs URL et de ne pas utiliser l’élément de lien
rel=”canonical” . Par exemple, l’élément de lien
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. Concevez pour plusieurs appareils
Pourquoi ?
Il est important que tous vos utilisateurs bénéficient de la meilleure expérience possible lors de la consultation de votre site Web, quel que soit leur appareil. Rendez votre site
—les polices, les marges, les remplissages, les boutons et la conception générale de votre site doivent s’adapter dynamiquement en fonction des résolutions d’écran et des fenêtres d’affichage des appareils.
Les petites images mises à l’échelle pour les ordinateurs de bureau ou les tablettes offrent une mauvaise expérience. À l’inverse, les images à très haute résolution mettent beaucoup de temps à se télécharger sur les téléphones mobiles et peuvent nuire aux performances de défilement sur mobile.
En savoir plus sur
UX pour les PWA.
Bonnes pratiques :
Utilisez
l'attribut srcset
pour récupérer des images de différentes résolutions pour des écrans de densités différentes afin d’éviter de télécharger des images plus grandes que ce que l’écran de l’appareil est capable d’afficher.
Adaptez la taille de votre police et la hauteur de ligne pour garantir que votre texte soit lisible quelle que soit la taille de l’appareil. De même, assurez-vous que le remplissage et les marges des éléments s’adaptent également de manière judicieuse.
Testez
diverses résolutions d’écran
en utilisant la
fonctionnalité Mode appareil des outils de développement Chrome
et l’outil
Test d’optimisation mobile.
Ne montrez pas aux utilisateurs un contenu différent de celui que vous montrez à Google. Si vous utilisez
des redirections ou la détection de l’agent utilisateur
(aussi appelé sniffing de navigateur ou
service dynamique) pour modifier la conception de votre site pour différents appareils, il est important que le contenu lui-même reste le même.
Utilisez l’outil “Explorer comme Google” de la Search Console pour vérifier que le contenu récupéré par Google correspond au contenu vu par un utilisateur.
Pour des raisons d’utilisabilité, évitez d’utiliser des polices de 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 consiste à effectuer des modifications de manière itérative. Si vous ajoutez des fonctionnalités une par une, vous pouvez observer l’impact de chaque modification individuelle.
Alternativement, de nombreux développeurs préfèrent considérer leur application Web progressive comme une opportunité de refondre leur site mobile en une seule fois — en développant la nouvelle application Web dans un environnement isolé et en la remplaçant par leur site mobile existant une fois prête.
Lors du développement itératif de fonctionnalités, essayez de diviser les modifications en parties distinctes. 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 qu’en combinaison avec d’autres fonctionnalités.
Les deux approches ont leurs avantages et leurs inconvénients. L’itération réduit la complexité liée à l’indexabilité de la recherche car la transition est continue. Cependant, l’itération pourrait entraîner un processus de développement plus lent et potentiellement une refonte moins innovante si le développement ne part pas de zéro.
Dans les deux cas, les domaines les plus sensibles à surveiller sont vos URL canoniques et la configuration robots.txt de votre site.
Bonnes pratiques :
Itérez sur votre site Web de manière incrémentale en ajoutant de nouvelles fonctionnalités pièce par pièce.
Par exemple, si vous ne prenez pas encore en charge HTTPS, commencez par migrer vers un site sécurisé.
À éviter :
Si vous avez développé votre application Web progressive 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 pointent vers le site réel et que votre configuration robots.txt permet aux robots d’exploration de parcourir votre nouveau site.
Il est logique d’empêcher les robots d’exploration d’indexer votre site en cours de développement avant le lancement, mais n’oubliez pas de débloquer l’accès des robots à votre nouveau site lors du lancement.
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 au test des navigateurs dont vous pensez qu’ils prennent en charge une fonctionnalité donnée.
Une mauvaise pratique courante par le passé consistait à activer ou désactiver des fonctionnalités en testant le navigateur de l’utilisateur. Cependant, comme les navigateurs évoluent constamment avec de nouvelles fonctionnalités, cette technique est fortement déconseillée.
Service Worker est une technologie relativement nouvelle et il est important de ne pas briser la compatibilité dans la poursuite du progrès — c’est un exemple parfait du moment où utiliser l’amélioration progressive.
Bonnes pratiques :
Avant d’enregistrer un Service Worker, vérifiez la disponibilité de son API :
Utilisez la méthode de détection par API pour toutes les fonctionnalités de votre site Web.
N’utilisez jamais l’agent utilisateur 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 dégradez-la gracieusement si elle n’est pas disponible.
Évitez de mettre à jour ou de lancer votre site sans le tester sur plusieurs navigateurs ! Consultez les analyses de votre site pour savoir quels navigateurs sont les plus populaires parmi votre base d’utilisateurs.
Tester avec Search Console
Pourquoi ? Il est important de comprendre comment la recherche Google voit le contenu de votre site. Vous pouvez utiliser
Search Console pour
récupérer des URL individuelles de votre site
et voir comment la recherche Google les voit en utilisant la fonctionnalité “Exploration > Explorer comme Google”. Search Console traitera votre JavaScript et rendra la page lorsque cette option est sélectionnée ; sinon, seule la réponse HTML brute est affichée.
Google Search Console analyse également le contenu de votre page de diverses manières, notamment en détectant la présence de données structurées, de Rich Cards, de liens de site et de pages mobiles accélérées.
Bonnes pratiques :
Surveillez votre site à l’aide de Search Console et explorez ses fonctionnalités, notamment Explorer comme Google.
Fournissez un sitemap via Search Console Explorer > Sitemaps. Cela peut être un moyen efficace de garantir que la recherche Google connaît toutes les pages de votre site.
Annoter avec des données structurées Schema.org
Pourquoi ? Schema.org les données structurées sont un vocabulaire flexible pour résumer les parties les plus importantes de votre page sous forme de données lisibles par machine. Cela peut être aussi général que de dire simplement qu’une page est un NewsArticleou aussi spécifique que de détailler l’emplacement, le nom du groupe, le lieu et le vendeur de billets pour un groupe en tournée, ou de résumer les ingrédients et les étapes d’une recette.
L’utilisation de ces métadonnées peut ne pas avoir de sens pour chaque page de votre application Web, mais elle est recommandée là où cela est judicieux. Google les extrait une fois la page rendue.
Il existe une variété de types de données, notamment NewsArticle, Recipeet
Product pour n’en nommer que quelques-uns. Vous pouvez également explorer tous les
types de données pris en charge 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 apparaissent et qu’il n’y a aucune erreur. Évitez d’utiliser un type de données qui ne correspond pas au contenu réel de votre page. Par exemple, n’utilisez pas
ru
Recette pour un T-shirt que vous vendez—utilisez Produit à la place.
Annotez avec Open Graph et Twitter Cards
Pourquoi ? En plus des métadonnées Schema.org, il peut être utile d’ajouter également la prise en charge du protocole Open Graph de Facebook et des Twitter rich cards.
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 application web existant utilise ces formats, il est important de s’assurer qu’ils sont également inclus dans votre progressive web application pour une viralité optimale.
Meilleures pratiques :
Testez votre balisage Open Graph avec le
Facebook Object Debugger Tool.
Familiarisez-vous avec
le format de métadonnées de Twitter.
N’oubliez pas d’inclure ces formats si votre site existant les prend en charge.
Testez avec plusieurs navigateurs
Pourquoi ? Clairement, du point de vue de l’utilisateur, il est important qu’un site web se comporte de la même manière sur tous les navigateurs. Bien que l’expérience puisse s’adapter à différentes tailles d’écran, nous nous attendons tous à ce qu’un site mobile fonctionne de la même manière sur des appareils de taille similaire, qu’il s’agisse d’un iPhone ou d’un téléphone mobile Android.
Bien que le Web puisse être perçu comme fragmenté en raison du nombre de navigateurs utilisés dans le monde, cette variété et cette concurrence font partie de ce qui fait du Web une plateforme si innovante. Heureusement, les standards du Web n’ont jamais été aussi matures qu’aujourd’hui et les outils modernes permettent aux développeurs de créer des sites web riches et compatibles avec tous les navigateurs en toute confiance.
Meilleures pratiques :
Utilisez des outils de test multi-navigateurs tels que
BrowserStack.com,
Browserling.com ou
BrowserShots.org pour vous assurer que votre PWA est
compatible avec tous les navigateurs.
Mesurez les performances de chargement des pages Pourquoi ?
Plus un site web se charge rapidement pour un utilisateur, meilleure sera son expérience utilisateur. L’optimisation de la vitesse des pages est déjà un axe bien connu du développement web, mais parfois, lors du développement d’une nouvelle version d’un site, les optimisations nécessaires ne sont pas considérées comme une priorité absolue.
Lors du développement d’une progressive web application, nous recommandons de mesurer les performances de votre vitesse de chargement de page et d’optimiser avant de lancer le site pour obtenir les meilleurs résultats.
Meilleures 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 ait un peu plus de patience lors du rendu,
des recherches ont montré
que 40 % des consommateurs quitteront une page qui met plus de trois secondes à se charger.
En savoir plus sur nos recommandations en matière de performances des pages web et le.
chemin de rendu critique ici
Évitez de laisser l’optimisation comme une étape post-lancement. Si le contenu de votre site web se charge rapidement avant de migrer vers une nouvelle progressive web application, il est important de ne pas régresser dans vos optimisations.
Nous espérons que la liste de contrôle ci-dessus est utile et fournit les conseils appropriés pour vous aider à développer vos Progressive Web Applications en gardant à l’esprit l’indexabilité.
Au fur et à mesure que vous commencez, assurez-vous de consulter nos
exemples d’indexabilité de Progressive Web App
qui démontrent le rendu côté serveur, côté client et hybride. Comme toujours, si vous avez des questions, veuillez nous contacter sur nos.
Comment nous l'appliquons
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.
Services associés