On parle beaucoup des apps web progressives ces derniers temps et il y a une bonne raison à cela. Google a clairement soutenu ce concept lors de son Dev Summit, et l’entreprise a également publié récemment ses premières recommandations officielles en matière d’indexation des AWP.

Malgré leurs nombreux avantages, elles présentent également certains problèmes (auxquels on pouvait s’attendre) du fait de leur conception intégralement en JavaScript. C’est pourquoi j’ai rédigé ce petit guide sur les pointeurs afin de vous aider à vous assurer que votre AWP est correctement indexée.

La plupart de nos conseils pour le référencement React.JS, Angular.JS et Angular 2.0 s’appliquent dans ce cas, en incluant quelques autres pointeurs spécifiques.

Qu’est-ce qu’une application web progressive ?

Regardez l’intervention d’Alex Russell concernant les applications web progressives lors du Chrome Dev Summit 2015 :

Source vidéo Applications web progressives (Chrome Dev Summit 2015)

Pour résumer, les applications web progressives sont :

  • Progressives – Elles fonctionnent pour tous les utilisateurs, indépendamment de leur navigateur, du fait de leur conception intégrant l’amélioration progressive comme principe de fond.
  • Réactives – Elles sont compatibles avec tous les supports : bureau, mobile, tablette ou autre.
  • Indépendantes de la connectivité – Améliorées avec leurs service-workers conçus pour fonctionner même hors-ligne ou sur des réseaux de mauvaise qualité.
  • Semblables à une app – Conçues sur le modèle du shell d’une app, elles s’utilisent comme une application en ce qui concerne leurs interactions et navigation.
  • Rafraîchies – Toujours à jour grâce au processus de mise à jour des service-workers.
  • Sécurisées – Elles utilisent le HTTPS pour éviter les fouineurs et assurer que le contenu n’a pas été trafiqué.
  • Découvrables – Elles sont identifiables comme « applications » grâce aux manifestes W3C et à l’étendue de l’inscription des service-workers, qui permet aux moteurs de recherche de les retrouver.
  • Ré-engageables – Elles simplifient le ré-engagement grâce à certaines fonctionnalités, telles que les notifications push.
  • Installables – Elles permettent aux utilisateurs de « garder » les apps qu’ils trouvent les plus utiles sans avoir à passer par une app store.
  • Accessibles par liens – Elles peuvent être partagées facilement par URL et ne requièrent pas d’installation complexe.
  • Source : Votre première app web progressive (Google)

Pour davantage de brièveté, nous désignerons par la suite les apps web progressives par la dénomination AWP.

D’abord, quelle est la différence entre un site web et une AWP ? Les deux caractéristiques principales sont, dans le cas de l’AWP, l’emploi d’une architecture basée sur le shell d’une application ainsi que de service-workers. À savoir, les pages servies contiennent l’intégralité code HTML, CSS et JS requis pour le chargement entier et correct de la page, qui est compris inline et ne nécessite donc aucun téléchargement de fichiers supplémentaires. Les service-workers permettent des fonctionnalités telles que les notifications push et la synchronisation en arrière-plan lorsqu’un utilisateur se reconnecte après avoir été hors-ligne.

Les spécifications de Google pour les AWP nécessitent également la technologie HTTPS pour la connexion, la capacité d’ajouter un écran d’accueil à un dispositif et elles impliquent que le navigateur fonctionne en mode plein écran, la barre d’URL masquée. Le dernier point est un sujet de discorde qui pourrait changer dans le futur ; cependant, pour l’instant, il implique que vous devrez concevoir un moyen pour que l’utilisateur ait la possibilité d’accéder à l’URL d’une page sans avoir à accéder à la barre URL.

Principaux pointeurs d’indexation

Premièrement, il vous faudra utiliser un type d’application de rendu JS universel. Personnellement, je serais tenté soit par React, soit par Angular 2. Étant donné qu’ils vous permettent un rendu côté serveur, vous pouvez envoyer une charge initiale contenant toutes les données pour afficher la page, ainsi que l’ensemble du CSS permettant de charger cette page spécifique. Ce CSS est placé inline, afin de garantir que l’affichage fonctionne même lorsque le client n’est pas connecté. Les modules CSS simplifient cette partie, étant donné que vous pouvez prendre exactement ce dont vous avez besoin, avant de le placer en ligne.

Deuxièmement, les service-workers jouent un rôle de proxy entre votre site et votre serveur, ce qui signifie que nous pouvons concevoir notre système de manière à ce qu’il considère qu’ils n’existent pas et qu’il fonctionne malgré tout. De cette manière, lorsque ce sera le cas, vous en obtenez les avantages, mais si ce n’est pas le cas, votre système restera fonctionnel. Il s’agit d’un élément important, car les service-workers ne sont pas bien pris en charge pour l’instant. Actuellement, nous vous conseillons de concevoir votre AWP de manière à ce que tout fonctionne en suivant les pratiques habituellement recommandées, puis d’ajouter les parties d’AWP progressivement afin d’être prêt lorsqu’elle existera pour le navigateur.

Troisièmement, assurez-vous d’utiliser des URL propres pour votre site et de fournir des URL canoniquem, afin que Google sache identifier l’AWP, le contenu AMP, votre site, etc. La compréhension de la version canonique de votre architecture se fera de plus en plus importante au fil du temps, en particulier si vous pensez procéder à une internationalisation à l’avenir.

Enfin, il semble qu’à ce jour, Google tarde à comprendre ce qui est ou n’est pas une AWP lors de l’indexation, mais je ne peux pas affirmer que cela restera le cas. Nous savons que Google a la capacité de les identifier, mais nous ne savons pas si cette capacité a déjà été intégrée à son architecture de collecte habituelle. Si ce n’est pas encore le cas, cela ne saurait tarder.

Utilisation avec WordPress

L’avantage, c’est que la compatibilité de WordPress avec les PWA peut aujourd’hui être ajoutée rapidement, grâce à une suite de plug-ins fournies par Mozilla. Ils n’ont besoin que du shell de l’application, qui nécessitera une personnalisation avant de pouvoir les prendre en charge.

Comme d’habitude, le meilleur moyen d’assurer que tout fonctionne correctement avec Googlebot consiste à consulter ses requêtes dans vos journaux des accès, regarder ce qu’il fait et résoudre les éventuels problèmes. Cependant, tant que vous procédez au rendu côté serveur, il y aura du contenu à indexer, connectant les pages à l’aide de liens et non pas d’événements, ainsi qu’à l’aide d’une architecture d’URL sensible, qui se chargera de la plupart des problèmes.