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

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

#21

Post by mmorris » Wed, Dec 18, 2013, 8:58 PM UTC

paulirish wrote: post #19

mmorris wrote: post #16

Earlier quoted context omitted.

Looking forward to that! Unfortunately the question then becomes, how long until all the major browsers support it? And once that happens, how long until the crowd not using the updated browsers is small enough that we can safely ignore them? I suppose the auto-updating browser trend should help a lot with the latter issue.

SPDY (and thus HTTP2) is implemented and shipping in Chrome, Firefox, Internet Explorer 11 (except win7) and Opera. It's all ready and mod_spdy and the nginx spdy module are solid and available.

Wow, okay. I knew some of the bigger sites supported SPDY, but I didn't realize that the browsers outside of Chrome were already supporting SPDY (and HTTP2) as well.

So (pardon my ignorance, I googled a bit but didn't find very conclusive results), why isn't everyone using HTTP2/SPDY now? Because of IE Edit: Or maybe because of the SSL requirement? Edited again: For clarity.

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

#22

Post by recuter » Wed, Dec 18, 2013, 9:11 PM UTC

mmorris wrote: post #21

paulirish wrote: post #19

Earlier quoted context omitted.

SPDY (and thus HTTP2) is implemented and shipping in Chrome, Firefox, Internet Explorer 11 (except win7) and Opera. It's all ready and mod_spdy and the nginx spdy module are solid and available.

Wow, okay. I knew some of the bigger sites supported SPDY, but I didn't realize that the browsers outside of Chrome were already supporting SPDY (and HTTP2) as well. So (pardon my ignorance, I googled a bit but didn't find very conclusive results), why isn't everyone using HTTP2/SPDY now? Because of IE Edit: Or maybe because of the SSL requirement? Edited again: For clarity.

Probably because the spec is not finalized yet - I bet once SPDY is essentially name changed to HTTP2 it will see wide adoption.

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

#23

Post by notfunk » Wed, Dec 18, 2013, 9:12 PM UTC

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 updated the article to move the inline update to the `2. Enable mod_pagespeed` section as requested =)

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

#24

Post by nfm » Wed, Dec 18, 2013, 9:27 PM UTC

mh- wrote: post #20

Domenic_S wrote: post #13

Earlier quoted context omitted.

How much CSS can you fit into 4 bytes?

a {}

Only if it's not gzipped :P That would bulk it up to more like 25 bytes.

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

#25

Post by at-fates-hands » Wed, Dec 18, 2013, 9:29 PM UTC

mtrpcic wrote: post #8

untog wrote: post #3

Earlier quoted context omitted.

Wait, you inline your JS and CSS? Doesn't that mean that the user has to re-download it with every page? I get the desire to have as few connections going as possible, but just be sensible about caching. First page load downloads the CSS + JS, subsequent page loads just serve it from cache.

I agree with this. By inlining all the JS and CSS, you lose the entire benefit of the browser cache, making each HTTP request for a real page a lot larger.

Unless you're using snippets or partial views where you can load only what's needed (in terms of JS and CSS) on a given page.

In that instance, I can see an advantage for inlining it, but it sure doesn't make for attractive code. Priorities though - right?

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

#26

Post by jdlshore » Wed, Dec 18, 2013, 9:42 PM UTC

nachteilig wrote: post #15

zoj_bad wrote: post #2

We have worked pretty hard to push the speed at which our mobile webpages load. In the interest of sharing...this is what has worked for us: 1. We don't have any references to external CSS and JS files. This means there is almost no reason for the browser to stop painting the webpage as soon as it starts getting the document or even fractions of it. This means that the user never gets impatient cause it seems that hi…

I just saw google recommending inlining small fragments of css/js in the newer pagespeed guidelines. This has definitely piqued my interest and I wondered if people were doing it, mainly because I'm never sure which side of the speed vs. proper semantics debate I want to be on.

You can have both speed and proper semantics (I assume you mean clean separation of concerns) by having your build script do the inlining.

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

#27

Post by carbocation » Wed, Dec 18, 2013, 10:01 PM UTC

notfunk wrote: post #23

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 updated the article to move the inline update to the `2. Enable mod_pagespeed` section as requested =)

Final table no longer makes sense. Might make more sense to extract your update to a new article and link to it from the top?

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

#28

Post by paulirish » Wed, Dec 18, 2013, 10:03 PM UTC

zoj_bad wrote: post #2

We have worked pretty hard to push the speed at which our mobile webpages load. In the interest of sharing...this is what has worked for us: 1. We don't have any references to external CSS and JS files. This means there is almost no reason for the browser to stop painting the webpage as soon as it starts getting the document or even fractions of it. This means that the user never gets impatient cause it seems that hi…

Love all of this. I'm always looking for well tuned sites like yours to showcase. Can you share a URL?

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

#29

Post by druiid » Wed, Dec 18, 2013, 10:29 PM UTC

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!

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

#30

Post by untog » Thu, Dec 19, 2013, 12:13 AM UTC

at-fates-hands wrote: post #25

mtrpcic wrote: post #8

Earlier quoted context omitted.

I agree with this. By inlining all the JS and CSS, you lose the entire benefit of the browser cache, making each HTTP request for a real page a lot larger.

Unless you're using snippets or partial views where you can load only what's needed (in terms of JS and CSS) on a given page. In that instance, I can see an advantage for inlining it, but it sure doesn't make for attractive code. Priorities though - right?

Even then, unless your partial views are barely ever repeated in different pages it still isn't worth it. And if they're barely ever repeated then there isn't much point in them being partial views.