100 requests was purposefully hyperbolic. In reality, everything I've done recently has been 3 static requests (html, js, css), and however many requests for images and data are necessary. It's really just the requests for data (which I don't think GWT helps with?) that end up being "extra", because server-side rendering still usually requires separate requests for js, css, and images.
Very fair point, but I was sort of not considering images. Although it's probably still a fair point, but so much of the rest is third-party ad junk, which isn't really affected by the server-side vs. client-side rendering question.
FYI, most of your images are also compiled into that single .html file I mentioned. This includes both the images used in css files, and the ones in <img /> tags. That means only one http request for loading your css, js, and most of your images.
No problem. Just to clarify, only the small / medium sized images are inlined in this way. The large images are done as their own http request, so the browser doesn't slow down with rendering them.
How so? You mean by having the server send the user's info to the ad provider? That doesn't seem to be a common setup, because of the advantages of cookies for tracking users across sites. Maybe I'm missing something though.
When it is done server side, any tracking cookie work has to be done ahead of time. So you have a single trip from the browser to get the ad, and maybe a second trip to confirm it was successfully shown. That's it.
Ah, but that won't work for the requests to third-party services that are for the purpose of telling those services "the user identified by the cookie in this request just visited this site" rather than actually showing ads, will it?
Absolutely it will (if that's what they want it to do). As I said, you've already done the cookie join, so you know what the magic userid is that the third party has in their system for that user.
