Une norme pour ce qui réduit grandement les connexions HTTP

Je propose que les navigateurs devraient être en mesure de prendre un fichier zip avec un dièse ( #hash) sur la fin du nom de fichier, extraire le fichier corosponding de l'archive zip, et utiliser le fichier comme s'il s'agissait du type indiqué par le hash nom de fichier dans le contexte de l'élément.

Le fichier zip doit être en mesure d'inclure des sous-répertoires afin que la zipfiles peuvent être organisées.

Je pourrais avoir un fichier zip nommé " ui. zip ", Qui comporte une poignée d'images qui seraient utilisés pour les boutons, fonds d'en-tête et autres éléments d'une interface Web.

Je pourrais utiliser un élément <img>, ou un fond d'image CSS à utiliser les ressources.




Je pourrais utiliser un <script> ou <link> d'utiliser la ressource.




Cela pourrait grandement réduire le nombre de connexions HTTP d'un navigateur ferait au serveur.

En raison de la compression, ce pourrait être une solution plus efficace pour les feuilles de l'image du sprite CSS.

Vu la façon dont les navigateurs devra récupérer les ressources du fichier zip comme s'ils étaient eux-mêmes les fichiers, les sites existants sprites CSS envisage de réduire le nombre de connexions HTTP sont faits pour leurs serveurs pourraient plutôt mettre en œuvre cette solution de rechange sans avoir besoin de redéfinir le style de sites à utiliser background-position compliquée règles CSS. Un administrateur de Savy pourrait mettre au travail l'utilisation créative des sed de remplacer les URL d'images dans les fichiers existants.

Ce serait utiliser un format déjà largement répandue que presque tout le monde sur l'Internet est en mesure d'utiliser dès maintenant.

J'invite chacun à signaler tout Avantages, inconvénients ou les ajouts ils peuvent penser d'environ une telle norme.
Mon objectif est d'avoir cette évoluer vers un standard ouvert que les décideurs navigateur envisagerait sérieusement d'exécution.

J'aime bien l'idée, mais quels sont vos sentiments sur un type de fichier normalisé? La foule * nix mai rejeter l'idée d'utiliser le format zip, même si Win et Mac ont inclus un certain temps.

Theres aussi la possibilité de créer un nouveau format de fichier spécifique à l'optimisation de cette utilisation particulière (à l'exception des questions de configurations variables au cours de la création du fichier?)

. NRA - Network Resource Archive

Mais alors, pourquoi le limiter à un seul fichier et / ou le type de compression? Que diriez-vous d'un marqueur qui vous permet de spécifier le type et le fichier:



Et puis, il référence par ID partout ailleurs:




Cela permettrait aussi d'un webmaster pour placer les images individuelles sur le serveur ainsi que l'archive, de sorte que si le navigateur ne supporte pas la fonctionnalité d'archivage, ou si l'image elle-même est absent de l'archive, le navigateur ne peut revenir à la recherche pour juste le nom du fichier lui-même.

Sounds good, où vous les meilleures pratiques - une archive par type de contenu? Vous voulez la même archive d'organiser votre js / css / imgs / etc?

Je pense que ça dépend comment vous envisagez d'optimiser votre contenu. Si vous avez un nombre relativement faible de ressources, puis de les placer tous dans la même archive de réduire le nombre de connexions HTTP assez spectaculaire. Cependant, s'il ya des ressources qui ne sont utilisées que sur certaines pages, il wouldnt de sens de les inclure dans l'archive pour chaque page, même si les archives sont en cache, car il va allonger le temps de téléchargement pour d'autres, plus importantes ressources, telles comme l'affichage des éléments.

Eh bien, beaucoup de navigateurs modernes prennent déjà en charge la compression gzip des pages, si la norme a permis de travailler avec "*. tar.gz" ou encore "*. bz2" dossiers ainsi?

Je n'aime pas vraiment l'idée d'utiliser un tout nouveau format de fichier pour cette raison sa essentually juste de définir une méthode pour les navigateurs d'accéder à des fichiers individuels dans un colis dans l'URL sans QueryString.

Je crois que Mozilla a déjà zipfile extensions pour Firefox et pour la compression gzip, et donc pour eux de mettre en œuvre ce ne nécessiterait des changements à la manière de Firefox travaille en collaboration avec l'URL d'une image, etc. Plutôt que de les obliger à mettre en place un tout nouveau format.

