Evils of dynamic content

Remember the dial-up-served HTML 0.x age, where pressing back button instantly brings you to previous page? Nowadays most of the content you see on the internet are actively served i.e. they are not loaded from static .html files, so sometimes we need to wait for the browser to revalidate the page before loading from cache. We are trending further away from static serving, and going further into dynamic pages, but what haven't we lost something along the way?

As mentioned previously, server-side scripting allows content to be generated on the fly. This sites will automatically be updated with the latest content posted, including comments. If you read an article this morning, and came back to check it in the evening, you can see all the comments posted between the two times.

But then, a problem crops up in the caching system. When a page is updated, the cache has to be purged, and the whole page, including the article, has to be redownloaded. Here, waste is introduced through redundant content fetching. Truthfully, this problem was also possible in the traditional update-by-hand method, if the web author goes through the pain of updating the site too often. But the problem wasn't prevalent as it was not practical for a web author to do such updates. Now with dynamic updates, authors just post and forget. The server handles everything for them. And on the client side, users worry nothing too. Headers are sent, response message received and checked, and if a pending update is confirmed, page is downloaded.

What went wrong?

Dynamic page serving itself is not bad. It makes for a very good front page, assuming the front page shows the news. But if the front page had menus, then the menus would be redownloaded too. Back then we had frames to separate dynamic content (the news page) from static ones (the menu). And it was easy to maintain; if the menu required any changes, you just need to modify the corresponding frame's source file and that's it. Since W3C decided frames was more harm than good, in order to do away with the frames whilst keeping the maintanability, we came to building menus with server scripts. Which meant redundant menu code on every page.

In the case of article pages with comments, the author can rectify the wastage by changing the interval to which the server-page is updated. Such measure may not be of the author's best interest, as his readers will want to read fresh comments.

This kind of problem is usually due to incompetence of webmasters, but sometimes server-page authors can be outright spartan, not allowing the content to be cached at all. Not even the back button shows previously visited site without reloading. If not for the advent of tabbed browser, browsing these pages can be really painful.

Seperation: dynamic vs. static

A solution to the above problem would be the seperation of dynamic and static contents. Static pages do not need to be .html, but they do need to be WORM. With currently available technology, there are a number of ways one can embed dynamic content to a static page, two of which I can recognize:

1. <iframe>: works without any scripting on client side.
2. XHR: uses JS to check/fetch new content. This can be a trouble for paranoid users who like to surf without JS enabled.

The problem with <iframe%gt;s is that you have to specify the height. It can be troublesome to make the embedded content look presentable. XHR (or JS+iframe) needs JS enabled, and the content is not picked up by search engines. But for non-crucial content like comments, this is acceptable. Authors shouldn't be forced to write for people deliberately disabling JS; they should cater to the median common denominator, not the lowest. In the context of today, it may mean JS 1.5 with XHR support.

Appeal to server-page webmasters

Please optimize your site for proper cache handling. Don't unnecessarily force people to redownload your pages if there is no change since last access. If there is change, and if it's minor, try to find ways so that only the changes need to be downloaded.

My next project is finding ways to rewrite the cache when the page is updated with XHR.