What actually slows a website down, cheapest fixes first

Fibvo editorial · 26 June 2026 · 4 min read

Pages feel slow on a phone. Someone suggests a faster server, and the money goes into hosting while an uncompressed hero photograph sits on the home page. Slow sites rarely have one cause. Several stack, and they get fixed in the wrong order: the cheapest problems are usually the heaviest. Here is that order, with the measurement for each.

Uncompressed images

Images are usually the largest download on a page and the easiest thing to fix. A photograph exported from a camera or design tool carries far more pixels than the space it fills on screen, and the browser downloads every one. Where that image is the largest element on screen, it decides when the page looks ready. Compress it, resize it to the dimensions it is displayed at, and serve WebP or AVIF with a JPEG fallback.

• In Chrome DevTools, Network tab: disable cache, throttle to a slow mobile profile, reload, sort by size. The top three rows are the work list.
• In the Elements panel, compare each image's intrinsic size with its rendered size. A large gap is wasted bytes.
• Give every image width and height so the layout cannot jump, and lazy loading below the first screen.
• Run Lighthouse and read only the image diagnostics. The overall score is a thermometer, not a target.

A faster server does not make a large image smaller.

Render-blocking third-party scripts

Scripts are the next cheapest fix and the one with the most resistance behind it, because every tag belongs to somebody. A chat widget, two analytics tools, a heat map, a review badge, a pixel for a campaign that ended last year. Each costs a DNS lookup, a connection, a download and time on the main thread. Anything in the head without async or defer stops the browser parsing, so the page waits on a server you do not control. A tag manager hides that rather than solving it.

• Group requests by domain in the Network tab. Anything that is not your domain needs a named owner in the business.
• Block one domain at a time with request blocking and reload. That finds the expensive tag.
• Record a trace in the Performance panel and look for long tasks. They are why a page looks loaded but ignores taps.
• Read the tag manager container. Any tag nobody can explain should go.

Remove first. Defer or load asynchronously what survives. Load a widget such as chat only on interaction.

Unbounded web fonts

Fonts are cheap to fix technically and awkward politically: the fix is often a design decision. Every family, weight and style is a separate file, so two families in four weights with italics is a stack of downloads before any text appears. An @import rule in CSS adds a serial request: the browser fetches the stylesheet, reads it, then fetches the font. Filter the Network tab to Font and count the files, then count the weights the design uses. Self-host, subset to the characters you need, preload the faces above the fold, and set font-display so text renders in a fallback rather than staying invisible.

Heavy page builders

The cost curve turns here: visual builders and multipurpose themes ship the assets for every feature they offer on every page, used or not. A contact page with a heading and a form can load a slider library, an animation library and a stylesheet for a page that does not exist. Plugins add their own assets sitewide. The page is slow structurally, and compression will not rescue it.

• Open the Coverage panel, reload, and read the unused bytes per file. A page using a small part of a large bundle is the signature.
• Count the stylesheets and scripts on your simplest page. If a contact page loads what the home page loads, assets are loading globally.
• On a staging copy, switch off plugins one at a time, measure, and note what each costs.

Conditional loading and switching off unused modules help. Past that you are paying to optimise a system built for flexibility rather than speed, and rebuilding the templates costs less.

Hosting

Hosting comes last because it is the most expensive layer to change and the least often the cause. A migration touches DNS, email, certificates and staging, and carries downtime risk. Look at time to first byte on the document request, not the assets. A long first byte on an otherwise light page means the server is thinking: no page cache, an old PHP version, database queries on every request, or CPU contention on a shared plan. Test from the region your buyers are in; distance is part of that number. If the server sits on one continent and the buyers on another, a content delivery network is cheaper than moving. We take no commission from any platform we recommend, and the hosting account stays in the client's name.

What fast enough means commercially

Lab tools are diagnostics. They tell you what to change, not whether the site is fast enough, because they run on a device and connection you chose. For that you need field data: real visits on the phones and networks your buyers have. Core Web Vitals are assessed that way, from real sessions, weighted towards the slower visits. Read them split by device and landing page: a quick home page can hide a slow product template.

Fast enough is the point where speed has stopped being the reason people leave. The test is whether the main content appears before a mildly interested stranger loses patience, whether the page answers the first tap, and whether the layout stops moving before a thumb reaches the button. Track enquiries per session alongside load time for a few months, so you see where the returns flatten in your own data rather than taking ours on trust. Then stop, and spend the next hour on the enquiry form.

---

Written by Fibvo — Bengaluru and Erode, India — working with clients in other time zones. Questions, or think we have it wrong? Tell us.