SEO & Javascript en 2021 : Challenger les acquis - Alexandre Pinat - SEO CAMP'us Paris 2021
•Télécharger en tant que PPTX, PDF•
1 j'aime•3,041 vues
Conférence du cycle
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à SEO & Javascript en 2021 : Challenger les acquis - Alexandre Pinat - SEO CAMP'us Paris 2021
Similaire à SEO & Javascript en 2021 : Challenger les acquis - Alexandre Pinat - SEO CAMP'us Paris 2021 (20)
Plus de SEO CAMP
Plus de SEO CAMP (20)
SEO & Javascript en 2021 : Challenger les acquis - Alexandre Pinat - SEO CAMP'us Paris 2021
- 1. SEO & Javascript en 2021: Challenger les acquis
- 2. Paris 2021 #seocamp Cycle Tech SEO €15M 80 experts chiffre d’affaires SEO / SEA / SOCIAL / DATA Alexandre Pinat Team Leader SEO
- 3. Paris 2021 #seocamp Cycle Tech SEO introduction
- 4. Paris 2021 #seocamp Cycle Tech SEO 2009 : l’arrivée des Frameworks JS JavaScript : > une “surcouche” pour le visuel et le tracking > un outil SEO de manipulation du maillage 2009 JavaScript : > utilisation massive des Frameworks et SPA (Single Page Application) React Angular Vue Ember Svelte Next
- 5. Paris 2021 #seocamp Cycle Tech SEO 2014 : Google interprète et indexe le JS 2014 “Today, we'll talk about our capability to render richer websites — meaning we see your content more like modern Web browsers, include the external resources, execute JavaScript and apply CSS.” En réalité, les choses sont plus compliquées... PHASE 1 CRAWL PHASE 3 RENDER PHASE 2 INDEX Sans la phase 3, Google ne peut pas découvrir le contenu d’un site full JS. Problème : la phase 3 n’est pas systématique. Elle dépend des ressources disponibles.
- 6. Paris 2021 #seocamp Cycle Tech SEO Crawl et indexation immédiats des éléments HTML, à chaque passage de Google sur le site La différence entre HTML et JS pour Google HTML site web Découverte et interprétation des éléments JS non systématique, et donc non garantie à chaque passage de Google JS
- 7. Paris 2021 #seocamp Cycle Tech SEO Le JavaScript fait toujours peur aux SEO = JavaScript Problèmes de crawl et d’indexation Problèmes de temps de chargement Baisses de position
- 8. Paris 2021 #seocamp Cycle Tech SEO Mais le JS est très avantageux Pour un annonceur, développer un site en JS offre beaucoup d’avantages : > Expérience plus fluide avec peu de rechargement de page pour l’utilisateur > Mise en place de site et fonctionnalités plus riches > Déploiement et maintenance accélérés coté dev
- 9. Paris 2021 #seocamp Cycle Tech SEO La question n’est donc pas si mais comment déployer un site en JS sans risque SEO ?
- 10. Paris 2021 #seocamp Cycle Tech SEO ENJEU #1 crawlabilité
- 11. Paris 2021 #seocamp Cycle Tech SEO Fournir une version HTML du site à Google HTML JS User site web HTML site web
- 12. Paris 2021 #seocamp Cycle Tech SEO Client Side Rendering Framework JS Version HTML Utilisateur Framework JS Version HTML sans rendering Googlebot requête la page requête la page + Javascript SEO Pas SEO Friendly car Google n’effectue pas systématiquement la phase de rendering
- 13. Paris 2021 #seocamp Cycle Tech SEO Comment passer du JS au HTML ? VERSION HTML DU SITE SERVEUR WEB 2. Static Site Generation (SSG) - Prerendering 3. Incremental Static Regeneration (ISR) 1. Server Side Rendering (SSR)
- 14. Paris 2021 #seocamp Cycle Tech SEO 1. Server Side Rendering Framework JS Utilisateur Version HTML + Javascript Framework JS Googlebot Pour chaque requête, la page est construite à la demande du côté du serveur par le Framework JS Version HTML complète SEO Temps de réponse plus longs et performances dégradées requête la page requête la page SEO Le contenu fourni à Google est toujours “frais”, à jour
- 15. Paris 2021 #seocamp Cycle Tech SEO 2. Static Site Generation Framework JS Le framework JS (ou un service de prerendering) construit une version statique de toutes les pages du site SEO La fraîcheur des contenus fournis à Google est dépendante de la fréquence de build Build des pages HTML construit le build Utilisateur requête la page Googlebot requête la page SEO Chargement rapide car les pages sont rendues côté serveur et mises en cache
- 16. Paris 2021 #seocamp Cycle Tech SEO L’enjeu du SSG : le temps de Build PAGES BUILD TIME Plus le nombre de pages à générer est important, plus le temps de build augmente.
- 17. Paris 2021 #seocamp Cycle Tech SEO Comment donner à Google un contenu HTML à jour sur des dizaines de milliers de pages avec du SSG ? + Se positionner en SEO sur des requêtes locales coiffeur paris épilation marseille massage lyon Case Study : Kiute x
- 18. Paris 2021 #seocamp Cycle Tech SEO Case Study : Kiute x 50% du potentiel couvert 75% du potentiel couvert 90% du potentiel couvert 100% du potentiel couvert Part du potentiel de CA Nb de pages sur le site Potentiel de CA SEO Build < 10min Build 1j Build 2j Build 7j
- 19. Paris 2021 #seocamp Cycle Tech SEO 3. Incremental Static Regeneration (ISR) Le framework JS met à jour la version statique à chaque fois qu’une page est requêtée re-génération Pages HTML pré- générées à jour requête la page renvoie la page requête la page renvoie la page Framework JS Utilisateur Googlebot OU Utilisateur Googlebot OU SEO Contenus toujours à jour sur des pages chargées rapidement (car mises en cache) Pages HTML pré- générées Build
- 20. Paris 2021 #seocamp Cycle Tech SEO CSR Client Side Rendering SSR Server Side Rendering SSG Static Site Generation ISR Incremental Static Regeneration Fonctionnement Pour chaque requête, la page est construite du côté du navigateur (client) Pour chaque requête, la page est construite à la demande du côté du serveur par le Framework JS Le framework JS (ou un service de prerendering) construit une version statique de toutes les pages du site Le framework JS met à jour la version statique à chaque fois qu’une page est requêtée Avantages SEO x Le contenu fourni à Google est toujours “frais”, à jour Chargement rapide car les pages sont rendues côté serveur et mises en cache Contenus toujours à jour sur des pages chargées rapidement (car mises en cache) Inconvénients SEO Pas SEO Friendly car Google n’effectue systématiquement la phase de rendering Temps de réponse plus longs et performances dégradées La fraîcheur des contenus fournis à Google est dépendante de la fréquence de build x Frameworks disponible Tous les frameworks Tous les frameworks sauf Angular 1 et React Tous les frameworks avec Prerender.io ou Pupeteer, Gatsby et Nuxt nativement Next.js Framework JS et SEO : quelle option choisir ?
- 21. Paris 2021 #seocamp Cycle Tech SEO Recetter l'implémentation SEO Comment s’assurer que les versions HTML fournies à Google soient optimisées pour le SEO et similaires à celles présentées aux utilisateurs ? La Search Console de Google Les crawlers
- 22. Paris 2021 #seocamp Cycle Tech SEO ENJEU #2 performances
- 23. Paris 2021 #seocamp Cycle Tech SEO Le temps de chargement global d’une page se décompose en deux grandes étapes qui ont des impacts distincts. Rappel : les étapes du chargement temps de réponse du serveur Impact crawlabilité temps d’éxecution de la page par le navigateur Impact utilisateur (core web vitals) Impact SEO
- 24. Paris 2021 #seocamp Cycle Tech SEO Les ressources inutilisées en JS Les sites JS présentent souvent le même problème de performance : des ressources inutilisées sont chargées sur les pages Google PageSpeed Insights
- 25. Paris 2021 #seocamp Cycle Tech SEO Un bundle JS c’est quoi ? script1.js script2.js Home Page script3.js script4.js Product Page jquery.js hotjar.js ga.js Libs Bundle.js Module Bundler
- 26. Paris 2021 #seocamp Cycle Tech SEO Optimiser la taille du bundle JS La taille et l’optimisation du bundle JS sont les éléments qui ont le plus d’impact sur les temps de chargement d’une SPA. Google Lighthouse Ce bundle doit être le plus léger possible !
- 27. Paris 2021 #seocamp Cycle Tech SEO Tree Shaking Supprimer toutes les ressources inutilisées js1.js js2.js js3.js js4.js Bundle js8.js js6.js js7.js js5.js js4.js js5.js js6.js - Avant optimisation : ~3Mo - Après optimisation : ~750Ko
- 28. Paris 2021 #seocamp Cycle Tech SEO Code Splitting Charger uniquement les ressources utiles - toutes les ressources sont chargées Une seule requête Une requête par module + Seules les ressources utiles sont chargées
- 29. Paris 2021 #seocamp Cycle Tech SEO Contrôler les performances SEO Google Lighthouse Google PageSpeed Insights
- 30. Paris 2021 #seocamp Cycle Tech SEO conclusion
- 31. Paris 2021 #seocamp Cycle Tech SEO En résumé, un site JS SEO compliant c’est... Des pages générées en HTML pour Google Avec la solution technique la plus adaptée au framework JS utilisé et aux spécificités de votre site (volumétrie de page, fraîcheur du contenu, priorités SEO,...) Des performances optimisées En réduisant le poids des différents bundle JS et en évitant de charger sur chaque gabarit de page des ressources qui ne seront pas utilisées
- 32. Paris 2021 #seocamp Cycle Tech SEO JavaScript & SEO : rien d’impossible x x x x x x
- 33. Paris 2021 #seocamp Cycle Tech SEO une bonne communication entre les équipes Les conditions d’une réussite Le JavaScript en SEO, ce n’est pas compliqué si on est bien accompagné. Une équipe dev expérimentée Une maîtrise des sujets SEO et JS
- 34. Question Mug Paris 2021 #seocamp Cycle Tech SEO Quel framework Javascript supporte actuellement l’ISR ?
- 35. MERCI AUX SPONSORS Paris 2021 #seocamp Cycle Tech SEO
Notes de l'éditeur
- Bonjour à tous, et bienvenu a la conf : SEO & Javascript en 2021: Challenger les acquis ou je parlerai plus spécifiquement des Framework javascript et de leur impact en SEO
- Alexandre PINAT 14 ANS DANS LE SEO TEAM LEADER CHEZ PRIMELIS DEPUIS 3ANS primelis, c’est une agence spécialisé dans l’acquisition et la data On travaille avec des centaines d’acteurs. Sur les derniers, on a constater une forte augmentation des problématiques SEO lié au Javascript. C’est pour ca que j’ai choisi de vous parler de ce sujet aujourdhui.
- pourquoi? Pour rappel Google nous dit indexer le Javascript depuis 2014. Une déclaration sympathique mais dans les faits , c’est beaucoup plus compliqué. Aujourd’hui, l’indexation des sites web s’opère en 3 phases Pour un site classique, google découvre l’essentiel de l’information lors de la phase de crawl, la phase de rendu qui opère dans un second temps ne donnera pas beaucoup d’information supplémentaire. Pour un site full Javascript, Google n’obtiendra quasiment aucune information avant la phase de rendu. PROBLEME : les capacités de rendu de Googlebot sont beaucoup plus limité que ses capacités de crawl. Il faudra donc plus de temps a un site JS pour etre indexé DONC ses perfs SEO seront moins bonnes
- pourquoi? Pour rappel Google nous dit indexer le Javascript depuis 2014. Une déclaration sympathique mais dans les faits , c’est beaucoup plus compliqué. Aujourd’hui, l’indexation des sites web s’opère en 3 phases Pour un site classique, google découvre l’essentiel de l’information lors de la phase de crawl, la phase de rendu qui opère dans un second temps ne donnera pas beaucoup d’information supplémentaire. Pour un site full Javascript, Google n’obtiendra quasiment aucune information avant la phase de rendu. PROBLEME : les capacités de rendu de Googlebot sont beaucoup plus limité que ses capacités de crawl. Il faudra donc plus de temps a un site JS pour etre indexé DONC ses perfs SEO seront moins bonnes
- Ce sont des caractéristiques inquiétantes pour le SEO: outre les questions de crawlabilité et donc de performance SEO comme on l’a vu plus haut, on peut ajouter la problématique de temps de chargement. Le javascript reste un peu lourd à digérer pour les navigateurs - notamment sur mobile. Quand on voit ca, on n’a pas vraiment envie d’y aller.
- Sauf qu’en 2021, Les Frameworks JS sont une des tendances fortes du marché pour plusieurs raisons: Cela permet d’avoir une expérience plus fluide car on recharge pas les pages durant la navigation Cela permet de mettre en place des sites plus riches Enfin le déploiement et la maintenance sont accélérées du côté développement.
- Par conséquent en 2021, La question n’est pas de savoir si on y va mais comment on y va sans risque du point de vue SEO car OUI les solutions existent
- Le problème principal avec les SPAS c’est donc la crawlabilté. De base, le serveur ne transmet pas un HTML viable à googlebot. Pour contourner ce problème, il va falloir générer le HTML coté serveur POur faire cela plusieurs méthodes s’offres à nous; plus ou moins adapté en fonction de la taille et du type de site cible.. Prerendering Server Side rendering INcremental Static regeneration
- La 2ème solutions est actuellement la plus courante et c’est celle que vous allez retrouver sur tous les framweworks JS “moderne” Ici le build JS va générer les pages HTML à la volée toujours coté serveur lorsque celle-ci sont demandées. (On est finalement assez proche de ce qui peut se faire avec un site PHP) C’est bien pour les pages nécessitant un contenu dynamique (par exemple, tests A/B ou contenu personnalisé en fonction de l'identité de l'utilisateur final). C’est surtout très adapté pour les Pages nécessitant un contenu actualisé (par exemple, prix et disponibilité du commerce électronique). Oui mais car il y a un mais , cela peut poser de gros problèmes de perf et notamment de temps de réponse car le serveur va être sollicité pour générer la page a chaque requête. Il est donc fortement recommandé de coupler le SSR à une mise en cache sur CDN ou un reverse proxy type Varnish. ON va revenir un peu plus tard sur cette notion de cache qui est clé dans la réussite du projet. Framework concerné: ANgluar + universal Vue JS + nuxt React + next
- Le problème principal avec les SPAS c’est donc la crawlabilté. De base, le serveur ne transmet pas un HTML viable à googlebot. Pour contourner ce problème, il va falloir générer le HTML coté serveur POur faire cela plusieurs méthodes s’offres à nous; plus ou moins adapté en fonction de la taille et du type de site cible.. Prerendering Server Side rendering INcremental Static regeneration
- La 2ème solutions est actuellement la plus courante et c’est celle que vous allez retrouver sur tous les framweworks JS “moderne” Ici le build JS va générer les pages HTML à la volée toujours coté serveur lorsque celle-ci sont demandées. (On est finalement assez proche de ce qui peut se faire avec un site PHP) C’est bien pour les pages nécessitant un contenu dynamique (par exemple, tests A/B ou contenu personnalisé en fonction de l'identité de l'utilisateur final). C’est surtout très adapté pour les Pages nécessitant un contenu actualisé (par exemple, prix et disponibilité du commerce électronique). Oui mais car il y a un mais , cela peut poser de gros problèmes de perf et notamment de temps de réponse car le serveur va être sollicité pour générer la page a chaque requête. Il est donc fortement recommandé de coupler le SSR à une mise en cache sur CDN ou un reverse proxy type Varnish. ON va revenir un peu plus tard sur cette notion de cache qui est clé dans la réussite du projet. Framework concerné: ANgluar + universal Vue JS + nuxt React + next
- La 2ème solutions est actuellement la plus courante et c’est celle que vous allez retrouver sur tous les framweworks JS “moderne” Ici le build JS va générer les pages HTML à la volée toujours coté serveur lorsque celle-ci sont demandées. (On est finalement assez proche de ce qui peut se faire avec un site PHP) C’est bien pour les pages nécessitant un contenu dynamique (par exemple, tests A/B ou contenu personnalisé en fonction de l'identité de l'utilisateur final). C’est surtout très adapté pour les Pages nécessitant un contenu actualisé (par exemple, prix et disponibilité du commerce électronique). Oui mais car il y a un mais , cela peut poser de gros problèmes de perf et notamment de temps de réponse car le serveur va être sollicité pour générer la page a chaque requête. Il est donc fortement recommandé de coupler le SSR à une mise en cache sur CDN ou un reverse proxy type Varnish. ON va revenir un peu plus tard sur cette notion de cache qui est clé dans la réussite du projet. Framework concerné: ANgluar + universal Vue JS + nuxt React + next
- La 2ème solutions est actuellement la plus courante et c’est celle que vous allez retrouver sur tous les framweworks JS “moderne” Ici le build JS va générer les pages HTML à la volée toujours coté serveur lorsque celle-ci sont demandées. (On est finalement assez proche de ce qui peut se faire avec un site PHP) C’est bien pour les pages nécessitant un contenu dynamique (par exemple, tests A/B ou contenu personnalisé en fonction de l'identité de l'utilisateur final). C’est surtout très adapté pour les Pages nécessitant un contenu actualisé (par exemple, prix et disponibilité du commerce électronique). Oui mais car il y a un mais , cela peut poser de gros problèmes de perf et notamment de temps de réponse car le serveur va être sollicité pour générer la page a chaque requête. Il est donc fortement recommandé de coupler le SSR à une mise en cache sur CDN ou un reverse proxy type Varnish. ON va revenir un peu plus tard sur cette notion de cache qui est clé dans la réussite du projet. Framework concerné: ANgluar + universal Vue JS + nuxt React + next
- Voici un petit case study pour vous montrez comment on peut gérer intelligemment le cache en ISR sur la base de l’interet SEO des pages. Chez Primelis nous avons parmis nos client sous angular un client avec un important réferentiel localisé impliquant la nécessité de générer un grand nombres de pages. Afin d’optimiser la gestion de cache nous avons pris le parti de catégoriser nos pages en fonction de leur interet SEO. en effet, comme très souvent avec les requetes localisés le potentiel se concentre sur un faible nombre de pages lié au grande ville ( plus d’offres, plus de recherche). Cette analyse nous a permis de déterminer 4 niveaux de cache en fonction du potentiel SEO des pages d’obtenir des temps de réponses satsisfaisant et de maximiser la fraicheur de la data sur les pages les plus importantes.
- Voici un petit case study pour vous montrez comment on peut gérer intelligemment le cache en ISR sur la base de l’interet SEO des pages. Chez Primelis nous avons parmis nos client sous angular un client avec un important réferentiel localisé impliquant la nécessité de générer un grand nombres de pages. Afin d’optimiser la gestion de cache nous avons pris le parti de catégoriser nos pages en fonction de leur interet SEO. en effet, comme très souvent avec les requetes localisés le potentiel se concentre sur un faible nombre de pages lié au grande ville ( plus d’offres, plus de recherche). Cette analyse nous a permis de déterminer 4 niveaux de cache en fonction du potentiel SEO des pages d’obtenir des temps de réponses satsisfaisant et de maximiser la fraicheur de la data sur les pages les plus importantes.
- La 2ème solutions est actuellement la plus courante et c’est celle que vous allez retrouver sur tous les framweworks JS “moderne” Ici le build JS va générer les pages HTML à la volée toujours coté serveur lorsque celle-ci sont demandées. (On est finalement assez proche de ce qui peut se faire avec un site PHP) C’est bien pour les pages nécessitant un contenu dynamique (par exemple, tests A/B ou contenu personnalisé en fonction de l'identité de l'utilisateur final). C’est surtout très adapté pour les Pages nécessitant un contenu actualisé (par exemple, prix et disponibilité du commerce électronique). Oui mais car il y a un mais , cela peut poser de gros problèmes de perf et notamment de temps de réponse car le serveur va être sollicité pour générer la page a chaque requête. Il est donc fortement recommandé de coupler le SSR à une mise en cache sur CDN ou un reverse proxy type Varnish. ON va revenir un peu plus tard sur cette notion de cache qui est clé dans la réussite du projet. Framework concerné: ANgluar + universal Vue JS + nuxt React + next
- La 2ème solutions est actuellement la plus courante et c’est celle que vous allez retrouver sur tous les framweworks JS “moderne” Ici le build JS va générer les pages HTML à la volée toujours coté serveur lorsque celle-ci sont demandées. (On est finalement assez proche de ce qui peut se faire avec un site PHP) C’est bien pour les pages nécessitant un contenu dynamique (par exemple, tests A/B ou contenu personnalisé en fonction de l'identité de l'utilisateur final). C’est surtout très adapté pour les Pages nécessitant un contenu actualisé (par exemple, prix et disponibilité du commerce électronique). Oui mais car il y a un mais , cela peut poser de gros problèmes de perf et notamment de temps de réponse car le serveur va être sollicité pour générer la page a chaque requête. Il est donc fortement recommandé de coupler le SSR à une mise en cache sur CDN ou un reverse proxy type Varnish. ON va revenir un peu plus tard sur cette notion de cache qui est clé dans la réussite du projet. Framework concerné: ANgluar + universal Vue JS + nuxt React + next
- La dernière solution c’est l’ISR et c’est la plus fonctionnel malheureusement elle n’est disponible que sur NEXT.JS Pour simplifier ca va mixer une approche de rendu à la volée et de la gestion de cache native qui permet a l’application de ne pas générer la page si le dernier snapshot est à jour. Cela vous permettre de gérer de très gros sites en prérendering sans faire exploser les perfs. cela demande cependant un peu plus de travail pour les développeurs pour gerer les pages avec des données très fraîches. par exemple: Zones du site où vous devez personnaliser la réponse en fonction de la demande (par exemple, tests A/B ou contenu personnalisé). Contrairement au rendu côté serveur, la réponse est rendue sans le contexte de la demande en cours. Les pages contenant des données "en direct" (par exemple, la disponibilité des stocks) - à moins qu'elles ne soient prises en charge par une extraction supplémentaire de données côté client.
- On vient de voir ensemble les enjeux moteurs, mais il y a également des enjeux utilisateurs a prendre en compte lorsqu’on travaille avec des frameworks JS qui ont des spécificités fortes.
- Un rappel rapide des 2 principales composantes du temps de chargement pour l’utilisateur utilisateur. Le temps de réponse dont on à déja parlé auparavant qui a également un impact sur la crawlabilité du site Le temps d’éxécution de la page par le navigateur (le rendu du HTML par le dom qui permet de tout afficher correctement à l’écran) C’est sur 2ème aspect que l’on va se concentrer car il y a la aussi quelques écueils a eviter avec les frameworks JS.
- Un rappel rapide des 2 principales composantes du temps de chargement pour l’utilisateur utilisateur. Le temps de réponse dont on à déja parlé auparavant qui a également un impact sur la crawlabilité du site Le temps d’éxécution de la page par le navigateur (le rendu du HTML par le dom qui permet de tout afficher correctement à l’écran) C’est sur 2ème aspect que l’on va se concentrer car il y a la aussi quelques écueils a eviter avec les frameworks JS.
- Le bundle JS : qu’est ce que c’est? Concretement aujourdhui, la plupart des framework JS vont packagés l’intégralité des dependances javascripts au sein d’un seul gros fichier utilisé sur toutes les pages du site. C’est certes très pratique pour les développeurs mais la taille de ce fichier que le navigateur devra charger au moins une fois peut vite exploser pour plusieurs raisons: présences de code inutile sur certaines pages présence de code morts En somme c’est un peu une boite noir coté front.
- le code splitting: Le code splitting permet de diviser votre code en plusieurs bundle qui peuvent ensuite être chargés à la demande ou en parallèle. Cela permet d’avoir des bundles moins lourd et ainsi de contrôler la priorisation du chargement des ressources.
- le code splitting: Le code splitting permet de diviser votre code en plusieurs bundle qui peuvent ensuite être chargés à la demande ou en parallèle. Cela permet d’avoir des bundles moins lourd et ainsi de contrôler la priorisation du chargement des ressources.