De 7 à 3s : retour d’expérience sur la performance web sur decitre.fr

PHP Tour 2016 - Clermont Ferrand - 24 mai 2016

@srogier / srogier

Pour plus d'informations

Tapez "s" pour ouvrir les notes de présentation.

La performance web sur decitre.fr

Présenter travail effectué PW sur notre site.
deux dernières années sur decitre.fr, chasse à la seconde côté front (réduisant et allégeant ressources exposées) et côté back afin d’en améliorer l’expérience utilisateur.
parlerai de pourquoi la PW est importante, quelles optimisations ont été faites et les résultats constatés.
sommes à un évènement de l’AFUP, la plupart d’entre vous sont des développeurs PHP. habitude du backend, suivre les performances côte serveur.
Mais je voulais parler de tout l’aspect performance hors serveur qui pouvait être parfois méconnu de beaucoup d’entre nous.
Je ne vous parlerai donc très peu d’optimisations serveur, mais je présenterai tout ce qu’on a pu faire pour accélérer l’affichage de nos pages sur decitre.fr

Decitre.fr

L'équipe

3 développeurs + 1 responsable technique
une dizaine de personnes hors technique

Decitre.fr

Le site

4,2 millions de pages vues par mois
1,3 million de produits

Qu'est-ce que la performance web ?

Afficher au plus vite son site Internet

L'importance de la performance web

Causalité entre performance technique et performance business
Walmart : -1s ⇒ +2% sur le taux de conversion
Google : +400ms ⇒ -0.6% sur le nombre de recherches
Impact sur le nombre de pages vues, les taux de rebond, conversion

Qu’est-ce que le web ?

Optimiser l'infra

Mesurer les performances

New Relic

Mesurer les performances

Blackfire

Migrer vers PHP 7

En cours de déploiement
Réduction du temps de traitement entre 35% et 40%

L'importance du réseau

Impact de la bande passante

Source : High Performance Browser Networking

L'importance du réseau

Impact de la latence

Source : High Performance Browser Networking

Prise en compte un second critère : la latence.
Délai nécessaire pour que les paquets fasse A/R entre le navigateur et le serveur.
Temps qui va principalement dépendre de la distance physique entre le navigateur et le serveur
+ on est loin, plus la latence va être importante.
+ réseau utilisé => plus élevée en mobile que sur une connexion fixe
+ on arrive à améliorer + on réduit tps chargement (cf graph)
tester très facilement impact latence dans outils de développement de votre navigateur. Réglage seuils de bande passante et de latence pour en visualiser l'impact.
Donc pour minimiser l'impact de la latence, on a deux possibilités : soit on rapproche navigateur et serveur pour en réduire la valeur, soit on réduit le nombre de requête serveur pour en réduire la quantité.

Anatomie d’un hit HTTP

WebPageTest.org

Faire moins de requêtes

Supprimer les images inutiles

Images chargées inutilement dans notre CSS.
Environ 20 images sur la home chargées dans la CSS.
Mise en forme du footer, barre de recherche, mini panier.
Parenthèse historique : souhait de compat et de rendu similaire IE7 -> chrome dernière version. de google chrome.
L’intention était louable, mais en pratique cela peut tourner au drame.
Voici le code d'un bouton. catastrophe : structure HTML complexe, tas énorme de CSS et une image à charger pour les coins arrondis.
Et ce sur tous les types de boutons que notre site pouvait utiliser. Je vous laisse imaginer tous les problèmes de maintenance liés.
Refonte avec de la CSS 3 : gradient et border-radius.
⇒ plus d’images à télécharger

Utiliser des sprites

Concaténation d'images en une seule
1 seul hit HTTP

Utiliser des font d'icônes

1 fichier (100 icônes) VS plusieurs sprites
Poids faible : 16 Ko

Utiliser les Data URI

Avant :

                                
.remise {
  background-image: url('vignette_remise.png');
}

Après :

                                
.remise {
  background-image: url('data:image/png;base64,iVBORw0KGgoAAAANSUhEU....');
}

Exemple concret avec le footer

25% de requêtes en moins

Gérer le cache

Cache HTTP
Durée de validité configurable

Lorsqu'il télécharge fichier, navigateur a possibilité de mettre de côté pour le réutiliser un peu plus tard s'il est utilisé ailleurs.
==> le cache HTTP.
Limiter les AR entre le serveur et navigateur en stockant côté utilisateur des ressources réutilisables.
Défini via le mécanisme de cache via l'entête HTTP Cache-Control ==> réglage durée de validité.
Page (recherche, FP, cat), ==> qq minutes à une heure.
Pour les image ==> qq heures.
js/css + importante.
Pour ces fichiers, les urls évoluent en fonction contenu ==> durée de cache peut être en théorie illimitée.

Garder les connexions ouvertes

