The Fastest Blog in the World

Post by [deleted] » Mon, Aug 03, 2015, 2:50 PM UTC

wahsd wrote: post #110

vog wrote: post #27

Earlier quoted context omitted.

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 by collinmanderson » Mon, Aug 03, 2015, 3:13 PM 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…

Post by [deleted] » Mon, Aug 03, 2015, 4:29 PM UTC

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!

Post by TheLoneWolfling » Mon, Aug 03, 2015, 5:18 PM UTC

jacquesm wrote: post #34

acjduncan wrote: post #29

You could also uglify your CSS and HTML by removing redundant whitespace and newlines

I'll have a look to see what the differences are, gzip is already enabled so it might be less than on a site that sends all the data in plaintext over the wire.

Post by nevinera » Mon, Aug 03, 2015, 6:38 PM UTC

jacquesm wrote: post #84

nevinera wrote: post #81

Earlier quoted context omitted.

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.