L’essor des usages mobiles change la donne du Web, entraînant une nouvel intérêt pour l’optimisation de l’expérience utilisateur, à commencer par la Performance Web. Mais pour appréhender la performance d’un site web, encore faut-il savoir quels indicateurs collecter, comment les interpréter et les améliorer. Quand on travaille sur un CMS comme WordPress, il est aussi important d’évaluer ce qui peut mettre en danger cette performance, et les techniques à développer pour s’en prémunir.

1. WP SUPER CACHE
ROCKET
RELOADED
suivre et améliorer la perf’ de son WordPress
sans s’arracher les cheveux
https://boris.schapira.dev/wcbdx

2. Boris
Schapira

3. Comprendre
Collecter & Automatiser
Savoir-faire, faire savoir
Maintenir

4. Google & la WebPerf

5. ● « Ne jamais livrer une fonctionnalité qui nous ralentit »
● Communication constante,
même une fois Chrome en position de leadership
● De l’investissement sur la performance:
○ outils ;
○ frameworks ;
○ protocoles ;
○ outils d’évaluation (tant Synthetic que Real User Monitoring).
● Et pour l’utilisateur ?
Google & la WebPerf

6. « Speed isn’t
just a feature,
it’s the
feature »
« The Google Gospel of Speed », Urs Hoelzle, 2012

7. Impacts
● Les optimisations qui mènent à :
○ ↘ Coûts d’exploitation
(réduction du bruit, gain de bande passante)
○ Une augmentation des gains publicitaires
● Évolution des usages, nouveaux marchés
● Essor des plateformes de contenus
● Capture des marchés émergents
● Structuration du domaine par
des Bonnes Pratiques

8. Comment se mesure
la performance web ?
Les types d’indicateurs, les indicateurs-clés

9. Dans un monde idéal…
Nous voudrions des indicateurs nous permettant de savoir quand un·e
utilisateur·ice :
1. a l’impression, en la regardant, qu’il peut interagir avec une page
2. peut réellement interagir avec la page et vivre une expérience positive
3. essaie réellement d’interagir avec la page, réussit, et le délai entre
l’action et sa prise en compte

10. SMART
● S comme Spécifique : compréhensible, clair
● M comme Mesurable : récupérable, non-uniquement qualitatif
● A comme Acceptable et Ambitieux : aux valeurs comparables
● R comme Réaliste : correspondant à une réalité
● T comme Temporellement défini

11. De nombreux indicateurs
● Des indicateurs issus :
○ du navigateur ;
○ de l’analyse vidéo ;
○ de l’observation du CPU et/ou du réseau ;
○ collectés auprès de vrai·e·s utilisateur·ice·s.
● Indicateurs de poids, de quantité, ou jalons temporels
● Indicateurs d’affichage, d’interactivité réelle ou supposée
● Indicateurs d’experts de la performance ou créés par le métier
C’est la jungle !

12. Les indispensables
● Les « temps serveur » :
○ côté serveur, avec une éventuelle instrumentation (Blackfire, New Relic) ;
○ ou côté client : Time To First Byte (TTFB).
● Les évènements navigateur :
○ DOMContentLoaded aka performance.timing.domContentLoadedEventEnd
○ load ou onload aka performance.timing.loadEventEnd
● ⚠ « temps de chargement »

13. Les « visuels »
● Start Render / First Paint : la page n’est plus « blanche »
Via la vidéo ou performance.getEntriesByName('first-paint')
● First Contentful Paint : premier pixel non blanc d’une image ou d’un
texte. performance.getEntriesByName('first-contentfull-paint')
● Visually Complete : la partie visible de la page (viewport) est
entièrement rendue
● et entre les deux ? Tout est possible !

18. Speed Index par l’exemple
200 ms 400 ms 600 ms 800 ms 1000 ms
0 % 60 % 75 % 90 % 100 %
0 % 60 % 60 % 60 % 100 %

19. Speed Index par l’exemple

20. Speed Index par l’exemple
1100

21. Speed Index par l’exemple
1280

22. Speed Index par l’exemple
200 ms 400 ms 600 ms 800 ms 1000 ms
0 % 60 % 75 % 90 % 100 %
0 % 60 % 60 % 60 % 100 %
1100 ❤
1280

