Speed work usually starts when a site “feels slow,” when a Lighthouse score drops, or when ads become more expensive as conversion rates slip. And honestly, that’s fair. But what we often see in agency handoffs is not a lack of effort — it’s effort spent in the wrong places.
Below are six mistakes we keep bumping into, why they hurt, and what we do instead when we run a proper speed pass.
Why “fast” is more than a score
A fast website is not just a nice UX detail. It’s a business lever:
- Faster pages usually mean more completed checkouts and form fills
- Fewer layout jumps and delays reduce rage clicks and drop-offs
- Better stability helps SEO and paid landing page performance
- A smoother site lowers support friction (“the site is broken” reports that are really slow loads)
The catch: speed issues rarely come from one “big” thing. They come from a few repeated patterns that stack up.
Mistake 1: Chasing the Lighthouse instead of the real user experience
Lighthouse is useful. But in many agency projects, it becomes the goal rather than a guide.
Many projects treat it like a final exam: “We got 95, so we’re done.” The problem is that users don’t browse your site in a lab.
The problem is simple: Lighthouse is a lab test. But your users are not in a lab.
Users are on mobile devices, on slower networks, with 5 tabs open. They’re clicking fast. They’re trying to find a product, filter the list, add it to the cart, and check out. A page can score great in Lighthouse and still feel slow, clunky, or “sticky” in real life.
So what does this mistake look like? You optimize only the homepage, while the category, product, cart, and checkout pages remain heavy. Or improve the score by fixing “what the tool complains about,” but ignoring what users actually do. Or you do the testing on a fast laptop and call it done.
Making these changes that help the score, but don’t improve conversions (or even make UX worse) is the biggest mistake.
What we do instead:
- Start with real user journeys (home → category → product → cart → checkout)
- Check field data (where available) and compare it to lab results
- Validate on mid-range mobile and realistic network conditions
- Define what “good” means for the business (bounce rate, conversion, revenue per visit)
Example: It’s often better to make product pages feel instant and stable than to squeeze 3 extra points out of a homepage report.
If this is the stage you’re in, our Website speed optimization process is built to align “fast” with outcomes, not just numbers.
Mistake 2: Image optimization stops at “We compressed them.”
Images are usually the biggest payload on modern sites. But “compressing” is only step one. We often see things like a 4000px hero image (and shown at 900px). The browser still downloads the full 4000px file, wasting download time, bandwidth, and memory/CPU.
We often see outdated formats (for example, using JPEG everywhere instead of modern formats) simply because they were the old default. But newer formats can often deliver the same quality with smaller file sizes (like WebP or AVIF). Smaller file = faster load.
Also, if the site uses the same URL for everyone and there are no responsive image sizes, mobile users will download desktop assets. And it will significantly slow your site. Mobile screens are smaller, but mobile networks are often slower. This is the worst combo: big downloads on slow connections. Use responsive images.
Lazy loading is another important tool for speed optimization. It delays images until the browser thinks they’re near the visible area. But lazy-loading the wrong images (including ones users need instantly) delays the most important visuals, so the page feels empty or “still loading” even when the layout is there.
Better approach (simple, but powerful):
- Serve modern formats when possible (like WebP/AVIF)
- Deliver responsive sizes (so each device downloads what it needs)
- Lazy-load below-the-fold images, but never delay the main hero/product image
- Preload truly critical visuals (carefully, not everywhere)
This is one of the fastest wins we deliver in Website speed optimization because it reduces bandwidth while improving perceived speed.
Mistake 3: “We have caching.” (but it’s not the right caching)
Caching is often configured as a checkbox feature: “CDN on, caching on, done.” But caching has layers, and the wrong setup can create weird bugs or no benefit at all.
We often find things like uncached HTML, so every request hits the server. Every time someone opens a page, your server has to regenerate it (run backend code, run database queries, build the HTML), which increases server load. Under traffic spikes, it can get much worse.
Or we find that static assets (images, CSS, JavaScript, fonts) are poorly cached (short TTLs, frequent cache misses). Browsers/CDNs are told to keep these files for only a short time (short TTL), or the setup causes them to re-download frequently. Static files should usually have long cache lifetimes (weeks/months), as long as you also use cache-busting.
Cache-busting is the other side of the coin. If you don’t have a cache-busting strategy and update your CSS/JS, some users will still have the old versions cached, and the site will look broken until they refresh. Use versioned filenames or query strings that change when the file changes to avoid these troubles.
You get random “site is broken” reports after deploys, and you can’t rely on caching to be safe? You need cache-busting.
A big e-commerce killer is failing to distinguish between logged-in and logged-out behavior. Caching treats all visitors the same, even though logged-in users see personalized content (account info, cart, prices, loyalty tiers, recommendations). The worst mistake would be if one user sees another user’s cart/account bits. To avoid that (”just to be safe”), caching gets disabled, and you lose performance.
Another caching mistake occurs when you have CDN enabled but still serve heavy assets from the origin (your main server where your site is hosted). CDN (content delivery network) is a global network that serves cached files closer to users. So if you turned on CDN and big files still load from your server, you are just wasting resources.
A more reliable caching stack usually includes:
- Browser caching for static files (long TTL + versioned filenames)
- CDN caching for global delivery (images, CSS, JS, fonts)
- Server-side caching, where it makes sense (especially for database-heavy pages)
- Clear cache rules for dynamic pages (cart/checkout/account)
This is where DevOps and hosting work often becomes the difference between “slightly faster” and “why didn’t we do this earlier?”
Mistake 4: Too many third-party scripts, too early
It’s very normal for a site to have: analytics, ads/pixels, heatmaps, chat widgets, A/B testing tools, review widgets, recommendation engines, embedded fonts, and icon libraries.
The mistake isn’t using them. The mistake is letting them all load immediately, on every page, for every user.
This causes a slower first load, especially on mobile. And you want to avoid that slow load. That first impression is everything.
Buttons feel unresponsive due to the ‘main thread’ blocking. When the main thread, which handles all the important stuff on the page (like showing content, running JavaScript, handling clicks, taps, scrolling, and typing, running animations and UI updates) gets overloaded, the browser can’t “pick up” user actions quickly.
It can cause Layout shifts (pop-ins from widgets). A layout shift occurs when the page is already visible and something loads, pushing content around. So the user is reading or about to click… and suddenly the text jumps down, or the button moves. Or the page “wiggles” while loading. That jumpy feeling is a layout shift.
Example: A chat widget loads a big bundle, then injects the bubble and shifts the page.
Third-party scripts can cause extra network requests that compete with your actual content. That’s bad because your page has a limited “download budget” at the exact moment it matters most. So your important content arrives later than it should.
What we typically recommend:
- Audit all third-party tags and remove duplicates
- Load scripts only on pages where they’re needed
- Delay non-critical scripts until after interaction or consent
- Replace heavy widgets with lighter alternatives where possible
If your site “should be fast” but still feels sticky, third-party scripts are a frequent culprit.
Mistake 5: No route/page-type splitting (shipping the whole site to every page)
A lot of agency builds look tidy in the repo, but ship too much at runtime.
For example, we have one giant JS bundle for the entire site. All JavaScript gets packed into one big file (bundle) and loaded on every page — even if the page only needs a tiny part of it.
So why is it bad? We have big files that take longer to download; the browser must parse and execute the bundle (CPU work) before the page feels interactive. Mobile devices feel this the most.
The solution is to only load the JS needed for that page.
Example: The checkout page should not load the homepage slider code.
Another mistake is CSS that includes every component, even if the page uses only five. Your CSS file contains styles for the whole site: every widget, every section, every page type… even when a page only uses a few components. This means it slows the initial render (the browser must download and process it before the page is displayed properly). And it often hides unused CSS that keeps growing over time.
The solution is to have small critical CSS for the above-the-fold content. The rest loads after, or per template/page type. And make sure to remove unused CSS regularly.
Code splitting is another important subject. No code splitting by route or template means your site loads the same JS for all routes/templates. And users pay for code they’ll never use on that page.
What “good” looks like:
Split by page type: product page JS, category filtering JS, checkout JS, blog page JS. Each page loads only what it needs.
Another important thing is animations and sliders that run on pages that don’t need them. Scripts for carousels/animations (that are part of the bundle) get loaded and executed site-wide, even on pages where those elements don’t exist. That means extra JS and CPU work for no benefit to users. It can cause janky scrolling and can create weird bugs (scripts trying to initialize things that aren’t there).
Load those scripts only on pages that actually use them, or only initialize them when the element exists.
Better patterns (without making the project complex):
- Split code by page type (home, category, product, checkout)
- Inline only the tiny CSS needed for the above-the-fold layout
- Defer non-critical JS and avoid heavy libraries when simple code works
This overlaps with Development work — because many speed problems are not “settings.” They’re architecture decisions.
Mistake 6: Render-blocking fonts (and font bloat)
Loading fonts is important. Fonts loading in a way that blocks rendering can be problematic. Fonts can block rendering when the browser waits for custom font files to load before showing text, which can look like a brief moment of invisible text (or text that appears and then “jumps” as the font swaps in).
But it should appear as text immediately, with minimal or no shifting, because only the most important font is loaded early (the rest is delayed). To achieve this, you can use a swap strategy and fewer font weights/files.
What we typically recommend:
- Use smarter font loading (and fewer font weights)
A quick checklist you can use on your next project
If you want a quick gut-check before you optimize:If you can’t confidently say “yes” to most of these, there’s usually real performance upside left on the table.
- Are you measuring speed on the full buying journey, not one page?
- Are images responsive and correctly prioritized?
- Do you have caching across the browser, CDN, and server where needed?
- Have you audited third-party scripts and delayed non-critical ones?
- Are you shipping only the CSS/JS a page actually uses?
Want us to find the bottleneck fast?
If you want a clear plan (not a vague list of “improve performance”), check out our Website speed optimization service and book a performance audit. We’ll pinpoint what’s slowing your site down, what to fix first, and what will move the needle for conversions.
If deeper work is needed, we’ll map it to Development and DevOps and hosting.
And if you want to see what this looks like in practice, check out our Case studies.
Let’s not let your website sprint in a winter coat
Speed optimization isn’t about squeezing one more point out of a score. It’s about removing friction so your users (and your revenue) can move freely.
If your site is trying to run while wearing five layers of scripts, oversized images, and “checkbox caching”… it’s time for a wardrobe change.
Book an e-commerce health audit →
FAQ
1) How many third-party scripts are “too many”?
There’s no magic number, but if you have multiple tracking tools doing the same job (or scripts loading on every page “just in case”), it’s usually too many. A good rule is: keep only the scripts that clearly impact revenue or decision-making, and load the rest only where they’re needed.
2) Should we remove scripts or just delay them?
Start by removing duplicates and anything nobody uses. After that, delay non-critical scripts (heatmaps, chat, A/B testing) until the main content loads or until consent is obtained. Keep only the truly essential scripts loading early.
3) What’s the fastest speed you usually see?
Images and third-party scripts. Serving properly sized images (with modern formats) and cleaning up tags often cuts load time quickly without touching the backend.
4) Will caching and a CDN fix everything?
They help a lot, but they won’t fix heavy pages on their own. If the site ships huge JS bundles, blocks rendering with fonts, or loads too many scripts early, caching can’t remove that work — it can only deliver it faster.