Why is my website slow? Diagnosis and the fixes that actually work

A slow site can be held up by its server, its files or the browser's work after loading. Test an affected page and a real customer task before you change anything. Many problems can be fixed within the existing site. The right fix depends on where the delay happens and what your platform lets you control.

Test the affected pages and tasks

Start by working out what's actually slow. Waiting and unresponsive buttons create friction. That doesn't mean every second costs a fixed share of sales.

Core Web Vitals are three experience measures. Largest Contentful Paint (LCP) tracks when the main content shows. Interaction to Next Paint (INP) tracks how fast the page responds. Cumulative Layout Shift (CLS) tracks how much it jumps around. Field data comes from real visits, while lab data comes from a simulated test.

Google says its core ranking systems look to reward a good page experience. The field Core Web Vitals are what Google's ranking systems use. Good scores still don't guarantee rankings. Our guide to website speed and SEO covers the search side. If paid clicks land on a slow page, see our guide to Google Ads landing page problems.

Ask what's slow first:

• the public page, before useful content shows

• menus, buttons or search

• form submission or checkout

• the editor or admin area

Then ask when it started and what changed. Note which pages and people it affects. A platform incident, a failed integration or a browser extension can cause symptoms. So can a local network. A new image format won't fix any of those.

Treat a broken enquiry form or checkout as a fault, not a speed tweak. If the problem appeared suddenly, check your provider's status page and recent releases.

Make sure you can restore the site before changing it. Our guide to website backup and recovery covers that. If you can't undo a mistake yourself, go through your provider or developer.

Use this guide as a troubleshooting sequence. A quick win here means a small, understood change with a retest. It doesn't mean every change is safe on the live site.

Treat it as triage, not a diagnosis.

Record comparable tests

Test the affected URL plus a few important templates. Think homepage, a service or landing page and the contact page. Add product and checkout pages if you sell online. Pick pages by traffic and business importance, because the homepage doesn't represent everything.

Test mobile and desktop, focusing on the devices your customers actually use.

PageSpeed Insights is a free starting point. Search Console shows field data patterns. Chrome DevTools helps with deeper investigation. A manual test on a typical phone fills the gaps. GTmetrix and WebPageTest are optional alternatives if their current access suits you.

For a lab baseline, run each test three times. Record the median and the spread, then repeat the same method afterwards. That's our editorial method, not a Google rule. A single best run is weak evidence.

Don't compare a repeat visit with a first visit and call the gap an improvement. Repeat visits can reuse files the browser already stored. A common mistake is testing only the homepage.

Test consent states and logged in or cart states separately. A clean browser profile cuts extension noise. Private browsing can change stored preferences and caching, so label the state. Use authorised test data. Keep passwords, session details and personal information out of shared reports.

Keep the reports or screenshots with the record. Don't expose personal information in them.

Read the metrics correctly

PageSpeed Insights shows two different kinds of evidence. Know which one supports each claim.

The real user section covers the previous 28 days of Chrome user data. It reports the URL or falls back to the whole site when a page lacks data. Sometimes it shows no real user data. The lab section is a simulated test of the page right now.

Google assesses these at the 75th percentile, separately for mobile and desktop. Three in four visits should meet them. They aren't full page load times or a conversion promise. Our guide to LCP, INP and CLS explained covers the definitions.

Google's Lighthouse bands put 0 to 49 as poor and 50 to 89 as needs improvement. Scores of 90 to 100 count as good. Lighthouse's scoring guide says a perfect 100 is extremely hard to reach and not expected.

When field data is missing

Missing field data is unknown. It isn't a pass or a fail. PageSpeed can show a pass without enough INP data when LCP and CLS are good. Don't record missing INP as zero. Don't claim every interaction was tested.

A whole site result doesn't prove a particular page passes. Search Console's report groups similar URLs and shows a sample of pages. It isn't a live test of every page.

Without page data, use controlled lab tests. Where it's proportionate, add real user monitoring. That's a script that measures real visits on your site, set up with privacy in mind.

A lab test of the page load can miss later taps and layout shifts. Lighthouse can't measure INP, because nobody interacts with the page. TBT is its lab stand in. Record the menu, search, form or cart interaction where the symptom happens.

Match the symptom to the next check

The symptom tells you where to look first. It isn't a diagnosis.

A slow admin area points to backend work. It isn't proof you need a new host.