23. Speed Index
● Mesure la progressivité de l’affichage par le calcul
du nombre de pixels de chaque couleur.
● Un bon indicateur de l’UX (eXpérience Utilisateur)
● Un indicateur pas si simple, perturbé par :
○ Les fonds colorés (état final + éloigné de l’état initial)
○ Tout ce qui bouge : carrousels, modales, vidéos
○ Les mauvais encodages vidéos
○ Les répartitions des pixels de couleurs =

24. L’interactivité réelle
● Delayed Interactions : à quelle fréquence l'interaction de l'utilisateur
a-t-elle été retardée de plus de 50 ms ? Se base sur le First Input Delay.
● Rage Clicks : clics répétés et rapides sur une zone du viewport
○ informe sur l’agacement des utilisateurs
○ entre 1,25 et 1,5 fois le temps nécessaire à l’affichage*
● Mouse Movements / Cursor Trashing : enregistrement des
mouvements rapides de souris sur l’interface
○ informe(ra) sur l’efficacité de l’interface
*+ d’infos : "User Experience & Performance: Metrics that Matter", Philip Tellis

25. Hors catégorie
● First Meaningful Paint : une tentative de capturer le moment
pertinent du rendu en observant les fontes, et les « layouts » du
navigateur dans le viewport.
● First Interactive / Time To Interactive : indicateurs complexes qui
observent à la fois les Long Tasks JavaScript (50 ms) et le trafic réseau
pour déterminer des fenêtres d’interaction « qualitativement
garanties » (⚠ noms trompeurs, communication Google ambiguë)

26. Comment mesurer ?
● Solutions synthétiques : produisent une navigation à la demande, en
contrôlant ou simulant des conditions, pour en capturer l’exécution et
calculer des métriques.
● Real User Monitoring : collecte des données auprès d’utilisateur·ice·s*
au fil de leur navigation, via un script ou le navigateur lui-même.

27. Comprendre
Collecter & Automatiser
Savoir-faire, faire savoir
Maintenir

28. Mes premières données
● Les mesures empiriques, c’est bien, mais ça ne donne pas une
information de qualité.
● Analyses ponctuelles : PageSpeed Insights, Dareboost
○ Vision objective, mais limitée (conditions, moment du test)
○ Conseils et bonnes pratiques
○ Parfois, des données RUM en plus (Chrome UX Report)

29. Données CrUX dans PageSpeed Insights

30. BigQuery, pour se servir soi-même

31. Et obtenir toutes les informations

32. Google Analytics aussi
● « Document Content Loaded Time » ou un Custom Timing
○ Éviter l’indicateur de « Page Load Time »
● Échantillonner à 100% en dessous de 20k PV/jour (siteSiteSampleRate)
● Segmenter pour analyser : matériel, navigateur, FAI…

33. Surveillance synthétique
● Contextes limités mais maîtrisés
○ Suivi dans le temps
○ Validation d’hypothèses
○ Pas d’installation (permet la mesure de concurrents)
● Stabilité permettant la levée d’alertes
● Parcours utilisateurs aussi
● mais pas uniquement

34. Comprendre
Collecter & Automatiser
Savoir-faire, faire savoir
Maintenir

35. Bonnes pratiques
● Quelques dizaines de BPs
○ testables
○ consensuelles
○ pas toujours universelles, mais pas loin
● Plusieurs grandes tendances
○ Optimisation de la diffusion : config serveur(s), protocole(s), CDN(s)
○ Optimisation du rendu : ressources critiques, ressources d’amélioration
○ Réduction des délai d’interaction

36. Quelques indémodables
● Un code HTML, CSS, et JS taillés avec soin, valide et épuré
○ CSS Purging ; JS tree-shaking… automatisez !
● Des domaines spécialisés (pages, assets) et des web serveurs adaptés
● Du cache (Varnish, CDN…)
● Des polices de caractères optimisées (subset) et non-bloquantes pour le
rendu (utilisez font-display)

37. Quelques indémodables
● Images :
○ adaptées à la surface de rendu et aux qualités de l’écran (srcset, picture)
○ optimisées* : le bon format en fonction du contenu, optimisé suivant le navigateur
○ chargées uniquement si présentes dans le viewport** (lazy loading)
○ GIF animés => video
* éventuellement via un proxy (Cloudinary, Sirv, ImageKit.io…)
** sur la base d’un échantillon statistique

