De nombreux services (PageSpeed, Webpagetest, Gtmetrix, Dareboost, Lighthouse,…) proposent des analyses plus ou moins poussées des facteurs qui permettent d’améliorer votre site pour qu’il soit plus performant et efficace. La mise en oeuvre de certains points nécessite de grosses ressources et qui peuvent être coûteuses et inefficaces. Gilles Tran vous propose de faire le tour des facteurs qui vont vous permettre de gagner de réelles et précieuses secondes sans pour autant déployer des ressources importantes ou effectuer une refonte totale. Des solutions vous sont proposées en fonction de l’importance du site web et de son potentiel de mise en œuvre.
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 ***
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
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
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,…)
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-sur
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
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-defe
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)
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,…
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/