Web Page Performance Death by a Thousand Tiny Cuts

55 点作者 dragthor大约 9 年前

15 条评论

For those who haven't tried it, disabling JS completely makes pages load surprisingly quickly. You'll also realise how many sites inanely use tons of JS (the bulk in bloated libraries of which a tiny fraction is actually used by the site) just to serve static content. But a lot of sites also continue to work fine, despite what "common knowledge" says.So before you dive into micro-optimising JS, consider whether you even need all that JS at all. Of course this is unavoidable for certain sites which must be app-like, but if plain HTML and CSS is sufficient, then you will have effectively optimised the JS to its ultimate end. (Don't serve CSS with thousands of rules which you don't use either.)

评论 #11323645 未加载

评论 #11323435 未加载

dmethvin大约 9 年前

Dedicating your development time to a laundry list of "best practices" doesn't pay off that well. Measure where your web page is spending its time and fix that. Take image sprites for example. Setting them up takes extra steps and complexity in your build process and requires you to track which images you are using. With HTTP2 becoming common the cost of individual image requests isn't that bad.

评论 #11323929 未加载

cbr大约 9 年前

Plug for my (open source) project, mod_pagespeed: it can automate all of these.> not using image spritessprite_images filter: <a href="https://developers.google.com/speed/pagespeed/module/filter-image-sprite" rel="nofollow">https://developers.google.com/speed/pagespeed/module/filter-...</a>> not using a cookieless domain for images and other static contentMapRewriteDomain directive: <a href="https://developers.google.com/speed/pagespeed/module/domains#mapping_rewrite" rel="nofollow">https://developers.google.com/speed/pagespeed/module/domains...</a>> not using a CDNOnce you have a (pull) CDN set up, mod_pagespeed can rewrite your resources onto it with the same MapRewriteDomain directive.> blocking javascript - worse if it’s in the headdefer_javascript filter: <a href="https://developers.google.com/speed/pagespeed/module/filter-js-defer" rel="nofollow">https://developers.google.com/speed/pagespeed/module/filter-...</a>> not minifying your javascript and CSSrewrite_javascript: <a href="https://developers.google.com/speed/pagespeed/module/filter-js-minify" rel="nofollow">https://developers.google.com/speed/pagespeed/module/filter-...</a>rewrite_css: <a href="https://developers.google.com/speed/pagespeed/module/filter-css-rewrite" rel="nofollow">https://developers.google.com/speed/pagespeed/module/filter-...</a>> not optimizing caching policiesmod_pagespeed automatically longcaches everything: <a href="https://developers.google.com/speed/pagespeed/module/filter-cache-extend" rel="nofollow">https://developers.google.com/speed/pagespeed/module/filter-...</a>> not gzipping your content - most if not all popular web servers support some type of compressionmod_pagespeed automatically enables gzip compressionAbout half of these are enabled by default (minifying css and js, optimizing caching, turning on gzip) and the rest need to be configured.(If I were making the list I would also have included resource combining for css and js, which mod_pagespeed does by default.)

评论 #11324668 未加载

jdavis703大约 9 年前

If you're doing green field development I strongly recommend you turn on network throttling and set it to 3G (I'm assuming you're builing a web app that could be used on a phone). That ways performance doesn't become an expensive after thought, and you avoid optimizing things prematurely.

iamleppert大约 9 年前

"Bottom line. Try not to overdo it (on company time). At the end of the day you need to ship it."What kind of abusive management structure has this guy thinking he has to work for performance issues on his own time? I shudder to think what company he's working for or what manager has instilled such a sense in him and I truly feel sorry for him that he thinks this way.

评论 #11324529 未加载

nawitus大约 9 年前

The article links to a bunch of jsperf.com benchmarks, but I believe[1][2] these microbenchmarks are not very useful, since they don't reflect real-time performance differences.1. <a href="http://mrale.ph/blog/2014/02/23/the-black-cat-of-microbenchmarks.html" rel="nofollow">http://mrale.ph/blog/2014/02/23/the-black-cat-of-microbenchm...</a> 2. <a href="http://mrale.ph/blog/2014/12/24/array-length-caching.html" rel="nofollow">http://mrale.ph/blog/2014/12/24/array-length-caching.html</a>

coldtea大约 9 年前

A lot of the advice is useless (or harmful) for modern HHTP/2 or SPDY serving (image sprites, CDN, etc).And minifying doesn't make sense if you gzip your content -- you just add an extra processing step for little to no benefit at all.

评论 #11323959 未加载

Mithaldu大约 9 年前

Performance isn't something you argue over, performance is something you measure, optimally with a highly detailed profiler.

评论 #11323547 未加载

tyingq大约 9 年前

The bullet point list misses the culprit that I find most often...just too many page assets. Usually driven by either:- Not combining javascript or css files where it makes sense- Not using lazy loading for pages with lots of images

评论 #11323925 未加载

pdkl95大约 9 年前

> blocking javascript - worse if it’s in the head> not minifying your javascript [...]If you designed properly with progressive enhancement, the page will at least work while the javascript is still loading. For most situations it's fine if the fancier features are not immediately available as long as the page itself is readable immediately.> third party javascript partnersAka shady ad/tracking networks. This isn't a technical problem.

sccxy大约 9 年前

My steps for better performance:<pre><code> 1. apache gzip rules 2. apache expires headers 3. smaller images with ImageAlpha/ImageOptim 4. javascript to bottom of the page </code></pre> Simple things to make your webpage load faster.

评论 #11324460 未加载

评论 #11324432 未加载

manigandham大约 9 年前

The very first step in web performance is to just load less: it's truly amazing how much unnecessary crap is put on pages these days to just convey some simple information.The modern web is perfectly fine and fast, it's just abused to hell by all the extra "design", images, ads, videos, analytics, etc. Just keeping it simple would solve more problems than anything else.

评论 #11325142 未加载

ungzd大约 9 年前

Everyone recommends to use CDN then lots of sites appear hidden beneath Cloudflare hoping they will load faster on cellphone.

评论 #11324147 未加载

评论 #11323293 未加载

frign大约 9 年前

<pre><code> "What about other areas and under-the-covers code that just needs rework? Just do what I do, and work on it on your own time." </code></pre> Yeah because doing unpaid work for your company is the way to go.Get a life and learn to leave work at work.It's not the developer's fault if the manager is not dedicating enough man-hours to finish something, only to find out later on that messy code eats up many more man-hours than having it written cleanly the first time with much lower maintenance costs later on.If developers don't man up and let the managers crash and fail for it, they will be supporting greed and exploitation in the workplace and probably make it worse.

评论 #11323559 未加载

评论 #11323332 未加载

rdiddly大约 9 年前

Beware of poor web page performance: You will LITERALLY die from 1,000 cuts.

评论 #11324196 未加载