Amélioration de la perception des performances avec Pingdom et GTmetrix –

Cet article fait partie d'une série de sur la construction d'un exemple d'application – un blog de galerie multi-images – pour l'analyse comparative des performances et les optimisations. (Voir le repo ici.)

Dans cet article, nous analyserons notre application de galerie en utilisant les outils que nous avons expliqués dans le guide précédent, et

Selon l'article précédent veuillez configurer Ngrok et rediriger vers l'application hébergée localement, ou héberger l'application sur un serveur de démonstration. ton propre. Cette URL statique nous permettra de tester notre application avec des outils externes comme GTmetrix et Pingdom Tools.

Nous sommes allés scanner notre site web avec GTmetrix pour voir comment nous pouvons l'améliorer. Nous voyons que les résultats, même s'ils ne sont pas catastrophiquement mauvais, peuvent encore être améliorés.

Le premier onglet – PageSpeed ​​- contient une liste de recommandations de Google . Le premier élément sous l'onglet PageSpeed ​​- un avertissement sur une URL cohérente – se rapporte à notre application de sortie des images au hasard, de sorte que c'est un élément que nous allons passer. La prochaine chose que nous pouvons faire est la mise en cache du navigateur.

Caching du navigateur

On voit qu'il y a un fichier main.css qui nécessite son Expire En-têtes ensemble, et les images dans la galerie ont besoin de la même chose. Maintenant, la première idée pour ces fichiers statiques serait de définir ceci dans notre configuration Nginx:

 location ~ * . (?: ico | css | js | gif | jpe? G | png) $ {
    expire 14d;
}

Nous pouvons simplement placer ceci dans notre bloc server et le laisser à Nginx, non?

Eh bien, pas vraiment. Cela prendra soin de nos fichiers statiques, comme CSS, mais les images / raw dont nous sommes avertis ne sont pas vraiment statiques. Cet extrait de notre configuration Nginx ne résoudra donc pas ce problème si facilement. Pour nos images, nous avons un contrôleur qui les crée à la volée, donc ce serait idéal si nous pouvions définir nos en-têtes de réponse directement dans le contrôleur. Glide

Peut-être pourrions-nous définir notre directive Nginx de manière à inclure les ressources raw mais nous avons senti que le contrôleur approche pour être plus à l'épreuve du futur. C'est parce que nous ne savons pas quel autre contenu pourrait finir par avoir un suffixe brut – peut-être quelques vidéos, ou même des fichiers audio.

Donc, nous avons ouvert / src / ImageController. php dans notre app galerie d'images, et a lâché ces deux lignes à l'intérieur de notre serveImageAction () juste avant la ligne return $ response :

 // cache pour 2 semaines
$ response-> setSharedMaxAge (1209600);
// (optionnel) définit une directive Cache-Control personnalisée
$ response-> headers-> addCacheControlDirective ('must-revalidate', true);

Cela modifiera nos réponses d'image dynamiques en ajoutant les en-têtes Cache Control et Expires appropriés.

Symfony propose des options plus complètes pour la mise en cache des réponses, comme document ici .

Après avoir redémarré Nginx, nous avons re-testé notre application dans GTmetrix, et voilà:

Compression

Ensuite, GTmetrix nous a donné un avertissement à propos de la taille et la compression de nos ressources:

En production, c'est une chose insignifiante, et améliorer cela ne ferait pas beaucoup de différence dans ce cas particulier, avec seulement quelques kilooctets à épargner. Mais, comme ces guides sont là pour montrer la voie avec d'autres applications, plus substantielles, nous couvrirons aussi cette amélioration.

Les images pourraient être optimisées à l'avance, mais comme ce sont des images dynamiques créées avec Glide que nous avons couvert dans un autre article nous ne le ferons pas. En fait, Glide fournit des moyens pour définir la qualité de l'image. Mais parfois nous n'utiliserons pas Glide pour manipuler nos images, donc nous allons d'abord essayer une autre approche ici.

A l'intérieur de notre bloc de serveur Nginx nous ajouterons quelques lignes qui instruisent Nginx pour compresser notre contenu:

 gzip on;
gzip_disable "msie6";

gzip_vary sur;
gzip_proxied any;
gzip_comp_level 9;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_types texte / texte brut / application css / application json / texte javascript / application xml / application xml / xml + texte rss / image javascript / jpeg;

Une explication de chacun de ces paramètres serait hors de la portée de cet article. Chacun de ces éléments est expliqué sur le site web de Nginx mais une chose mérite d'être discutée gzip_comp_level .

Avec la compression, la sagesse commune est qu'il y a un compromis. Nous en gagnons sur la bande passante du réseau, en réduisant la taille de nos fichiers, mais nous en perdons dans les cycles du processeur de notre serveur, nécessaires pour gâcher et rallumer nos ressources, à chaque requête. Ou comme cet article de blog de Cloudflare (auquel nous reviendrons plus tard) dit:

