One of the problems web apps have against native apps, especially on the mobile front, is the constant need to re-download each web page on request. Ultimately, this leads to slower performance. Why if web apps only download new pages if they’re actually needed, not because they’re simply requested.
For example: perhaps the server can store a web page version in a cookie. Every slight change to the page on the server-side changes the version number. Now instead of the browser requesting a new page each time, why not just check the version number and have the server send the page if they’re different? If the page similar, the user can just use a cached page.
I’m sure browsers doesn’t necessarily have to change to accommodate changes to this, correct?
2
You are talking about client side caching and it’s been available and extensively in use for many years.
There are several ways to implement and control client side caching, mostly involving changing the HTTP headers that the server sends along with the initial page response. Similar to the cookie method you propose.
Here’s a good summary: http://www.librosweb.es/symfony_1_2_en/capitulo12/http_11_and_clientside_caching.html
Have a read of RFC 1945 – Hypertext Transfer Protocol — HTTP/1.0.
The idea that “instead of the browser requesting a new page each time, why not just check the version number and have the server send the page if they’re different” has been part of the spec since May 1996, and I assume that was just formalizing what was already implemented.
When talking about web apps (instead of static content), the accepted approach to this is AJAX – just reload the parts of a page that have to change (instead of the whole page).
Caching doesn’t really help much, because in many cases the page is hardly ever identical.