Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

"WP Super Cache Rocket Reloaded…" – WordCamp Bordeaux 2019

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.

  • Be the first to comment

  • Be the first to like this

"WP Super Cache Rocket Reloaded…" – WordCamp Bordeaux 2019

  1. 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. 2. Boris Schapira
  3. 3. Comprendre Collecter & Automatiser Savoir-faire, faire savoir Maintenir
  4. 4. Google & la WebPerf
  5. 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. 6. « Speed isn’t just a feature, it’s the feature » « The Google Gospel of Speed », Urs Hoelzle, 2012
  7. 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. 8. Comment se mesure la performance web ? Les types d’indicateurs, les indicateurs-clés
  9. 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. 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. 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. 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. 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 !
  14. 14. 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 %
  15. 15. Speed Index par l’exemple
  16. 16. Speed Index par l’exemple 1100
  17. 17. Speed Index par l’exemple 1280
  18. 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 % 1100 ❤ 1280
  19. 19. 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 =
  20. 20. 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
  21. 21. 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ë)
  22. 22. 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.
  23. 23. Comprendre Collecter & Automatiser Savoir-faire, faire savoir Maintenir
  24. 24. 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)
  25. 25. Données CrUX dans PageSpeed Insights
  26. 26. BigQuery, pour se servir soi-même
  27. 27. Et obtenir toutes les informations
  28. 28. 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…
  29. 29. 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
  30. 30. Comprendre Collecter & Automatiser Savoir-faire, faire savoir Maintenir
  31. 31. 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
  32. 32. 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)
  33. 33. 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
  34. 34. 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
  35. 35. 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
  36. 36. ● 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
  37. 37. 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)
  38. 38. 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
  39. 39. 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 ?!)
  40. 40. Et après c’est fini ? Non, après on commence la vraie lutte…
  41. 41. 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
  42. 42. Merci ! testez ! proposez, venez !

    Be the first to comment

    Login to see the comments

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.

Views

Total views

2,059

On Slideshare

0

From embeds

0

Number of embeds

697

Actions

Downloads

9

Shares

0

Comments

0

Likes

0

×