One, it is the second largest contributor to webpage weight, behind images, thereby increasing download time; and two, once downloaded, the browser then needs to run the script, which can delay the downloading/rendering of other (perhaps more important) assets on the page.
Scripts perform numerous functions on webpages such as loading ads, A/B testing, tag management (personalizing the page) or displaying an inline video player.
Over the last five years, the total weight of pages sent to mobile devices has quadrupled to 2.2MB. Size matters because, in general, the more data that is sent over a mobile, or fixed, network the longer a page will take to load. More data, more seconds staring at an empty mobile screen.
This suggests that images – which tend to take up more of the total kilobytes (KB) or megabytes (MB) of each page – are the main culprit. But this is not always the case.
“Scripts are usually a (bigger) issue because of the time it takes to actually execute the script in addition to the download size, while images really only matter because of the download size. With mobile devices for example, it can take several seconds to run a script even after it has been downloaded.”
“The problems are often compounded where the script is referenced in the page. The content after a ‘blocking’ script (as opposed to an async script) doesn’t exist, as far as the browser is concerned, until after the script has been downloaded and executed. When, as is commonly the case, scripts are put at the beginning of the page this means that the page will be completely blank until the scripts have downloaded and executed.”
If you have tested your webpages using Google PageSpeed Insights (N.B. you should regularly test your mobile webpages using tools such as WebPageTest and PageSpeed Insights), chances are you have seen the following warning:
! Should Fix:
Your page has 8 blocking script resources and 7 blocking CSS resources. This causes a delay in rendering your page.
None of the above-the-fold content on your page could be rendered without waiting for the following resources to load. Try to defer or asynchronously load blocking resources, or inline the critical portions of those resources directly in the HTML.
The text and image above is from a Mobile PageSpeed Insights test on BBC.com conducted in February 2017.
Note “above the fold” refers only to the part of the webpage which is visible on a mobile device, without scrolling, Google is not analyzing scripts on the rest of the page.
- BBC.com PageSpeed test (8 blocking scripts; 7 blocking CSS resources)
- NYTimes.com PageSpeed test (0 blocking scripts)
- ESPN.com PageSpeed test (2 blocking scripts; 3 blocking CSS resources)
- CNN.com PageSpeed test (6 blocking scripts; 2 blocking CSS resources)
This is clearly illustrated in the graph below from HTTP Archive. HTTP Archive tests the top 1 million sites several times every month using data from WebPageTest, and publishes trends and stats that are essential benchmarking for the performance of your site.
The image below compares the breakdown by content type for the average site with BBC.com tested by HTTP Archive (15 February 2017):
- The first thing to note is how impressively small the BBC page size is: 609KB v 2225KB.
- The second thing to note is how small the combined size of the BBC images: 70KB v 1501KB.
- The third thing to note is how proportionally large the scripts are: 458KB or 75.2% of total page size.
- The fourth thing to note (not shown in the charts below) is that 39 (44.3%) of the BBC’s total 88 requests are scripts.
- BBC.com tested by HTTP Archive: Scripts 458KB (75.2%) of 609KB of total data; 39 JS requests (44.3%) of 167 88 total requests.
- NYTimes.com HTTP Archive test: Scripts 1511KB (51%) of 2953KB of total data; 73 JS requests (43.7%) of 167 total requests. (N.B. NY Times has a dedicated mobile site at mobile.nytimes.com, which is not listed by HTTP Archive, which may deliver different results.)
- ESPN.com HTTP Archive test: Scripts 1183KB (65.7%) of 1802KB of total data; 50 JS requests (47.2%) of 106 total requests.
- CNN.com HTTP Archive test: Scripts 1484KB (68%) of 2182KB of total data; 67 JS requests (31.9%) of 210 total requests.
What is the effect on mobile page speed?
So does it follow that the slim-line BBC site would load much faster than all its rivals?
Err, no. On 15 February 2017, HTTP Archive recorded the following load times:
- BBC.com: 18.3 seconds
- NYTimes.com: 27.4 seconds
- ESPN.com: 8.8 seconds
- CNN.com: 31.5 seconds
So, the BBC is faster loading on a mobile device than CNN and the New York Times, but considerably slower than the (larger) ESPN.
This is what the two sites look like on a mobile device. (The filmstrip is one of WebPageTest’s most visually compelling features, easily understood by any non-techie). Each frame represents 1 second. When the HTTP Archive test took place, for 9 seconds BBC.com mobile visitors saw nothing, while for 4 seconds ESPN visitors saw nothing.
There could be many reasons why one website might be faster than another, such as server response times, use of content delivery networks (CDN), the impact of ad networks, inclusion of third-party data (common on news sites), or the time and place of the test (in this case California, USA).
Alex Painter, Web Performance Consultant at NCC Group:
- Inline scripts also stop the page build, but as they are included in the HTML, they do not need to be individually downloaded. However too large or too many inline scripts will bloat and delay the initial download of HTML file.
Are blocking scripts ever justified?
“If the site functionality relies on the code, then it needs to be run as a blocking script so that it is ready before the page needs it. A very common case for this is tag managers and A/B testing platforms where the code will change the page. In other cases blocking is used when it will be more work to load the functionality asynchronously.”
How big is too big? How many requests is too many?
This will always be a balancing act.
“Since the browser will only load six requests at a time for each domain, if you have more than that it needs to request the rest after the first ones have completed, leading to longer times from the request/response delays.
For more on how to optimize the speed of your mobile site, check out our previous three-part series:
Andy Favell is Search Engine Watch’s columnist on mobile. He is a London-based freelance mobile/digital consultant, journalist and web editor. Contact him via LinkedIn, or on Twitter at Andy_Favell.