SEO et applications Web progressives: regards tournés vers l'avenir

Les praticiens du référencement ont toujours été méfiants à l'égard de JavaScript.

Ceci est en partie basé sur l'expérience; la capacité des moteurs de recherche à découvrir, à explorer et à indexer avec précision le contenu qui repose fortement sur JavaScript a toujours été médiocre. Mais c’est aussi une habitude, née d’une méfiance générale à l’égard de JavaScript qui n’est pas basé sur la compréhension ou l’expérience. Cela se manifeste par une dépendance à des techniques de référencement traditionnelles qui ne sont plus pertinentes depuis des années et une conviction que pour être bon en référencement technique ne nécessite pas une compréhension du développement Web moderne.

Comme l'a écrit Mike King dans son post La renaissance technique du référencement ces attitudes contribuent à “un fossé croissant des connaissances techniques dans le domaine du référencement en tant que domaine marketing, rendant difficile pour de nombreux référenceurs de résoudre nos nouveaux problèmes”. Ils exposent également les praticiens du référencement au risque d’être laissés pour compte, car un trop grand nombre d’entre nous refusons d’explorer – et encore moins d’adopter – des technologies telles que les applications Web progressives (PWA), les frameworks JavaScript modernes, et d’autres avancées de ce type, qui sont de plus en plus considérées comme les plus avancées. L'avenir du Web.

Dans cet article, je jetterai un nouveau regard sur les PWA. En plus d'explorer les implications à la fois pour le référencement et la convivialité, je vais présenter quelques frameworks modernes et créer des outils dont vous n'avez peut-être pas entendu parler, et suggérer des manières dont nous devons nous adapter si nous voulons nous placer à la pointe de la technologie. du Web.

1. Récapitulation: PWA, SPA et travailleurs des services

Les applications Web progressives sont essentiellement des sites Web offrant une expérience utilisateur similaire à celle d’une application native . Des fonctionnalités telles que les notifications push permettent un réengagement facile avec votre public, tandis que les utilisateurs peuvent ajouter leurs sites favoris à leur écran d'accueil sans la complication des magasins d'applications. Les PWA peuvent continuer à fonctionner en mode hors connexion ou sur des réseaux de qualité médiocre et permettent une expérience plein écran de niveau supérieur sur les périphériques mobiles, plus proche de celle offerte par les applications natives iOS et Android.

Mieux encore, les PWA ceci tout en conservant – voire en renforçant – la nature fondamentalement ouverte et accessible du Web . Comme leur nom l'indique, ils sont progressifs et adaptatifs conçus pour fonctionner pour tous les utilisateurs, quel que soit le navigateur ou le périphérique choisi. Ils peuvent également être tenus à jour automatiquement et, comme nous le verrons, sont accessibles et pouvant être reliés comme des sites Web traditionnels. Enfin, ce n’est pas tout ou rien: les sites Web existants peuvent déployer un sous-ensemble limité de ces technologies (en utilisant un simple prestataire de services) et commencer à en tirer immédiatement parti.

La spécification est encore relativement jeune et, naturellement, il existe des domaines qui nécessitent travail, mais cela ne les empêche pas d’être l’un des plus grands progrès des capacités du Web depuis une décennie. L'adoption de PWA croît rapidement et les entreprises découvrent la myriade d'objectifs commerciaux réels qu'ils peuvent avoir.

Vous pouvez en savoir plus sur les caractéristiques et les exigences des PWA sur Google Developers mais deux des technologies clés qui rendent les PWA possibles sont les suivantes:

• Architecture de l'appli shell : Généralement réalisé à l'aide d'un cadre JavaScript tel que React ou Angular, il s'agit d'une manière de créer des applications d'une page (SPA). qui sépare la logique du contenu réel. Considérez le shell d'application comme le code HTML, CSS et JS minimal requis pour que votre application fonctionne. un squelette de votre interface utilisateur pouvant être mis en cache.
• Service Workers : un script spécial que votre navigateur exécute en arrière-plan, indépendamment de votre page. Il agit essentiellement comme un proxy, interceptant et gérant par programme les demandes réseau de votre page.

