art-in
commented
9 years ago Implemented in 6f6d511d23b6221bbb23d07d82d83c36af3f2394
Reduced number of requests to 2: one for API call, second for manifest file (only chance for browser to decide whether to refresh cache or not).
Performance.
Before (remote access, cache enabled): 5 requests | 1.8 KB | 450 ms (load: 177 ms, DOMContentLoaded: 153 ms)
After (remote access, cache enabled): 5 requests | 317 B | 449 ms (load: 349 ms, DOMContentLoaded: 328 ms)
Really browser sends 2 request, not 5. And there's no indication of request for manifest file in Dev Tools Network tab.
Have no idea why load/DOMContentLoaded time increased. Overall load time is the same.
While with 50KB throttling, load time decreased from 2.39s to 0.45s.
Now (cache enabled, remote, no throttling):
Cache control HTTP headers like 'Expires' and 'Cache-Control' works not very reliable. Meaning that, although they define when browser should get resources from cache and when it should request server instead, it is too easy to force browser to forget cache and start loading resources again. In Chrome you just need hit F5, or click site shortcut from desktop. Only way to use cache I've found - is set cursor inside URL bar and hit Enter.
While 'Last-Modified' technique works well already, it requires browser to create additional requests for each resource file in order to verify if there are any updates on the server anyway.
Let's try a bit more modern approach - HTML5 Offline Apps.
For now it is 5 requests we have. I expect it to be just one - for API call. Refreshing app cache is by updating manifest file. Cache should not bother Debug mode in any form.