Rank the backlog by evidence, not by a list of usual suspects. Weigh how many important visits it affects and how severe it is. Then weigh effort and change risk. An oversized image may be a quick fix when its transfer is the bottleneck. It won't solve a slow interaction.

Keep a simple action list:

• the observed evidence

• the proposed change

• the owner and any dependency

• the acceptance check

When the main content appears late, the time goes in one of four stages:

Those stages come from Google's LCP guidance. The measured element can be text, not an image.

Images arrive too late or are too large

Fix images when the evidence points to them. Keep the originals, and test one representative change before replacing them in bulk.

Work through it in order:

• Find the measured LCP element and the file it actually downloaded. It may be text, or another image on mobile.

• Check the displayed size and screen density. Then check the format and the version actually served.

• Export versions in an efficient format such as WebP or AVIF. Compare the quality and keep the crop.

• Use your platform's responsive image features. Confirm the browser picks a sensible size.

• Keep the main image easy for the browser to find early. Lazy load suitable images further down instead.

• Set each image's width and height to stop movement.

• Replace the asset, test key screen sizes and repeat the same measurements.

There's no universal 1,200 pixel ceiling. The right size depends on the layout and the screen. Compression isn't always lossless, so check quality, crop and alt text as well as file size.

A small box on screen doesn't prove a small file was downloaded. Google's guidance is clear here. Never lazy load the LCP image. Use high priority on one or two key images at most. A common mistake is exporting every image at one fixed size.

<img src="/images/workshop-1200.webp"
srcset="/images/workshop-600.webp 600w,
/images/workshop-1200.webp 1200w"
sizes="(max-width: 640px) 100vw, 1200px"
width="1200" height="800"
style="max-width:100%;height:auto"
fetchpriority="high"
alt="Team preparing an order in the workshop">

This is an example for developer review, not a copy and paste fix. Paths, sizes, breakpoints and alt text must match your real assets. It leaves out lazy loading on purpose.

If the image is already small but starts late, look at discovery and priority. Discovery is when the browser first finds the file. A CSS background or a script that controls display can hide it from the browser.

If it downloads quickly but stays invisible, look at render delay, the gap before it's drawn. More compression won't necessarily help. Either way, a developer can trace the cause. Then repeat the same test.

The server or connection responds slowly

A slow first response is a symptom, not proof of bad hosting. Time to First Byte (TTFB) covers redirects, connection setup and waiting for the response. It isn't one of the Core Web Vitals.

Compare repeatable request timings and the routes affected. Check cache hits and misses too. A hit means the cache served a saved copy. A miss means the server built the page fresh. Before you buy an upgrade, ask the host for evidence:

• processor and memory use

• slow database work

• calls to outside services

• errors in the logs

A slow admin area supports an investigation. It can't isolate the cause on its own. Neither can the plan's price or an Australian server address.

For Australian visitors, test from a representative Australian connection. A documented nearby test location works too. A content delivery network (CDN) can cut some distance delays. Dynamic pages may still need the main server.

An Australian server isn't automatically faster than every overseas setup. Don't switch providers only because a remote test looks slow. Then retest the same timings.

Make server or software changes in an agreed maintenance window, with compatibility checks. A supported PHP upgrade can suit WordPress. It still isn't a blind toggle. When changing hosts, protect email, domain records and recovery. Our guide to choosing Australian website hosting covers capacity and host decisions.

An Australian test location helps represent local users. It doesn't prove every site needs Australian hosting.

Plugins or apps add unnecessary work

Don't switch off anything just because you don't recognise it. Record what each plugin or app does first:

• its purpose and business owner

• the pages and tasks it affects

• what it loads in the browser and does on the server

• what depends on it

Some plugins do no front end work at all. One poorly built feature can be expensive. A common mistake is judging a site by its plugin count.

Take a recoverable copy and use a safe test copy where practical. Disable one understood candidate at a time. Test every task that depends on it before removal. A licence tool, consent tool or hidden integration may matter even without a visible widget.

On Shopify, use the vendor's removal steps. Shopify notes that uninstalling an app doesn't automatically remove its code from your theme. Check for leftover theme code and any separate subscription. Repeat the baseline and the dependent tasks after removal.

An unknown purpose means investigate, not delete.

The theme or page builder does too much

A builder's name isn't a diagnosis. Compare the affected templates and find what causes the rendering work, large layouts or extra files.

Start with one important template. Remove unnecessary work and test equivalent content. Rebuilding one template or replacing one costly feature may be enough.

Then check the repair didn't break something else. Headings, links and structured data should still work. Accessibility and measurement need the same check.

