Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Right Stuff: Breaking the PageSpeed Barrier with Bootstrap

appneta.com

Post reply on HN
Print view View original

11–20 of 34 posts

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

#11

Post by zoj_bad »

untog wrote: post #3
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…

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.

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-downloaded. However, we are focused on mobile phones and some of our user base is on crappy mobile phone browsers (Nokia phones that are still popular here) that have a bad caching system. So the trade off is between 3-4 bytes of CSS that is a repeat, versus a whole new request. And 3-4 bytes of CSS is not even noticeable. A request most defiantly is.

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

#12

Post by cbr »

dave1010uk wrote: post #10
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…

Does mod_pagespeed work with Apache 2.4 now?

Yup. Both the beta and stable versions work with 2.4.

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

#13

Post by Domenic_S »

zoj_bad wrote: post #11
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.

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?

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

#14

Post by kaishiro »

"After Ilya’s talk ended, I started to think more about why performance always seems to be an afterthought with developers."

In my (admittedly somewhat limited) agency experience, performance is rarely an afterthought to developers. Rather, it can be difficult to convince stakeholders that it's worth the extra time to ensure that each of these avenues is thoroughly explored. They'd rather spend their retainer implementing new feature X then making what they've already purchased perform faster.

We do what we can in terms of adding additional time to estimates to account for these things, but it's always a balance. At the end of the day, someone still needs to pay for my time.

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

#15

Post by nachteilig »

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.

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

#16

Post by mmorris »

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.

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.

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

#17

Post by paulirish »

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.

Semantically there is no difference between adding network requests for assets or inlining them, whether through data URIs or inline script/style tags. It's a fast vs slow debate. :)

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

#18

Post by Klinky »

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?

Maybe they meant kbytes?

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

#19

Post by paulirish »

mmorris wrote: post #16
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.

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.

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

#20

Post by mh- »

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?

  a {}
Post reply on HN