JavaScript can make a page feel slow even when the files are not huge. The browser has to download scripts, parse them, compile them, and run them on the main thread before it can respond to some user actions.
Third-party scripts make the problem harder to see because the cost comes from services outside your codebase: analytics, chat, consent banners, embeds, ads, tag managers, heatmaps, and testing tools.
The main-thread cost
Images mostly cost network and decode time. JavaScript also costs execution time.
When a script is running, the browser may not be able to process a tap, scroll smoothly, paint the next frame, or finish building the page. This is why a page can look loaded but still feel sticky.
Open DevTools, record a Performance trace, and look for long yellow blocks near page load or first interaction. Then expand the block to see which script or domain caused it.
Third-party domains in Network
Switch to the Network panel and filter by JS. Look at the domain for each request.
Common patterns:
- several scripts from a tag manager
- a chat widget that loads more scripts after its first file
- analytics from multiple vendors
- social embeds that request fonts, images, and extra JavaScript
- A/B testing scripts that run before content appears
Each request has its own connection, timing, and execution cost. A tiny script can also become expensive if it triggers more files.
Render-blocking JavaScript
A script placed early in the document can block rendering when it has no async or defer attribute. The browser pauses HTML parsing, downloads the script, runs it, then continues.
Use this pattern only for code that must run before the page can be shown. Most analytics, widgets, and enhancement scripts do not belong there.
async vs defer
Both attributes stop a script from blocking HTML parsing, but they behave differently.
Use defer for scripts that should run after the HTML is parsed and preserve order:
<script src="/assets/site.js" defer></script>Use async for independent scripts where order does not matter:
<script src="https://analytics.example/script.js" async></script>Do not add either attribute blindly. Some old plugins and widgets depend on a specific load order. Test the page after changing script attributes.
Remove scripts before delaying them
The best script is the one the page does not load. Check whether each third-party script still has a current purpose:
- Is the heatmap tool still being reviewed?
- Are two analytics tools tracking the same event?
- Does the chat widget need to load before the visitor opens it?
- Is the tag manager carrying old campaigns?
- Does a social embed matter more than page responsiveness?
Removing one unused service can cut network requests, JavaScript execution, cookies, and layout injections at the same time.
Delay nonessential work
Some scripts are needed, but not during the first screen. Load them after the page becomes usable, after consent, after interaction, or only on pages where the feature appears.
Examples:
- load a booking widget only on booking pages
- load a map after the visitor opens the location section
- load a chat widget after the main content is visible
- load video embeds only when the preview is clicked
This changes the visitor’s first few seconds without removing the feature entirely.
Keep a before-and-after trace
After removing, deferring, or delaying scripts, record the same page again. Compare:
- total JavaScript transfer size
- number of third-party domains
- long yellow blocks in Performance
- first-screen render timing
- input delay after the page appears
If JavaScript work is now under control but the first screen still appears late, move to loading strategy. The next bottleneck may be font loading, image priority, or layout stability.