Utiliser le Keep-Alive
Configurer la durée d'ouverture
Attention à ne pas saturer les serveurs

Chaque fois que le navigateur récupérait un fichier ==> établissait une connexion.
Côté serveur, peut spécifier directive qui s'appele Keep-Alive ==> permettre de garder ouverte connexion pendant un temps donné.
Navigateur pourra réutiliser connexion déjà ouverte au lieu d'en ouvrir une autre
Économie A/R réseaux d'initialisation de connexion.
Paramètre qui se règle sur votre serveur web et sur lequel vous réglez la durée d'ouverture de la connexion.
juste faire attention à ne pas affecter une valeur trop importante sur le KA
risque d'avoir effet inverse et saturer les serveurs en gardant trop longtemps les connexions ouvertes.

Slow Start TCP

profite du Keep Alive pour parler mécanisme de TCP : le Slow Start
TCP connait pas débit optimal connexion ==> essayer de l'atteindre en augmentant le débit jusqu'à ce que des paquets soit perdus et que le réseau n'absorbe plus le débit.
Slow Start TCP : algorithme qui va permettre d'augmenter graduellement le débit.
Chaque fois le serveur reçoit un ACK (confirmation de réception de paquet), le Slow Start va doubler la fenêtre de congestion (le nombre de paquets à transmettre).
L'intérêt réutiliser la connexion et KeepAlive ==> s'épargner le Slow Start nouvelle connexion + profiter d'une fenêtre de congestion avec une forte valeur.
Slow start restart : régler serveur pour que TCP ne réinitialise pas fenêtre la connexion est mise en attente.
Démarrage 4 (10 sur kernel récents) segments de 1460o

Concaténer les assets

Regrouper les fichiers JS et les fichiers CSS

Lazy-loader les images

25% de requêtes et code téléchargé en moins

-12% sur le temps de chargement

Alléger les ressources

Compresser le contenu

Activer la compression gzip
Diminution de la bande passante
Facteur 5 de compression

Minifier les assets

Suppression des caractères inutiles, simplification du code
Pas en place chez nous (pour le moment)

Utiliser des domaines cookieless

Alléger les requêtes HTTP
Création d'un domaine sans cookie pour livrer les images

Optimiser les images

Sensibiliser sur les risques
Intégrer un outil pour optimiser
Nettoyage de nos images avec tinypng.com

Image et travail qui avait été fait pour en réduire le nombre.
Autre problème concernant le poids.
Un jour, se retrouve avec images qui font 500 Ko sur page d'accueil
Qu'avons nous fait pour empêcher cela ?
Sensibiliser différentes équipes qui interviennent sur le site
Si on n'explique pas risques liés au poids des images et ce que cela implique pour nos clients ==> on ne peut s'en prendre qu'à nous mêmes
PNG et jpeg compressé, mais pas de manière optimale pour le web.
Présentation d'un outil en ligne pour compresser les images comme tinypng. Chiffre à l'appui pour montrer l'importance et la nécessité de l'étape.
Nettoyage côté dev sur les images du dépot sur lesquelles nous ne nous étions jamais penchés.
Nettoyage permis diviser taille de toutes les images stockées, passage de 4Mo à 2 Mo.

Nettoyer le code mort

15% de CSS morte

Réduire les contenus bloquants

Rendre l'exécution du javascript non bloquante

Descendre les fichiers
Charger en async

Parmi ces contenus bloquants on trouve fichiers javascripts.
Traiter le js dès le début n'est pas utile.
pas nécessaire pour le rendu que les interactions ajoutées par javascript soit chargées immédiatement.
nettoyé une partie de nos pages pour décaler les appels de fichiers javascripts du head vers le bas de la page.
Attention refactoring pour gérer js inline si vous en avez
les scripts qui comptaient sur la présence d’un js chargé immédiatement ne fonctionneront plus et lèveront une erreur.
attribut async : téléchargement et traitement du fichier javascript seront fait en parallèle.
Malheureusement, je n'ai pas de comparatif à vous montrer pour cette optimisation.
Modif en mm tps que la FP : pas d'impact spécifique chiffré

Auditer les scripts externes

http://requestmap.webperf.tools/

Charger sur site scripts qu'on n'héberge pas ou sur lesquels pas la main.
ces scripts tombent, et s'ils sont chargés synchrone ==> timeout navigateur
Pour évitez ça, auditez, regardez ce qui est chargé, quand et de quelle manière.
Voici graphique représentant dépendances de notre FP effectué sur webperftools.
Voit très bien que moitié des dépendances, partie droite, à cause d'un seul script.
Faire attention à ce que ce script, ne fasse pas tomber notre page.
pouvez tester cela dans webpagetest indiquant dans configuration SPOF domaines vous souhaitez ne pas pouvoir charger.

Auditer les scripts externes

Auditez les scripts
Améliorez leur qualité