Notez que ces technologies ne s’excluent pas mutuellement; le modèle d'application à page unique (mûri avec AngularJS en 2010) est évidemment antérieur aux travailleurs des services et aux PWA. Comme nous le verrons, il est également tout à fait possible de créer un PWA qui ne soit pas conçu comme une application à page unique. Pour les besoins de cet article, cependant, nous allons nous concentrer sur l’approche «typique» du développement d’APP modernes, explorant les implications SEO – et les opportunités – rencontrées par les équipes qui choisissent de rejoindre rapidement -Un nombre croissant d'organisations qui utilisent les technologies décrites ci-dessus .

Commençons par l'architecture du shell de l'application et les implications en termes de rendu du modèle d'application à page unique.

2. Architecture du shell de l’application

URL

En résumé, l’architecture du shell de l’application implique la mise en cache agressive d’actifs statiques (minimum d’interface utilisateur et de fonctionnalités), puis le chargement dynamique du contenu réel à l’aide de JavaScript. La plupart des frameworks JavaScript JavaScript modernes encouragent quelque chose qui ressemble à cette approche, et la séparation de la logique et du contenu profite à la fois à la rapidité et à la convivialité . Les interactions sont instantanées, un peu comme celles d'une application native, et l'utilisation des données peut être extrêmement économique.

Credit à https://developers.google.com/web/fundamentals/architecture/app-shell

