Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

SPAs are supposed to be more efficient by only loading the data needed to update, but somehow back/forward are 100x more responsive on static pages or static sprinkled with JS, and they don't break the back button either. SPAs always have a kind of sluggish feel to them.


Totally different caching techniques. MPAs have a built in mechanism called back/forward cache. It works automatically on most sites, though some invalidate the cache. https://web.dev/articles/bfcache

SPAs need to hold onto the data themselves, and correctly transition it between pages/components. Poorly-built ones will simply refresh it every time, or discard it if the data is too large.

Both mechanisms can allow for immediate page loads if they've been correctly implemented. They just require a different approach.


And frankly, most big sites in my experience break bfcache. For instance: YouTube, Gmail, NYT, steampowered.com, CNN. All have broken bfcache in Chrome.


That's because backend-rendered sites need a shit load of caching. SPAs tend to just use APIs that aren't cached.


That's primarily because many SPAs aggressively prevent caching of all xhr responses using headers (which are ofc defined from the BE side)

And the reason for that is mainly to prevent edge cases and make sure people in CRUD apps see up-to-date content.

The experience with a no-cache max-age=0 server-rendered site would be very similar.

All of the headaches around custom routing code + restoration of state are pretty much obsolete wirh bfcache, introduced more than 5 years ago.

If you build a dynamic page and use HTTP headers to prevent caching, stop complaining about it. Most people making this argument want to offload dealing with external APIs to the frontend, and then complain about the result when no requirements around API response caching were defined, let alone time was given to define them.


No, this proves my point. Back in my days of backend programming, Varnish was the "magic" that made servers (especially CMSs) feel fast. Memcached is another common go-to cache.

Browser caching isn't a replacement as the first request for every endpoint is still going to be slow.

Yet somehow, APIs aren't treated with the same requirements for performance as web pages.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: