Les clés d’un site (beaucoup) plus rapide selon des facteurs qui restent trop souvent oubliés Gilles Tran

1. #seocamp 1
Les clés d’un site
(beaucoup) plus rapide selon
des facteurs qui restent trop
souvent oubliés

2. #seocamp 2
Gilles TRAN
Consultant SEO

3. #seocamp 3
Pourquoi optimiser la webperf ?

4. #seocamp 4
Des visites
Sont abandonnées si la
page met plus de 3s à se
charger *.
La WebPerf
Oui, mais pourquoi ?
De délais Depuis Juillet 2018
53%
● * Source: Google Data, Aggregated, anonymized Google Analytics data from a sample of mWeb sites opted into sharing benchmark data, n=3.7K, Global, March 2016.
● **https://developer.akamai.com/blog/2015/09/01/mobile-web-performance-monitoring-conversion-rate
● ***https://www.searchenginejournal.com/google-ads-updates-mobile-speed-score-for-landing-pages/294401/
1sec
Peut impacter jusqu’à 20%
des conversions **
La vitesse de
chargement est un critère de
ranking pour les recherches
mobiles
Depuis Aout 2018
Un score de
vitesse sur mobile est
présent
dans Google Ads ***

5. #seocamp 5
Pour qui optimisons nous le site ?

6. #seocamp 6
Pourcentage utilisateurs Desktop Mobile
49%
33%
18%
* Source Médiamétrie 2018 : https://www.mediametrie.fr/fr/lannee-internet-2018 en France

7. #seocamp 7
Résolution d’écrans 2018-2019 France
0
2
4
6
8
10
12
14
16
2560x1440 1920x1080 1600x900 1440x900 1366x768 1280x800 375x667 360x640
1,9% > 1920px
1920 pixels c’est le pourcentage d’utilisateurs sur un
écran de plus de 1920px de large
* Source : http://gs.statcounter.com/screen-resolution-stats/all/france

8. #seocamp 8
Visible dans le “viewport”
Mobile Desktop

9. #seocamp 9
Contenu de la page
Mobile Desktop

10. #seocamp 10
Pages les plus visitées
Trafic bien diffusé Trafic concentré
Il s’agit ici des principales pages d’entrées sur le site (pages de destination) Captures : source GA

11. #seocamp 11
Conclusions
Pour qui optimisons-nous ?
Il faut connaître votre audience et ses usages de VOTRE site
pour cibler précisément vos actions d’optimisation.
_
Certains sites ont 80% de visites sur Desktop
lorsque d’autres l’ont sur Mobile
_
En optimisant une page vous pouvez
optimiser 75% de votre trafic

12. #seocamp 12
(Quelques) Principaux KPI de la
WebPerf

13. #seocamp 13
TTFB (Time To First Byte)
Le TTFB mesure le temps écoulé entre la requête
HTTP d'un client et le premier octet de la page reçu
dans le navigateur du client.
Les principaux KPI de la WebPerf
Speed Index
Le Speed Index est un indice de performance qui
indique à quelle vitesse le contenu d'une page
commence à être visible à l’utilisateur
FCP (First Contentful Paint)
C’est un critère important car s’est le premier instant
où l’utilisateur va voir des éléments s’afficher dans la
page
TTI (Time To Interactive)
Ce critère est très important sur le fait que c’est le
temps nécessaire pour que votre utilisateur puisse
commencer à interagir avec votre site et votre
service
Affichage Critique
C’est ce que l’internaute va voir à l’écran avant
même de pouvoir interagir avec la page. En général
ce qui est visible dans le viewport

14. #seocamp 14
Premières pistes d’optimisation

15. #seocamp 15
Lighthouse
Un plugin Chrome pour analyser vos web
performances (Obtention rapide des KPIs :
FCP, Speed Index, TTI,…)
Services d’analyse des webperfs
Webpagetest
Cet outil dispose du Speed Index (le
temps moyen à partir duquel la page
devient visible à l’utilisateur)
Gtmetrix
Ce service est rapide et pratique pour se
faire une idée sur ses performances sans
délais (accès rapide aux poids de page et
assets chargés)
PageSpeed Insights
Un service de Google pour analyser ses
performances en version mobile et
desktop (First Contentful Paint)
Utiliser l’un de ces services tiers pour obtenir des temps de chargement précis
Faire ressortir les premières pistes d’optimisations