Comme je l'ai mentionné dans l'introduction, une forte confiance en JavaScript côté client est un problème pour le référencement . Historiquement, bon nombre de ces problèmes étaient centrés sur le fait que, même si les robots d'exploration de recherche requièrent des URL uniques pour découvrir et indexer le contenu, les applications à page unique n'ont pas besoin de changer l'URL pour chaque état de l'application ou du site Web la phrase 'page simple'). Le recours à des identifiants de fragments – qui ne sont pas envoyés dans le cadre d’une requête HTTP – pour manipuler le contenu de manière dynamique sans recharger la page était un casse-tête majeur pour le référencement. Les solutions existantes impliquaient le remplacement du hachage par un hashbang (#!) Et le paramètre _escaped_fragment_, un hack qui est depuis longtemps déconseillé et que nous n'explorerons pas aujourd'hui.

Merci au HTML5 Historique API et méthode PushState, nous avons maintenant une meilleure solution. La barre d’URL du navigateur peut être modifiée à l’aide de JavaScript sans recharger la page, ce qui la synchronise avec l’état de votre application ou de votre site et permet à l’utilisateur d’utiliser efficacement le bouton «Précédent» du navigateur. Bien que cette solution ne soit pas une solution miracle – votre serveur doit être configuré pour répondre aux demandes de ces URL profondes en chargeant l'application dans son état initial correct – elle nous fournit les outils pour résoudre le problème des URL dans les SPA. [19659021] // Exécutez ceci dans votre console pour modifier l'URL dans votre
// navigateur – notez que la page n'est pas rechargée.
history.pushState (null, "Page 2", "/page2.html");[19659022HERLeproblèmeleplusimportantauquelleréférencementestaujourd'huiconfrontéestenréalitébeaucoupplussimpleàcomprendre: rendu du contenu à savoir lorsque et comment cela se fait.

Rendu du contenu

Notez que lorsque je parle de rendu ici, je parle du processus de pour construire le HTML . Nous nous concentrons sur la façon dont le contenu actuel parvient au navigateur, et non sur le processus d'affichage des pixels à l'écran.

Au début du Web, les choses étaient plus simples à cet égard. Le serveur renvoie généralement tout le code HTML nécessaire au rendu d'une page. De nos jours, cependant, de nombreux sites utilisant une infrastructure d'application à une seule page ne fournissent qu'un minimum de HTML du serveur et délèguent le travail lourd au client (qu'il s'agisse d'un utilisateur ou d'un bot). Compte tenu de l'échelle du Web, cela nécessite beaucoup de temps et de ressources de calcul. Comme Google l'a précisé lors de sa conférence sur les E / S en 2018, cela pose un problème majeur aux moteurs de recherche:

"Le rendu des sites Web JavaScript dans Google Search est différé jusqu'à ce que Googlebot dispose des ressources nécessaires pour traiter ce contenu."

Sur les sites plus grands, cette seconde vague d'indexation peut parfois être retardée de de plusieurs jours. . En plus de cela, vous rencontrerez probablement une myriade de problèmes avec des informations cruciales, telles que les balises canoniques et les métadonnées, manquantes. Je recommanderais vivement de regarder la vidéo de l'excellent exposé de Google sur ce sujet pour un aperçu des difficultés rencontrées par les robots de recherche modernes.

Google est l'un des rares moteurs de recherche permettant de rendre JavaScript à JavaScript. tout. De plus, il utilise un service de rendu Web qui était jusqu’à récemment basé sur Chrome 41 (publié en 2015). Évidemment, cela a des implications en dehors des applications d'une seule page, et le sujet plus vaste du JavaScript SEO est un domaine fascinant en ce moment. Le livre blanc récent de Rachel Costello sur le référencement JavaScript est la meilleure ressource que j'ai lue sur le sujet et comprend des contributions d'autres experts comme Bartosz Góralewicz, Alexis Sanders, Addy Osmani et bien d'autres. [19659002] Pour les besoins de cet article, il est important de noter qu'en 2019, vous ne pouvez pas vous fier aux moteurs de recherche pour analyser et restituer avec précision votre application Web dépendante de JavaScript. Si votre contenu est restitué côté client, l'exploration par Google demandera beaucoup de ressources et votre site aura des performances insuffisantes. Peu importe ce que vous avez entendu dire, si la recherche naturelle est un canal précieux pour votre site Web, vous devez prévoir le rendu sur le serveur.

Mais le rendu sur le serveur est un concept. ce qui est souvent mal compris…

«Implémentation du rendu côté serveur»

Il s’agit d’une recommandation courante en matière d’audit de référencement, que j’entends souvent comme une solution autonome et facile à mettre en œuvre. Dans le meilleur des cas, il s’agit d’une simplification exagérée d’un énorme projet technique et, au pire, d’une incompréhension de ce qui est possible / nécessaire / avantageux pour le site Web en question. Le rendu côté serveur est un résultat de nombreuses configurations possibles et peut être réalisé de différentes manières. Cependant, en fin de compte, nous voulons que notre serveur renvoie le code HTML statique .

Alors, quelles sont nos options? Décomposons un peu le concept de contenu rendu côté serveur et explorons nos options. Voici les approches de haut niveau décrites par Google lors de la conférence d'E / S susmentionnée:

• Rendu dynamique – Les navigateurs normaux obtiennent ici l'application Web "standard" qui requiert un rendu côté client lorsque des robots (tels que Googlebot et services de médias sociaux) sont servis avec des instantanés statiques. Cela implique l’ajout d’une étape supplémentaire à l’infrastructure de votre serveur, à savoir un service qui récupère votre application Web, restitue le contenu, puis renvoie ce code HTML statique aux bots en fonction de leur agent d’utilisateur (c'est-à-dire le sniffing UA). Historiquement, cela était fait avec un service tel que PhantomJS (maintenant obsolète et non plus développé), alors qu'aujourd'hui Puppeteer (sans tête Chrome) peut exécuter une fonction similaire. L’avantage principal est qu’il peut souvent être intégré à votre infrastructure existante.

• Rendu hybride – C’est la recommandation à long terme de Google, et c’est la voie à suivre pour les nouvelles versions de site. En bref, tout le monde – les robots et les humains – obtiennent la vue initiale sous forme de code HTML statique intégralement rendu. Les robots d'exploration peuvent continuer à demander des URL de cette manière et obtiendront un contenu statique à chaque fois. Sur les navigateurs classiques, JavaScript prend le relais après le chargement initial de la page. C'est une excellente solution en théorie et présente de nombreux autres avantages en termes de rapidité et de convivialité; plus à ce sujet bientôt.

Ce dernier est plus propre, n’entraîne pas la détection d’UA et constitue la recommandation à long terme de Google. Il convient également de préciser que le «rendu hybride» n’est pas une solution unique; il résulte de nombreuses approches possibles pour rendre le contenu pré-rendu statique disponible sur le serveur. Décrivons maintenant les différentes façons d’atteindre un tel résultat.

Applications isomorphes / universelles

C’est l’une des façons de réaliser une configuration de «rendu hybride». Les applications isomorphes utilisent JavaScript qui s'exécute sur le serveur et le client . Ceci est rendu possible grâce à l'avènement de Node.js qui, entre autres choses, permet aux développeurs d'écrire du code pouvant être exécuté sur le backend ainsi que dans le navigateur.

Typiquement, vous allez configurer votre framework (React , Angular Universal, peu importe) à exécuter sur un serveur de nœud, en pré-rendant tout ou partie du code HTML avant son envoi au client. Votre serveur doit donc être configuré pour répondre aux URL profondes en rendant le code HTML de la page appropriée. Dans les navigateurs classiques, l’application côté client prend le relais de manière transparente. Le code HTML statique restitué par le serveur pour la vue initiale est "réhydraté" (terme génial) par le navigateur, ce qui le reconvertit en une seule page d'application et en exécutant les événements de navigation ultérieurs avec JavaScript.

Terminée, cette configuration peut être fantastique, car il offre les avantages en termes de convivialité du rendu côté client, les avantages en matière de référencement du rendu côté serveur et une première peinture rapide (même si Time to Interactive est souvent impacté négativement par la réhydratation lors de l'entrée en vigueur de JS). Par peur de trop simplifier la tâche, je n’entrerai pas plus dans les détails, mais le point clé est que, même si le rendu JavaScript isomorphe / vrai côté serveur peut être une solution puissante, il est souvent extrêmement complexe à définir. up .

Alors, quelles sont les autres options? Si vous ne pouvez pas justifier le temps ou les dépenses d'une configuration isomorphe complète, ou si vous tentez trop d'atteindre vos objectifs, pouvez-vous utiliser d'autres méthodes pour profiter des avantages du modèle d'application à page unique – et configuration de rendu hybride – sans saboter votre référencement ?

Prerendering / JAMstack

Avoir rendu le contenu disponible côté serveur ne signifie pas nécessairement que le processus de rendu lui-même doit avoir lieu sur le serveur. Tout ce dont nous avons besoin est que le rendu HTML soit là, prêt à être utilisé par le client; le processus de rendu lui-même peut se produire où bon vous semble. Avec une approche de JAMstack votre contenu est rendu au format HTML dans le cadre de votre processus de construction.

J’ai déjà écrit sur l’approche de JAMstack avant . En guise d'introduction, le terme désigne JavaScript, API, et balisage et décrit un moyen de créer des sites Web complexes sans logiciel côté serveur. Le processus d'assemblage d'un site à partir de composants frontaux – une tâche qu'un site traditionnel peut réaliser avec WordPress et PHP – est exécuté dans le cadre du processus de construction, tandis que l'interactivité est gérée côté client à l'aide de JavaScript et d'API.

de cette façon: tout habite dans votre référentiel Git. Votre contenu est stocké sous forme de fichiers de texte brut (modifiable via un CMS sans tête ou une autre solution basée sur une API) et vos modèles de page et votre logique d'assemblage sont écrits en Go, JavaScript, Ruby ou dans la langue utilisée par votre générateur de site préféré. Votre site peut être intégré en HTML statique sur n’importe quel ordinateur à l’aide du jeu approprié d’outils de ligne de commande avant d’être hébergé n’importe où. L'ensemble de fichiers statiques faciles à mettre en cache qui en résulte peut souvent être hébergé de manière sécurisée sur un CDN pour presque rien.

Je pense sincèrement que les générateurs de sites statiques – ou plutôt les principes et technologies qui les sous-tendent – sont l'avenir. Il ya toutes les chances que je me trompe, mais la puissance et la flexibilité de cette approche devraient être claires pour quiconque utilise un logiciel d’automatisation moderne basé sur npm comme Gulp ou Webpack pour créer leur code CSS ou JavaScript. Je mettrais tout le monde au défi de tester l'intégration en profondeur de Git proposée par le spécialiste de l'hébergeur Web Netlify dans un projet réel et de toujours penser que l'approche de JAMstack est une lubie.

L'importance d'une configuration de JAMstack pour notre discussion sur les applications sur une seule page et les prérendering devrait être assez évidente. Si notre générateur de site statique peut assembler du HTML à partir de modèles écrits en Liquid ou en Guidons, pourquoi ne peut-il pas en faire autant avec JavaScript?

Il existe un nouveau type de générateur de site statique qui ne fait que cela. Souvent générés par React ou Vue.js, ces programmes permettent aux développeurs de créer des sites Web à l’aide de frameworks JavaScript de pointe et peuvent être facilement configurés pour produire du code HTML statique, convivial pour le référencement, pour chaque page (ou "itinéraire"). Chacun de ces fichiers HTML est un contenu entièrement rendu prêt à être consommé par les humains et les robots, et sert de point d'entrée dans une application complète côté client (c'est-à-dire une application à une seule page). C’est une exécution parfaite de ce que Google a appelé «rendu hybride», bien que la nature précise du processus de pré-rendu le distingue nettement d’un montage isomorphe.

Un excellent exemple est GatsbyJS qui est construit en React et GraphQL . Je n’entrerai pas dans les détails, mais j’encourage tous ceux qui l’ont lu jusque-là à consulter leur page d’accueil et une excellente documentation . C'est un outil bien supporté avec une courbe d'apprentissage raisonnable, une communauté active (une v2.0 riche en fonctionnalités est sortie en septembre), une architecture extensible avec plugin, des intégrations riches avec de nombreux CMS, et il permet aux développeurs d'utiliser des frameworks modernes. comme Réagir sans saboter leur référencement. Il y a aussi Gridsome basé sur VueJS et React Static qui – vous l'avez deviné – utilise React

L'adoption au niveau de l'entreprise de ces plates-formes semble devoir se développer; GatsbyJS a été utilisé par Nike pour leur campagne Just Do It Airbnb pour leur site d'ingénierie airbnb.io et Braun l'ont même utilisé pour site de commerce. Enfin, nos amis de SEOmonitor l’ont utilisé pour alimenter leur nouveau site Web.

Mais c’est assez sur les applications à page unique et le rendu JavaScript pour le moment. Il est temps que nous explorions la deuxième de nos deux technologies clés qui sous-tendent les AHP. Promise vous resterez avec moi jusqu’à la fin (haha, plaisanterie de nerd), car il est temps d’explorer les travailleurs des services.

3. Travailleurs des services

Tout d’abord, je dois préciser que les deux technologies que nous explorons – les ASP et les travailleurs des services – ne ne s’excluent pas mutuellement . Ensemble, ils forment ce que nous appelons communément une application Web progressive, mais il est également possible d’avoir un PWA qui n’est pas un SPA . Vous pouvez également intégrer un agent de service dans un site Web statique traditionnel (c’est-à-dire sans aucun contenu restitué côté client), ce qui, à mon avis, se produira beaucoup plus prochainement. Enfin, les employés des services travaillent en tandem avec d’autres technologies telles que le Web App Manifest que ma collègue Maria a récemment exploré plus en détail dans son son ​​excellent guide sur les PWA et le référencement.

En fin de compte, cependant, ce sont les travailleurs des services qui rendent possibles les caractéristiques les plus intéressantes des AHP . C’est l’un des changements les plus importants de la plate-forme Web de son histoire et tous ceux dont le travail consiste à créer, maintenir ou auditer un site Web doivent connaître le nouvel ensemble de technologies performantes. Si, comme moi, vous avez regardé avec impatience la page de Is Service Worker Ready de Jake Archibald et que l'adoption par les éditeurs de navigateurs a augmenté vous le saurez Il est maintenant temps de commencer à construire avec les travailleurs des services.

Nous allons explorer ce qu’ils sont, ce qu’ils peuvent faire, comment les mettre en œuvre et quelles en sont les implications pour le référencement.

Que peuvent faire les travailleurs des services?

Un agent de service est un type spécial de fichier JavaScript qui s’exécute en dehors du thread principal du navigateur. Il se situe entre le navigateur et le réseau. Ses pouvoirs incluent les éléments suivants:

• Interception des requêtes réseau et décision de leur utilisation par programme. Le travailleur peut se connecter normalement au réseau ou s’appuyer uniquement sur le cache. Il pourrait même fabriquer une réponse entièrement nouvelle à partir de diverses sources. Cela inclut la construction de HTML.
• Préchargement de fichiers lors de l'installation du service worker. Pour les SPA, cela inclut généralement le "shell d'application" dont nous avons parlé précédemment, alors que de simples sites Web statiques pourraient choisir de précharger tous les codes HTML, CSS et JavaScript afin de garantir le maintien des fonctionnalités de base en mode hors connexion.
• similaire à une application native. Cela signifie que les sites Web peuvent obtenir l'autorisation des utilisateurs pour envoyer des notifications, puis faire appel au technicien de service pour recevoir des messages et les exécuter même lorsque le navigateur est fermé .
• Exécution de la synchronisation en arrière-plan report des opérations réseau jusqu'à ce que la connectivité se soit améliorée. Il peut s’agir d’une "boîte d'envoi" pour un service de messagerie Web ou d'une fonction de téléchargement de photos. Plus aucune «requête échouée, veuillez réessayer plus tard» – le technicien s'occupera de la traiter pour vous au moment opportun

Les avantages de ce type de fonctionnalités vont au-delà des avantages évidents liés à la convivialité. Outre qui a conduit à l'adoption de HTTPS sur le Web (tous les principaux navigateurs n'enregistrent que les opérateurs du service sur le protocole sécurisé), les opérateurs du service transforment en vitesse et en performance . Elles sous-tendent de nouvelles approches et idées telles que Google PRPL Pattern car nous pouvons maximiser l’efficacité de la mise en cache et minimiser la dépendance à l’égard du réseau. De cette manière, les employés du service joueront un rôle clé dans la création d'un accès rapide et accessible au Web pour le prochain milliard d'utilisateurs.

