How do we cache HTML "fragments"?
I have a page which looks like this:
<!doctype html>
<head></head>
<body>
<div>Content 1000 chars</div>
<div>Content 1000 chars</div>
<div>Content 1000 chars</div>
</body>
</html>
When a client downloads the page, basically he's downloading 3100 characters. If he visits the page again and the contents of the first div changes, he will have to redownload the entire page again (3100 characters).
Now basically I was wondering are we able to cache HTML fragments like the way we do with images?
So I was thinking is there somewhere to get this effect:
<!doctype html>
<head></head>
<body>
<div src="page1.html"></div>
<div src="page2.html"></div>
<div src="page3.html"></div>
</body>
</html>
So if I were to change the contents of page1.html, the browser would be able to know that only page1.html was changed since the last visit, and downloads 1000 characters instead of the entire page (3100) characters. Essentially this behavior is identical to what is happening now with images:
<!doctype html>
<head></head>
<body>
<img src="img1.gif">
<img src="img2.gif">
<img src="img3.gif">
</body>
</html>
whereby changing img1.gif will invoke the browser to redownload only img1.gif (assuming all the other files have not been edited)
To be clear, I开发者_JAVA技巧'm not looking for an AJAX solution. I need a solution that works without javascript (as with all the above examples). I'm also not particularly in favor of the frames solution, However I would accept that as answer if there are simply no other alternatives / quirks / hacks
Have you thought of IFrames?
However, I think that this is such a micro-optimization, that it wouldn't have any advantage (except caching inside server applicvation, which is a completely other can o'worms).
(Or you're talking about way more than 3000 chars here.)
Edit: There is another solution, but it is not supported in any browser on HTML documents without using AJAX, and only in some server scenarios: HTTP Range requests. You can tell the server with an additional header to return only a certain range of a document:
GET /large-document.html HTTP/1.1
Accept-Range: bytes
Range: bytes=0-500
Response will contain only the first 500 bytes. This technique is used to resume aborted downloads, for example.
But as I said, this doesn't help you in your scenario. For one, no browser supports this without AJAX (or outside the download manager). And for the second, the client has no idea, which range to request, and where to put it in the already fetched document to replace the old part.
If you really need to support legacy browsers down to IE3 and Netscape 2 and even old text-browsers like legacy Lynx versions, use the classic <frameset>, not an <iframe>. It is supported in basically everything since the olden days of Mosaic and was back then specifically designed for this task. (So it was the tool of choice back then when the browsers came out that you seek to support.)
The only way I can think of for achieving what you want without any JavaScript is using frames. There are, however, a number of disadvantages to frames, which you should be aware of before using them in your website.
Modern versions of Firefox and Chrome do this natively - they cache images and code whenever they can. In fact, the only way to get reloads is to clear cache at the browser level.
You might also want to look into reverse-proxy caching, which essentially does what you are doing on a site-wide basis to avoid DB traffic. Varnish is a good option that will cache pages and is highly customizable.
I don't know if doing such optimizations is reasonable. Modern browsers accept data compression (and moderns servers do it), and the text compresses really well. You have to use output buffering (e.g. see ob_start in PHP) so the page won't be sent chunk-by-chunk in tiny pieces by the server, but it will wait some time for output to be ready, then compress it and send to client, and client uncompresses it.
Using frames as a layout technique is highly discouraged nowadays (maybe iframes are sometimes a good solution, but it depends).
加载中,请稍侯......
精彩评论