31–40 of 130 posts
Earlier quoted context omitted.
if you care about bytes, you could minimise the css & html also
then the ultimate, which would be whether you use web components to minimize tag lengths/define structures to compress. Though at that point gzip is probably the better solution.
> I positively hate bloat in all its forms. Take the Google homepage. It’s a one liner text field and two buttons. It weighs in at a whopping 1170 kilobytes! That’s more than a megabyte for what technically should not take more than a few hundred bytes. That's because you didn't consider the business reasons behind it being 1170Kb. If it was your "few hundrend bytes" design it would have sank the company (or only hav…
It only really starts getting js-heavy after about 2010. Evidently the relative cost of bandwidth and value of analytics have crossed over.
Mine is faster :) https://github.com/kaihendry/natalian X1C3:~$ httping http://natalian.org PING natalian.org:80 (/): connected to 54.192.159.125:80 (147 bytes), seq=0 time= 91.36 ms connected to 54.192.159.123:80 (147 bytes), seq=1 time= 28.63 ms ^CGot signal 2 --- http://natalian.org/ ping statistics --- 2 connects, 2 ok, 0.00% failed, time 1394ms round-trip min/avg/max = 28.6/60.0/91.4 ms X1C3:~$ httping http://ja…
But then your css had to load... that was another 104ms. ;)
Pretty awesome.
You could also uglify your CSS and HTML by removing redundant whitespace and newlines
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.
This is absolutely brilliant if the only metric your audience cares about is page load time . For most sites that's only part of the story. Take the first paragraph, about how Google's homepage of just a textbox should really be a few hundred bytes instead of a megabyte. Google's homepage does a lot more than just enabling you to enter a search - there's the autosuggest feature, there's analytics, the apps tray, G+ i…
On the other hand, I don’t personally want autosuggest, analytics, G+ integration, live updates, an apps tray, or any of the rest. For me, Google’s homepage circa 2005 was just as useful as the current one (or more useful even, since their results weren’t as crapped up by SEO spam sites, and the search syntax itself was more power-user friendly and predictable). I used to occasionally click google ads, but they’ve go…
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 perform…
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.
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 perform…
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.
Very zippy indeed! Have you thought about switching to nginx so you can get SPDY (and soon HTTP/2)? Also, Hugo is cool. I've evaluated it myself, but I have 8 years of WordPress archives -- ~500 posts -- and I worry about things like images, comments, etc.
Doing an import is hardly going to ruin your existing installation. Back up your blog and do the Jekyll import, and see if it’s worth switching to you. :)
Mine is faster :) https://github.com/kaihendry/natalian X1C3:~$ httping http://natalian.org PING natalian.org:80 (/): connected to 54.192.159.125:80 (147 bytes), seq=0 time= 91.36 ms connected to 54.192.159.123:80 (147 bytes), seq=1 time= 28.63 ms ^CGot signal 2 --- http://natalian.org/ ping statistics --- 2 connects, 2 ok, 0.00% failed, time 1394ms round-trip min/avg/max = 28.6/60.0/91.4 ms X1C3:~$ httping http://ja…
Pretty good though, I think if you inline the CSS you'll win hands down :)