Your Script Loader is Killing You (Slowly)
Your Script Loader is Killing You (Slowly)
My name is Ben, I'm a developer at Gawker, and today I just want to briefly go over one very small part of the process of auditing web performance and looking for possible improvements.Kinja Performance Team
Our mandate: dramatically improve site performance on Gawker Media sites (Gawker, Jezebel, Deadspin...). Try to deliver readable pages to most users within 1 second.
At Gawker, we recently started to focus more intensively on web performance. We're working on improvements in a number of areas, and I wanted to show some of the process for how we identify the issues to improve on.Some Possible Performance Angles to Investigate
Network requests/initial page load time Rendering performance Script execution / event-handler performance There are a lot of areas to target in a performance analysis. For purposes of this presentation, I'm going to focus in just on network requests and initial page load time, as this is the simplest way of targeting some of the most critical performance issues affecting a site and a logical starting point.Waterfall Analysis
A great way to begin any web performance effort is by analyzing waterfall charts. (Webpagetest.org is one fantastic free tool for viewing these)
Let's take a look at one!
Gawker.com Homepage Waterfall
Fancy D3 use here is just for presentation prettiness purposes... just going to Webpagetest.org, or other synthetic testing tools like New Relic Synthetics, is all you need to do to get started analyzing page load waterfalls.
While LTE usage is rapidly increasing, it still represented < 50% of US mobile subscriptions as of 2014. So it's important to test for worst-case performance.
All requests
144 in total!
Total load time: 23.5s
This is a lot of requests! And total load time on 3G is obviously far from ideal. Let's take a look at some of the issues that could be resolved here.All requests
Scripts • Images • Fonts/Styles
Scripts
Third-party requests
Ad-related requests, mostly. 114 of our 144 requests...
Can we just remove all ads?
Like most media companies, a large chunk of our revenue comes from ads.
Revenue is used to pay software developers as well as some others involved in the business.
So we need some other way of making money.
Emergent Media Revenue Models
A lot of people like to talk about the future of media and what revenue models will work if ad revenue dries up. These are just a few ideas for alternate business models.
Current Bitcoin exchange rate is ~$245/BTC. If we sell the egg cups for 1/10th BTC and half of that is profit, we have to sell 3,646,677 egg cups to reach Gawker Media's 2014 net revenue of $45 million.
(The business side nixed both ideas)
Back to the waterfall...
Third-party requests
So, we can't eliminate these 114 requests right away. Let's focus on our first-party content...
First-party requests
Now we're looking at 30 requests, much more manageable.
(loaded in 18.8s)
First-party requests(images)
First-party requests(no images)
23 requests (loaded in 10.4s)
First-party requests(script loader + main scripts)
Our script loader, require.js, followed by a 0.94s gap before the scripts it loads start to come in. 1.67s total delay.
3 requests (loaded in 8.4s)
Conventional Wisdom on Script Loading
This is bad:
<script src="dependency1.js"></script> <script src="dependency2.js"></script>
This is good:
<script src="combined-scripts.js"></script>
This is acceptable:
<script src="require.js" data-main="combined-scripts.js"></script>
But... concurrent is better
Two inline scripts (2.63s):
Concatenated (2.62s):
Require.js (2.8s):
These are some example timings for the various script-loading approaches. Require.js is a great tool, but as you can see, it imposes some clear performance penalty here. This penalty isn't so extreme in this simple example, but on a complicated site, you're more likely to be CPU-limited, and it can take extra time for Require.js to begin execution, meaning a longer pause before your real scripts even start to load.Summary
We used the power of waterfall charts to identify some key performance issues to investigate further:
- A lot of third-party scripts — can we reduce # of vendors?
- Images — can we improve image delivery/optimize further?
- Blocking behavior of script loader — we are working on switching to Webpack.
- (Almond.js is another alternative option for loading an AMD build) We did not succeed in identifying a workable alternative revenue model for a large-scale media company.
Thank you!
Tools used for this presentation: