Quelques propositions d'optimisations issues de ce rapport :
- Il faudrait un img.linuxfr.org par exemple pour pouvoir accélérer les "Parallelize downloads" (téléchargements en parallèle ?)
- Imposer la taille des images, pour que les navigateurs n'aient pas à les calculer
La chaîne à la fin de chaque ressource statique ("?8ee4320" par exemple) empêche le contenu d'être correctement mis en cache. Pour l'enlever, il faut ajouter à config/environments/production.rb :
config.serve_static_assets = true
La classique optimisation des png
Après c'est pour le CSS : Sprites, "inline CSS" quand le fichier CSS est petit, règles inutiles, sélecteurs trop compliqués (potentiellement lents), ...
À part ça, linuxfr.org à l'air de bien s'en sortir.
(c'est vraiment illisible, le gris sur gris quand on écrit)
À bon entendeur, salut !
# Ou pas
Posté par Bruno Michel (site web personnel) . É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
[^] # Re: Ou pas
Posté par Dorian . Évalué à 4 (+0/-0).
Merci pour cette réponse claire, je croyais que le "?trucmachinbizarre" changeaient constamment alors qu'en faite c'est donc quand le fichier a été modifié.
Juste pour les png, j'ai pas l'impression que ce ne soit que la bannière de la Quadrature.
À part ça, bravo pour toute les optimisations.
« En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.