Internet Explorer, Opera, Flock, Safa...euh, quel type de fichier compressé de soutien ne Safari / Mac ont?

Venez pour penser à elle, une nouvelle balise HTML est probablement excessif. Pourquoi ne pas simplement utiliser le tag <link> avec un autre rel attribut, comme ceci:

Fichiers communs à toutes les pages pourraient aller dans un zipfile, et des éléments de la page pourrait aller dans d'autres zipfiles.

Un navigateur mai utiliser une connexion à garder la récupération de contenu texte, alors qu'il utilisait un autre lien pour récupérer le zipfile référencés par une feuille de style, avec la feuille de style, à son tour, faisant référence à la figure zipfile que ce lieu d'être autorisés à faire une douzaine de nouvelles connexions à la serveur pour aller chercher de 12 images.

Cette réduction de la charge sur le serveur va lui permettre de servir ces zipfiles à un débit plus rapide de la vitesse.

Thats une bonne idée.
Il serait essentually précharger une série complète d'images et de permettre à des éléments de référence pour les droit comme d'habitude?

Un navigateur serait obligé d'attendre pour les archives de calcul avant qu'il ne soit en mesure de dire si elle a besoin pour faire une demande au serveur d'un élément.

Parce <link> éléments sont <head> contenu, vous serait obligé de charger archives avant tout contenu, ou après l'ensemble du contenu a chargé si quelque chose comme un «reporter attribut" étaient disponibles. On ne pouvait pas par exemple, ont une archive <script> avant la balise </ body>

Exactement. L'avantage ici est que les éléments de la première tentative de charger la ressource de l'archive spécifié, mais si thats échoué pour une raison ou une autre (pas de navigateurs, pas dans le fichier d'archive, etc), tout simplement l'élément revient à la charge des ressources, comme si aucune ARN ont été associés il, pour l'essentiel en ignorant les nra = "xxx" attribut.


Je suppose que vous avez un point, même si j'aime l'idée d'être en mesure de différer le chargement de l'archive que la première fois l'une des ressources est prié de lui.

Cela introduit un gros problème avec ma proposition droite.
Pas moyen de contourner manque de soutien vient à l'esprit. Un manque de soutien de laisser une page complètement brisé.

Comment avoir le tag rel point et non pas à un fichier, mais pour un dossier complet où tous les fichiers sont situés, ainsi que les archives de leur reflétant la même structure de répertoire? Si l'archive est pris en charge, le faire, si un besoin de fichier est corrompu, ou pas d'appui se trouve à tous, la pleine utilisation des fichiers à partir du même répertoire.

À moins, (j'ai toujours frappé présenter trop tôt...), Il a été passé autour de manière à ce que le nom de fichier sont d'abord et les archives ont été précisées dans la table!

Les navigateurs sans soutien, serait tout simplement ignorer le hash, je crois, mais avec l'aide des navigateurs savent à charge et de vérifier l'archive pour le fichier spécifié avant le hachage.

Cela pourrait être mis en œuvre comme la «valeur ajoutée» à la fonctionnalité de l'élément <link> proposition. Il pourrait servir comme un indice qui permet de connaître le navigateur va charger les ressources de l'archive, ou comme un moyen de préciser des cas particuliers d'archives en ligne.

En fait, bien au contraire. Imaginez que vous déclarez votre NRA avec une balise <link>, comme ci-dessus:

Les navigateurs qui ne supportent pas cette fonctionnalité sera tout simplement ignorer cette balise de lien. So far, so good.

Supposons maintenant que nous déclarons une image comme ceci:


Si le navigateur prend en charge la fonctionnalité de l'ARN, il cherche dans les archives images.nra du fichier img / logo.png . S'il est trouvé, ce fichier sera utilisé. Si le fichier n'est pas trouvé, ou si le navigateur ne supporte pas les ARN et a ignoré la déclaration archive, puis l'ARN = "images" attribut est également ignoré, et le navigateur charge l'image à partir img / logo.jpg, une image régulière situé dans le répertoire courant.

La seule chose que je n'aime pas sur l'utilisation de la notation de hachage, c'est que ça semble un peu hackish. Définir une structure pour ajouter cette fonctionnalité permet d'extension / modification ultérieurement.