pack graphique à télécharger

[Asphodèles]

Bonjour à tous !

Dans le temps, pas mal de jeux PHP proposaient des packs graphiques à télécharger, on spécifiait l'emplacement où on l'avait sauvé, et les graphismes étaient chargés depuis cet endroit là. De nos jours, je ne joue plus à aucun jeu web, mais je me souviens qu'il y avait eu un problème technique suite à une version de firefox qui interdisait le chargement de quoi que ce soit depuis le disque du client.

Qu'en est-il aujourd'hui ? Ca se fait encore de proposer ce genre de packs ? Est-ce que ça se fait de mettre du code javascript dedans ?

Je comprends bien qu'avec les caches ça fait double emploi, mais c'est quand même encore vachement plus rapide en local, j'imagine.

Merci !

[Sephi-Chan]

C'est une pratique d'un autre âge !

De nos jours, on a plein d'outils :

• De bonnes connexions ;
  
• Des CDN (Content Delivery Network) (type Amazon S3 ou Google Librairies API) ;
  
• Des caches côté client très efficace ;
  
• Des caches côté serveur, notamment les reverse proxy type Nginx ou Varnish) ;
  

Bref, il y a de quoi faire avant d'embêter l'utilisateur.
Le plus important, c'est de bien comprendre le fonctionnement de HTTP et de savoir en tirer profit en configurant son serveur Web.


Sephi-Chan

[Argorate]

Et avoir les bon outils sur son hébergeur... :roll:

[Sephi-Chan]

Mais ça, c'est comme tout : si on veut être sérieux, on s'en donne les moyens.
Et ça n'est pas forcément excessif. Il faut juste investir son argent dans les bons services.

Pour ceux qui ont un hébergement mutualisé, c'est un minimum que celui-ci doit propose mod_deflate (compression Gzip). Sans ça il est inutile d'optimiser : le Gzip est la principale source de gain lors d'un chargement. Vouloir optimiser sans compression, ça revient à passer le balai dans le désert…

Après, il faut utiliser tout ce qui permet de paralléliser le chargement des pages. Un navigateur peut charger 2 ressources simultanément par domaine : il faut donc multiplier les domaines depuis lesquelles ont charge.

Ça inclut les librairies Javascript qu'on peut charger depuis les serveurs de Google (Google Libraries API). Ces ressources sont déjà dans le cache de milliers d'utilisateurs (et bientôt dans celui de vos joueurs !) et sont compressées. Le tout gratuitement !

Ça inclut le service Amazon S3 qui permet de stocker des quantités de ressources à moindre frais et de les servir rapidement grâce à un cache efficace et des serveurs géographiquement proches.

Ainsi, en chargeant jQuery et jQuery UI (par exemple) chez Google (depuis le domaine ajax.googleapis.com) et nos images depuis Amazon S3 (depuis le domaine mygame.s3.amazonaws.com), on permet au navigateur de charger en même temps les feuilles de styles (hébergée sur notre propre serveur, dans l'exemple).

N'oubliez pas de mettre les inclusions de scripts en bas de la page (car leur téléchargement empêche de récupérer le reste de la page et de commencer à l'afficher).

On peut également utiliser les attributs async et defer pour charger les scripts de manière asynchrone.

À ceux qui ont peur de se rendre dépendant de Google en utilisant leurs API, il existe un moyen simple d'éviter tout problème (bien que ce soit très improbable) :

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.js"></script>

<script>window.jQuery || document.write('<script src="javascript/jquery-1.5.1.min.js"></script>');</script>

Sephi-Chan

[Asphodèles]

Super intéressant ! merci beaucoup !
Je n'avais pas connaissance de cette limite à deux ressources par domaine... C'est lié à quoi cette limitation ? Effectivement ça donne envie de dispatcher son contenu.

Très intéressant les CDN, je ne connaissais pas ça, merci beaucoup !

Pour ce qui est de google api, je n'utilise que json2.js qu'ils ne semblent pas proposer, mais dans le futur ça pourrait m'être utile, on verra.

Dans tous les cas merci beaucoup pour ces infos passionnantes.

[Sephi-Chan]

Cette limite vient du protocole HTTP 1.1 (décrit ici). Je n'ai pas pu trouver rapidement la documentation de ce comportement, mais c'est à explorer. Notez d'ailleurs la section 13, dédié au cache.

Je cite les ingénieurs Web de Yahoo sur Best Practices for Speeding Up Your Web Site :

Put Scripts at the Bottom

The problem caused by scripts is that they block parallel downloads. The HTTP/1.1 specification suggests that browsers download no more than two components in parallel per hostname. If you serve your images from multiple hostnames, you can get more than two downloads to occur in parallel. While a script is downloading, however, the browser won't start any other downloads, even on different hostnames.

Il faut donc mettre les balises de script en bas de la page car ils empêche les téléchargement parallèles.

Reduce DNS Lookups

Reducing the number of unique hostnames has the potential to reduce the amount of parallel downloading that takes place in the page. Avoiding DNS lookups cuts response times, but reducing parallel downloads may increase response times. My guideline is to split these components across at least two but no more than four hostnames. This results in a good compromise between reducing DNS lookups and allowing a high degree of parallel downloads.

Il faut utiliser des ressources réparties sur au moins 2 autres domaines (ou sous-domaine, ça marche aussi). Cependant, il ne faut pas dépasser 4. Au delà, la vitesse apportée par la parallélisation est plombée par la quantité de résolutions DNS à effectuer.


Il y a également quelques autres articles intéressants sur le sujet :

• Performance Research, Part 4: Maximizing Parallel Downloads in the Carpool Lane, qui fait partie des recherches qui ont conduit à la rédaction de l'article cité plus haut ;
  
• Optimize Parallel Downloads to Minimize Object Overhead, qui s'appuie sur l'article précédent mais contient un tas de notes de bas de page intéressants !
  

Sephi-Chan