Live data from Hacker News

The Fastest Blog in the World

jacquesmattheij.com

101–110 of 130 posts

Re: The Fastest Blog in the World

#101
post #64
post #28

Here's a page of mine that's almost 20 years old.[1] Look at the page source. That's HTML in its pure form. No styling at all. Looking at the page source for the "fastest blog", there's still far more formatting info than content. Much of that bloat isn't doing anything. [1] http://www.animats.com/papers/leggedrun/leggedrun.html

HTML in its pure form doesn't render well on current mobile devices. It's idiotic that you are punished when you use HTML like it was supposed to be used but that's unfortunately how the mobile browsers work currently.

Doesn't render nice in desktop browsers either. Once upon a time, at least that page would actually be a little easier on the eyes (and a bit uglier) thanks to Netscape's gray background. But the real kicker is that user stylesheets have gone the way of the dodo. There's no reason that page (as is) couldn't look better than most pdfs generated from LaTeX or what not. Sad, but true.

Re: The Fastest Blog in the World

#102

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…

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…

> 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?]

Re: The Fastest Blog in the World

#103
I really enjoy trying to make things as bloat free as possible but also retaining some styling, unlike motherfuckingwebsite.com.

Many of my posts use images and I use Google Analytics so I made a text only one and disabled GA to see how it compares. With your trick of the inline stylesheet I got a massive speed improvement[0], down from about 100ms to between 60-70ms.

I too use Hugo. I host the site on a $10 VPS from digital ocean located in London, but I also use Cloudflare to speed up image delivery.

I'm not sure where your site is physically hosted but testing from Amsterdam we're pretty much the same given the 1KB page size difference.

Very cool post and thanks for the tips!

[0] http://tools.pingdom.com/fpt/#!/bvkhPp/http://josharcher.uk/...

Re: The Fastest Blog in the World

#104
post #55

Earlier quoted context omitted.

It should be, but measurements bear out that it isn't...

Speed isn't everything to me. I love the fact that for example view-source: http://natalian.org/2015/07/06/Bank_secrecy_in_Singapore/ is more readable than most blogs.

It's mind boggling to me, as someone who was first introduced to web development in the days of gopher, that most fresh developers don't adequately understand simplicity, but also believe it's a-ok to glue a bunch of js & css libraries together and call it "good enough".

The first Java version of an internal app we had converted from Progress 4GL used Java Webstart to dynamically load & launch, and because of programmer laziness (and the 93 3rd party Java components they'd included) it literally took 3 minutes to launch. That was the point where the manager -- who was a better programmer than anyone in the team, but who had previously been hands-off -- stepped in and created some rules and instituted code reviews. Still, though, totally insane behavior by so many young web programmers.

Re: The Fastest Blog in the World

#105
post #102

Earlier quoted context omitted.

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…

> 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…

Yes, absolutely. You can easily verify this for yourself if you want with a simple page with embedded CSS and one with the CSS included from a file.

The configuration line reads:

  ExpiresByType text/css "access plus 1 week"
And I verified that it worked using a commandline http tool as well as the firefox developer tools (network section), on the second view it only loaded the page and not the CSS.

Re: The Fastest Blog in the World

#106

I really enjoy trying to make things as bloat free as possible but also retaining some styling, unlike motherfuckingwebsite.com. Many of my posts use images and I use Google Analytics so I made a text only one and disabled GA to see how it compares. With your trick of the inline stylesheet I got a massive speed improvement[0], down from about 100ms to between 60-70ms. I too use Hugo. I host the site on a $10 VPS from…

I'm hosting at virtual access in Uitgeest. Any difference you see is most likely because the server this is on is a massive beast.

Re: The Fastest Blog in the World

#107
post #15

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…

Mine is even faster than you. PING gotchacode.com:80 (/): connected to 104.28.19.6:80 (651 bytes), seq=0 time=540.86 ms ^CGot signal 2 --- http://gotchacode.com/ ping statistics --- 1 connects, 1 ok, 0.00% failed, time 1259ms round-trip min/avg/max = 540.9/540.9/540.9 ms

Not even close, 9 requests, 145 kilobytes, total time 300 ms. You're loading 3 css files and 5 files related to fonts.

But not as bad as most, so there's hope :)

Re: The Fastest Blog in the World

#108

Earlier quoted context omitted.

The google homepage doing a lot more was pointed out earlier, I've updated the page to reflect that. > If Jacques blog gets a significant amount more traffic by loading super fast then that's a definite, measurable success. If the only change is that it loads faster, and he doesn't grow his audience, then he hasn't really achieved anything. If audience growth were the target, then yes that's true. But what matters to…

"On top of that I suspect (but can't prove) that a faster site will lead to people viewing more pages on that same site simply because of the convenience." I'm reasonably sure that this theory is backed up by data. I don't have the time to look up the studies just now, but as someone with a professional interest in this, I'm pretty sure I've seen them in the past. Certainly, page speed has a surprisingly large impact…

Just an anecdotal evidence, I open fefe's blog (http://blog.fefe.de/), which is quite popular in the German hacker scene, several times a day, often just to check whether the data connection is working, since it's so basic and loads instantly.

Re: The Fastest Blog in the World

#109

Earlier quoted context omitted.

The google homepage doing a lot more was pointed out earlier, I've updated the page to reflect that. > If Jacques blog gets a significant amount more traffic by loading super fast then that's a definite, measurable success. If the only change is that it loads faster, and he doesn't grow his audience, then he hasn't really achieved anything. If audience growth were the target, then yes that's true. But what matters to…

"On top of that I suspect (but can't prove) that a faster site will lead to people viewing more pages on that same site simply because of the convenience." I'm reasonably sure that this theory is backed up by data. I don't have the time to look up the studies just now, but as someone with a professional interest in this, I'm pretty sure I've seen them in the past. Certainly, page speed has a surprisingly large impact…

IBM did a study on this, i think they call it the doherty treshold, or maybe just the show "halt and catch fire".

it assumes that anything under 400ms response can add to the addictiveness of a user interface.

http://www.vm.ibm.com/devpages/jelliott/evrrt.html

Re: The Fastest Blog in the World

#110
post #27
post #18

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…

While I agree with your comment about Google, I disagree with this one: > If the only change is that it loads faster, and he doesn't grow his audience, then he hasn't really achieved anything. If this makes his readers happier, it is a success nonetheless. Maybe this is a startup/HN thing that everything must grow and grow. But that isn't the only successful strategy, even from a purely economic point of view. If you…

load time is not a success factor in and of itself. Fast load times for bad content will not lead to success as little as really great content with horrible load times. But that being said, I am a proponent of significantly prioritizing load times over everything else. Load time should be a constant multiplier in decisions. If a "great feature" significantly taxes load time it needs to either die or be optimized.
Post reply on HN