avons également mis l'accent sur qualité ressources externes. Tout ce que je vous ai dit plus tôt sur compression des contenus, le cache, etc. n'est parfois pas mis en place sur ces scripts partenaires.
regardez bien ce que vous avez sur vos sites, lisez bien documents d'intégration de ces scripts (qualité technique du module)
Rmonter ces problèmes (bénéfique pour eux et surtout pour vous).
Pour terminer, ces scripts sont là souvent pour des raisons de business et il faut être conscient qu'ils ont quand même un coût technique.
Pour comparer entre decitre.fr et une de nos MB qui est mm plateforme, mais avec nettement moins de ces scripts externe ==> delta de près d'1s sur le temps de chargement global entre les deux sites.

Paralléliser les chargements des images

Augmenter la capacité à paralléliser
Attention aux coûts du sharding

On a vu bcp images à charger par le navigateur ==> point de blocage
HTTP 1, navigateur peut paralléliser les appels, mais limite de onnexions/domaine.
Comment détourner limite et améliorer le tmps de chargement ?
Technique pour augmenter la capacité à paralléliser en chargeant sur de nouveaux domaines : domain-sharding
www.decitre.fr/mon-image.jpg ==> media.decitre.fr/mon-image.jpg (image : media, reste www)
Attention : nouveau domaine == 1 résolution DNS à faire + nouvelle connexion potentiellement très coûteuse.
Peut ne pas être rentable. Bien évaluer le nombre de domaine sur lequel on compte effectuer la répartition.
Exemple de test sans impact final. On voit l'effet dans webpagetest, la parallélisation fonctionne. toutefois pas d'impact dans GA il n’y a pas eu gain notable suite à cette mise en place.

Et ensuite ?

HTTP/2

Multiplexage des requêtes
Compression des headers
Content pushing

Gros chantiers vers lequel on va se pencher dans les prochains mois sera de basculer vers HTTP/2.
Pourquoi cette bascule est intéressante ?
Parmi les avancées de HTTP/2 on peut citer :
Le multiplexage des requêtes : le navigateur n’ouvre plus qu’une seule connexion par domaine, mais il peut désormais envoyer et recevoir plusieurs messages en parallèle (au lieu séquentiel).
La compression des headers est désormais possible que ce soit pour les réponses ou les requêtes. Cela permet de réduire la bande passante utilisée.
Le content pushing qui permet dans une réponse d'envoyer du contenu lié. Par exemple, lorsque je demande ma page HTML, je peux directement lier la feuille de style.
Au final, parmi les points dont je vous ai parlé plus tôt, si on prends le domain sharding ou le keepAlive, voire la concaténation des assets ceux-ci sont rendus inutiles par une implémentation de HTTP/2.

Autres pistes

Travailler sur le chemin critique du rendu navigateur

Pour aller plus loin

Mesurer

Se documenter

Impliquer les équipes

Intégrez la web performance dans votre culture d'équipe
Créez vos process
Mesurez
Vendez votre travail

revue de code, testing ou plein bonnes pratiques, PW culture équipe.
Mettez process pour impacts des modifications, ex webpagetest après un développement.
On ne peut améliorer ce qu’on ne mesure pas
Ajoutez dans intégration continue mesures régulières pour suivre l'évolution.
Enfin, certes en tant qu'équipe de développement ==> impact fort sur le site.
Mais nous ne sommes pas les seuls à influer sur le contenu du site.
chez nous des équipes éditos interviennent tous les jours
Donc expliquez à vos collègues et vendez-leur votre culture de la PW pour qu'ils se l'approprient.
Exposez vos métriques et accompagnez-les dans l'application de vos process,
de manière à ce que tt ceux qui travaillent sur vos sites aient conscience de ces enjeux.

Tout ça pour quels résultats ?

Durant les deux dernières années, on a de manière itérative, effectué toutes ces modifications, dans l'objectif de charger le minimum, au plus vite en décalant le superflu à plus tard.
Plein d’optimisation, mais contrairement aux exemples célèbres cités en intro, il n'y pas eu d’effet sur le business ou sur le SEO.
A voir sur le plus long terme, car beaucoup de grosses modifications ont été faites au cours de la dernière année.
Mais même si d'un point de vue business ==> les effets mitigées, d'un point de vue perception utilisateur, bénéfique avoir site pages qui répondent + vite.
Pour moi l'objectif de ce sujet c'était de vous présenter ces aspects.
De montrer que même dans une petite équipe on peut travailler sur ces éléments qui pour la plupart sont assez faciles à mettre en oeuvre.
Et aussi de vous rappeler qu'il n'y a pas le back dans la vie mais également plein de travail super intéressant à faire de l'autre côté du serveur.

Merci pour votre attention

Des questions ?

https://joind.in/talk/6f757 / @srogier