
Web Page Performance Death by a Thousand Tiny Cuts - dragthor
http://metroize.com/web-page-performance-death-by-a-thousand-tiny-cuts/
======
userbinator
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.)

~~~
codedokode
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.

~~~
nitwit005
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.

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

~~~
codedokode
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.

~~~
imaginenore
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.

------
cbr
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-...](https://developers.google.com/speed/pagespeed/module/filter-
image-sprite)

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

MapRewriteDomain directive:
[https://developers.google.com/speed/pagespeed/module/domains...](https://developers.google.com/speed/pagespeed/module/domains#mapping_rewrite)

> 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-...](https://developers.google.com/speed/pagespeed/module/filter-
js-defer)

> not minifying your javascript and CSS

rewrite_javascript:
[https://developers.google.com/speed/pagespeed/module/filter-...](https://developers.google.com/speed/pagespeed/module/filter-
js-minify)

rewrite_css:
[https://developers.google.com/speed/pagespeed/module/filter-...](https://developers.google.com/speed/pagespeed/module/filter-
css-rewrite)

> not optimizing caching policies

mod_pagespeed automatically longcaches everything:
[https://developers.google.com/speed/pagespeed/module/filter-...](https://developers.google.com/speed/pagespeed/module/filter-
cache-extend)

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

~~~
vmorgulis
Very cool project (and in C++)!

HN is not bad with 91/100:
[https://developers.google.com/speed/pagespeed/insights/?url=...](https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fnews.ycombinator.com%2Fnews)

Compared to PageSpeed home (unfair) 64/100:
[https://developers.google.com/speed/pagespeed/insights/?url=...](https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fdevelopers.google.com%2Fspeed%2Fpagespeed%2F)

;-)

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

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

~~~
lukebennett
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.

------
nawitus
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...](http://mrale.ph/blog/2014/02/23/the-black-cat-of-
microbenchmarks.html) 2\. [http://mrale.ph/blog/2014/12/24/array-length-
caching.html](http://mrale.ph/blog/2014/12/24/array-length-caching.html)

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

~~~
tyingq
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.

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

~~~
tyingq
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.

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

~~~
jacquesm
Or simply not caring about the end user.

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

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

~~~
Roboprog
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.

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

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

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

~~~
manigandham
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.

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

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

~~~
duaneb
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.

~~~
blakeyrat
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.

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

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

~~~
icebraining
It's more a marketing page than documentation:
[https://www.cloudflare.com/mirage/](https://www.cloudflare.com/mirage/)

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

------
frign

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

~~~
oolongCat
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.

~~~
formula1
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.

~~~
tyingq
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.

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

~~~
tyingq
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.

~~~
jdmichal
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.

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

~~~
throweway
Lol

