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

81–90 of 130 posts

Re: The Fastest Blog in the World

#81

Post by nevinera »

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.

How much of that win was only on the first time a page from your site is requested?

I'd expect in-lining the css to be a slight net loss once the data is cached - my strategy would be a `style-.css` with a long max-age.

I wish browsers could cache page fragments!

Re: The Fastest Blog in the World

#82

Post by jsnell »

It's really hard to argue with the basic idea. For my blog[1] it'd generally be about 6kB for the html + 1.5kB of CSS that'd be cached for return visitors (typically 15% of pageloads) + Google Analytics almost always from cache.

The "Recent Tweets" part of this site feels somehow at odds with the principles though. It's got nothing to do with the actual page, and has a really bad ratio of markup to content. Those 20 tweets are still 11kB uncompressed! It's also a very heavy visual element.

[1] http://www.snellman.net/blog/

Re: The Fastest Blog in the World

#83

Post by jacquesm »

jsnell wrote: post #82

It's really hard to argue with the basic idea. For my blog[1] it'd generally be about 6kB for the html + 1.5kB of CSS that'd be cached for return visitors (typically 15% of pageloads) + Google Analytics almost always from cache. The "Recent Tweets" part of this site feels somehow at odds with the principles though. It's got nothing to do with the actual page, and has a really bad ratio of markup to content. Those 20…

The goal was not 'minimum size per se' but 'minimum size while retaining all the elements of the old blog'. So yes, the 'recent tweets' (and the older posts) sections are at odds with a total minimalist style. But the whole idea was to not simply strip but to strip while maintaining all the old functionality.

Re: The Fastest Blog in the World

#84

Post by jacquesm »

nevinera wrote: post #81
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.

How much of that win was only on the first time a page from your site is requested? I'd expect in-lining the css to be a slight net loss once the data is cached - my strategy would be a `style- .css` with a long max-age. I wish browsers could cache page fragments!

> I'd expect in-lining the css to be a slight net loss once the data is cached

I expected that too but it didn't work out that way. I'm not sure why, possibly a cache lookup is still slower than reading the style info out of the same page. I don't know enough about the guts of a modern browser to make the call but the numbers aren't there.

Re: The Fastest Blog in the World

#87

Post by rheide »

losvedir wrote: post #72

> I’m sure I can do better still, for instance the CSS block is still quite large (too many rules, not minified yet) CSS doesn't minify particularly well since the class names, tag names, and attributes all have to stay in their full form. Basically it just ends up being removing extraneous whitespace. However, ever since reading James Hague's post on "Extreme Formatting"[0], I've rather liked CSS without all the ext…

But if everything that could possibly reference a class or tag or attribute is inlined into the same file then you know exactly what the scope of your CSS is for that particular request. So it should be possible to minify even the names.

Re: The Fastest Blog in the World

#88

Post by chmike »

fauigerzigerk wrote: post #70
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…

>If the only change is that it loads faster, and he doesn't grow his audience, then he hasn't really achieved anything. Sure he has achieved something. He has made his readers a little bit happier. Presumably, he has also made himself a little bit happier. It's called progress.

I guess it also have increased the rentability of his hosting (rentability=page views/hosting cost). Servers are still damn expensive.

Re: The Fastest Blog in the World

#89

Post by awalGarg »

thaumaturgy wrote: post #74
S4M wrote: post #58

Earlier quoted context omitted.

Brilliant! I have been planning to do the same with youtube (in combination with youtube-dl) but kept postponing it. Your comment might give me the final motivation I need.

Here's a crude starting point: html,body { margin: 0, width: 100%; } body, input { font-family: Verdana, sans-serif; font-size: 1.2em; line-height: 1.4em; } form { margin: 20% auto; width: 26em; }

bookmarking the following works as well:

    data:text/html,%20%20%20%20%3Chtml%3E%0A%20%20%20%20%20%20%20%20%3Chead%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%3Cstyle%20type%3D%22text%2Fcss%22%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20html%2Cbody%20%7B%20margin%3A%200%2C%20width%3A%20100%25%3B%20%7D%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20body%2C%20input%20%7B%20font-family%3A%20Verdana%2C%20sans-serif%3B%20font-size%3A%201.2em%3B%20line-height%3A%201.4em%3B%20%7D%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20form%20%7B%20margin%3A%2020%25%20auto%3B%20width%3A%2026em%3B%20%7D%0A%20%20%20%20%20%20%20%20%20%20%20%20%3C%2Fstyle%3E%0A%20%20%20%20%20%20%20%20%3C%2Fhead%3E%0A%20%20%20%20%20%20%20%20%3Cbody%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%3Cform%20action%3D%22https%3A%2F%2Fwww.google.com%2Fsearch%22%20method%3D%22get%22%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3Cinput%20type%3D%22text%22%20name%3D%22q%22%20placeholder%3D%22search%22%20size%3D%2230%22%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3Cinput%20type%3D%22submit%22%20value%3D%22google%22%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%3C%2Fform%3E%0A%20%20%20%20%20%20%20%20%3C%2Fbody%3E%0A%20%20%20%20%3C%2Fhtml%3E
:-)

Re: The Fastest Blog in the World

#90

Post by davewasthere »

CognitiveLens wrote: post #35

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…

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)

Post reply on HN