The Fastest Blog in the World • Hacker News Board

Re: The Fastest Blog in the World

#11

Post by coldtea » Mon, Aug 03, 2015, 8:14 AM UTC

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…

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

Apparently they don't. I remember reading 2-3 articles on the issue, and most things we'd expect to go there, don't even touch the browser cache.

Maybe for Google (a page we visit every day multiple times) that would be different, but for your average site the browser cache could as well be a forbidden zone with all the competition for the same limited resource.

Re: The Fastest Blog in the World

#12

Post by vog » Mon, Aug 03, 2015, 8:16 AM UTC

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…

For small datasets[1], latency may dominate bitrate. So it may be advantageous to receive everything with a single request and a single response.

Also, if your blog doesn't change often, it will also be seldom visited[2]. So the browser cache may not help here - either due to cache invalidation, or because you changed a tiny bit of your CSS in the meantime.

[1] And honestly, from that perspective all blogs are small.

[2] Ideally, all your readers use Atom/RSS.

Re: The Fastest Blog in the World

#13

Post by lucianp » Mon, Aug 03, 2015, 8:17 AM UTC

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

The Google homepage does a lot more than that. Since it is one of the most important pages for Google, I think that the engineers over there know what they are doing. I don't think it is a good example of bloat.

Re: The Fastest Blog in the World

#14

Post by jacquesm » Mon, Aug 03, 2015, 8:18 AM UTC

coldtea wrote: post #9

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

That's a good point, there is a lot of functionality behind the google homepage. Bad example! I'll search for a better one.

I've updated the article with another example (a BBC news page).

Thanks!

Re: The Fastest Blog in the World

#15

Post by hendry » Mon, Aug 03, 2015, 8:18 AM UTC

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://jacquesmattheij.com/the-fastest-blog-in-the-world
  PING jacquesmattheij.com:80 (/the-fastest-blog-in-the-world):
  connected to 62.129.133.242:80 (329 bytes), seq=0 time=550.05 ms
  connected to 62.129.133.242:80 (329 bytes), seq=1 time=550.08 ms
  ^CGot signal 2
  --- http://jacquesmattheij.com/the-fastest-blog-in-the-world ping statistics ---
  2 connects, 2 ok, 0.00% failed, time 2760ms

Re: The Fastest Blog in the World

#16

Post by rtpg » Mon, Aug 03, 2015, 8:21 AM UTC

dimitar wrote: post #5

Is there a better way to have fast-loading comments than outsourcing them to Twitter/HN or Discus?

Post

That will probably load really fast. You can server-side cache the post comments section fragment (or the render of the entire page really) to get nice results

Re: The Fastest Blog in the World

#17

Post by jacquesm » Mon, Aug 03, 2015, 8:25 AM UTC

lucianp wrote: post #13

> 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. The Google homepage does a lot more than that. Since it is one of the most important pages for Google, I think that the engineers over there know what they are doing. I don't think it is a good example of blo…

Coldtea pointed that out as well, I've changed the article to reflect this. Thank you!

Re: The Fastest Blog in the World

#18

Post by onion2k » Mon, Aug 03, 2015, 8:26 AM UTC

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+ integration with live updates, etc. Google's homepage looks basic but under the hood there's a lot going on. Which is the real crux of the matter - Google have designed something that doesn't get in the way of searching but is really a powerful portal to Google's suite of services because that's what gets them the data that makes them money. The fact they might be able to shave a milliseconds off the domContentLoaded time (which is only 394ms on my work PC) wouldn't make anyone happier but it would damage their bottom line because they'd know less about us.

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.

There's a good lesson in this that's analogous to startups that spend huge amounts of time and money doing things that get them no additional customers. Optimising things that don't affect the metrics you use to measure how successful you're being is a waste of effort. Put your time in to things that actually matter.

Re: The Fastest Blog in the World

#19

Post by [deleted] » Mon, Aug 03, 2015, 8:26 AM UTC

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…

[deleted]

Re: The Fastest Blog in the World

#20

Post by jacquesm » Mon, Aug 03, 2015, 8:27 AM UTC

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.