Web Page Performance Death by a Thousand Tiny Cuts | Hacker News Reader

Web Page Performance Death by a Thousand Tiny Cuts

metroize.com

55 pointsdragthor59 comments

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.)

I installed dillo last year. It just fetches html, does a little bit of CSS layouting and that's it. Usually, the job is done by the time my finger leaves the left button. Gets you thinking.

Which means internally browsers are probably dying a performance death of a thousand cuts, too

I have JS disabled by default except some sites. I just want to notice that usually it is not only JS fault. Javascript in general is not slow - the problem is usually with third-party scripts (analytics, advertisement, social network buttons) that add huge load on a browser. They load large JS frameworks, create many iframes (and every iframe is like a new tab in a browser - it has own DOM, own stylesheets, its own JS VM), track events like mouse movement. For example Google AdSence can add several additional iframes per banner.

For example, reddit frontpage (which doesn't have much ad) has 6 additional iframes. It makes 76 requests (775 Kb) while loading of which only 15 (taking 335 Kb) belong to reddit domains, other are third-party. So by just disabling third-party services (you can do it on the browser side) they can make the page two times smaller.

Techcrunch has 19 additional iframes. It makes 273 requests (of which approximately 190 are third-party) and loads 2.1 Mb of data (of which approximately 1.1 Mb account for third-party domains). Opening single techcrunch page is like opening 20 new tabs in your browser.

And as a site owner you cannot optimize your ad provider scripts. Yet you can "optimize" them out at a browser side as a user.

Instead of blaming everything on javascript or jquery people should look at network tab in developer tools.

> And as a site owner you cannot optimize your ad provider scripts.

You can, if you directly negotiate ad contracts.

You can sort-of optimize your ad javascript. Some of the ad networks are starting to require that you ads come essentially pre-packaged and be under a certain size.

They still might have dumb code and overly fancy animations of course.

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.

Usually most time is spent loading third party trackers, advertisement and social network widgets. You can "optimize" that only on client side by blocking them.

We iFramed them on one of the major websites I worked on. Didn't affect the revenue. And they render completely separately, don't block anything / cause layout thrashing.

Plug for my (open source) project, mod_pagespeed: it can automate all of these.

> not using image sprites

sprite_images filter: https://developers.google.com/speed/pagespeed/module/filter-...

> not using a cookieless domain for images and other static content

MapRewriteDomain directive: https://developers.google.com/speed/pagespeed/module/domains...

> not using a CDN

Once 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 head

defer_javascript filter: https://developers.google.com/speed/pagespeed/module/filter-...

> not minifying your javascript and CSS

rewrite_javascript: https://developers.google.com/speed/pagespeed/module/filter-...

rewrite_css: https://developers.google.com/speed/pagespeed/module/filter-...

> not optimizing caching policies

mod_pagespeed automatically longcaches everything: https://developers.google.com/speed/pagespeed/module/filter-...

> not gzipping your content - most if not all popular web servers support some type of compression

mod_pagespeed automatically enables gzip compression

About 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.)

Very cool project (and in C++)!

HN is not bad with 91/100: https://developers.google.com/speed/pagespeed/insights/?url=...

Compared to PageSpeed home (unfair) 64/100: https://developers.google.com/speed/pagespeed/insights/?url=...

;-)

PS: The FAQ source code link points Google Code (instead of GitHub: https://github.com/pagespeed/mod_pagespeed)

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.

"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.

I think that's a bit unfair. He's not saying you are required to commit your own time in order to meet performance requirements; he's just saying that the business needs to take a balanced view on priorities in order to ship. So if you care enough about a deprioritised issue that you can't sleep, and the company is unable or unwilling to change its priorities, feel free to fix it on your own time. Or don't. Your call.

Now if the company demanded certain perf issues be resolved ahead of shipping and didn't provide company time for it, that would be a different matter and I'd agree with you.

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. http://mrale.ph/blog/2014/02/23/the-black-cat-of-microbenchm... 2. http://mrale.ph/blog/2014/12/24/array-length-caching.html

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.

Anyone have a credible resource for when HTTP/2 might be more common? Akamai has it, but it's in "beta". The apache module is marked as "experimental". Cloudflare says about 25% of current browser traffic is from browsers capable of using it.

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

I agree with that at a high level, but it's not necessarily practical to do that definitively and cover

  - all the various browsers
  - all the various network speeds (3G, 4G, DSL, Fiber, etc)
  - all the different devices

There is value in having some set of high level guidelines or best practices, which of course, can be argued over.

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

Or simply not caring about the end user.

> 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 partners

Aka shady ad/tracking networks. This isn't a technical problem.

My steps for better performance:

  1. apache gzip rules
  2. apache expires headers
  3. smaller images with ImageAlpha/ImageOptim
  4. javascript to bottom of the page

Simple things to make your webpage load faster.

Agreed, although I'm not sure how much #4 matters for a "CRUD" app written in Angular - there's nothing worth seeing until JS runs :-)

... other than a div that says "Loading..." for half a second to a second. Yeah, not great, but it's an app (HUGE government form), not a marketing flyer.

Is there any advantage to moving JavaScript to the bottom of the page when most browsers support <script async> and <script defer>?

Also, number 2 REALLY shines when you have concatenated items such as scripts together, so you just check the expiration of "all-the-scripts.js", and only load it once.

(apologies to those who already mentioned concatenation, but I thought it worth mentioning what a bonus "cache headers PLUS concatenation" is)

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.

That's easy to say. Tons of websites can actually function financially due to those ads and analytics.

I know, I work in the ad industry.

However a good 75% of it is unnecessary and because of bad business management rather than technical reasons. There are better ad networks and analytics services, combined with better site architecture and code, that can make a big impact if the publishers cared to do it.

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