Il y a un compromis entre la vitesse de compression et la vitesse de transfert. Il est seulement utile d'augmenter votre taux de compression si vous pouvez réduire le nombre d'octets que vous devez transférer plus vite que vous ne les transférez réellement.

C'est pourquoi les gens règlent rarement gzip_comp_level au maximum 9, comme nous l'avons fait. Ils se contentent généralement de quelque chose comme 6. De cette façon, les visiteurs obtiennent toujours des ressources compressées, mais le processeur n'est toujours pas soumis à une forte pression, en particulier pendant les pointes de trafic.

Mais nous ne suivrons pas ce conseil commun raisons: d'abord, en production, il y a de fortes chances que nous déployions notre application sur un CDN ce qui enlèverait complètement le fardeau de notre serveur, et deuxièmement, même si nous n'utilisons pas de CDN, nous utiliser la mise en cache des pages, donc ce gzipping effectué par notre serveur sera – espérons-le – fait une seule fois par ressource. Et, avec la mise en cache complète de notre navigateur, même ces ressources gzippées en cache ne seront pas demandées aussi souvent.

Donc, c'est la raison pour laquelle notre gzip_comp_level est à 9, mais au cas où nous ne le ferions pas. Nous avons l'intention d'utiliser la mise en cache page / HTTP, nous aurions probablement mis ce nombre à un plus petit nombre.

En faisant cela, nous avons pu améliorer notre résultat gzip :

Cependant, nous n'avons pas réussi à obtenir la même amélioration avec nos images. Donc, nous sommes retournés à la documentation de Glide et avons trouvé comment contrôler la qualité de nos images: à l'intérieur de notre serveImageAction () à l'intérieur de notre ImageController nous avons trouvé ligne:

 $ cachePath = $ glide-> getGlide () -> makeImage ($ fichier, ['w' => $size]);

Nous avons ajouté un argument de qualité à l'argument second tableau makeImage () :

 $ cachePath = $ glide-> getGlide () -> makeImage ($ fichier, ['w' => $size, 'q' => 60]);

Nous ne voulions pas baisser la qualité de l'image, car cela ne serait pas bon:

Puis nous avons supprimé toutes les images de notre / var / uploads / cache dossier, et retesté. Nos résultats sur GTmetrix ont montré que nous pouvions nous améliorer de 5%:

Il y a encore des améliorations possibles, mais dans 99% des cas, les

Nous sommes également allés à Pingdom Tools pour consulter notre site web – et nous avons été surpris de voir que nous avons obtenu un score de 100%. Bien que le temps de chargement de la page ne soit toujours pas ce qu'il devrait être, cela représentait une amélioration significative par rapport au score de 92% obtenu précédemment:

Ces recommandations sont utiles, mais notre score de 100% serait une simple métrique de vanité si notre temps de chargement devait rester à 4,21 secondes, donc nous avons activé la mise en cache de Nginx dont nous avons parlé dans Optimisation côté serveur avec Nginx et pm-static . Avec la mise en cache activée, notre résultat était maintenant 100% pour toutes les métriques, et notre temps de chargement inférieur à 1 seconde:

Nous attachons un fichier HAR de ce test .

Conclusion

Bien que nous ayons atteint 100 sur 100 avec Pingdom Tools, il existe des métriques qui ne sont pas satisfaites à 100% à la fois sur YSlow et PageSpeed ​​(GTmetrix). Cependant, ces choses sont hors de nos mains – comme la minification des ressources (jQuery et Bootstrap) servi par d'autres CDN. Nous pourrions les télécharger et les réduire, mais il est douteux que cela soit utile étant donné que la plupart des gens les téléchargent déjà dans leur navigateur en raison de l'adoption généralisée des ressources.

Il y a des choses que nous n'avons pas couvertes dans cet article recommandé dans la production – ou au moins cela vaut la peine d'explorer – comme la compression de Brotli. Les gens de Cloudflare ont écrit un article de blog intéressant sur leurs résultats avec cet algorithme de compression. Comme pour toutes les autres choses, avant la mise en œuvre réelle, il serait nécessaire de tester soigneusement sur différents types de ressources et les connexions des visiteurs. À notre avis, avec la mise en cache HTTP activée, même le coût de compression du processeur, éventuellement associé à un taux de compression élevé, serait tout de même rentable, car il s'agit d'un coût ponctuel.

. Cet article est approfondi dans cet article .

Si vous connaissez d'autres améliorations qui pourraient impacter significativement la performance, faites le nous savoir!

Tonino est un développeur web et consultant en informatique qui a plongé dans le code open-source pendant plus d'une décennie. Il est également un passionné de crypto, un fan de Linux et un libertaire modéré.