Performance optim #50
Conversation
|
@bertrandkeller après discussion avec @Twikito il nous semble que cette micro-optimisation n'est pas vraiment nécessaire. Serais-tu estimer le gain en performance, sur un mobile 3G par exemple ? |
|
Si les amis webperformeurs @borisschapira ou @nhoizey ont un avis sur la question, nous sommes tout ouïs :) |
|
Mouais, rien à voir avec Jekyll, mais surtout pas clair que ça apporte beaucoup. Avec votre taille native actuelle de 200px pour un affichage à 104px ou 78px, vous avez un bon compromis pour gérer le x2 sur desktop et x3 sur mobile sans avoir à gérer plusieurs tailles avec Pour être vraiment puriste, oui, vous pourriez avoir plusieurs versions de chaque image, aux dimensions 78px, 104px, 156px, 208px, etc. et mettre des D'autre part, mettre les dimensions en attribut HTML peut être intéressant, mais ça ne sera pertinent que sur grands écrans… |
|
Merci pour ton retour très instructif @nhoizey, ça confirme ce que je pensais. |
|
De rien ! |
|
@Twikito : une simulation mobile 3G montre que les bannières ralentissent considérablement le temps de chargement, peut-être peut-on faire mieux ? http://www.webpagetest.org/result/160303_4P_YPF/2/details/ |
|
Ok, je n'aurais peut-être pas dû faire de pull request avec une demi proposition. Mais la problématique de départ c'est que le site se charge en 3 secondes, voire 7 secondes sous webpagestest : http://www.webpagetest.org/result/160303_ME_17X2/1/details/ Dans ce cas là, la plus grande variable à traiter concerne les images. Pourquoi ? Parce qu'on appelle pas que des images en 200x200 mais aussi des images en 482x482 ou 512x512. Il fallait donc uniformiser. Donc, si on considère qye 200x200 est plus convenable que 104x104 comme résolution, il faudrait donc appeler des images au moins en 200x200 pour diminuer le temps de chargement de cette grande page. |
|
@bertrandkeller ce ne sont pas les images des avatars qui ralentissent le plus, ce sont les images décoratives, principalement Déjà en optimisant cette image - on peut la rendre plus floue peut-être - on devrait gagner de précieuses secondes. Facile et efficace. On peut uniformiser la taille des images avatars, mais ce n'est pas ça qui nous fera passer sous la seconde 📉 |
|
@DirtyF - Oui tout à fait, je ne l'avais pas identifié car le waterfall de gtmetrix est moins lisible sur le chargement des images. C'est bien un élément d'optimisation supplémentaire. D'ailleurs, je pensais qu'on pouvait aussi "inliner" les svg pour limiter les requêtes. |
|
Je ne comprends pas l'objectif de WebPerf. Bien qu'amateur et fervent défenseur, il faut que ça apporte quelque chose à l'utilisateur ou dans une politique de transformation. Là, on a des analyses très positives avec des Speed Index (vitesse ressentie) de très bonne facture (<1500) alors que le test est réalisé à Dulles. Donc si vous voulez optimiser pour optimiser, lançons-nous : précisons les tailles, intégrons des images RWD, re-encodons les Hero en JPEG progressif (plus lourd, mais meilleur ressenti utilisateur), sortons le Par contre, c'est pas dit que les utilisateurs verront la différence, vu que très peu de gens doivent s'y rendre tous les jours. |
|
Pour avoir une vue d'ensemble sur la Perf depuis une source française et avec des explications : https://www.dareboost.com/fr/report/56d927f50cf2674cc042a854 |
|
Merci @borisschapira. @bertrandkeller ce qui compte c'est le ressenti et l'utilsateur a rapidement accès au contenu comme le montre la vidéo de ton test: http://www.webpagetest.org/video/view.php?id=160303_ME_17X2.1.0 Comme l'a tweeté @nhoizey je pense aussi qu'on est dans la surqualité , si chère à @eliesl. Mon premier réflexe avait été de clore l'issue et de supprimer la branche, mais la discussion que cela génère est éducative et c'est le but d'être dans une démarche ouverte et transparente, je kiffe. À noter que le 'document.write' est un fallback issu de HTML5 Boilerplate, si vous pensez avoir une solution plus performante, je vous suggère d'aller proposer une PR à HTML5BP, je serais curieux des retours de Paul Irish, de Matthias et des mainteneurs du projet 😲 Pour la politique de cache, j'avoue que comme le site est hébergé par Github Pages (avec reverse proxy) derrière le CDN de Fastly avec un Varnish, je me demande dans quelle mesure nous pouvons influer sur ce point. Le rapport Dareboost indique que la belle photo de @borisschapira nous ralenti de près de deux secondes : avouez que c'est un comble :) |
|
Il faut effectivement sans doute optimiser les principales grandes images, pour améliorer le temps de chargement. Sur Github Pages, vous n'avez pas la main sur le cache, et je ne sais pas ce que Fastly permet. |
|
Je m'aperçois que les photos des orateurs ne sont pas toutes à la même taille, que j'avais initialement prévue à 200px x 200px, qui est le meilleur compromis entre poids et rendu mobile. Donc déjà première chose à faire : les redimensionner et compresser. Ensuite j'ai pensé à différer le chargement des images en background des bannières (soirée, gâteaux, etc.). Elles "ne servent qu'à" faire du joli, et ne sont pas en haut de la page, donc ça ne devrait pas poser de problème de les charger quelques secondes après le chargement complet de la page. J'ai pensé par la même occasion à simplifier l'ajout de ces bannières, comme j'en ai discuté avec @DirtyF. Du coup une div avec l'url de l'image d'arrière plan dans un data attribut, puis après timeout js, appliquer l'image en background-image, qui lancera le téléchargement. Vous en pensez quoi ? :-) |
|
@Twikito d'accord avec toi et @bertrandkeller pour uniformiser tous les avatars en 200px bien entendu, je prépare une PR. Je t'invite à faire de même pour le chargement des bannières (branche dédiée + PR). |
|
@DirtyF Ok :-) |
|
@bertrandkeller pas bien grave la "demi-PR" (Une PR de perdue, dix de retrouvées comme on dit), t'as vu ça aboutit à une solution encore plus au poil et qui a coûté/coûtera moins de temps à implémenter qu'avoir faire une "PR complète". |
|
@oncletom - bah c'était l'objectif intial en fait. une proposition sans penser qu'elle devait être acceptée. L'objectif pour moi n'est pas de servir le site le plus rapide, mais d'essayer d'être le moins énergievore. |
Quel problème cette PR corrige-t-elle ?
Le temps de rendu de la page par le navigateur
Quels sont les changement(s) apporté(s) ?
Qui devrait être prévenu de cette demande ?
@sudweb/thym