De 7 à 3s : retour d’expérience sur la performance web sur decitre.fr – PHP Tour 2016 - Clermont Ferrand - 24 mai 2016 – La performance web sur decitre.fr

View Github Repository Open presentation in a new window

srogier

See all presentation from srogier

De 7 à 3s : retour d’expérience sur la performance web sur decitre.fr – PHP Tour 2016 - Clermont Ferrand - 24 mai 2016 – La performance web sur decitre.fr

0 0

presentation-web-performance-decitre

On Github srogier / presentation-web-performance-decitre

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
01:00 Développeur chez DI, équipe technique de 4 personnes (3 dev et un responsable technique). éditons decitre.fr, librairie en ligne, basée sur magento. gérons également des versions en MB de notre site, et différents outils webs en symfony 2. Voilà pour contexte de l'équipe technique. Autour de nous,dizaine de personnes qui interviennent sur le site pour gérer contenu, clients ou bien SEO.

Decitre.fr

Le site

  • 4,2 millions de pages vues par mois
  • 1,3 million de produits
Decitre.fr existe depuis 1997. version actuelle basée sur magento mise en ligne en 2012. Idée du trafic du site : 4,2 millions de pages vues par mois. Catalogue produit, 1.3 million de livres et ebooks.

Qu'est-ce que la performance web ?

02:00 Commencer par définir ce qu'est la WP.

Qu'est-ce que la performance web ?

Afficher au plus vite son site Internet

02:00 La performance web c'est tout simplement comment afficher au plus vite son site Internet. Historiquement, début des années 2000 pour premières règles. 2007 apparition des yahoo rules for web performance rédigées par Steve Souders. 14 bonnes pratiques proposées par ordre d'importance applicables pour tous les sites / permettent d'améliorer la rapidité d'affichage de son site. Pratiques étaient connues avant mais une des premières compilation de tout cet ensemble de règles.

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
Pourquoi la PW est importante ? pourquoi cherche-t-on à afficher le plus vite possible les pages à nos utilisateurs ? Exemple connus monde du web lien de cause à effet perf technique et perf business Walmart : 1s de chargement => augmentation du taux de conversion de 2 %; Google : tps chargement + 400ms => baisse de 0.6% sur nb de recherche. tps de chargement , Influence sur le nombre de page vues, sur le taux de rebond, sur la conversion Critère SEO : google admet vitesse pris en compte dans leur algo de recherche

Qu’est-ce que le web ?

03:30 Le web : système client serveur. navigateur via réseau communique avec serveur backend. Quand on affiche une page sur le temps d'affichage complet, 15 à 20% côté serveur. 80 et 85% du temps consacré au reste ==> cad traitement de la page par le navigateur et le transfert réseau. Avec telles répartitions, pour accélérer sa page, marge de manoeuvre pas serveur.

Qu’est-ce que le web ?

Ressortir des cartons le modèle OSI. Le web, s'appuie le protocole TCP/IP. C'est à dire, une communication via un réseau physique interfacé couche IP pour adressage TCP transport des données en haut couche application (HTTP).

Optimiser l'infra

05:00 La partie serveur va donc être assez courte. Parler des outils utilisé pour suivre performances code PHP + grosses optimisations faites.

Mesurer les performances

New Relic

principaux outils utilisé pour suivre développements PHP. New Relic suivi serveurs. outil de monitoring applicatif le plus utilisé. Erreurs applicatives, temps de réponse, requêtes et pages lentes, évolution du trafic, le tout historisé. bon outil suivre évolution mode macro sur quelques mois mais aussi aperçu laps de temps très court.

Mesurer les performances

Blackfire

suivre nos optimisations de code PHP ==> Blackfire. Profiler dans le détail le temps, la mémoire consommée par scripts php ==> identifier appels les + consommateurs. Outil utilisé phase de dév lorsque effectuons nos modifications ==> assurer pas de régression de performance.

Migrer vers PHP 7

  • En cours de déploiement
  • Réduction du temps de traitement entre 35% et 40%
sujet du moment PHP : PHP 7 et gains de perf promis avec nelle version. Pour ceux que ça intéresse, Julien Pauli comparatif des performances de PHP 5 vs PHP 7 cet après-midi. Il y a trois mois, appel à conférencier, pensais être large pour migration avant PHPtour. En vrai, commencé à envoyer du contenu sur nos serveurs prod vendredi Optimisation tps traitement entre -35% et -40% selon premières observations.

L'importance du réseau

08:00 Pour que navigateur et serveur communiquent , passage réseau (partie basse vue dans modèle OSI de tout à l’heureà.

L'importance du réseau

Impact de la bande passante Source : High Performance Browser Networking 08:00 Souvent quand on pense réseau, on va penser bande passante. Bande passante : capacité à transmettre des données pendant un temps. On peut penser que + elle sera élevée, plus notre page va se télécharger rapidement, Mais comme on peut le voir sur le graphique, l'amélioration ne dure qu'un temps : la bande passante n'est plus le goulot d'étranglement.

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

Quand on consulte une page, navigateur récupère la page HTML et les fichiers associées. Visible onglet network navigateurs. Obtient liste des dont notre page a besoin, le moment où ils sont chargés, combien de temps ce chargement a mis. On va rentrer dans le détail d'un des hits HTTP pour voir plus précisément ce qui se passe.

Anatomie d’un hit HTTP

1. 3 1ere lignes Temps d'attente avant envoi (restriction navigateur) 2. Requete DNS. indentification du serveur si on connu 3. Etablissement de la connexion. Retombe sur les parties basses du modèle OSI de tout à l'heure 3.bis au besoin négo TLS, cf ligne SSL 4. connexion établie : envoi de la requete 5. le serveur (traite, prépare contenu). attente du premier paquet reçu par le nav : TTFB 6. Téléchargement

WebPageTest.org

pouvez utiliser webpagetest.org. URL + lieu physique test joués + nav + eventuellement réseau (BP + latence). Installable sur infra pour tests urls dev + privées

Faire moins de requêtes

12:00 Entre recherche DNS, l'établissement de la connexion, l'envoi de la requête et son téléchargement ==> appel réseau à chaque A/R serveur nous serons confrontés aux problèmes de latence. réduire le nombre de requêtes vers le serveur.

Supprimer les images inutiles

                                

    
        
            
                Commander
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
Point positif : utilisation sprite. sprite : technique consiste assembler plusieurs images en une seule Avantage : 1 appel réseau pour plusieurs éléments regroupés.

Utiliser des font d'icônes

  • 1 fichier (100 icônes) VS plusieurs sprites
  • Poids faible : 16 Ko
Certains éléments sprites existantes ne nous intéressaient pas. 4 images mais une seule \o/ . Pictogrammes tout simples (loupe, panier, logo, etc.), fond bleu dégradé faisable CSS. Utiliser font-icônes. Un fichier svg par icone, tache qui compiles cvgs en font utilisables sur le site. Remplacement de plusieurs sprites par un ficher de font (contient 100+ icones). Le tout pour une taille raisonnable (fichier font 16 Ko poour comparer l'image de 4 icônes 2 Ko) Au final sur decitre.fr, on utilise peu de sprites.

Utiliser les Data URI

Avant : 
                                
.remise {
  background-image: url('vignette_remise.png');
}
Après : 
                                
.remise {
  background-image: url('data:image/png;base64,iVBORw0KGgoAAAANSUhEU....');
}
Enfin, nous avions des petites images que nous utilisions fréquemment, plutôt que faire un hit HTTP, nous les avons directement intégré dans la CSS ou le code HTML. Comment vous pouvez le voir, au lieu de mettre l'URL de l'image, nous avons mis sa data-URI.

Exemple concret avec le footer

exemple le plus visuellement parlant du travail sur images est ce que nous avons fait sur notre footer. Voici le pied de page tel qu'il était affiché il y a encore quelques mois. En rouge images spécifiquement utilisées pour ce bloc. en tout plus de 10 images utilisées pour ce footer.

Exemple concret avec le footer

Voici ce que nous avons fait pour le remplacer en utilisant les différentes techniques dont je viens de parler. On a refait un peu le design et toujours en rouge, on retrouve les différentes images sur la nouvelle.

Exemple concret avec le footer

25% de requêtes en moins

Pour finir effet sur nombre de ressources économie d'un certain nombre d'appel serveurs (graphe jaune) effet sur temps de chargement 0.1/0.2s ==> peu

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
Bcp de fichier js et CSS chez nous, 10 css et 70 js Charger ces fichiers un par un serait catastrophique pour les performances réseaux. On va donc concaténer ensemble tous fichiers javascripts et tous fichiers CSS éviter les AR inutiles entre le client et le serveur. Pour beaucoup ici, pratique triviale et évidente. Mais dans un écosystème tel que magento, une option configurable dans le back office. signifie que sites peuvent partir en prod sans se soucier d'avoir allégé le nombre de ressources appelées.

Lazy-loader les images

Supprimé les images inutiles plus tôt, mais il en reste encore beaucoup. Cf image. Charge donc plein d'images qui pour certaines d'entre elles sont trop bas dans la page et ne seront jamais affichées. C'est dommage, c'est du chargement inutile. Pour résoudre problématique mis en place mécanisme sur visuels : le lazy loading. On ne charge les images qu’à partir du moment où elles sont dans le viewport, CAD dans zone visible par l'utilisateur. temps de chargement initial de la page réduit et images ne sont chargées que si elles sont affichées par l’utilisateur.

Lazy-loader les images

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

-12% sur le temps de chargement

Comme vous pouvez le contaster on a réduit le nombre de ressources chargées (partie jaune). Dans le cas des images de notre FP, permis d'économiser une vingtaine d'A/R avec le serveur. On a également économisé 200Ko au chargement initial de la page En terme de temps de réponse, indicateurs de temps de chargement utilisateurs remontés dans GA indique passage de 4.80s à 4.20s, ce qui est une de plus grosses optimisations effectuées sur le site. Peu impact perception utilisateur : zone allouée qui se rempli au fur & à mesure

Alléger les ressources

23:00 Je viens de vous présenter ce que nous avons fait pour charger moins de ressources sur notre site et réduire les allers retours avec le serveur. Maintenant, je vais vous parler de ce que nous avons fait pour alléger les requêtes restantes.

Compresser le contenu

  • Activer la compression gzip
  • Diminution de la bande passante
  • Facteur 5 de compression
Allègement des fichiers retournés par le serveur. Activation compression gzip. Non seulement, ressources moins lourdes à charger Quota de bande passante : des données moins lourdes qui transitent. Pertinent pour les fichiers de type texte. Image déjà optimisée Page d'accueil (html + css + js) 1 Mo après gzip 200Ko.

Minifier les assets

  • Suppression des caractères inutiles, simplification du code
  • Pas en place chez nous (pour le moment)
Après la concat des CSS et JS, bonne pratique suivante : minification Suppression des caractères inutiles (espaces, tab), commentaires, simplification des noms de variables pour le JS. Permet d'avoir des versions allégées en prod Pas mis en place chez nous. Coût de mise de place de la couche supplémentaire pas assez rentable par rapport aux autres modifications possibles pour le même temps. environ 5% de la taille des fichiers

Utiliser des domaines cookieless

  • Alléger les requêtes HTTP
  • Création d'un domaine sans cookie pour livrer les images
Egalement travail sur l'optimisation des requêtes serveur pour les ressources statiques. On a tous des cookies sur nos sites Internet. Chaque hit sur le domaine du cookie ==> envoi du cokie. ==> coût car il faut uploader le cookie. Dans le cas de fichiers statiques comme les images ou les feuilles de style, quel intérêt a-t-on à transmettre les cookies utilisateurs ? Aucun. Autre domaine di-static pour servir ces ressources. Cookies liées à decitre.fr donc non envoyé. Requête allégée (300 octets à qq 2Ko en fonction de l'utilisation du site et des cookies présents)

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
Au fil des évos du site, code non utilisé, chargé et alourdi les données téléchargées. 15% de css qui porte sur du code mort qu'on a nettoyé profité d'une migration de la css existante vers sass pour ne porter que le code qui était réellement utilisé sur le site. Sur le long terme, avoir un outil automatisé de détection du code css mort comme uncss et une intégration continue sur ce point parait indispensable.

Réduire les contenus bloquants

29:30 Moins de ressources chargées, contenu plus léger, maintenant comment continuer à accélérer notre site. Nous nous sommes penchés sur les contenus bloquants. livrer dès le début la feuille de style afin d'avoir le plus vite le rendu définitif. Contenu bloquants qui vont retarder affichage page (chargement et traitement) Identifier sur pages tous les types de contenus qui pourrait être bloquants puis reporter leur /chargement exécution

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 ?

35:00 Voilà pour les modifications que nous avons effectuées. Quels sont les axes d’améliorations que nous avons prévu pour la suite.

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
En piste d'amélération, nous pourrions également nous pencher sur les optimisations côté navigateur pour que la page affiche au plus tôt les contenus nécessaires. Nettoyage du code HTML et CSS et travail sur le le chemin critique du rendu navigateur. Mais c’est un autre pan de l’optimisation de la performance sur lequel nous n’avons pas travaillé et que je ne développerai pas.

Pour aller plus loin

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
De 7 à 3s : retour d’expérience sur la performance web sur decitre.fr PHP Tour 2016 - Clermont Ferrand - 24 mai 2016 @srogier / srogier