What JavaScript costs in load time

How it works

An image is done once it has arrived. A script only starts then: the browser has to read it, compile it and run it. All of this happens on the main thread, the same one that handles clicks and input. While a script runs, the page does not respond. That is what INP measures.

How much this slows things down depends on the device. A current laptop runs the same script many times faster than a budget phone.

bytereport counts the transferred size of all script files the HTML includes. Scripts written directly into the HTML and those that other scripts load later are not included. Up to about 350 KB is good, over 1 MB counts as poor. Because the size is measured compressed, the browser has several times that amount to process.

What matters

• Only what is needed. A page often loads a whole library for a single feature, such as a slider or a menu.
• Rare features on demand. A form wizard or a map need not load with the page, only when someone opens it.
• Minified and compressed. Minifying strips spaces and comments; compression during transfer comes on top.
• Keep an eye on third-party scripts. Tracking, chat and advertising often bring more JavaScript than the page itself, see third parties.
• Out of the way. Scripts in the head of the page need defer or async, otherwise they halt rendering, see render-blocking resources.

How to set it up

Which scripts a page loads is decided by the theme, plugins and embedded services. In the CMS, switch off plugins nobody uses, or limit them to the pages that need them. In the tag manager, check which tags anyone still looks at.

For custom-built sites this is a job for the agency or development team: the build tool (a bundler such as esbuild, Rollup or webpack) minifies the files and splits off rarely used code, which is then loaded with import() when needed. The list in the details shows the scripts by size; start at the top.