Webperf & SEO : les mythes et la réalité
•Télécharger en tant que PPTX, PDF•
0 j'aime•2,541 vues
Avoir un site rapide n'est plus une simple option, que ce soit pour vos utilisateurs ou pour les crawlers. Depuis 2010, la vitesse d'un site est prise en compte par Google et en juillet la vitesse sur mobile sera un facteur de classement officiel (Google Speed Update). Mais dans quelle mesure ? Concrètement, est-ce que gagner une seconde de temps de chargement fait gagner des positions ? Quelles sont les optimisations webperf qui marchent le mieux ? Y'a t il des optimisations contre-productives ? Faut il optimiser spécifiquement pour les robots ? Combien de pages Google peut crawler en 24h ? Au travers de cas concrets vus chez Fasterize et du témoignage de RueDuCommerce, nous essaierons de faire le point sur les mythes et les réalités de l'impact de la webperf sur le SEO en 2018 !
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (8)
Similaire à Webperf & SEO : les mythes et la réalité
Similaire à Webperf & SEO : les mythes et la réalité (20)
Webperf & SEO : les mythes et la réalité
- 1. Webperf & SEO Mythes & réalités Stéphane Rios / Aniss Boumrigua
- 2. • Stéphane Rios, CEO Fasterize, ex-CTO RueDuCommerce • Solution en mode SaaS qui accélère l’affichage des sites web • Startup française créée en 2011, leader européen du FEO • Plusieurs centaines de millions de pages vues traitées par mois • 200 sites accélérés • Experts de la webperf • Classement JDN
- 3. Comment ça marche ? 1 2 3 Le navigateur transmet une requête http vers la plateforme. Fasterize intercepte les requêtes des internautes vers le site (comme un proxy). 1 Fasterize récupère les pages et les ressources demandées aux serveurs d'origine et analyse le code html, le javascript, le css et les images. 2 Fasterize applique les règles d’optimisation (des plus connues aux plus récentes). Chacune de ces règles est préalablement sélectionnée et testée par nos experts techniques afin de garantir la qualité de nos services. 3 Fasterize génère le contenu optimisé à la volée avant de le renvoyer au navigateur. Celui-ci est bien sûr mis en cache si la réponse du serveur d'origine le permet. 4 4
- 4. RueDuCommerce • Création en 1999 • Marketplace en 2007 • Sous pavillon Carrefour 2016 • Volume d’affaire +400M€ • +4M d’offres actives • 5M de VU par mois
- 5. Disclaimer Nous ne sommes pas des experts SEO !
- 6. Un peu d’histoire …
- 8. 2009 - 2010 • Let's make the web faster • Premier plugin PageSpeed • Speed = (small) ranking factor • “the current implementation mentions that fewer than 1% of search queries will change as a result of incorporating site speed into our ranking”. Matt C. • PageSpeed online
- 9. 2011
- 10. 2013 - 2014 • “You don’t get a boost for having a fast site. Sites that are outliers in terms of being slow will rank lower. All other things being equal, a site that’s too slow will rank lower.” Matt C. / SMX Seattle • Googlebot devient capable d’exécuter du JS : il s’approche du comportement de vrais utilisateurs • HTTPS comme critère de ranking
- 11. 2015 • “Mobilegeddon” • la prise en compte du mobile par les sites devient un critère de ranking • Expériences diverses • Red Slow Label • Slow to Load • AMP !
- 12. 2016 - 2018 • Index Mobile-First • Chrome UX Reports (CrUX) intégré dans PageSpeed Insights • Nouveaux outils • Google Speed Update
- 13. C’est quoi un site rapide ?
- 14. Métriques techniques • Temps de réponse serveur • TTFB • DomContentLoaded • (= DomReady) • Onload
- 15. Métriques UX • Start Render • Speed Index • First ContentFul Paint • First Interactive • Visually Complete
- 16. Et pour Google ? • Time To Download Page (≠ TTFB) • CrUX • Mobile / 90th • FCP • + DCL • + onload
- 17. Et Google Analytics • Métriques techniques • Possibilité de remonter d’autres métriques • Des défauts • moyenne • sampling • Certainement pas utilisé par Google pour le ranking
- 18. Impact TTFB • Etude Moz / Zoompf (2013)
- 19. Dans la vraie vie
- 20. Modernisation de la plate-forme web • Refonte from scratch • Home, Search, Browse, PDP
- 21. Déploiement AVANT TYPE DE PAGE APRES 1500ms Fiche produit 45ms 1200ms Liste produit 150ms 900ms Moteur de recherche 150ms RESULTATS
- 22. Et sur le SEO ?
- 23. Crawl Crawl Google bot Temps de téléchargement mesuré par Google
- 24. Et pourtant … CLASSEMENT JDN MARS 2017
- 25. SpeedIndex : de 9000 à 2800
- 27. Classement JDN Décembre 2017 Janvier 2018
- 29. Impact Business Taux de conversions site mobile : +56% par rapport à N-1
- 30. Crawl
- 31. Crawl
- 32. Dans la vraie vie (bis)
- 33. Résultats Fasterize • Tests sur un client Fasterize, été 2015 TTFC Load Time Dom Ready StartRender TTFB Speed Index Avec Fasterize 9,836 5,943 3,238 2,095 1,295 2719 Sans Fasterize 11,217 7,349 5,19 3,303 1,885 4024 Différence moyenne -12,3 % -19,1 % -37,6 % -36,6 % -31,3 % -32,4 %
- 34. Résultats GA
- 35. Résultats GA Load Time Taux de transfo Panier Moyen Pages vues /visite Taux de rebond Avec Fasterize 4,01 1,05 744,57 € 3,09 36,42 % Sans Fasterize 9,26 0,98 743,08 € 3,03 36,12 % Différence moyenne -56,7 % 7,1 % 0,2 % 2,0 % 0,8 %
- 36. Test du Khi2
- 37. SEO • Temps de téléchargement de la page divisé par 2 • Nombre de pages crawlées en hausse • Changement léger dans le classement • Suivi de position via un outil dédié • 23/07 : +10 mot clefs en position 1-3 • 08/08 : +22 mots clefs en position 1-3
- 40. Les erreurs à éviter
- 42. HTTP vs HTTPS vs HTTP2
- 43. HTTP1.1 vs HTTP2 + unsharding • Pas de HTTP2 + nombreux domaines différents : coûts des connexions TLS (6 par domaines) et DNS ! HTTP1.1 HTTP2 sur le domaine principal
- 44. Redirections • Peu importe le code (30x) • … mais vaut mieux le faire avec un redirect permanent • et laisser Google découvrir le trafic HTTPS
- 45. Une mauvaise expérience HTTPS
- 46. Images • Utilisation d’un mauvais sous-domaine pour les statics • Lazyloading / inlining / versionning ont peu d’impact
- 47. CDN • Utilisation d’un CDN mal configuré • les robots Google ont des IP Anycast • certains CDN détectent les robots aux US ! • forcer le POP du CDN si trafic géographiquement délimité
- 48. A retenir
- 51. Se détacher
- 52. Passer à AMP ? • Contraintes (très) fortes de webperf • pages cachables • chargement limité des scripts, widgets, etc … • Limitations dans les fonctionnalités • a démarré pour les sites de contenu • de plus en plus de fonctionnalités ecommerce • Activable facilement avec un CMS • Favorisé dans certaines pages de résultats
- 53. Faut il avoir peur ? • Cf. Annonces passées • Google ne fait que s’adapter !
- 54. Et le mobile ?Attentes sur mobile 71% des mobinautes s’attendent à ce qu’une page web se charge au moins aussi rapidement sur mobile que sur ordinateur (contre 58% en 2009) 46% estiment que les sites se chargent généralement plus lentement sur mobile que sur ordinateur Pour 60% des mobinautes, une page web doit se charger en moins de 3 secondes sur un mobile
- 55. Taux de conversion mobile
- 57. Questions ?
Notes de l'éditeur
- Bonjour à tous Merci à tous d’être venus nous écouter, Aniss et moi-même. Aujourd’hui, nous allons vous parler des liens qui peuvent exister entre Webperf et SEO essayer de faire la part des choses comme on dit, et ce avec des exemples concrets.
- Je me présente je suis Stéphane rios, président et fondateur de Fasterize depuis presque 7 ans maintenant et auparavant j’ai passé 10 comme CTO de RueDuCommerce. En résumé, Fasterize c’est un Next-gen CDN qui réécrit les pages à la volée pour appliquer tous les conseils de PageSpeed Insights Nous sommes des experts de la webperf : On publie des livres blancs on co-organise le Meetup webperf On co-organise la conférence WeLoveSpeed qui aura lieu le 9 octobre à Bordeaux Bref, on est présent dans l’écosystème Webperf
- Rapidement, Fasterize c’est un super proxy dans le cloud, qui réécrit les pages HTML à la volée. Aniss je te laisse te présenter ?
- Bonjour, Je m’appelle Aniss Boumrigua, je travaille chez rdc depuis plus de 10 ans et depuis quelques années je suis en charge du Front Office chez RueDuCommerce. J’espère que vous connaissez tous RueDuCommerce, un des leaders du eCommerce en France.
- D’abord, j’aimerais rappeler que nous ne sommes pas des experts du SEO. On a une culture générale du SEO mais nous voyons principalement ça sous l’angle technique. Donc on dira certainement des bêtises, n’hésitez pas, profitez des questions à la fin pour nous corriger !
- Commençons par remonter un peu dans le temps. Euh …ce n’est pas l’histoire du SEO en général sinon on va remonter loin mais un bref historique des liens entre Webperf et SEO. Ou plutôt entre webperf et google
- Car oui, dans d'autres parties du monde, ce n'est pas forcément vrai mais pour moi SEO = Google.
- Tout a commencé aux environs 2009 quand Google a pris une initiative nommée « Let’s make the Web faster » pour rendre eh ben … le web plus rapide par tous les moyens possibles. Depuis, c’est devenu leur Mantra. Je ne sais pas si certains se souviennent de ce graph qu’on avait avant sur les GWT Et je ne sais pas combien d’entre vous savent comment il faut lire la ligne entre le vert et le rouge. Quelqu’un sait ce que ça représente ? C’est le 20th percentile, seulement 20% des sites testés par Google à l’époque étaient plus rapide que cette ligne En 2010, petite bombe dans le milieu du SEO : un certain Matt C. annonce que la vitesse des sites devient un signal de ranking. A partir de là, mon business est né, merci Google. Plus sérieusement, ça marque vraiment le départ de la prise en compte de la webperf pour le référencement naturel.
- La vitesse chez Google ce n’est pas que pour les sites c’est aussi le principal avantage mis en avant pour ses produits. En 2011, quand Google fait de la pub pour Chrome dans le métro, tout tourne autour de la vitesse. On est loin des fonctionnalités farfelues ajoutées à l’époque par Internet Explorer (qui se rappelle du web slicing ?) …
- 2013-2014, le même Matt C. ajoute quelques précisions sur ce critère de vitesse et finalement dit tout haut ce que tout le monde a constaté … Faut vraiment avoir un site lent pour être pénalisé. Pendant ces années, Googlebot devient capable de lire du JS (et auaujourd'hui capable de quasiment tout lire) et donc se rapproche du comportement des utilisateurs. Le HTTPS devient un signal de ranking, là encore, rien de fousfous. A priori, 1% des requêtes seulement pourraient être affectées. Mais ça montre la voie. Ajd, une bonne partie du trafic Internet est en HTTPS.
- 21 avril 2015 : c’est le Mobilegeddon. L’adaptabilité des pages à la consultation mobile devient un critère de ranking. Les expériences Red Slow Label et Slow to Load sont aussi menées en 2015. D’ailleurs, c’est toujours drôle de voir Youtube en Slow To Load même si ça s’explique. Je peux vous dire que ça en a effrayé plus d’un !! En parallèle, Garry Illyes (Webmaster Trends Analyst chez Google) évoque à demi-mots que la vitesse pourrait constituer une deuxième étape après l’adaptabilité au mobile . Et enfin, 2015 se termine avec l’introduction du projet Google AMP (Accelerated Mobile Pages). Google commencera l’année suivante à mettre en avant AMP dans ses résultats de recherche (Carrousel AMP).
- 4 novembre 2016 : Google annonce l’indexation Mobile First. Avec une mise en place confirmée à partir d’octobre 2017 pour certains sites (par le même Gary Illyes) Ils ont lancé mis à jour PageSpeed Insight, lancés de nouveaux outils (TestMySite, Speed ScoreCard) et cette année, re-boum, le Google Speed Update qui indique que la vitesse sur mobile sera prise en compte (nan, sans blgue ?) Le moins qu'on puisse dire c'est que depuis 10 ans, ils ont respecté ce credo de la vitesse Et c’est vrai que quand vous interrogez un expert SEO, la perf revient invariablement dans les critères avec les critères principaux tel que la sémantique, netlinking etc ...et le mobile
- Bon, mais c’est quoi un site rapide ? Parce qu’il existe plusieurs façons de mesurer, plusieurs définitions. Faisons un petit tour rapide.
- On commence par les métriques techniques parce que c’est ça qu’on a mesuré pendant longtemps. On s’est longtemps focalisé sur le temps de réponse serveur : ouais c’est super mon serveur répond en 100ms. De là est né le TTFB, popularisé par WPT, c’est un temps de réponse serveur mais pas que : il prend aussi en compte la latence puisque c’est le temps qui se passe entre le départ d’une requête et l’arrivée du premier octet. On a aussi longtemps parlé de loading time, qui n’est en fait que l’événement « onload » du navigateur et qui indique que globalement le navigateur a fini de charger les éléments. Sauf que pas tout à fait, on peut aujourd’hui parfaitement truander le navigateur et lui faire croire qu’il a fini. Le problème avec ces métriques c’est que : 1 . Les internautes ne vivent pas dans des datacenters 2 . Elles ne rendent pas compte de l’expérience utilisateur
- Et c’est là qu’interviennent les métriques qu’on utilise depuis quelques années maintenant (j’espère que vous êtes familier de ces noms ?) Start Render, c’est le moment … Le Speed Index mesure quant à lui le rythme de remplissage du contenu au dessus de la ligne de flottaison. Le but c’est vraiment de faire en sorte qu’on ait le contenu le plus rapidement possible. FCP, c’est FI correspond au moment où l’utilisateur peut utiliser la page ! Et enfin le Visually Complete comme son nom l’indique dit quand est=ce qu’on a fini de remplir la page
- Et Google dans tout ça ? Ce que Google remonte depuis des années, c’est le temps de téléchargement d’une page. Démerdez-vous avec ça ! En vrai, ça veut dire quoi ? . C’est une moyenne ? Une médiane ? Sûrement une moyenne . Ça n’est pas le TTFB : cela prend en compte tout le code HTML (il en a besoin pour lire ce qu’il y a dedans) == on peut avoir un très bon TTFB mais avoir un temps de download pourri parce que les pages sont énormes. . Ça n’est pas le TTFB non plus car Google, lui, vit dans un datacenter. Donc la latence joue très peu à ce niveau (c’est une bonne nouvelle au cas où vous n’auriez pas suivi Depuis quelques mois est apparu le CrUX : Chrome User Experience Report (CrUXR ?) qui est une tentative pour réconcilier mesures réelles (c’est du RUM sur les navigateurs Chrome seulement), métriques techniques et métriques UX Il est utilisé dans PageSpeed Insight, dans Speed Scorrecard, etc …
- Vous allez me dire, on a aussi d’autres infos via Google, c’est Google Analytics. Oui vous avez raison. GA n’est pas la panacée car la configuration par défaut est pas terrible : moyenne, sampling Mais elle permet d’avoir déjà des informations sympathiques sur la perf des mes utilisateurs. Ceci dit, ça a souvent été précisé, ce n’est certainement pas utilisé pour le ranking vu le peu de fiabilité de cette mesure.
- J’aimerais revenir 2 minutes sur une des rares étude qui ait été faite sur une plutôt grande échelle (2000 mots clefs, 50 sites, 100000 pages). Cette étude montrait qu’il y avait assez peu de corrélation entre temps de chargement et positions dans le classement. Par contre, sur les premières positions, on voyait une corrélation assez forte avec le TTFB. C’est de là qu’est né la légende du TTFB dans le SEO : tout faire pour avoir un site qui répond super vite au niveau backend.
- Mais dans la vraie vie, comment ça se passe ? Aniss, c’est à toi, j’aimerais que nous explique un peu ce que vous avez vécu en terme de webperf ces deux dernières années et ce que vous en avez tiré comme enseignement, notamment d’un point de vue SEO
- Et au niveau SEO ? Vous avez vu des choses ?
- Oui. Quand on a fait la première migration, on est passé de 400000 pages vues crawlées à 3 millions ! Par contre on a peu vu d’impacts sur el positionnement. Ensuite, on a mis un CDN en place : explications Cloudflare Mais là, assez peu d’impact sur le crawl, idem sur le ref Au final, on est dans une situation moins bonne qu’avant mais qui ne nous fait pas souffrir.
- Parle pour toi ! Ce n’est pas le cas de tout le monde : j’ai un client de Fasterize qui n’a pas vécu la même chose lui ! (Heureusement ça s’est bien fini)
- Merci Aniss J’aimerais vous raconter une expérience qu’on a faite il y a quelques années sur un de nos clientS. Chez Fasterize, on aime bien mesurer. On aime montrer l’impact de la webperf sur tout un tas de métrique, technique ou business (puisque la finalité c’est quand même faire plus de biz).
- Depuis le début, on a donc la possibilité de faire des tests A/B avec et sans Fasterize, pour voir les mesures des gens optimisés et non optimisés. Donc sur ce client, on avait un impact sympa (ce sont des médianes) avec un gain d’environ 30% un peu partout.
- Le truc c’est qu’on est capable de remonter ça dans GA en créant des variables personnalisées et des segments pour voir ces impacts.
- Et on est capable de voir ça aussi sur les métrique business Et là, bim, 7% sur le taux de transfo !
- Bien sur, on vérifie que ça a du sens avec un test statistique. Et comme ce client avait un outil pour suivre ses positions, on en a profité pour là aussi faire des mesures. Alors bien sûr, on ne peut pas faire de test A/B en SEO et c’est bien dommage. Mais on a quand même essayé de mesurer quelque chose.
- Voici ce que ça donne : on voit qu’on a une amélioration sur 2 mois des positions dans un peu tous les endroits.
- On voit aussi que l’outil permet d’apprécier l’évolution du trafic SEO en fonction de ces changements de positions. Ca n’est pas neutre _ Mais de là à conclure que c’est uniquement dû aux meilleures perfs … je ne m’avencerais pas …
- Avant de conclure, j’aimerais revenir sur quelques points webperf importants en terme de SEO.
- D’abord, l’impact du HTTPS.
- On voit sur ces filmstrips comparés 2 choses : . Passer en HTTPS est pénalisant ! Et en premier lieu pour le TTFB. . Utiliser HTTP2 n’est pas suffisant, il faut optimiser à fond pour avoir de bonnes perfs ! D’où ça vient ?
- N’oubliez pas les URL canoniques !
- Ça peut être vraiment catastrophique. On a un client qui n’était pas optimisé en HTTPS et malheureusement les résultats Google envoyait tout le monde vers du HTTPS. Résultat, double pénalité : la différence est flagrante !
- Autre chose qu’on a constaté, c’est sur la gestion des images. En fait, il faut faire super attention à la façon dont les images sont appelées, sur quel domaine, etc … Ça vaut particulièrement quand on installe ses images sur un CDN, qu’on n’a pas mis les bonnes URL canoniques ou bien que le sous=domaine ne nous appartient pas. Et dernière chose, les techniques de lazyloading, d’inlining et de versionning qui sont essentielles dans la webperf n’ont que peu d’impact si elles sont bien codées. On a le cas d’agence qui nous interdisent encore de mettre en place ces techniques … en 2018 …
- Et enfin, pour reprendre le cas de rueducomerce raconté par Aniss, effectivement, il faut faire attention !
- Ce que j’ai pu retenir en creusant les liens entre webperf et SEO c’est
- La pertinence d’abord. C’est bête mais ça fait du bien de le redire. Ce n’est pas parce que vous avez le site le plus rapide du monde que vous serez parmi les premiers. Je le redis : la vitesse n’est qu’un critère parmi des centaines !!
- D’ailleurs, si on compare 2 sites au hasard, rueducommerce et Leclerc premier. A votre avis qui est devant sur une requête comme tv 4K ?
- La deuxième chose que je retiens c’est que travailler sur la webperf, c’est long, et vous ne verrez certainement un impact que dans cette situation, que dans le cas où vous vous détachez du groupe. Inversement, vous ne serez pénalisé que si vous êtes à la traine par rapport à vos concurrents.
- Quid de AMP? Vous connaissez AMP ? Personnellement j’ai un avis assez réservé mais force est de constater que ça soit son chemin et que de plus en plus de sites sont en mesures de l’utiliser. A voir s’il y a un intérêt. Court-terme surement, long-terme, je ne sais vraiment pas.
- Enfin, le Google Speed Update, que faut il en penser ? Vous avez vu tout ce qui a été fait par le passé ? Pour moi ce n’est qu’une suite logique. Encore une fois, ça ne sera pas une révolution. Comme d’habitude, on en parle beaucoup, ça fait peur mais au final, ce n’est que google qui s’adapte.
- Parce que oui, le mobile c’est une réalité. La majeure partie du trafic est mobile auo aujourd'huiet eles attentes des internautes sont bien plus fortes. C’est souvent vu comme un pb parce que les taux de transfo actuel sur mobile sont moins bons et donc mécaniquement on fait baisser ce taux de transfo au glbal. Mais j’aimerais montrer un dernier graphique qui montre que ce n’est pas une fatalité.
- En fait ce graphique montre que si les perfs sur mobile sont au rdv, les taux de conversion sont plus importants.
- Je finirais par la chose la plus importante et qu’on vous répète souvent et je crois qu’Aniss sera d’accord avec moi : n’optimisez pas pour google mais pour l’internaute, le reste suivra. Google est un utilisateur comme les autres, soignez le !