Donc, oui, ils constituent une puissance absolue.

Implémentation d'un prestataire de service

Plutôt que faisant un mauvais travail d'écriture d'un tutoriel de base ici, je vais plutôt créer un lien vers des ressources clés. Après tout, vous êtes le mieux placé pour savoir à quel point votre compréhension des travailleurs du service doit être approfondie.

Les MDN Docs sont un bon endroit pour en savoir plus sur les travailleurs du service et leurs capacités. Si vous êtes déjà confiant avec les éléments essentiels du développement Web et que vous appréciez une approche d’apprentissage par la pratique je vous recommande vivement de suivre le cours de formation PWA de Google . Il comprend un exercice complet sur les travailleurs des services, un excellent moyen de se familiariser avec les bases. Si ES6 et les promesses ne font pas encore partie de votre répertoire JavaScript, préparez-vous à un baptême du feu.

Il est essentiel de comprendre – et vous vous en rendrez très vite compte une fois que vous aurez commencé à expérimenter -, c'est que les travailleurs du service rendent un niveau incroyable de contrôle pour les développeurs. Contrairement aux tentatives précédentes de résoudre l’énigme de la connectivité (telle que le malheureux AppCache ), les prestataires de services n’imposent aucun modèle spécifique à votre travail; c’est un ensemble d’outils qui vous permet d’écrire vos propres solutions aux problèmes auxquels vous êtes confrontés

