4 ms·

Often on mobile phone browsers and such, the number of parallel requests is much lower. That's where something like GWT can help a lot, as it can cut your 100 r

Often on mobile phone browsers and such, the number of parallel requests is much lower. That's where something like GWT can help a lot, as it can cut your 100 requests down to just 2.

sanderjd 12y ago
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.
- cbsmith 12y ago
  > 100 requests was purposefully hyperbolic. Have you checked out your average content web site?
  - sanderjd 12y ago
    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.
    - cbsmith 12y ago
      Actually the ad stuff would largely go away if everything moved server side.
      - sanderjd 12y ago
        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.
        cbsmith 12y ago
        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.
        sanderjd 12y ago
        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?
        cbsmith 12y ago
        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.
    - aliakhtar 12y ago
      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.
      - sanderjd 12y ago
        That's really intriguing. Not sure I've seen anybody else do it that way. Thanks for enlightening me!
        aliakhtar 12y ago
        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.

Often on mobile phone browsers and such, the number of parallel requests is much lower. That's where something like GWT can help a lot, as it can cut your 100 requests down to just 2.

sanderjd 12y ago

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.

cbsmith 12y ago
> 100 requests was purposefully hyperbolic. Have you checked out your average content web site?
- sanderjd 12y ago
  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.
  - cbsmith 12y ago
    Actually the ad stuff would largely go away if everything moved server side.
    - sanderjd 12y ago
      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.
      - cbsmith 12y ago
        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.
        sanderjd 12y ago
        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?
        cbsmith 12y ago
        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.
  - aliakhtar 12y ago
    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.
    - sanderjd 12y ago
      That's really intriguing. Not sure I've seen anybody else do it that way. Thanks for enlightening me!
      - aliakhtar 12y ago
        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.