16. #seocamp 16
Chrome Dev Tool
La console de Chrome ou de Firefox vous apporte
des informations précieuses en un clin d’oeil
119 images sur 137 assets au total
pour charger cette page

17. #seocamp 17
CSS
Bien que concaténés et minifies par de
nombreux sites, il existe encore de
nombreux sites qui font appel à de
nombreux fichiers CSS
Les 4 pistes fréquentes
JS
Le nombre de fichiers appelés est très
souvent de l’ordre de 35 à 50%
Images
Les images sont les fichiers qui
généralement représentent le nombre de
hits et le volume le plus important d’une
page
Réponse serveur
Le temps de chargement du code HTML de
votre page est bien souvent trop long. Des
ajustements doivent être faits sur votre
serveur (amelioration du TTFB,…)

18. #seocamp 18
Optimisation des images

19. #seocamp 19
Quelle taille pour mes images ?
3 points à vérifier
1) Indice : vérifier l’espace occupé par
l’image (en responsive)
2) Vérifier l’emplacement
alloué (col-md-6 pour
1920px on obtient 960px*)
3) Vérifier la taille de l’image
Dans cet exemple, il est probable que
l’image qui ne doit occuper que 50% de la
largeur de l’écran n’atteigne jamais 1200
pixels
Tips : Votre développeur peut tout à fait
faire ses appels aux images d’une largeur
définie en fonction de la largeur de la
colonne cible !
Source : https://www.creative-tim.com/presentation/
* 960 px, c’est 4 fois moins que 1920px !

20. #seocamp 20
Quelle taille pour mes images ?
Calcul avec breakpoints multiples
Pour un site responsive, la largeur d’affichage des colonnes est variable.
Dans certains cas, il faudra communiquer la largeur optimale à votre
développeur :
col-xs-12 : largeur max 576px
col-sm-6 : largeur max 768px / 2 = 384px
col-md-6 : largeur max 992 / 2 = 496px
col-lg-6 : largeur max 1200 / 2 = 600px
col-xl-4 : largeur max 1920 / 4 = 480px
Il faudra donc tenir compte de ces largeurs pour fournir vos dimensions
idéales surtout si vous utilisez les markups d’images responsive

21. #seocamp 21
Des images adaptées à mon audience
Nous avons vu que seul 1,9% de nos visiteurs
disposent d’un écran d’une taille supérieure à
1920px de large
Si votre audience est de 75% sur mobile vous
pourrez tout à fait adapter ces chiffres
Mis à part pour des sites d’images,
vous ne devriez jamais opter pour
des images d’une dimension
supérieure à 1920px
* Source : http://www.actea-consulting.fr/assurance-surpoids
3159x2106 px

22. #seocamp 22
Des images optimisées LossLess
Notre image de 3160px de large
une fois compressée permet un
gain de 82%
Notre image de 3160px réduite à
1920px de large puis compressée
permet un gain de 93%
* Source : https://www.imagerecycle.com/
Tips : Optimiser les images à l'aide d'une
librairie de compression (Google fournie lui-
même une librairie open source : Guetzli)

23. #seocamp 23
Des images adaptées au responsive
2 intégrations possibles
La balise « Picture » et
La balise image avec un attribut « srcset »
L’utilisation de « srcset » étant plus simple à
mettre en place
Chacune des 2 méthodes n’est cependant
pas 100% compatible avec tous les
navigateurs, mais les 2 profitent d’un
dégradé progressif sur l’attribut « src »
Tips : Il est tout à fait possible de lazy-loader
vos images responsives. Vous emploierez
l’attribut : data-srcset

24. #seocamp 24
Lazy-loader mes images
Seules les images de l’encadré
sont visibles dans le viewport
Il conviendra de toujours
charger les suivantes en
asynchrone et seulement
lorsque l’image sera à proximité
immédiate du viewport.
Tips : Vous pouvez lazy-loader toutes les
images <img/> et images de fond
* Source : http://www.mikiyakobayashi.com/projects

25. #seocamp 25
Lazy-loader mes images de fond
* Source : http://www.hellothierry.com/
Voici 2 exemples de scripts compatibles avec la
gestion du lazy-loading des images de fond :
Lazy-loading de Mika Tuupola : l'un des scripts les plus anciens
et aboutis sur cette problèmatique :
https://appelsiini.net/projects/lazyload/
Lazysizes de Alexander Farkas : Un script plus récent qui
permet aussi le lazy-loading d'autres éléments (expl. : iframes et
vidéos) : https://github.com/aFarkas/lazysizes
<div class="lazyload" data-src="original.jpg" />

