3 ms·

Surely you're throwing away some of the speed benefits of parallel requests by massively-inlining everything? I'd be interested in seeing some waterfall charts

Surely you're throwing away some of the speed benefits of parallel requests by massively-inlining everything? I'd be interested in seeing some waterfall charts comparing this setup with something that keeps the number of total requests small (say 3-5 requests) and evenly balanced. Particularly as we move toward HTTP2, having lots of small parallel requests will be a more effective way of getting raw page load performance. The speed gains from eliminating all but the most necessary components is definitely the biggest win here, though - cool to see what you can do when you decide to get focused about what needs to be on the page.

gabemart 11y ago
> Surely you're throwing away some of the speed benefits of parallel requests by massively-inlining everything? When you're loading less than 20KB of content, I don't think there are any speed benefits of parallel requests. I suppose in theory an extremely slow mobile connection might benefit, but extremely slow mobile connections tend to have very high latency and packet loss that make the cost of additional requests hugely outweigh the benefits.
jacquesm 11y ago
I expected that to be the case but repeated measurements tell me that it is in fact the opposite. The difference was about 50% faster on the version with everything inlined. Counter-intuitive for sure! For instance, just taking the CSS out and loading that separately doubled the page rendering time (because another resource had to be loaded after the first one). Now it is just like a 'declare before use' program in a regular programming language, by the time the browser reaches a tag that needs definitions from the CSS the CSS is already there, right there in the page, no need to wait until reading that separate resource is done. And that round-trip to the server is actually more expensive than the entire embedded CSS. Looking at it after going through the whole exercise it makes sense but that was definitely not what I expected. Even more counter-intuitive: this holds even when loading multiple pages on the same site that share the same (small) CSS file. So in the end the inlining of the CSS was a good thing to test. Presumably, there is some cross over point where if the CSS file gets very large there is a benefit for follow-up pages on the same site to be able to re-use it.
- igravious 11y ago
  A couple of Hugo questions Jacques, and please don't tell me to RTFM! Is there a way to instruct Hugo that once a crossover point is reached to unbundle the CSS? That'd be sweet. Is there a way to concatenate multiple Markdown files into a single post? The reason I ask is because I've recently started building a site that has weird hand-rolled static Markdown pages served up dynamically by a Rails/Bootstrap combo. The kicker, some of the pages are very long so I've split them up into multiple files to make them cognitively easier to edit. I'd be interested if I could drop the Rails part :) Thx in advance ps: I'm now too afraid to measure the page load times of my Wordpress blog now :(
  - jacquesm 11y ago
    > Is there a way to instruct Hugo that once a crossover point is reached to unbundle the CSS? Not that I'm aware of, Hugo is pretty much of the 'sausage grinder' variety of blog post generators, not much in terms of decision making during the processing from what I've seen so far. I also ran into a pretty serious bug while doing this and there are likely more. Still, as fresh as it is it performs amazingly well and the authors are super helpful and worked hard to track down and fix that bug. > Is there a way to concatenate multiple Markdown files into a single post? Again, not from within hugo but that one should be fixable with some pre-processing. I use a makefile that does some pre and post processing. > I'm now too afraid to measure the page load times of my Wordpress blog now :( Do it anyway, that will give you a nice before-and-after benchmark.
- e12e 11y ago
  > Even more counter-intuitive: this holds even when loading multiple pages on the same site that share the same (small) CSS file. Did you verify that the cache headers where correct, and that the CSS file was only loaded once? It's certainly possible, but indeed surprising (to me) if the actual overhead of parsing the html (and then the css - 2x render time) is that big? [ed: Did you see the same pattern using local static files?]
  - jacquesm 11y ago
davewasthere 11y ago
Also, remember that each request is actually not running in parallel. (for example, the css can not be retrieved until the html has been received by the client and parsed) Also, each of those parallel requests have their own overhead (connection, server response time, then downloading) So while intuitively, the parallel request seem like the faster option, it's probably likely in this case, that the single page in-lined option is optimal. (Even at the expense of ever so slightly more bandwidth)

gabemart 11y ago

> Surely you're throwing away some of the speed benefits of parallel requests by massively-inlining everything? When you're loading less than 20KB of content, I don't think there are any speed benefits of parallel requests. I suppose in theory an extremely slow mobile connection might benefit, but extremely slow mobile connections tend to have very high latency and packet loss that make the cost of additional requests hugely outweigh the benefits.

jacquesm 11y ago

I expected that to be the case but repeated measurements tell me that it is in fact the opposite. The difference was about 50% faster on the version with everything inlined. Counter-intuitive for sure! For instance, just taking the CSS out and loading that separately doubled the page rendering time (because another resource had to be loaded after the first one). Now it is just like a 'declare before use' program in a regular programming language, by the time the browser reaches a tag that needs definitions from the CSS the CSS is already there, right there in the page, no need to wait until reading that separate resource is done. And that round-trip to the server is actually more expensive than the entire embedded CSS. Looking at it after going through the whole exercise it makes sense but that was definitely not what I expected. Even more counter-intuitive: this holds even when loading multiple pages on the same site that share the same (small) CSS file. So in the end the inlining of the CSS was a good thing to test. Presumably, there is some cross over point where if the CSS file gets very large there is a benefit for follow-up pages on the same site to be able to re-use it.

igravious 11y ago
A couple of Hugo questions Jacques, and please don't tell me to RTFM! Is there a way to instruct Hugo that once a crossover point is reached to unbundle the CSS? That'd be sweet. Is there a way to concatenate multiple Markdown files into a single post? The reason I ask is because I've recently started building a site that has weird hand-rolled static Markdown pages served up dynamically by a Rails/Bootstrap combo. The kicker, some of the pages are very long so I've split them up into multiple files to make them cognitively easier to edit. I'd be interested if I could drop the Rails part :) Thx in advance ps: I'm now too afraid to measure the page load times of my Wordpress blog now :(
- jacquesm 11y ago
  > Is there a way to instruct Hugo that once a crossover point is reached to unbundle the CSS? Not that I'm aware of, Hugo is pretty much of the 'sausage grinder' variety of blog post generators, not much in terms of decision making during the processing from what I've seen so far. I also ran into a pretty serious bug while doing this and there are likely more. Still, as fresh as it is it performs amazingly well and the authors are super helpful and worked hard to track down and fix that bug. > Is there a way to concatenate multiple Markdown files into a single post? Again, not from within hugo but that one should be fixable with some pre-processing. I use a makefile that does some pre and post processing. > I'm now too afraid to measure the page load times of my Wordpress blog now :( Do it anyway, that will give you a nice before-and-after benchmark.
e12e 11y ago
> Even more counter-intuitive: this holds even when loading multiple pages on the same site that share the same (small) CSS file. Did you verify that the cache headers where correct, and that the CSS file was only loaded once? It's certainly possible, but indeed surprising (to me) if the actual overhead of parsing the html (and then the css - 2x render time) is that big? [ed: Did you see the same pattern using local static files?]
- jacquesm 11y ago

davewasthere 11y ago

Also, remember that each request is actually not running in parallel. (for example, the css can not be retrieved until the html has been received by the client and parsed) Also, each of those parallel requests have their own overhead (connection, server response time, then downloading) So while intuitively, the parallel request seem like the faster option, it's probably likely in this case, that the single page in-lined option is optimal. (Even at the expense of ever so slightly more bandwidth)