LoadTime & SEO : le TOP et FLOP des meilleures (et pires) intégrations. Le temps de chargement est de plus en plus important pour vos utilisateurs, votre business et vos rankings. Google, plus que jamais, prend en compte les différents temps de chargement comme indicateur de qualité des sites web. Pour rivaliser avec les meilleurs et flirter avec la note maximale de Lighthouse sur ce KPI, Erlé vous exposera les meilleures pratiques (ainsi que les pires) d’après sa propre expérience basée sur de nombreux sites qu’il a accompagnés dans leur parcours vers l’optimisation.

1. Web Perf pour le SEO
le top et le flop des
meilleures et pires optimisations

3. Erlé ALBERTON
15 ans de WEB
Speaker depuis 2004
Ex Responsable SEO Boutiques Orange &. Sosh
#1 Customer Success Manager OnCrawl
Ambassadeur OnCrawl France
Evangéliste Octopulse
Consultant technique grands comptes et agency
Acquisition & Digital Performance
Manager Reezocar
@cubilizer

5. Rappels
Un site rapide, c’est avant tout un site qui
favorise la rétention et que Google Crawl ++
-1 sec. = -10% de Rebond
-1 sec. = +15% de Conversion
20% des utilisateurs abandonnent leur
panier à cause du temps de chargement
Un temps de chargement divisé par 2
c’est 11% d’augmentation de panier
moyen

6. DNS
TTFB
FP
FCP
FMP
DOM
Speed Index
First CPU Ide
Le moment ou le browser
rend autre chose que sa page
blanche
First Paint
Moment ou apparaissent les
premières données utiles
Hero Time
First Meaningfull Paint
Le score de rapidité
d’affichage des éléments au-
dessus de la ligne de
flottaison
Temps avant la réception du
premier BIT de données
Time To First Bit
Apparition des premiers
éléments de layout
First Content Paint
Le DOM est en partie
chargée et les interactions JS
peuvent être jouées
Interactive/Content Loaded Le CPU souffle
le délai à partir duquel la
thread (fil d’exécution)
principale est suffisamment
disponible pour gérer les
entrées
Domain.com
=
xxx.xxx.xxx.xxx
Résolution DNS
A BRIEF HITORY OF LOAD.... … …. TIME
Time to Interactive
Temps a partir duquel
les éléments sont
cliquables ou utilisables
(input/form/liens)
On peut interagir
Visualy Complete
L’UX/UI commencent
La page est rendue, il reste
des taches en cours en
background mais rien
n’empêche la lecture
DOM Complete
Les JS synchrone sont
exécutés et les ressources
images les plus lourdes sont
chargées
Tout est là !
Page Load
Voilà, voilà on a
mit 12 secondes
à charger une
recette de cuisine
GA timing

7. C’EST SIMPLE….

9. LES OUTILS SONT
LA POUR SIMPLIFIER LA LECTURE

10. LA VERSION SIMPLE

11. Pourquoi Google aime les sites rapides
Le bot n’a pas de temps à perdre !
Plus une page charge rapidement plus le
bot peut crawler des pages
Rapide = plus de contenus analysées
Google veut connaitre le plus de pages
possibles il doit parcourir le maximum de
contenu en un minimum d’argent
2.15

13. L’image de 4Mo sur la HP
Lorsqu’une image est uploadée sur le
serveur via un BackOffice, vous DEVEZ :
1. Réduire sa taille à la taille d’affichage sur la page
2. Optimiser son poids
3. Choisir le meilleur format en fonction de votre
besoin de rendu
Cela évite de se retrouver avec une
image de 4000x3000px et 4Mo sur la
page

14. Page speed module
La page est rapide pour
l’utilisateur, mais le bot ne voit que
des appels PageSpeed à des
ressources certes optimisées mais
dont les temps de chargement
sont impactés par le « compute »
du module
La différence entre le temps de
chargement USER et BOT est
considérable !
https://DOMAIN.COM/ressources/references/miniatures/x150x150_accessoire-couteau-petrin-
xxl-du-robot-cuiseur-cook-expert-166550.png.pagespeed.ic.lvRFcHlWzT.webp

15. Le CDN gratuit
Passer sous CloudFlare est une très
bonne pratique mais, si l’on prend
la version gratuite, le TTFB vu par
Google est augmenté :/
Passage sur CloudFlare Gratis
Perte de Crawl :/  RollBACK !!!!

16. Le full JS
Les framework JS sont de plus
en plus utilisés par les
développeurs Front…
… mais on oublie que Google
(malgré ce qu’il dit) ne sait pas
vraiment voir tout le code
HTML et donc vos optimisation
SEO…

17. Ce que dit Google
Googlebot passe en mode « EVERGREEN »
A l’occasion du récent événement Google I/O, Google a
annoncé que son bot explorait dorénavant le web en
utilisant la dernière version de Chrome. En clair,
Googlebot se comporte maintenant comme un Chrome
version 74, et non 41 !