26. #seocamp 26
Lazy-loader mes images de fond responsive
En ce qui concerne les images de fond, il n’y a pas
encore de solution efficace !
Il y a bien des tentatives : image-set
Mais c’est encore mal supporté
* Source : https://caniuse.com/#search=image-set
Une piste de solution ? Untested

27. #seocamp 27
Optimisation des JS & CSS

28. #seocamp 28
Le chargement du JavaScript
Synchrone : <script src="…"></script>
Les fichiers sont téléchargés au fur et à mesure de la lecture du code HTML par le navigateur
Le navigateur attends que le fichier soit téléchargé pour continuer à télécharger le reste de la page !
Cela va retarder l’affichage de votre page et avoir une incidence négative sur tous vos KPI de performances
Source : https://bitsofco.de/async-vs-defer/

29. #seocamp 29
Le chargement du JavaScript
Asynchrone : L’attribut “ASYNC”
ASYNC semble être un attribut plus souple (et c'est surtout plus récent) car il n'attendra pas que le DOM soit chargé pour être
appliqué. Néanmoins il faut savoir que si vous avez plusieurs scripts Async à télécharger, les scripts seront executés dès lors qu'ils
seront disponibles !
L'ordre ne sera pas préservé, il n’y a pas de respect des dépendances !
Pour 2 scripts « ASYNC » successifs, si le premier contient des fonctions et le second y fait appel, on pourra se retrouver dans la
situation ou l’appel des fonctions sera fait avant que nous les ayons téléchargées

30. #seocamp 30
Le chargement du JavaScript
Asynchrone : L’attribut “DEFER”
On sera alors peut-être tenté d'utiliser DEFER à la place, mais attention !
Les scripts ne seront exécutés qu'après le chargement complet du HTML
Si les scripts ont un effet sur le style d'un bloc de page, il faudra s'assurer que le contenu visible de ce HTML est bien rendu
correctement à l'aide des CSS (utilisation du progressive enhancement) sous peine de voir un saut de page des éléments (FOUC,
flash of unstyled content). Bonus : L’ordre des scripts est préservé avec « DEFER »

31. #seocamp 31
Le chargement du JavaScript
En bas de page : Avant la fermeture du </body>
L’utilisation des attributs « Async » ou « Defer » devient alors obsolète car le DOM est déjà chargé
Vous pouvez télécharger vos scripts en bas de code seulement si ces derniers n’ont pas d’incidence sur l’affichage
Vous perdez néanmoins un temps précieux de téléchargement en parallèle du code HTML
Inlining des petits scripts
Lorsque des scripts sont suffisamment petits (< 5kos), et que d’autres scripts peuvent dépendre de ce dernier, il peut s’avérer
nécessaire d’ « inliner » ce fichier (inclure le code directement dans votre HTML)

32. #seocamp 32
Le chargement du JavaScript
Exemple d’intégration

33. #seocamp 33
N’inclure que le nécessaire
jQuery UI
Supprimer les extensions inutiles
Ne cochez pas toutes les extensions lors du
téléchargement. Il ne faut prendre que le strict
necessaire !
Source : https://jqueryui.com/download/

