The Right Stuff: Breaking the PageSpeed Barrier with Bootstrap • Hacker News Board

Re: The Right Stuff: Breaking the PageSpeed Barrier with Bootstrap

#31

Post by bmcquade » Thu, Dec 19, 2013, 1:06 AM UTC

recuter wrote: post #7

Food for thought: all this wisdom is really an attempt to prioritize how bits hit your browser and is very much due to legacy issues. These are hacks, albeit clever and measurably better. HTTP2 when it comes (2014?) will negate the need to inline/concatenate CSS or cook up image sprites because it solves it at the proper level, the network layer.

SPDY addresses some shortcomings in HTTP, but you will always have to be mindful of the amount of render blocking JavaScript and CSS loaded on your page, regardless of network protocol.

If you load large amounts of render blocking JS/CSS in the , the browser must wait for it to finish downloading before it can render content in to the screen.

To deliver a fast experience, keep the amount of JS/CSS needed to render the initial view to a minimum. Ideally, that'd be no JS, and just the CSS needed to style the content in the initial view. Then, once the initial view has rendered, load the JS and additional CSS needed for the rest of the app.

Re: The Right Stuff: Breaking the PageSpeed Barrier with Bootstrap

#32

Post by zoj_bad » Thu, Dec 19, 2013, 5:20 AM UTC

Domenic_S wrote: post #13

zoj_bad wrote: post #11

Earlier quoted context omitted.

We don't exactly inline the CSS. (Actually, to be perfectly honest, sometimes we do when that seems like the more efficient thing to do and there is no benefit of modularity to be got from CSS.) However, in general we actually construct the HEAD and CSS also through the server library using some logic and parameters. Now, you are right, this means that from page to page, those 3-4 bytes might be the same and re-downl…

How much CSS can you fit into 4 bytes?

Lol. Sorry KB! My bad!

Re: The Right Stuff: Breaking the PageSpeed Barrier with Bootstrap

#33

Post by sampk » Thu, Dec 19, 2013, 12:05 PM UTC

recuter wrote: post #7

Food for thought: all this wisdom is really an attempt to prioritize how bits hit your browser and is very much due to legacy issues. These are hacks, albeit clever and measurably better. HTTP2 when it comes (2014?) will negate the need to inline/concatenate CSS or cook up image sprites because it solves it at the proper level, the network layer.

Don't even video games using image sprites for (non-network) performance benefits?

Re: The Right Stuff: Breaking the PageSpeed Barrier with Bootstrap

#34

Post by cbr » Thu, Dec 19, 2013, 7:02 PM UTC

druiid wrote: post #29

cbr wrote: post #5

While they do point out Ilya's comment in an update, it should be more central: Here's a slightly modified MPS config that gets you to 100 without any manual work: ModPageSpeed on ModPagespeedRewriteLevel CoreFilters ModPagespeedEnableFilters prioritize_critical_css ModPagespeedEnableFilters defer_javascript ModPagespeedEnableFilters sprite_images ModPagespeedEnableFilters convert_png_to_jpeg ModPagespeedEnableFilter…

I've had huuuuge problems with defer_javascript before using specific libraries. If it works it is an amazing help, but I'd carefully bug-test after you implement if you use that filter!

The defer_javascript filter is amazing on some pages and completely breaks others. It's frustrating because it has so much potential, but it's too dangerous for us to turn on by default. If it looks good on your site in testing, though, it's probably fine.

The basic problem is that javascript expects to run at a certain time and at a certain point in the page so we have to do all sorts of crazy things in the background to make that appear to be the case when it isn't. This fixes many of the pages (document.write works) but there are enough ways for javascript to be introspective that we can't catch everything.