Your own code is usually not the slowest part of your WordPress site. The scripts you borrow from other companies often are.
Analytics, ad networks, social embeds, chat widgets, font services, review badges, and video players all arrive from domains you do not control. Each one can add network requests, download JavaScript, run code on the main thread, and sometimes pull in further scripts of its own. Individually they look harmless. Together they are one of the most common reasons a site that is well cached and well optimised still feels sluggish, especially on a phone over a mobile connection.
The fix is rarely to delete everything. It is to know exactly what is loading, decide what each script earns, and control when the rest runs. Done carefully, you can keep the tools you need and still recover a meaningful amount of speed.
What counts as a third-party script
A third-party script is any JavaScript file loaded from a domain other than your own. It typically falls into one of these groups:
- Analytics and marketing tags, such as Google Analytics, Meta Pixel, and tag managers
- Advertising scripts and header-bidding code
- Social embeds, share buttons, and comment systems
- Chat, support, and pop-up widgets
- Video embeds from YouTube, Vimeo, and similar platforms
- Review, booking, map, and form widgets
- Font and icon services
The cost is not just file size. A script can block rendering while it downloads, compete for bandwidth with your own content, execute long tasks that delay interaction, and set cookies or trigger further requests long after the page appears loaded. That is why PageSpeed Insights flags third-party code separately, and why two sites with identical themes can score very differently.
Step 1: Audit what is actually loading
Do not guess from your plugin list. Many plugins quietly load scripts from other domains, and some scripts only appear on certain pages, such as a chat widget on every page or a booking form on one landing page.
Start with a baseline measurement. Run your homepage and one important inner page through PageSpeed Insights and note the third-party summary, the total blocking time, and the interaction score. Then open the same pages in your browser, open DevTools, and look at the Network tab filtered by JavaScript. Sort by domain. You will usually find a short list of heavy hitters and a long tail of small files that add up.
Write the audit down. For each third-party script, record the domain, the pages it appears on, what business purpose it serves, and roughly how much it costs in requests and execution time. This list becomes your decision sheet. Without it, optimisation turns into random plugin toggling, and you will not know what actually helped.
If the audit shows heavy JavaScript from your own theme or plugins rather than outside domains, that is a related but separate job. Our guide to removing unused JavaScript covers per-page script control, and our guide to reducing JavaScript execution time explains how to measure script costs with DevTools.
Step 2: Sort every script into keep, delay, or remove
Once you have the list, be honest about each entry. Every script should justify its place on the page.
Keep, but load well: scripts that directly support revenue or a core function, such as analytics on a site that acts on its data, or an ad script on a page that earns from ads. These still deserve the loading techniques below, but they are not candidates for removal.
Delay until interaction: scripts that are useful but not needed for the first view, such as chat widgets, social feeds, review badges, and many marketing tags. A visitor does not need a chat box before they have read a headline. Delaying these until the user scrolls, moves the mouse, or simply after a short idle period is often the single biggest win in this whole exercise.
Remove or replace: scripts nobody uses, duplicates, and tools installed for a campaign that ended months ago. Tag managers deserve special attention here. They make it easy to add tools, and just as easy to forget them. Audit the container itself, not just WordPress. The same applies to old social share plugins that load several networks at once when you only need one share link.
Step 3: Delay non-critical scripts properly
Delaying a script means it does not compete with your content during the initial load. Most good caching and optimisation plugins now offer this in some form.
In WP Rocket, the Delay JavaScript Execution option holds back selected scripts until user interaction. In FlyingPress and LiteSpeed Cache, similar delay and defer options exist, and Perfmatters offers a script manager with delay controls. The exact label differs, but the principle is the same: list the scripts to hold back, and let the plugin release them when the visitor interacts or after the page has settled.
Start conservatively. Delay one group at a time, then test the affected pages as a real visitor would. Check that analytics still records pageviews, that forms still submit, and that any delayed widget appears when expected. A common mistake is to delay everything, including the script that renders a form or a checkout button, and only discover the breakage from a customer complaint.
Step 4: Load only what each page needs
Many third-party scripts load everywhere by default, even when they are only needed on one page type. A booking widget does not belong on blog posts. A review badge does not belong on the checkout. A map embed does not belong on every page just because it appears in a footer widget.
Per-page control is the fix. Perfmatters and Asset CleanUp both let you disable scripts on specific pages, post types, or URLs. Some plugins also offer their own per-page toggles. Use them deliberately: keep the script where it earns its cost, remove it everywhere else, and retest the pages you changed.
The same logic applies to embeds. A YouTube video in a post should not cost the full YouTube player on every page that links to the post. On the page where the video actually appears, a facade — a lightweight thumbnail that loads the real player only when clicked — keeps the visual appeal without the upfront cost. Our earlier guide to lazy loading videos and iframes walks through that pattern in detail.
Step 5: Self-host where it genuinely helps
Self-hosting means serving a file from your own domain instead of someone else’s. It can help when the file changes rarely and you can cache it properly. Google Fonts is the classic example: hosting fonts locally removes an extra domain connection and gives you full control over caching and font display. That is a well-understood win, and it is covered in our guide to hosting Google Fonts locally.
Be selective, though. Self-hosting an analytics script or an ad script is usually a bad idea. Those files change, they may be served with specific headers or cookies, and hosting a stale copy can break tracking or violate the provider’s terms. The same caution applies to scripts that load further scripts dynamically; copying the first file does not capture the chain behind it.
Step 6: Use resource hints sparingly
Preconnect and DNS-prefetch tell the browser to set up a connection to a third-party domain early, so that when the script is eventually needed, the connection is already warm. For a script you have decided to keep — analytics on every page, for example — a preconnect can shave off a small but real delay.
The key word is sparingly. Every preconnect costs the browser work, and preconnecting to ten domains you barely use is worse than preconnecting to none. Limit hints to the one or two domains that matter most on that page, and place them in the head where they can act early. Our guide to resource hints explains each hint type, when it helps, and when it hurts, including the common mistake of preconnecting to domains that only load after interaction.
Step 7: Handle ads and chat widgets as special cases
Ads and chat widgets are the two categories most likely to undo an otherwise good optimisation job, because both are designed to load early and stay active.
For ads, the fixes are familiar: load ad scripts asynchronously, reserve space for ad slots so the layout does not jump when an ad arrives, lazy load below-fold ad units, and delay non-critical ad-related scripts where your ad setup allows it. Do not delay the script that fills an above-fold slot you depend on for revenue, but do question whether every ad unit on the page needs to compete for the first load. Our guide to stopping ads from slowing down WordPress covers these techniques in more depth, including ad density and layout-shift fixes.
Chat widgets need a similar judgement call. If live chat genuinely converts visitors, keep it — but delay it until interaction or until the visitor has spent time on the page, and consider showing a simple contact button first. Many sites install chat because it was offered free with another tool, not because visitors use it. Check your chat logs before assuming it earns its cost. If nobody has started a conversation in weeks, the honest fix is to remove it and put a clear contact link in its place.
Step 8: Measure the before and after
Third-party optimisation is easy to get wrong if you only look at a single score. A script delayed until interaction may barely change a lab score while making a large difference to a real visitor, and vice versa. So measure both.
Re-run PageSpeed Insights on the same pages you baselined, and compare the third-party summary, total blocking time, and interaction metrics. Then test as a visitor: load the page on a phone, scroll, open the delayed widgets, submit a form, and complete any key action the page exists for. Check that analytics still fires and that no console errors appeared. Keep the before-and-after numbers with your audit sheet, so the next person who proposes adding a new tool can see what the last round of additions cost.
Common mistakes to avoid
Delaying a script that renders visible content, then wondering why part of the page appears late or not at all. If content depends on a script, delay the script only if you also accept the content arriving late.
Adding preconnect hints for every third-party domain on the page. Two well-chosen hints help; ten just add overhead.
Removing a script in a staging test, declaring victory, and never checking the live page where a different plugin loads it again. Always verify on the live URL, on the page types that matter.
Forgetting the tag manager. If your tags live in a container, auditing WordPress alone misses half the problem. Audit the container with the same keep, delay, or remove discipline.
A practical checklist
- Audit every third-party script by domain, page, purpose, and cost
- Sort each one into keep, delay, or remove
- Delay chat, social, review, and non-essential marketing scripts until interaction
- Restrict page-specific widgets to the pages that actually need them
- Replace heavy embeds with facades, plain links, or native alternatives where possible
- Self-host only stable, rarely changing files such as fonts
- Preconnect to at most one or two essential domains per page
- Treat ads and chat as special cases, with layout space reserved for ads
- Measure before and after, and test every key action as a visitor
Third-party scripts are not the enemy. They are tools rented from other companies, and each should justify its cost on every page it appears on. Audit once, control when scripts load, and revisit the list whenever a new tool is proposed.