Atelier Webperf - Fermé

Criterion N° 20 - L'indication de mise en cache des ressources statiques est d'au moins un mois.


  • Version 2 - L'indication de mise en cache des ressources statiques est d'au moins un mois.

  • Version 1 - L'indication de mise en cache des ressources statiques est d'au moins un mois.

  • Version 0 - L'indication de mise en cache des ressources statiques est d'au moins un mois.

    • 21 May 2012 11:31 - Elie Sloïm (1)

      une petite justification du chiffre choisi ferait le plus grand bien :-)

      • 22 May 2012 09:00 - Boris Schapira (1)

        +1, je suis sceptique sur l'arbitraire du "un mois". D'autant que si on versionne les ressources statiques, alors on peut avoir un indicateur de mise en cache aussi grand qu'on le souhaite...

        • 20 June 2012 13:00 - Fabrice Bonny (1)

          Tout à fait d'accord sur le versionnage des éléments et le cache sans limitaton de durée.

          • 21 June 2012 20:31 - Éric Daspet (1)

            Si on veut faire sérieux, Yahoo! avait publié de vraies statistiques pertinentes sur la probabilité que le cache soit toujours présent avec X jours. Normalement c'est ça qu'il faut prendre comme base pour déterminer le "au moins".<div><br></div>

            • 22 June 2012 07:38 - Laurent Denis (2)

              Concrètement : {L'indication de mise en cache des ressources statiques est d'au moins X mois.} avec X à déterminer ou bien on oublie cette BP ?

              • 22 June 2012 07:57 - Boris Schapira (1)

                <div>Nuance pour ajouter le versionning, car sinon la longue mise en cache peut poser problème :&nbsp;{L'indication de mise en cache des ressource&nbsp;statiques&nbsp;<b>versionnées </b>est d'au moins X mois}.</div><div><br></div><div>En revanche je n'arrive pas à trouver de statistiques qui définissent avec un raisonnement complet ces durées minimales. En revanche on trouve pas mal d'articles sur le Web de gens qui définissent des expirations suivant le type de ressources, et ça correspond assez bien à ma propre vision :&nbsp;</div><div><ul><li>Favion : 1 semaine</li><li>Media (images, video, audio) : 1 mois</li><li>CSS/JS : 1 an</li></ul></div>

                • 22 June 2012 08:37 - Nicolas Hoizey (1)

                  Pour moi, tout peut être en "far future" du moment qu'on gère bien le versioning dans les URL. Sur le favicon, c'est pénible si on veut juste laisser faire l'URL par défaut, sans mettre d'info dans le &lt;head&gt;.<div><br></div><div>Le versioning ne doit pas être dans cette BP par contre, c'est dans deux autres :</div><div>https://checklists.opquast.com/webperf/workshops/criterion/19048<br></div><div>https://checklists.opquast.com/webperf/workshops/criterion/19049</div>

                  • 22 June 2012 15:03 - Éric Daspet (1)

                    En fait c'est plus compliqué que ça.&nbsp;<div><br></div><div>- Favicon dans son adresse par défaut : court (de l'ordre de la semaine)</div><div>- Ressources statiques propre au design : long&nbsp;</div><div>- Ressources de contenu (images illustratives) : court ou moyen&nbsp;</div><div><br></div><div>La dernière catégorie est liée à la possibilité de remplacer l'image sans perdre les liens direct (genre google images). Ca peut certes se gérer via des redirections HTTP 301 mais ça devient complexe dès qu'on commence à mêler CDN + versionning + redirections, du coup peu de gens le font.</div><div><br></div><div>Le "far future" c'est sur l'illustratif. Sur le contenu ça se discute.</div>

                    • 22 June 2012 15:18 - Nicolas Hoizey

                      Je n'avais pas pensé à l'impact sur Google Images pour les images de contenus, effectivement

              • 22 June 2012 08:34 - Nicolas Hoizey

                Pour moi il faut clairement garder cette BP.<div><br></div><div>Yahoo! parle de "far future" :</div><div>http://developer.yahoo.com/performance/rules.html#expires</div><div><br></div><div>Chez Google, ils disent "Set <code>Expires</code>
                to a minimum of one month, and preferably up to one year, in the
                future" :</div><div>https://developers.google.com/speed/docs/best-practices/caching<br></div><div><br></div><div>Je propose de prendre la formulation de Google qui a le mérite de fixer un minimum.</div>