18. La réalité !
Seuls les outils de
rendu et de test
pour les webmasters
sont en Chrome
Evergreen…
Le bot est toujours
en 41, donc peu de
compréhension du
JS moderne ou
complexe

19. Le Server Side Rendering… avec Rendertron
… heureusement ils proposent
d’utiliser le SSR avec leur
middleware Rendertron…..
Problème :
+400ms pour chaque requête

20. La requête DB qui rame
Une bonne requête DB est une
requête qui va vite à l’essentielle
Sinon un simple appel peut couter
plus de 2 secondes au DOM LOAD
Une bonne architecture est essentielle
à une bonne WEB Perf

21. Lazy loading
Bien intégré c’est pertinent
mais si ce n’est pas à
l’encontre de l’optimisation du
contenu HTML vu par le BOT
(sans JS)
Ici, lorsque le JS est désactivé
l’image n’est pas présente
dans le code de la page

22. Redirect en boucle de la Home Page
Pour diverses besoins (switch
langage, mobile devices, …)
La home page peut jouer de
redirections et malheureusement
lorsqu’elles sont gérées avec les
pieds cela peut conduire à des
boucles infinie pour les BOTs

23. GA load Time mal compris
La construction d’un
dashboard qui fait peur n’est
pas bon pour le moral des
troupes !
Le chef cri, les devs pleurent,
les devOps se pendent !
Filtrer sur les pays qui vous
concernent !

25. QUELLE EST LA DIFFERENCE ENTRE CES
DEUX IMAGES ?1,3Mo

26. optimize-images 1.3.3
> pip install optimize-images
Un utilitaire d'interface en ligne de
commande (CLI) écrit en Python
pur pour vous aider à réduire la
taille des fichiers d'images
Cette application se veut pure Python,
sans dépendance particulière en dehors
de Pillow, assurant ainsi la compatibilité
avec une large gamme de systèmes, y
compris les iPhones et les iPads utilisant
Pythonista 3.

27. Lazy loading la bonne version !
Le lazyloading est
implémenté pour
les utilisateurs
Le bot voit ce qu’il y a
dans le <noscript>

28. Preloading de ressources
Profiter des « preload » navigateur pour améliorer les temps de
réponses de vos ressources dans la page où dans les pages suivantes

29. HTTP2
HTTP/2 (issu du protocole expérimental
SPDY de Google) est une version majeure
du protocole réseau HTTP utilisé sur le
World Wide Web
• Synchronise les appels de ressources
• Permet de profiter au maximum de preload et prefetch
• Compresse les header
• Réduit de le DOMLoad considérablement !

30. AVANT
appels en cascade
APRES
appels synchronisés

31. CDN
Content Delevery Network
A partir de (20+5)$/mois
• DNS ultra rapide
• HTTP2 natif
• Web Content Optimisation
• Optimisation des images
• CDN/caching
• GZIP agressi
• AutoMinify
• Argo*

32. CDN
ARGO: routage intelligent
dirigeant les visiteurs vers les
chemins les moins saturés et les
plus fiables du réseau privé de
Cloudflare
Réduit la latence du trafic
d'origine de 35 % en moyenne
et les erreurs de connexion de
27 %

33. JS async / defer
Charger un JS demande des
ressources au navigateur et
interrompt le parse du HTML
Si un script n’est pas essentiel pour
le FCP ou le FI

35. LES CACHES APPLICATIF
Varnish : est un serveur
de cache HTTP apparu en 2006
Déployé en tant que proxy inverse entre
les serveurs d’application et les clients
Il permet de décharger les serveur en
mettant en cache les données lorsqu’elles
ont été déjà demandée une fois
Les règles de cache sont données par les
administrateurs système pour conserver une
version statique des pages (cache) et servir
plus rapidement les requêtes, tout en
allégeant la charge des serveurs
REQUEST #1 :
pas de cache
REQUEST #2,n :
cache statique sans requête serveur

36. Strapi & Gatsby les magnifiques

37. Strapi
Strapi permet de bootsptraper une base
de donnée, un backoffice et une interface
sécurisée modulable et qui s’interface
avec Gatsby
Monter un backoffice en
3 lignes de codes
Lors du build final, Gatsby va créer un site
complétement static depuis le code
React/GraphQl
Un framework React /
GraphQL qui sera static en prod
ReactJS en FULL STATIC

38. UN PETIT CADEAU ?

39. LIGHTHOUSE BENCHER
Problématique :
Suivre les performance du site avec Lighthouse, sur
un pool d’URLs prédéfini et de manière
automatique afin de constater les
améliorations/défaut du site rapidement
Solution :
Grâce à un système basé sur des container Docker,
du shell script pour lancer Lighthouse headless, du
python pour parser les résultats et Logz.io pour
stocker les données nous suivons en temps réel les
performance d’un ensemble de pages. SpeedIndex
/ TTFB / JS loading/… peuvent être analysés dans
un dashboard gratuit et interactif !
Les sources de cette machine partagées sur GitHub aux participants
du WeLoveSEO ♥️

40. Merci…
…vous avez des questions !