Mettre en cache des scripts statiques externes?
Dans ma quête sans fin d'un site Web plus rapide, j'ai pensé que je pourrais peut-être mettre en cache certains scripts. J'utilise Yslow pour noter mon site. Tout est à peu près tout ce qui est A (ce qui est génial, notre site Web sur Pingdom se charge en 0.4-0.6 secondes, ce qui est 5-20x plus rapide que nos concurrents), sauf deux choses:
Ajouter des en-têtes d'expiration:
(2011/7/7) http://fonts.googleapis.com/css?...
(2011/7/6) http://fonts.googleapis.com/css?...
(no expires) http://s7.addthis.com/js/250/addthis_widget.js#pubid=ra-4d7a205f1e2a0b4b
Et trop de recherches DNS:
Les composants sont répartis sur plus de 4 domaines
static1.scirra.net: 4 composants, 19.3K (4.3K GZip)
fonts.googleapis.com: 2 composants, 0.8K (0.5K GZip)
static3.scirra.net: 2 composants, 5,5K (2,7K GZip)
static4.scirra.net: 3 composants, 12.7K
static2.scirra.net: 3 composants, 76,6K
s7.addthis.com: 3 composants, 126.3K (40.4K GZip)
ajax.googleapis.com: 1 composant, 78,6 Ko (27,1 Ko GZip)
www.scirra.com: 1 composant, 8,0 Ko (3,3 Ko GZip)
Cette réponse sur SO:
Suggère de créer un script de mise en cache intermédiaire qui les récupère et les sert à partir de votre propre serveur.
Pensées? Si vous êtes un fou de vitesse comme moi, pouvons-nous espérer réduire le temps de chargement des utilisateurs au détriment de notre bande passante?
Déplacer des fichiers statiques uniques vers votre propre domaine afin de réduire les recherches de domaine et de contrôler les en-têtes d'expiration est une bonne idée, à condition que vous soyez prêt à vérifier les fichiers principaux. change périodiquement.
Déplacer des fichiers statiques communs vers votre propre domaine n'est pas toujours une bonne idée, car vous perdez l'avantage s'ils sont déjà mis en cache sur un autre site que l'utilisateur peut a visité. (par exemple, les polices Web de Google et les fichiers JavaScript hébergés dans le API Google Libraries. )
[À part: à ma connaissance, pingdom mesure le temps de réponse du serveur , pas le temps de chargement de la page, mais 0,6 seconde sonne quand même vite!]
La bande passante est presque une marchandise à ce stade. Surtout si vous êtes en train de compresser votre fichier avant de l'envoyer à l'utilisateur. Et comme il a été prouvé que la vitesse de la page affecte non seulement classement de la recherche mais, plus important encore taux de conversion , je dirais que ce n’est pas une mauvaise stratégie à employer. Assurez-vous simplement que vos comptes de moteur de mise en cache permettent de mettre à jour les scripts externes que vous mettez en cache. Ne pas être synchronisé avec eux peut entraîner des résultats indésirables.