2010-03-03 11 views
3

J'ai une application web où masterPage/template contient du HTML statique qui ne change jamais mais qui est envoyé avec chaque requête. (beaucoup de ce HTML sont des éléments cachés qui sont montrés après qu'un utilisateur fasse quelque chose)Mettre en cache le contenu HTML en stockant une variable javascript dans un fichier js externe?

Je me demande s'il y a un moyen de le mettre en cache? Je pensais mettre le HTML dans une variable javascript et faire un document.write ou un jquery $ (tag) .html (cachedHTML); pour obtenir ce contenu. L'avantage ici est que le fichier javascript sera mis en cache par le navigateur et que le HTML ne sera pas transmis (accélérant le pageload et diminuant la bande passante).

Existe-t-il une solution plus élégante? Et si je fais cette route, y a-t-il un moyen facile de convertir tout le HTML à l'intérieur d'une chaîne javascript sans passer par le HTML et le formater? (supprimer des espaces, échapper des guillemets doubles, etc ...) Pensées?

Merci!

Mise à jour: Voici l'info YSlow ... cette page vous semble-t-elle trop grande? (Il y a 3597 éléments DOM)

Quelques notes: En termes de fichiers JS, il y en a trois principaux: jquery, jquery-ui, et js globalement minifié, le reste est généré par asp.net ou des choses comme l'insatisfaction

+0

En regardant YSlow, votre HTML est presque négligeable, seulement 10Kb. Votre cache amorcé est cependant médiocre, configurez votre serveur pour vous assurer que les feuilles de style et les images CSS et JS sont mis en cache. – Pool

+0

@The Feast Merci pour les suggestions ... J'utilise etags pour définir la mise en cache du serveur pour css/images/js mais je vais voir s'il y a plus à faire pour optimiser cela. Je pourrais utiliser des sprites css pour les images. – rksprst

+0

Cela semble être une bonne idée, avez-vous déjà compris? Pour rappel, google chrome prend en charge un type d'encodage qui permet la mise en cache des blocs de html du côté du navigateur. Il s'appelle [Compression de dictionnaire partagé sur HTTP (SDCH)] (http://en.wikipedia.org/wiki/Shared_Dictionary_Compression_Over_HTTP). Seul google.com code ces pages pour autant que je sache. –

Répondre

3

Je peux me tromper, mais pour moi, cela semble bien intentionné mais inutile. Si votre serveur est configuré correctement, la sortie HTML sera gzippée. Si nous ne parlons pas de mégaoctets de HTML, chaque image sur votre page prendra plus de bande passante que le balisage du document. Dans mon expérience, le plus grand souci à propos de gros blocs de données HTML est la façon dont le navigateur le gère. Un document HTML de 2 à 3 Mo occupera le centuple de la mémoire lorsqu'il sera finalement rendu. Si c'est le cas dans votre scénario, vous pouvez avoir un problème de conception à résoudre que même la mise en cache ne résoudrait pas.

+0

Merci pour les commentaires ... J'ai posté les ventilations de la page dans l'image ci-dessus. La page n'est pas très grande, donc vous avez probablement raison, ça ne fera pas beaucoup de différence. Je m'inquiète du nombre d'éléments DOM qui existent ... Avez-vous des suggestions sur les optimisations? (que ce soit orienté design ou non) – rksprst

+0

@rksprst Caching ne vous aidera pas avec les éléments DOM, ils doivent être rendus, peu importe d'où ils viennent. En ce qui concerne le nombre d'éléments DOM, si vous n'avez pas eu de problèmes de vitesse, je ne m'inquiéterais pas. Vous pourriez mieux avec une approche basée sur AJAX qui charge/enregistre ces champs sur demande, mais il est impossible de dire sans plus d'informations sur la page. –

Questions connexes