How does browser caching come into play here? Doesn't it make a difference?

Web perfomance optimization tells me a lot about a product and its priorities. I do not mind bloated products that perform a certain function well for their users and never try to pretened to be optimial from an engineering standpoint.

But this is nim, language that markets itself as efficient and elegant, and bloat like this hurts their credibility and brand perception in the very community they are trying to market themselves in (developers).

It's not really: we don't have a proper caching infrastructure anyway to conserve both CPU cycles and bandwidth by allowing the whole page to be cached and just minor fragments to be loaded dynamically. Back in the days, when most individuals/offices/ISPs would have some sort of cascaded Squid setup, it was more helpful.

As for caching in the client itself: possible and useful (provided the user will load the page many times per day), but not helping with the "re-rendering for each user" part as far as bandwidth is concerned.

The rendering effort itself is largely a non-issue. If your web framework is inefficient and you run out of juice on the server side, you can simply cache the static parts of your page with memcached or even use some setup with ESI on a load balancer.

Caching gives sites about two orders of magnitude speed uplift in my experience. Sometimes more. Especially if you are building the pages live and compressing them.

Brotli -11 is really really expensive and egress data transfer is one of the more expensive commodities to purchase from cloud venders.

Caching also reduces latency significantly - which is a much better user experience.

But these resources are probably already cached by the browser anyway (using the appropriate http headers). So how can this solution add any improvements to that, once the resources have been loaded for the first time?

I totally get that, it is dramatically simpler and it probably does well enough for most things.

My theory was that you can effectively cache parts of a page, and then build pages out of the cache. Like if my page relies on a user ID and some kind of "is logged in" boolean, the "is logged in" parts have probably already been rendered before so we only have to dynamically render the parts that rely on this user ID (presuming we haven't seen this user ID and cached those parts already).

Caching the whole page requires rendering both the user ID and the "is logged in" part, because it caches over the totality of the parameters.

Now that I'm writing this out, it does seem a touch excessive lol. It's kind of like server side React, but I'd probably rather push that processing onto the client device because I don't pay for their CPU cycles.

For a blog or CMS this is probably not the case. The majority of the page is going to be the same for all users. Maybe you have something at the top of tbe page showing the user is logged in, and admin links to edit it, but that's probably about as dynamic as you will get.

> Rendering apps on the client-side allows fetching partials and content data piecemeal, which is ideal for caching

Yes.. but why? 99% of websites aren't going to have enough traffic that this would cause load issues on the server. On the client the browser probably does a better job of caching pages than you could.

For something more complicated that a blog or CMS you need to think about security. It's not a trivial task to cache something and securely serve it to only people who have an active session and are authorised to view it.

Isn't this the exact problem that a reverse proxy cache solves?

Shouldn't caching have the opposite effect? i.e. it's treated as a new resource but no new http request is needed because it's in the cache..

Is the browser cache that unreliable? Especially when you can use localstorage or something fancier to hold a few megabytes of code.

That's a common (mis)assumption, but that's not how it works in practise. Sorry ^^

I cannot comment on what was the intended behavior when HTTP caching and headers were first designed, a very long time ago.

It seems to me, that is was "request everytime + get 304 if not modified, thus save the file transfer time". That's how most implementations work in my experience.

Historically, transfer duration was way more problematic than latency. It's only recently that there are pages with hundreds of dependencies.

---

Rails and webservers: They MUST change the filename or the application will be fucked because of caching issues, mostly because of Firefox :D

How so? Browsers have had caches for consistent URIs for some time now.

Does this extend to other thick client apps like SAP or even ftp just for thinking's sake?

>This information stored should obviously not be time sensitive. But if you're >running a client for social networks or such, it's perfectly a good idea to cache >the last 10 posts seen for example, so that when the user loads the page, he >instantly has something to look at while the browser is fetching the fresh >content.

Correct but now this is why I say an API because each app can have its own way of caching the last few items (http objects, files, posts whatever might be tagged)

>One key consideration is security: do not cache things on the browser that may be >private or sensitive information, unless encrypted, but even then the argument >could be made to not do it at all. That said, storing your application graphics >and most of the UI bits in local storage can certainly improve the user >experience greatly.

Is it because of the browser? Say I remove it out of the browser and place it somewhere else, encrypt it store it and wont display until I verify the end user with SSO etc, would that take away this concerns. Depends on the user(most UI bits I agree need be cached and harmless either way) for what bits might be cacheable

This is also true for Web apps that do not have meaningful amounts of client-side code.

> Caching also works for client side rendering

There are obviously a lot of differences in how caching works, but client-side caching is generally strictly worse than doing so on the server. Using the e-commerce example in TFA, every browser has to maintain their own cache of the product information, which may include cache-busting things like prices, promotional blurbs, etc.

The server can maintain a single cache for all users, and can pre-warm the cache before any users ever see the page. Adding fragment caching, which allows parts of a page to be cached, a server-side caching strategy will typically result in less total work being done across the user population, as well as less work done at request time for each visitor.

Why not, at least as long as that's the topmost tab? Wouldn't then the view-source-new-request problem be solved by just using the existing features?

Is this rendering the page remotely and fetching it? If so, it seems like the only point would be to reduce the server load on their end.

> Do you really need the contents of the newest blog posts to be pulled in each time you want to test a CSS layout change?

You would need something. At the minimum a "Lorem ipsum ..." to see how the text flows. What better than the real content for that? Especially if you already have it.