38. Images : services dédiés
https://res.cloudinary.com/dareboost/image/fetch/e_blur:200,c_crop,ar_1200:600,b_white/e_g
rayscale/w_1200/b_rgb:294661,o_30/l_1a252f.png,w_1200,h_110,g_south,y_0/w_1000,c_fit,l_tex
t:Roboto_80:Lazy%20Loading%E2%80%99%20faster%20webpages%E2%80%99%20SEO%20friend
ly,x_2,y_-48,co_black,o_80/w_1000,c_fit,l_text:Roboto_80:Lazy%20Loading%E2%80%99%20faste
r%20webpages%E2%80%99%20SEO%20friendly,y_-50,co_white/l_text:Roboto_50:dareboost.com,
g_south_east,x_45,y_35,co_black,o_40/l_text:Roboto_50:dareboost.com,g_south_east,x_45,y_33,co
_white/c_scale,g_south_west,l_db-white,w_350,x_35,y_25/https://blog.dareboost.com/wp-conten
t/uploads/2018/10/metrics_1200.png

39. Images : services dédiés
https://res.cloudinary.com/dareboost/image/fetch/e_blur:200,c_crop,ar_1200:600,b_white/e_g
rayscale/w_1200/b_rgb:294661,o_30/l_1a252f.png,w_1200,h_110,g_south,y_0/w_1000,c_fit,l_tex
t:Roboto_80:Lazy%20Loading%E2%80%99%20faster%20webpages%E2%80%99%20SEO%20friend
ly,x_2,y_-48,co_black,o_80/w_1000,c_fit,l_text:Roboto_80:Lazy%20Loading%E2%80%99%20faste
r%20webpages%E2%80%99%20SEO%20friendly,y_-50,co_white/l_text:Roboto_50:dareboost.com,
g_south_east,x_45,y_35,co_black,o_40/l_text:Roboto_50:dareboost.com,g_south_east,x_45,y_33,co
_white/c_scale,g_south_west,l_db-white,w_350,x_35,y_25/https://blog.dareboost.com/wp-conten
t/uploads/2018/10/metrics_1200.png

40. ● Polices :
○ adaptées à la surface de rendu et aux qualités de l’écran (srcset, picture)
○ optimisées* : le bon format en fonction du contenu, optimisé suivant le navigateur
○ chargées uniquement si présentes dans le viewport** (lazy loading)
● JavaScript : différer tout ce qui peut l’être (en asynchrone ou non, voire
en injectant au bon moment)
Quelques indémodables

41. Et niveau Wordpress ?
● À la main
○ Enlever les JS inutiles (emoticons, RLY?)
○ Réduire le nombre de requêtes (Query Monitor)
○ Du Fragment Caching partout où c’est possible
● Cache :
○ Cache objet (exemple : Redis Cache)
○ Cache de pages (exemple : WP Super Cache)
○ Transformation en pages statiques (exemple : Simply Static)

42. Et niveau Wordpress ?
● Optimisation des assets (exemple : Merge + Minify + Refresh)
● Plugins « tout-en-un » : WP Rocket, W3 Total Cache, AutoOptimize
● Développement de Custom Block Types pour les images

43. Comment faire le tri ?
● Optimisations à la main : garder l’historique
● Optimisations via des plugins : itérer, tester, communiquer
○ Audits synthétiques : comparaison de versions A / B
○ Des tests fonctionnels, pour éviter les régressions
○ Quelle que soit la ou les solutions automatisé·e·s : envisager des procédures de
désactivation
● Et une fois en Production ?
○ On continue de mesurer pour vérifier qu’on respecte ses budgets de performance
○ On éviter les optimisations à la volée et les montées de versions de plugins
(vous étiez déjà au courant, HEIN, on est d’accord ?!)

44. Et après c’est fini ?
Non, après on commence la vraie lutte…

45. 3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party3rd party
3rd party
3rd par
3rd
3rd party
3rd party
3rd party
3rd pa
3rd party3rd party
arty
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd partyarty
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party
3rd party3rd party

46. Merci !
testez ! proposez, venez !