34. #seocamp 34
N’inclure que le nécessaire
Bootstrap
Supprimer les extensions inutiles
Ne cochez pas toutes les extensions lors du
téléchargement. Il ne faut prendre que le strict
necessaire !
C’est valable pour les fichiers JS comme pour le CSS
Source : https://getbootstrap.com/docs/3.4/customize/
La dernière version de Bootstrap incluant toutes les fonctionnalités pèse 153kos minifiée
Les CSS de grille Bootstrap n’en pèse que 48kos
Mais il faut aussi faire du ménage dans ce dernier par rapport à vos besoins !
(https://getbootstrap.com/docs/4.3/getting-started/download/ )

35. #seocamp 35
Supprimer ou différer le chargement de vos scripts
Filtrer puis trier les assets chargés pour cibler vos efforts sur
les fichiers les plus volumineux
A l’aide de la console, vous pouvez voir rapidement les fichiers les plus volumineux pour cibler les actions qui vont
vous faire gagner le plus de poids

36. #seocamp 36
Astuce WordPress
Reprenez le contrôle du chargement de vos fichiers
De simples fonctions existent pour vous
permettre de supprimer et réordonner le
chargement de vos fichiers JS dans vos
templates WordPress

37. #seocamp 37
Le progressive Enhancement
Comprendre le principe d’amelioration progressive et son effet sur la vélocité de notre affichage
Exemple du “carousel”
Prenons l’exemple du carousel et décrivons
les étapes de chargement des fichiers pour
faire en sorte de parvenir à l’affichage
désiré
L’amélioration progressive est une manière de concevoir un site
web qui prend très largement en compte l'accessibilité, la
sémantique et le référencement. En séparant strictement le fond
(le contenu proposé à l'utilisateur) et la forme (l'enjolivement et les
interactions avancées), cette technique permet de
présenter un contenu simple et de rendre un
service minimum à tous les utilisateurs, quel que
soit le débit de leur connexion ou leur navigateur, tout en
améliorant progressivement l'affichage proposé en fonction de
l'équipement de l'internaute.
* Source : https://fr.wikipedia.org/wiki/Am%C3%A9lioration_progressive

38. #seocamp 38
Le progressive Enhancement
Etape 1
Afficher les premières images mises en
forme à l’aide de quelques lignes de CSS
et adaptées à la taille de l’écran
Télécharger 3 images et le CSS
correspondant

39. #seocamp 39
Le progressive Enhancement
Etape 2
Afficher les boutons Next / Prev
Et les puces en bas de slider
Télécharger les images des flèches et
les fichiers JS et CSS permettant le
bon fonctionnement et affichage du
slider

40. #seocamp 40
Le progressive Enhancement
Etape 3
Il faut maintenant preparer le
chargement des images suivantes qui
ont été lazy-loadées
Télécharger les images à l’aide de
votre script de lazy-loading

41. #seocamp 41
Le progressive Enhancement
Etape 4
Si vous voulez permettre aux internautes de
faire glisser les images à l’aide du scroll de la
souris
Télécharger le fichier JS de scroll de souris
(https://github.com/jquery/jquery-
mousewheel)

42. #seocamp 42
Le progressive Enhancement
Etape 5
Si vous voulez permettre aux internautes
de faire glisser les images à l’aide du doigt
sur leur écran mobile
Télécharger le fichier JS de “swipe” sur
écran tactile

43. #seocamp 43
Le progressive Enhancement
En rouge les fichiers qui ne ralentissent pas
l’affichage
Des économies non négligeables pour un
affichage critique beaucoup plus rapide
• Moins de poids
• Moins de hits en chargement synchrone
40kos
4kos
3kos
15kos
40kos
40kos
40kos

44. #seocamp 44
Le progressive Enhancement
J’utilise ASYNC, il faut donc
faire attention aux
dépendances
62kos
40kos
40kos
40kos

45. #seocamp 45
Améliorations usuelles du JavaScript
Quelques efforts usuels
• Minification
• Compression des fichiers (gzip, à appliquer par le server lors de l’envoie de vos fichiers)
• Concaténation des fichiers (si vous servez vos fichiers en protocole HTTP/1 (ce n’est pas nécessaire
en HTTP/2)

46. #seocamp 46
Autres fichiers qui méritent votre attention
Les fonts
Les fichiers de fonts sont des fichiers qui
peuvent ralentir de façon significative votre
chargement de page. Vous pouvez
opter pour un chargement
asynchrone de vos fonts.
Google et Typekit ont codéveloppé un script
pour vous aider en ce sens
Web Font Loader
Repo Github : https://github.com/typekit/webfontloader

47. #seocamp 47
Autres fichiers qui méritent votre attention
Les fonts
ATTENTION au FOUT
Flash Of Unstyled Text
Le FOUT, c’est ce moment ou vous obtenez un texte
qui n’est pas encore stylé par vos fonts et qui le
devient après chargement
Aussi, attention à ne charger vos fonts en asynchrone
que si ces dernières sont relativement rapides à
charger
Opter pour des fonts légères
Source : https://fonts.google.com/

48. #seocamp 48
Autres fichiers qui méritent votre attention
Les icons fonts
Les librairies de font d’icônes sont très pratiques pour
raccourcir les temps d’intégrations pour afficher vos
icônes
Cela a néanmoins un coût non négligeable !!!
Si vous ne prenez pas garde, vous pourriez charger des
fichiers volumineux de CSS, JS et de galeries icônes que
vous utiliserez ! Privilégiez l’utilisation de
versions SVG de ces librairies d’icônes
Utiliser des SVG inline
Créer ses propres pack de SVG
Par exemple ICOMOON APP permet de choisir ses icons parmi
les fonts les plus utilisées (Fontawesome, Material,…

49. #seocamp 49
Optimisation de la réponse
serveur

50. #seocamp 50
Pourquoi des Réponses serveur lentes ?
L’internaute demande une page, le serveur analyse la
demande et envoie la réponse
Une requête traditionnelle
Ce qui se passe réelement : Le server intercepte la demande,
interprête les scripts, fait appel à la base de données pour
obtenir les informations puis delivre la page
La même requête en détails
A chaque affichage, le serveur va
effectuer le calcul de tous les scripts
nécessaires à afficher la page.
Il va de plus faire de nombreuses
requêtes à votre serveur de base de
données
Lorsque vous expérimentez un pic de
trafic, le serveur va donc avoir du mal à
effectuer tous
les calculs et accès en BDD

51. #seocamp 51
Quelle solution : mise en place d’un cache
La mise en cache sous forme de plugins : Wordpress
WP Super Cache
Un plugin de cache développé et
maintenu par l’équipe derrière
Wordpress.com
WP Rocket
Un plugin “premium” reconnu des
experts
Lorsque les pages sont en cache, le serveur n’a plus besoin d’effectuer les calculs et appels en base de données
Vous allez donc normalement améliorer de façon significative le TTFB

52. #seocamp 52
Quelle solution : mise en place d’un cache
La mise en cache par un service SAAS : Cloudflare
Source : https://support.cloudflare.com/hc/fr-fr/articles/200172256-Comment-mettre-en-cache-du-contenu-HTML-statique-
Cloudflare s’intercale entre votre
utilisateur et votre serveur, ce qui
diminue les risques de surcharge
Cloudflare permet de servir
vos assets depuis ses propres
serveurs au plus proche de
votre utilisateur (principe du
CDN)
Il peut dans certains cas
mettre en cache vos pages
HTML

53. #seocamp 53
Quelle solution : mise en place d’un cache
La mise en cache par un serveur de cache : Varnish
Source : https://fr.wikipedia.org/wiki/Proxy_inverse
Varnish fonctionne en interceptant les requêtes
avant qu’elles ne parviennent à votre serveur
(que votre serveur soit sous Apache, Nginx ou
autre...)
Il ne transmet les requêtes au serveur applicative
que s’il ne dispose pas d’un cache valide.
Il permet ainsi de soulager énormément votre
serveur applicatif
Attention néanmoins, Varnish (Open source) ne sait gérer que des requêtes
HTTP, il faudra prévoir des développements supplémentaires pour servir
vos pages en HTTPS

54. #seocamp 54
Quelle solution : mise en place d’un cache
La mise en cache par un serveur de cache : Varnish
L'utilisation des ESI :
L'équivalent d'include plus dynamiques pour servir
des portions de pages avec une période de cache
différente (utile dans le cas où vous devez fournir
des informations sensibles susceptibles d’évoluer
sur une courte période de temps)
https://varnish-cache.org/docs/3.0/tutorial/esi.html
Il est possible d’utiliser 2 fonctionnalités de Varnish pour améliorer vos règles de mise en cache
L'utilisation du "Grace mode“ :
Donner une valeur “Grace mode” positive à un objet
indique à Varnish qu’il doit proposer le cache un certain
temps après l’expiration du TTL (Cela pendant que
Varnish rafraichi son cache)
https://varnish-cache.org/docs/trunk/users-guide/vcl-
grace.html
TTL, indique le temps pendant lequel une information doit être
conservée

55. #seocamp 55
Votre cache est-il efficace ?
La question qu’on ne se pose pas assez souvent !
Mon cache n’est efficace que si les délais de mise
en cache sont suffisants
Si votre cache dure 30 minutes mais que votre
page n’est consultée qu’une fois toutes les
2 heures, votre cache ne sera jamais utilisé !!!
Il conviendra d’étudier vos logs pour connaître la
fréquence de consultation de vos pages. Vous
pourriez procéder par template…
- Pages categories
- Pages articles
- …
Exemple :
Les pages dont les entêtes HTTP de
réponses sont en MISS ne sont pas
servies par votre serveur de cache
Test effectué à l’aide de :
SEO Tools For Excel
Sur une liste d’URL dans Excel
Fonction :
=HttpHeader(A2,"X-Cache")
Source : https://seotoolsforexcel.com/httpheader/

56. #seocamp 56
Question Mug
● Qu’est-ce que
l’inlining ?

57. #seocamp 57
MERCI AUX SPONSORS