We still hear the same opener in client calls: "Could this be our CSS?" Sometimes yes. Often no. On plenty of sites, the first real bottleneck is not your h1 style or a spacing token. It is third-party JavaScript that arrives early, executes long, and competes with the content users came for.
Before we touch CSS on a slow page, we run one quick triage pass. It is not fancy. For a key template, this is a short set of script patterns we can usually spot in under an hour, then turn into action items with owners.
If you want the full deep dive specifically on third-party offenders, read our Watcher guide on Third-Party Scripts and Performance: How to Identify and Fix the Worst Offenders. And if your biggest LCP element is an image (which it often is), see also our Image Optimisation Strategies for Better LCP Scores
Below is the field checklist we use before opening a CSS file. It matters most when you manage multiple sites and regressions hide between client handoffs.
1) The "loaded on every page by default" tag manager
Pattern: You have one container script in <head>, then years of marketing and product experiments inside it, all loading on every route.
Why it hurts: The container itself is not always huge, but the chain reaction is. A "small" addition this month can become five extra downloads, plus parse and execute work on pages where that logic has no purpose.
What we check first:
- Which tags fire on landing pages versus logged-in app routes
- Whether old campaign tags are still active
- Whether consent gating actually blocks execution, not just UI display
Typical fix: Split triggers by route and user intent. Keep default fire rules tight. If a script only matters after an interaction, do not run it at first paint.
2) Chat and support widgets booting before content
Pattern: Chat launches on page load, including pages where users are still reading hero copy.
Why it hurts: Many chat widgets do setup work immediately, then keep listeners active. That means more main-thread pressure while the browser is still trying to render above-the-fold content and become interactive.
What we check first:
- Does chat load before or after LCP
- Is there a clear conversion benefit on first screen
- Can "open chat" click be the load trigger
Typical fix: Load on intent. A small launcher can render early, but the heavy script can wait until click, inactivity threshold, or specific routes like pricing/support.
3) A/B test scripts rewriting the DOM during paint
Pattern: Experiment code runs early and mutates hero blocks, CTAs, or pricing cards before stable render.
Why it hurts: You get a two-part penalty: extra JavaScript work plus layout instability from late mutations. Even when CLS does not spike dramatically, you still get visual delay and shaky user trust.
What we check first:
- How many active experiments target first-screen modules
- Whether experiments run server-side or client-side
- Whether the script blocks while waiting for variant assignment
Typical fix: Move critical variants server-side where possible. Keep client-side tests for below-the-fold or non-critical components. End stale experiments quickly.
4) Social, video, and map embeds used as live iframes by default
Pattern: A page ships with full YouTube/Maps/social embeds in every article card or blog section.
Why it hurts: Those embeds pull heavy third-party stacks and iframes, even when users never interact.
What we check first:
- Number of embeds in viewport at load
- Connection and CPU cost from each provider
- Whether each embed is essential to the first-screen experience
Typical fix: Use facades. Show a thumbnail and play button first; load full embed on click or when it nears viewport. This one change alone can cut large chunks of JavaScript work.
5) Analytics duplication across tools and team boundaries
Pattern: GA, product analytics, ad pixels, and custom events all track similar actions, often multiple times, with no one owning cleanup.
Why it hurts: Duplicate tracking means duplicate network calls and duplicate handlers. It also poisons reporting, because teams debate numbers coming from overlapping instruments.
What we check first:
- Event map by tool, not by team
- Duplicate page-view or conversion events
- Pixel overlap after consent and route filters
Typical fix: Create one tracking ownership map. Decide primary tool per event type. Remove duplicate sends unless there is a clear legal or platform requirement.
6) "Defer" scripts that still execute in one long burst
Pattern:
Everything is marked defer, so the build looks fine in code review, but execution still lands in a dense block right after parse.
Why it hurts:
Deferring download order is not the same as controlling execution cost. You can still get long tasks that damage responsiveness and push INP in real interactions.
What we check first:
- Long tasks around load and first user input
- Script execution waterfall in Performance panel
- Which vendor scripts contribute the biggest task chunks
Typical fix:
Phase execution by importance. Keep critical measurement, delay secondary scripts, and push non-essential tooling after first interaction or idle windows.
7) Third-party scripts with no budget and no owner
Pattern: There is no performance budget line for third-party script cost, and no explicit owner can approve or reject additions.
Why it hurts: The stack grows silently. Every quarter adds "just one more" script, then teams only revisit it when Lighthouse scores dip or paid traffic quality drops.
What we check first:
- Is there a budget for third-party transfer and execution cost
- Who approves new script additions
- Whether regressions trigger alerts or only show up in ad hoc audits
Typical fix: Treat third-party scripts like any other production dependency. Add budget thresholds, approval rules, and recurring cleanup. If you need a structure for that governance layer, use your existing review cadence plus a simple monthly offender list.
The triage order we actually use
When a page is slow, we do not start with broad "optimisation" statements. We run this sequence:
- Identify the largest render and interaction bottlenecks from real runs.
- List third-party scripts by cost (bytes + execution + main-thread time).
- Remove or delay the top offenders that have weak business value.
- Re-test, then move to image and CSS improvements if needed.
This order matters. CSS work has value, but it is often marginal compared with removing one badly timed third-party widget.
What changes after you do this for a month
You get cleaner pages, but also cleaner decision-making.
Teams stop arguing in abstractions such as "marketing versus engineering". Instead, you can ask one practical question for each script: what outcome does this drive, and what performance cost are we accepting for it?
Once that conversation is visible, script bloat usually drops within the first cleanup cycles.
A practical next step for this week
Pick your top ten revenue or lead pages.
For each page, document:
- third-party scripts loaded at first view
- who owns each script
- whether each script must run before first interaction
Then remove or delay the weakest 20 percent and measure again.
You do not need a full rebuild to see gains. You need clear triage, ownership, and one pass of disciplined cleanup.