How JavaScript impacts page loading speed on mobile

By Andy Favell

Screenshot shows tested with PageSpeed Insights (as detailed in text).

The effect of JavaScript on mobile web performance is twofold.

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.

JavaScript (aka scripts or JS) is one of the triumvirate of technologies that make web pages (and web apps) work. The HTML (Hypertext Markup Language) controls the structure and content of the webpage; CSS (Cascade Styling Sheets) controls how the site looks on different devices; and JavaScript makes the page more interactive and dynamic.

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.

JavaScript could potentially have more of an impact on page performance than images. As Patrick Meenan, founder of the web performance testing site WebPageTest and software engineer at Google, explains:

“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.”

It’s not necessarily JavaScript, per se, that is the problem, but how it is implemented: scripts can monopolize browser activity, blocking the download and rendering (displaying) of other content.

“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.”

We will discuss below the difference between blocking, inline, synchronous (sync), asynchronous (async) and deferred scripts and how to fix JavaScript problems, but first we’ll look at how to spot issues.

Testing for blocking JavaScript

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:

Eliminate render-blocking JavaScript and CSS in above-the-fold content

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 Go to the full article.

Source:: Search Engine Watch

Be Sociable, Share!