Could you expand? I'm going through this right now and it would probably be useful.

I think he's noting a cdn won't help with low bandwidth on the client end, i.e. assumably cellphone users, which make up a large proportion of the Internet. Only reducing the size of the site would help.

Yeah. I think we've all seen sites that use an image CDN to serve up a 4 MB PNG, which ends-up scaled down to 1/3rd size on the page anyway.

The CDN might help the ping time of that request, but on a low-bandwidth device, 4 MB is still 4 MB no matter what server it's coming from.

Yeah, though CF does have content optimization features, including one that auto-resizes images to the type of device.

That's awesome. Do you have link to docs?

It's more a marketing page than documentation: https://www.cloudflare.com/mirage/

They have a bunch of similar features: https://www.cloudflare.com/features-optimizer/

Wouldn't the CDN'd resource be already cached for most users (if we're talking about the average, often used resource)?

The last mile is the limiting factor in this case. A super cached 4mb image still takes a minute to load on a 64 KiB/second connection.

Augh, I see.

I don't understand why a 4 mb image would be likely cached. The problem is mostly custom sites with massive assets, not your copy of jquery that's probably heavily redundant.

CDN will pretty much always help, regardless of the device, by responding faster to requests.

They aren't magic though and still require optimization at some stage to be optimal for everyone. This can be during the development process of some CDNs like CF have front-end optimization settings to reduce images dynamically, inline JS, minify content, etc.

Using both dev-time and run-time optimization can greatly help performance.

   "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."

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.

Not if you love your work and you are lucky enough to work for a good company that you really want to contribute to.

I think its a bit rude for you to suggest someone who brings some work home has no life. Many developers are passionate about their job, they love learning and most importantly they love a good challenge. You don't stop thinking about a challenge at work as soon as the clock hits 5.

Perhaps this is a great contrast between individuals that pushed themselves into programming for a job and people who fell in love with it and got a job out of it.

Its also a shane that the former is what most people find themselves in. A means to an end in a world that isnt very kind to everyone.

That's not the only two groups in question here.

There are those that spend off-time programming, just not for their employer's tasks.

The quid-pro-quo of employee-employer loyalty is largely gone these days, so it's not unreasonable to only work the hours you're compensated for.

Why would loyalty have any impact on gifting your employer free work? You can be loyal without giving away things for free.

Perhaps we're using the term in two different contexts.

I'm using the term loyalty for lack of a better term. There was a time when employees would often go above and beyond for their employers, because the reverse was also often true. Roughly, the shift away from the "lifetime employment" model.

Things like:

- Somewhere in the 1980's, when layoffs started to happen even in relatively financially healthy companies

- The move from pensions to 401k's

- The shift of a higher percentage of healthcare costs to the employee's portion

- More focus on hiring outsiders into higher level positions, versus training/placing internal candidates

Specifically, I might be incented to occasionally "work for free" if I thought the company would, for example, not lay me off during a particularly rough financial period.

Ah, I see. Personally, I think it's a bit healthier regardless to see your employment as a fair exchange of time for money, and not read anything else into it. There's no confusion about who owes what -- it's all spelled out for you.

What is the connection between "people who fell in love" with programming and donating your time to a for profit enterprise? If you love what you do, that's wonderful. However, work (and time) should be compensated for.

It's actually the difference between professionals, who know how to negotiate and get compensation for their work, and naive exploited people who will get the short end of the stick in most deals and get dropped like dead weight when the company downsizes without a second thought for all their gift contributions...

I fell in love with programming but I think it's ridiculous to gift my free time to my employer. During my free time I'd rather write my own software (or open source) that has a chance of either benefiting humanity or getting me rich.

I think that people who work on their employer's projects during their own time are unimaginative - they could be writing their own software for their own benefit but they instead choose to make their employer rich and not see any of that compensation themselves.

This is of course assuming you're drawing a salary from the company and you're not mostly paid in equity, in which case putting in free hours might make more sense if you can make the product profitable.

I think perpetuating this stereotype is pretty bad for programmers everywhere. You can be a good programmer and passionate about your job and still not gift your time to your company without compensation. Work-life-balance is really important if you don't want to burn out after five years.

I am pretty much in agreement with you.

However I am curious how others feel about learning on your own time. I do a fair bit of that (and the company often benefits as a result) but there is hardly a set line between working and learning in our line of work, its definitely a continuum.

If you are passionate about coding, work on free software or build a team with which you work on stuff.

This is much more rewarding than doing unpaid work for your boss on code that will probably never see the light of day anyway.

There is a lot to learn by collaborating with other people on code projects of this nature.

I'd say learning is a bit different, it might benefit your current employer but it also benefits your future employment prospects so it makes sense for you to study it in your own time. Working on your employer's work probably doesn't.

I love what I do and really enjoy contributing to what the company I work for does (web based education software). But I absolutely don't rewrite bits of the codebase or develop new features in my free time.

I love programming and working out how to solve a problem, but if it something my employer makes money off then they can give me the time to fix it. In my own time, I work on my own projects and challenges. Be it the automation bot I have running in my house or the games that me and a few friends create.

Doing work stuff in your own time can - and does - lead to the expectation that you'll do it more, so the business accounts for that and will possibly even count it against others that don't do it.

Jeez people, I also disagree with oolongCat, but is the heavy downvoting really warranted?

> messy code eats up many more man-hours than having it written cleanly the first time

I think it's more accurate to assume that a company/team doesn't have the ability to write it cleanly until proven otherwise, and a manager/developer blame game signals the company's lack of this ability (this says nothing about an individual manager or developer's ability when taken alone or in a different context - due to multiplicative factors, a team is often much better or much worse than the sum of its members)

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

Lol

Reply on news.ycombinator.com