A high element count or an unused code warning is a clue. It isn't proof every flagged byte can go. Menus, form validation and consent states may use code a first load never runs. If the builder's output can't be trimmed, take it to the theme developer. Our WordPress page builder comparison helps once a builder's limits are proven.

Scripts delay rendering or interaction

Scripts often carry real business functions, so take stock before cutting. List every script, including:

• tags coded into the site

• tag manager containers and apps

• consent tools

• maps, chat, reviews and booking widgets

Record each script's purpose, owner, trigger and pages. Note any sensitive data it sends.

Remove obsolete or duplicate integrations through the right owner. A heavy embed can wait until someone chooses to use it, with an accessible fallback. That can simply move the delay to the tap. Test that moment and the finished task.

For slow responses, record the interaction. Google splits it into input delay, processing time and presentation delay. A developer can then shorten long tasks and unnecessary layout work. There's no universal defer, async, minify or combine setting. Load order and required early behaviour matter.

A form can show a spinner straight away, yet take ten seconds to return from an outside service. That isn't ten seconds of INP. Check the prompt feedback and the time to a confirmed result. Include what the business actually receives.

Chrome DevTools records performance as the page runs. Its CPU throttling helps mimic a slower phone.

After any script change, retest:

• consent, before and after a choice

• form validation and successful delivery

• conversion events, without duplicates

• chat or booking access, and checkout

Don't delay a necessary consent control to lift a score. Don't remove measurement just to get a better lab report.

Server side tagging is a separate architecture decision. It can change some browser work. It still needs a measurement and privacy design. It won't remove every browser script or fix every slow response.

Caching is missing or misconfigured

Caching means reusing work instead of repeating it. There are several kinds:

• browser caching of reusable files

• page caching of generated pages

• object caching of repeated backend work

• CDN caching closer to visitors

A first time visitor can still get a cached page if someone else loaded it recently. A repeat visitor isn't guaranteed a cached copy. Several layers can each have their own clearing rules.

Check what your host and platform already provide before adding a plugin. Confirm the cache headers or documented diagnostics. Test an intended miss, then a hit. A common mistake is stacking two optimisation plugins that rewrite the same files.

Keep personal pages out of shared caches. WooCommerce says cart, checkout and account pages need to stay dynamic. Its cookies need the right handling too. A cached account page can even break password resets.

Test with several authorised sessions. Check that prices, carts and account details are right for each one. Forms should still submit. Never serve one customer's private content in a shared public response.

Clear caches the way your platform recommends after a change. Purging everything over and over can make measurements worse. It doesn't fix incorrect rules either. Leave detailed server configuration to the developer.

Video and animations compete with content

Video and animation earn their place when they help the message. Find the media requests and rendering work before removing anything.

A useful static poster, click to play video or fewer carousel slides can keep the message. Keep controls accessible and respect reduced motion settings.

A placeholder can steady the layout. It shouldn't hide a slow or broken essential task. If the platform controls the player, ask its support or your developer. Then retest the page and the video task.

Mobile pages do unnecessary work

Test the published page on representative phones. Screen size, processor power and connection are separate variables.

Check responsive images and duplicated desktop and mobile content. Embeds and extra rendering matter too. Hiding an element doesn't prove its downloads stopped. Check the network requests after you hide or remove it. If hidden content still downloads, ask your developer to stop it loading.

Don't cut what users need. Keep readable content, usable navigation, tap targets and forms. Shortening a page or deleting useful content isn't automatically a speed fix. Record mobile and desktop results, then prioritise the users actually affected.

It's a content call, not a ban.

Fonts delay text or shift the layout

Review the font files actually requested and the weights you need. Check which characters you use. An efficient format such as WOFF2 helps, with a suitable fallback font.

Google's font guidance suggests a swap display setting. Text shows sooner. A late font can still shift the layout. Match the fallback's size to the web font and test the result.

Preload only fonts that are genuinely critical, after checking the request order. Preloading takes browser resources from other files. Avoid downloading the same font twice.

Self hosting fonts isn't automatically faster. It still needs the right licence and setup. Leave advanced font adjustments to the developer.

Redirects or broken resources add delays

Point internal links and requested files straight at their final HTTPS address. Keep the redirects from old public URLs that people still use.

Fix missing scripts, styles and images. Don't remove HTTPS, security controls or required redirects to chase a small timing gain. Our guide to SSL and TLS explained covers secure connections.

