Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Fastest Blog in the World

jacquesmattheij.com

Post reply on HN
Print view View original

21–30 of 130 posts

Re: The Fastest Blog in the World

#21

Post by 5h »

jacquesm wrote: post #20
rtpg wrote: post #6

doesn't inlining the CSS make the page require more data in the long run? Especially if you're not changing it often Browser caches solve a lot of things for us. Though you're still parsing a bunch of JS, google's front page is "only" fetching 56kb Granted, this blog post is 13.5kb, but it doesn't have an entire search app embedded into it (with the whole search results automatically appearing thing, I imagine that i…

There is a small penalty but it does not seem to weigh up against the advantage of having all the data in one shot even on first page view on that site. Total overhead of the CSS 'in flight' is about 6.6K, versus doing another request which would require another round-trip to the server. Inlining the CSS was considerably faster in all my tests.

if you care about bytes, you could minimise the css & html also

Re: The Fastest Blog in the World

#22

Post by jacquesm »

onion2k wrote: 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…

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 too is that the audience that you already have does not spend more money (downloaded bytes on mobile for instance) or time (delay time waiting for stuff to load) than they really need 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. For ad driven sites (which this is definitely not) that might turn into more turnover, and for e-commerce sites (which there is plenty of proof for) faster load times result in more turnover.

Keeping your users happy is important, even if you don't attract more of them directly. (Retention is a very important factor in a growth strategy...)

Premature optimization is definitely the root of all evil, but bloat is something you can do without. It's a matter of striking the right balance and I think that this blog probably is on the 'wrong' side of that balance but I just wanted to make an example of how much bloat there really is.

Re: The Fastest Blog in the World

#23

Post by rtpg »

5h wrote: post #21
jacquesm wrote: post #20

Earlier quoted context omitted.

There is a small penalty but it does not seem to weigh up against the advantage of having all the data in one shot even on first page view on that site. Total overhead of the CSS 'in flight' is about 6.6K, versus doing another request which would require another round-trip to the server. Inlining the CSS was considerably faster in all my tests.

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.

Re: The Fastest Blog in the World

#24

Post by jacquesm »

kijin wrote: post #10

> inlined the stylesheet (there is a cache penalty here so you have to trim it down as much as possible but the page starts rendering immediately which is a huge gain at the cost of a little bit of extra data transferred) I guess you're optimizing for people who only visit one page and bounce away? Well, come to think of it, the majority of visitors who followed this HN link is never going to navigate past the single…

By my measurements (and pagespeed and a couple of other tools like that) it's actually faster for repeat visits and multiple pages on the same site as well (which surprised me but I'll yield when the data is that conclusive).

Re: The Fastest Blog in the World

#25

Post by jacobolus »

onion2k wrote: 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…

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 gotten so obnoxious that I just zap the domain in /etc/hosts. I used to exclusively use google search, but it’s gotten slow and annoying enough that I now mostly use duckduckgo instead.

Clearly that’s not the main part of their user base, but spending a decade chasing money at the expense of user experience isn’t all upside, even for Google.

Re: The Fastest Blog in the World

#26

Post by icebraining »

hendry wrote: 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…

Your blog is hosted in the US, jaquesm's is in Netherlands. The results from a single machine are not comparable.

Re: The Fastest Blog in the World

#27

Post by vog »

onion2k wrote: 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 have a niche, and serve that niche very well, you can beat your competitors by quality rather than quantity. Not all niches are large. If you manage to cover 100% of your niche, it is a huge success! - even if 100% means just a few thousand people.

Re: The Fastest Blog in the World

#28

Post by Animats »

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

Re: The Fastest Blog in the World

#30

Post by jacquesm »

Animats wrote: 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

That's much better than most and the images on there are functional.

The 'payload to wrapper' ratio of that page is excellent.

Post reply on HN