Il ne faut pas toujours croire ce que dit ce genre de rapport ;-)
Il faudrait un img.linuxfr.org par exemple pour pouvoir accélérer les "Parallelize downloads" (téléchargements en parallèle ?)
Déjà, il ne faudrait pas qu'un seul sous-domaine mais plusieurs, sinon on ne parallélise rien du tout. Mais surtout, avec les navigateurs modernes, le gain est à peu près nul : ce que l'on gagne en ouvrant plus de connexions, on le perd à faire des résolutions DNS supplémentaires. Et en HTTPS, c'est carrément contre-productif à cause du coût d'ouverture des sessions SSL. Par exemple, github a fait le chemin inverse (ils ont toujours un sous-domaine parce qu'ils utilisent un CDN, chose que LinuxFr.org n'a pas les moyens de s'offrir).
Imposer la taille des images, pour que les navigateurs n'aient pas à les calculer
Je vais regarder mais ce n'est pas aussi simple que cela en a l'air.
La chaîne à la fin de chaque ressource statique ("?8ee4320" par exemple) empêche le contenu d'être correctement mis en cache.
Oui et non. La réalité est bien plus compliquée que ça. Il y a différents types de mises en cache (etags vs date d'expiration). Dans notre cas, la chaîne est là pour forcer les navigateurs à venir chercher une nouvelle version quand un fichier a été modifié. Ensuite, le navigateur va pouvoir utiliser cette ressource depuis son cache sans avoir à faire de requête HTTP vers le serveur pendant un bon bout de temps.
Si j'enlève la chaîne, les navigateurs vont mieux cacher la ressource, à tel point qu'ils continueront d'utiliser l'ancienne version même quand une nouvelle version sera déployée. Pour éviter les nombreux bugs qui s'en suivraient, il faudrait alors demander aux navigateurs de revalider chaque ressource à chaque utilisation, ce qui rendrait quasiment inutile l'utilisation du cache pour la majorité des ressources de LinuxFr.org (on a beaucoup de petits fichiers).
=> Je garde la solution actuelle même si ça donne une note moindre à LinuxFr.org dans les rapports de performances.
config.serve_static_assets = true
Non, rien à voir. Cette ligne sert à indiquer au serveur applicatif de servir les fichiers statiques. Nous n'en avons pas besoin car Nginx sert les fichiers statiques en production.
La classique optimisation des png
Déjà faite ;-)
Le rapport donne une mauvaise note à cause de la bannière qui provient de La Quadrature Du Net. Je n'ai pas la main pour optimiser ça.
Je ne suis pas d'accord avec l'outil. Le fichier CSS en question n'est pas si petit que ça et il se trouve sur toutes les pages donc autant l'avoir en cache.
# Ou pas
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Optimisations. Évalué à 5 (+0/-0).
Il ne faut pas toujours croire ce que dit ce genre de rapport ;-)
Déjà, il ne faudrait pas qu'un seul sous-domaine mais plusieurs, sinon on ne parallélise rien du tout. Mais surtout, avec les navigateurs modernes, le gain est à peu près nul : ce que l'on gagne en ouvrant plus de connexions, on le perd à faire des résolutions DNS supplémentaires. Et en HTTPS, c'est carrément contre-productif à cause du coût d'ouverture des sessions SSL. Par exemple, github a fait le chemin inverse (ils ont toujours un sous-domaine parce qu'ils utilisent un CDN, chose que LinuxFr.org n'a pas les moyens de s'offrir).
Je vais regarder mais ce n'est pas aussi simple que cela en a l'air.
Oui et non. La réalité est bien plus compliquée que ça. Il y a différents types de mises en cache (etags vs date d'expiration). Dans notre cas, la chaîne est là pour forcer les navigateurs à venir chercher une nouvelle version quand un fichier a été modifié. Ensuite, le navigateur va pouvoir utiliser cette ressource depuis son cache sans avoir à faire de requête HTTP vers le serveur pendant un bon bout de temps.
Si j'enlève la chaîne, les navigateurs vont mieux cacher la ressource, à tel point qu'ils continueront d'utiliser l'ancienne version même quand une nouvelle version sera déployée. Pour éviter les nombreux bugs qui s'en suivraient, il faudrait alors demander aux navigateurs de revalider chaque ressource à chaque utilisation, ce qui rendrait quasiment inutile l'utilisation du cache pour la majorité des ressources de LinuxFr.org (on a beaucoup de petits fichiers).
=> Je garde la solution actuelle même si ça donne une note moindre à LinuxFr.org dans les rapports de performances.
Non, rien à voir. Cette ligne sert à indiquer au serveur applicatif de servir les fichiers statiques. Nous n'en avons pas besoin car Nginx sert les fichiers statiques en production.
Déjà faite ;-)
Le rapport donne une mauvaise note à cause de la bannière qui provient de La Quadrature Du Net. Je n'ai pas la main pour optimiser ça.
Pour les sprites CSS, il y a déjà une entrée ouverte : http://linuxfr.org/suivi/utiliser-loutil-de-google-pour-acc%C3%A9l%C3%A9rer-le-site-web#comment-1223067
Je ne suis pas d'accord avec l'outil. Le fichier CSS en question n'est pas si petit que ça et il se trouve sur toutes les pages donc autant l'avoir en cache.
Là, j'avoue, je ne suis pas un spécialiste des CSS, il y a sûrement pas mal de choses à faire :p