Check redirect chains and failed requests along the affected journey. A missing file isn't always slow. Prioritise what sits on the measured critical path and breaks tasks.

Have a developer fix migration leftovers and template errors at the source. Patching each symptom separately leaves the cause in place.

Apply the fixes on your platform

Your platform decides which controls you have. Use its current official help for settings.

Platform notes:

• Self hosted WordPress: check the theme, plugins and host cache rules. Make a reversible change and test every affected task.

• Shopify: start with its Web Performance reports, built on Core Web Vitals from real visits. Shopify runs the hosting and image delivery. Review theme and app changes, media and storefront scripts. Then test product, cart and checkout journeys.

• Wix: check the Site Speed dashboard. Wix adjusts image sizes and lazy loads media by default. It can't optimise third party content, so add outside code only where needed. Test the published site, not just the editor.

• Squarespace: keep pages under 5 MB, as Squarespace advises. Custom code can slow a site. Save it in a text document before removing it to test.

• Webflow: check media, interactions and custom code. Then test forms and key templates.

Hosted platforms run their own infrastructure. A WordPress cache plugin or a new server isn't an option there. This guide fixes a diagnosed delay. It doesn't rank platforms.

Retest and keep the improvement

A change only counts once you've measured it the same way and the tasks still work.

Here's a worked example. The values are made up for teaching, not measured on any Elev8d or client site. Each state uses the median of three comparable mobile lab runs. No field INP value is implied.

The homepage figure fell by 2.8 seconds, about 53.8%. That's one metric under stated conditions. It doesn't mean the whole site or every visit got twice as fast.

The example work might include a better image file and a corrected load order. With several changes at once, you can't credit each one separately. Don't mix this lab example with a whole site field value.

Accept the change on three checks

Acceptance needs three separate checks:

• the diagnosed metric improves under comparable conditions

• required tasks still work

• the change holds up on real journeys

Retest forms through to the monitored inbox or CRM. Then check bookings or checkout, consent and tracking. Accessibility and key devices need a pass too.

Lab results show up straight away. The field window still holds older visits from the past 28 days. Review new real user data as it arrives. Separate a changing audience from the release effect.

Don't expect Google's report to turn green the next morning. A conversion change after the release doesn't prove the speed work caused it.

Keep the gain

Record the release date and the changed scope. Name an owner and a rollback route. Agree how often you'll review it.

A later app, image upload, campaign tag or template change can undo the gain. Keep a light performance budget for each important page, such as agreed file sizes and tasks. There's no universal byte limit. Regression checks belong in your ongoing website maintenance.

Lab evidence, task checks and later field data answer different questions. Fast pages but missing enquiries? That's a different problem. Our guide to why a website is not converting covers that.

Common mistakes and fixes

What to ask a developer and what it costs

There's no fair universal price for speed fixes. Ask for a quote that covers:

• diagnosis and the affected templates

• implementation and test coverage

• any licence or host changes

• exclusions, rollback and acceptance

Avoid any unconditional promise of a 100 score.

Here's an example quote in AUD excluding GST, at an assumed $150 an hour:

If the work is taxable at 10%, that's $1,320 with GST. These aren't Elev8d rates or a market benchmark. Recurring upgrades and new licences are separate.

When the cause is uncertain, pay for a diagnostic stage first. Set an approval limit before any fixes start. A fixed quote should name the scope and the test conditions.

Compare quotes for the same pages, functions and device conditions. Support and exclusions should match too.

Keep real fees separate from this teaching quote.

Repair a page or rebuild the site

Compare a targeted repair with a broader replacement before you decide. A supported site with one costly feature usually merits a scoped repair assessment.

A rebuild can make sense when several needs and measured limits line up. Unsupported software is one. Repairs that keep coming back are another.

Several slow pages don't make a rebuild the only fix. Compare the total cost and the downtime. Then weigh content migration and redirects. Access, support and your ability to run the new site matter too.

Try a proof of concept first. One representative page shows whether a new approach solves the problem. Our guide to when a website needs a redesign covers the broader signs. For a scoped repair or rebuild, see our website performance and development support.

What we recommend at Elev8d

Frequently asked questions

Next steps

Written by Ajay K.Co-founder, Elev8d

Ajay is the co-founder of Elev8d and writes most of what you will read here. Psychology grad turned marketer, which is a fancy way of saying he cares about why people click, not just where things rank. Every guide is written in plain English for Australian businesses, tested on real campaigns before it earns a spot on this site.