4 ms·

He's right. The silliest thing about how many sites are designed is that the entire HTML is re-rendered differently for each user (so that the username can be

He's right. The silliest thing about how many sites are designed is that the entire HTML is re-rendered differently for each user (so that the username can be displayed somewhere on the page) for identical content. Doing this is a horrible waste of resources.

icebraining 12y ago
Isn't making extra HTTP requests just to get the username even more wasteful?
- nkuttler 12y ago
  You can get several things in one request if you want to. But yeah, it's a tradeoff. The main advantage seems to be cacheability, though that can get less important if you cache e.g. template fragments instead of entire pages.
  - grandalf 12y ago
    Template caching is still server side which means you are using an application process to do the same exact trivial thing over and over which could have been offloaded to a cache or to the client.
    - nkuttler 12y ago
      You always need to do the server-side work, no matter where the data is rendered or cached later. Like I said, it's a tradeoff.
- remon 12y ago
  Yes, yes it is. For a number of reasons but the most overlooked one is that server CPU cycles and client CPU are not equally expensive.
- grandalf 12y ago
  No, not with pipelining or SPDY or HTTP2. Also No, not with any kind of intermediate caching (assuming not all resources have identical cache lifetimes)
lazyjones 12y ago
> Doing this is a horrible waste of resources. 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.
- grandalf 12y ago
  Rendering is a non-issue? Tell that to RapGenius :)

icebraining 12y ago

Isn't making extra HTTP requests just to get the username even more wasteful?

nkuttler 12y ago
You can get several things in one request if you want to. But yeah, it's a tradeoff. The main advantage seems to be cacheability, though that can get less important if you cache e.g. template fragments instead of entire pages.
- grandalf 12y ago
  Template caching is still server side which means you are using an application process to do the same exact trivial thing over and over which could have been offloaded to a cache or to the client.
  - nkuttler 12y ago
    You always need to do the server-side work, no matter where the data is rendered or cached later. Like I said, it's a tradeoff.
remon 12y ago
Yes, yes it is. For a number of reasons but the most overlooked one is that server CPU cycles and client CPU are not equally expensive.
grandalf 12y ago
No, not with pipelining or SPDY or HTTP2. Also No, not with any kind of intermediate caching (assuming not all resources have identical cache lifetimes)

lazyjones 12y ago

> Doing this is a horrible waste of resources. 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.

grandalf 12y ago
Rendering is a non-issue? Tell that to RapGenius :)