L’une des conséquences de cela est qu’elles peuvent être très complexes. L’enregistrement et l’installation d’un technicien de service n’est pas un exercice simple, et toute tentative d’en assembler un par copier-coller à partir de StackExchange est vouée à l’échec (ne le faites pas sérieusement). Il n’existe pas de prestataire de services prêt à l'emploi pour votre site . Si vous souhaitez créer un ouvrier approprié, vous devez comprendre l'infrastructure, l'architecture et les modèles d'utilisation de votre site Web. Oncle Ben, toujours le gourou du développement Web, a dit le mieux: un grand pouvoir implique une grande responsabilité.

Une dernière chose: vous serez probablement surpris de voir combien de sites que vous visitez utilisent déjà un technicien . Allez à chrome: // serviceworker-internals / dans Chrome ou sur: débogage # travailleurs dans Firefox pour afficher une liste.

Travailleurs de service et référencement

En ce qui concerne les implications en matière de référencement, la chose la plus pertinente à propos des travailleurs de service est probablement leur capacité à détourner des demandes et à modifier ou fabriquer des réponses à l’aide de l’API Fetch . Ce que vous voyez dans ‘View Source’ et même dans l’onglet Réseau n’est pas nécessairement une représentation de ce qui a été renvoyé par le serveur . Il peut s'agir d'une réponse en cache ou de quelque chose construit par le prestataire de services à partir de différentes sources.

Crédit : https://developer.mozilla.org/en-US/docs/Web/API / Fetch_API

En voici un exemple pratique:

• Dirigez-vous vers la page d'accueil GatsbyJS
• Cliquez sur le lien vers la page 'Documents'.
• Clic droit – Voir la source [19659012] Pas de contenu n'est-ce pas? Quelques scripts et styles en ligne, ainsi que des éléments HTML vides – une application JavaScript classique côté client, intégrée à React. Même si vous ouvrez l'onglet Réseau et actualisez la page, les onglets Aperçu et Réponse raconteront la même histoire. Le contenu réel apparaît uniquement dans l'inspecteur d'élément, car le DOM est en cours d'assemblage avec JavaScript.

  Exécutez maintenant une demande curl pour la même URL ( https://www.gatsbyjs.org/docs/ ), ou récupérez la page en utilisant Screaming Frog. Tout le contenu est là avec les balises de titre appropriées, les textes canoniques et tout ce que vous pouvez attendre d'une page rendue côté serveur. C’est ce qu’un robot d'exploration tel que Googlebot verra également.

  En effet, le site Web utilise un rendu hybride et un agent de maintenance (installé dans votre navigateur) gère les événements de navigation ultérieurs. Il n’est pas nécessaire qu’il récupère le code HTML brut de la page Docs sur le serveur car l’application côté client est déjà opérationnelle. View Source vous montre donc ce que l’agent de service a renvoyé à l’application pas ce que le réseau est retourné. De plus, ces pages peuvent être rechargées en mode hors connexion grâce à l'utilisation efficace du cache par le prestataire de services.

  Vous pouvez facilement identifier les réponses provenant du prestataire de services à l'aide de l'onglet Réseau – notez la ligne 'depuis ServiceWorker' ci-dessous. .

  

  Dans l'onglet Application, vous pouvez voir le service worker qui s'exécute sur la page en cours, ainsi que les différents caches qu'il a créés. Vous pouvez désactiver ou ignorer le travailleur et tester l'une des fonctionnalités plus avancées qu'il pourrait utiliser. Apprendre à utiliser ces outils est un exercice extrêmement précieux. Je n’entrerai pas dans les détails ici, mais je recommanderais d’étudier le didacticiel de Google "Fondamentaux de Google sur le débogage des services .

  

  J’ai fait un effort conscient pour limiter au maximum les extraits de code. article, mais accordez-moi celui-ci. J'ai présenté un exemple illustrant comment un simple opérateur peut utiliser l'API Fetch pour traiter les demandes et le degré de contrôle auquel nous avons droit:

  

  Le résultat:

  

  J'espère que cela (extrêmement simplifié et exemple non prêt à la production) illustre un point clé, à savoir que nous avons un contrôle extrêmement granulaire sur le traitement des demandes de ressources. Dans l'exemple ci-dessus, nous avons opté pour un modèle simple try-cache-first, fall-back-to-network, fall-back-to-custom-page mais les possibilités sont infinies. Les développeurs sont libres d’indiquer comment les demandes doivent être traitées en fonction des noms d’hôte, des répertoires, des types de fichiers, des méthodes de requête, de la fraîcheur du cache et de charges supplémentaires. Les réponses – y compris des pages entières – peuvent être fabriquées par le technicien de service. Jake Archibald explore certaines méthodes et approches communes dans son livre Offline Cookbook .

  Il est temps de se renseigner sur les capacités des travailleurs du secteur des services. Les compétences requises pour le SEO technique moderne se chevauchent assez bien avec celles d'un développeur web, et aujourd'hui, une compréhension approfondie des outils de développement de tous les principaux navigateurs – y compris le débogage des opérateurs de services – doit être considérée comme une condition préalable.

  4. Wrapping Up

  Les référenceurs doivent s'adapter

  Jusqu'à récemment, il était trop facile de ne pas comprendre les conséquences et les opportunités offertes par les PWA et les travailleurs du secteur des services.

  C'étaient des fonctionnalités de pointe qui se situaient à la périphérie. de ce qui était pertinent pour le marketing de recherche, et la méfiance susmentionnée de nombreux référenceurs vis-à-vis de JavaScript n’a rien fait pour encourager l’expérimentation. Mais les PVA sont en passe de devenir rapidement une norme et il sera bientôt impossible de faire un travail efficace sans comprendre les mécanismes de fonctionnement de . Pour rester pertinent en tant que technicien en référencement (ou ingénieur en référencement, pour emprunter un autre terme à Mike King), vous devez vous mettre à la pointe de ce type de développements qui changent de paradigme. Le SEO technique qui est analphabète dans le développement Web est déjà un anachronisme et je pense que de nouvelles divergences entre les aspects techniques et axés sur le contenu du marketing par moteur de recherche ne sont pas une mauvaise chose. Spécialisation!

  Dès qu’une équipe de développement apprend qu’un nouveau cadre JavaScript est créé pour la construction d’un nouveau site, il n’est pas rare que les référenceurs réagissent avec un certain cynisme. Je suis certainement coupable de plaisanter sur le fait que les développeurs sont attirés par la dernière technologie ou le dernier cadre brillant, et par la rapidité avec laquelle le monde du développement JavaScript semble évoluer, couche sur couche d'abstraction et d'automatisation s'ajoutant à ce que, de l'extérieur, peut souvent semblent être une tour penchée d'une pile de développement. Mais il faut prendre le temps de comprendre pourquoi les cadres sont choisis, alors que les technologies sont susceptibles de commencer à être utilisées en production, et les conséquences de ces décisions sur le référencement .

  Instead of criticizing 404 handling or internal linking of a single page app framework, for example, it would be far better to be able to offer meaningful recommendations which are grounded in an understanding of how they actually work. As Jono Alderson observed in his talk on the Democratization of SEOcontributions to open source projects are more valuable in spreading appreciation and awareness of SEO than repeatedly fixing the same problems on an ad-hoc basis.

  Beyond SEO

  One last thing I’d like to mention: PWAs are such a transformative set of technologies that they obviously have consequences which reach far beyond just SEO. Other areas of digital marketing are directly impacted too, and from my standpoint, one of the most interesting is analytics.

  If your website is partially or fully functional while offline, have you adapted your analytics setup to account for this? If push notification subscriptions are a KPI for your website, are you tracking this as a goal? Remembering that service workers do not have access to the Window object, tracking these events is not possible with ‘normal’ tracking code. Instead, it’s necessary to configure your service worker to build hits using the Measurement Protocol, queue them if necessary, and send them directly to the Google Analytics servers.

  This is a fascinating area that I’ve been exploring a lot lately, and you can read the first post in my series of articles on PWA analytics over on the Builtvisible blog.

  That’s all from me for now! Thanks for reading. If you have any questions or comments, please leave a message below or drop me a line on Twitter @tomcbennet.

  Many thanks to Oliver Mason and Will Nye for their feedback on an early draft of this article.