Why Is My Website Slow? A Complete Guide to Web Performance

The message usually arrives in one of two forms. Either a business owner writes, "My website is very slow, can you look at it?" Or, more often, they don't notice anything at all, and the problem surfaces sideways: enquiries have dropped, the Google Ads bill is the same but fewer people are calling, or a customer mentions in passing that "your site wasn't opening."

Then they open the site on their office laptop, on fibre broadband, with the page already sitting in the browser's cache from yesterday. It loads in a second. Everything looks fine.

That gap, between how your website behaves for you and how it behaves for the person you're trying to sell to, is where most speed problems hide. Your customer isn't on your Wi-Fi. They're on a three-year-old Android phone with two bars of 4G, standing in a queue, giving your page maybe three seconds before they hit back and tap the next result.

I've been building and fixing websites for businesses since 2018, and slow sites are one of the most common things I'm asked to look at. The good news is that the causes are rarely mysterious. The same seven or eight problems account for almost every slow site I've opened, and most of them can be found in an afternoon if you know where to look.

This guide walks through all of it in plain language: how to measure speed honestly, what the numbers mean, the usual culprits and how to fix each one, what you can do yourself, and how to tell when patching has stopped being worth it.

The short answer

If you want the list before the explanation, here's what makes most websites slow, roughly in order of how often I find it:

1. Oversized images. Photos uploaded straight from a phone or camera, several megabytes each, shown at a fraction of their real size.
2. Slow or overloaded hosting. Cheap shared servers, servers on the wrong continent, and pages rebuilt from the database on every single visit.
3. Too much JavaScript. Sliders, animations, page builders and frameworks that ship far more code than the page needs.
4. Third-party scripts. Chat widgets, tracking pixels, embedded reviews, social feeds and pop-up tools, each one adding weight you don't control.
5. No caching or compression. The server sends everything fresh and uncompressed, every time, to everyone.
6. Plugin and theme bloat. Especially on WordPress, where every plugin can add its own scripts and styles to every page.
7. Web fonts loaded badly. Several font families and weights pulled from external servers, blocking text from appearing.
8. Layout shift. Not technically slowness, but pages that jump around as they load feel broken, and Google measures it alongside speed.

Most slow sites have three or four of these at once. That's actually encouraging, because it means fixing the two biggest usually produces a dramatic difference.

First, find out how slow it really is (and for whom)

Before changing anything, get an honest measurement. Opening the site yourself and counting "one, two" doesn't tell you much, for the reasons above. Here are the tools I actually use, all free.

PageSpeed Insights

Go to PageSpeed Insights, paste your homepage URL, and run it. You'll get two kinds of results, and the difference between them matters a lot.

The top section, "Discover what your real users are experiencing," is field data. It comes from the Chrome User Experience Report, which collects anonymised timings from real Chrome users who visited your site over the previous 28 days. This is the closest thing you have to the truth. If your site doesn't get enough traffic, this section will say there isn't enough data, which is common for small business sites.

The lower section, "Diagnose performance issues," is lab data. Google loads your page once on a simulated mid-range phone with a throttled mobile connection and reports what happened. It's useful for finding causes, and the list of opportunities underneath is a decent to-do list. But it's a single synthetic test, so the score can wobble by several points between runs.

People fixate on the big coloured performance score. Don't. A score of 62 isn't a grade you failed. What matters is the individual metrics underneath, and specifically whether real users are getting a good experience.

Google Search Console

If your site is connected to Search Console (and if it isn't, set it up today, it's free and takes ten minutes), open the Core Web Vitals report. It groups your pages into "Good," "Needs improvement," and "Poor" based on field data, separately for mobile and desktop. It's the best way to see whether the problem is site-wide or limited to certain templates, like product pages or blog posts.

WebPageTest and your own browser

For deeper digging, WebPageTest lets you test from different locations and devices and shows a waterfall chart: every file the page loads, in order, with how long each one took. The waterfall is where causes become obvious. A 3 MB image or a script that takes two seconds to arrive from some ad server jumps right out.

You can do something similar in Chrome. Open DevTools (right-click, Inspect), go to the Network tab, tick "Disable cache," set the throttling dropdown to a slower mobile profile, and reload. Sort by size. Whatever's at the top is usually where you start.

Do one more thing that no tool can do for you: borrow an ordinary phone, not a flagship, switch off Wi-Fi, and open your site on mobile data somewhere with average signal. Watch it load. That experience is your real customer's experience, and it's often humbling.

A laptop screen showing a performance analytics dashboard with bar charts of page load time plotted against bounce rate. As load times stretch out, the share of visitors who leave without doing anything climbs with them

What the numbers mean

Google's Core Web Vitals are three measurements that try to capture what a visitor actually feels: how fast the main content appears, how quickly the page responds when you tap something, and how stable it is while loading. A page passes when at least 75% of real visits meet the "good" threshold for each one.

Metric	What it measures	Good	Poor
LCP (Largest Contentful Paint)	How long until the biggest visible element, usually the hero image or main heading, appears	2.5 s or less	Over 4 s
INP (Interaction to Next Paint)	How quickly the page visibly responds after a tap, click or key press	200 ms or less	Over 500 ms
CLS (Cumulative Layout Shift)	How much the content jumps around while loading	0.1 or less	Over 0.25
TTFB (Time to First Byte)	How long the server takes to start sending the page	0.8 s or less	Over 1.8 s

TTFB isn't one of the three Core Web Vitals, but I've included it because it's the first domino. If your server takes two seconds just to start responding, nothing else on the page can begin until it does, and a good LCP becomes nearly impossible.

A quick way to read your results:

• High TTFB? Look at hosting, caching and server-side code first.
• Fine TTFB but poor LCP? Usually images, fonts, or CSS and JavaScript that block the page from rendering.
• Poor INP? Too much JavaScript running on the main thread. Often third-party scripts or a heavy page builder.
• Poor CLS? Images and embeds without reserved space, late-loading banners, or fonts swapping in.

That one mapping will save you a lot of guesswork. Instead of "the site is slow," you'll know which part of loading is slow, and that points straight at the cause.

Why it matters more than it seems

It's easy to treat speed as a technical nicety, something developers care about. It isn't. It's a sales problem that happens to have a technical cause.

Think about who's on your site. Someone who searched "dentist near me" or "pashmina shawl online" and tapped your result. They have other options one swipe away. If your page is still white after three seconds, the cost to them of going back and trying the next result is almost nothing. You never find out they came. They don't appear in any enquiry form or phone log. They just leave.

There's decent research on this. A 2020 study by Deloitte and Google, Milliseconds Make Millions, looked at mobile sites for 37 brands and found that a 0.1 second improvement in mobile speed was associated with retail conversions rising by 8.4% and average order values going up as well. I'd treat any single number with some caution, since your business isn't a European retail brand. But the direction is consistent across every study I've read, and it matches what I see in analytics: slower pages lose more visitors at every step.

Then there's money you've already spent. If you're paying for Google or Meta ads, every click you buy lands on your site. A slow landing page means you pay full price for visitors who leave before seeing your offer. Speeding up the page is often the cheapest way to make the same ad budget go further.

And search rankings. Google does use page experience, including Core Web Vitals, as a ranking signal. I want to be honest about its weight, though: it's a tiebreaker, not a trump card. A fast page with thin content won't outrank a genuinely better answer that's a bit slower. Where speed really matters for SEO is indirect. Fast pages get crawled more efficiently, keep visitors around longer and earn the engagement that helps everything else. If you're working on rankings more broadly, my 12-month SEO roadmap and the local SEO checklist for Srinagar businesses cover the parts that carry more weight.

A laptop on a table showing an online store's shopping cart page with a sofa in the basket, next to a mug of hot chocolate. The checkout is where a slow page costs the most, because the visitor has already decided to buy

What actually happens when someone opens your page

A rough mental model helps you understand why some fixes matter enormously and others barely register. Simplified, a page load goes like this:

1. The browser finds your server. DNS lookup, then a secure connection. On mobile networks, each of these round trips can take a noticeable fraction of a second, longer if your server is far away.
2. The server builds and sends the HTML. On a static or well-cached site, this is nearly instant. On a site that runs dozens of database queries per visit, it can take seconds. This is your TTFB.
3. The browser reads the HTML and discovers what else it needs. CSS files, fonts, scripts, images. Some of these, particularly CSS and scripts in the page head, block anything from being shown until they've arrived.
4. The page paints. Text and layout appear, then images fill in. The largest element appearing is your LCP.
5. JavaScript runs. Interactive bits come alive. If there's a lot of it, the phone's processor is busy and taps feel sluggish. That's INP.
6. Late arrivals. Ads, chat widgets, cookie banners and embeds load in, sometimes shoving content around. That's CLS.

Every slow site I've fixed was slow at one or more of these stages. Now let's go through the usual causes.

Cause 1: Images that are far too big

This is the most common problem by a distance, and the easiest to fix.

Here's how it usually happens. Someone takes a lovely photo of the shop, the product or the team on a modern phone. That file is 4 to 6 MB and around 4000 pixels wide. It gets uploaded straight into the website's hero section, where it's displayed at maybe 1200 pixels wide on a laptop and 400 on a phone. Every visitor downloads the full 5 MB anyway. Multiply that by a homepage with eight such photos and you've built a 30 MB page. On mobile data, that's not a page load, it's a download.

A Sony camera body and three Canon lenses arranged on a dark table. A single photo from a modern camera or phone can easily outweigh an entire well-built web page

How to fix it

• Resize before you upload. No image on a typical website needs to be wider than about 1600 to 2000 pixels, and most can be much smaller. A product thumbnail might only need 600.
• Compress. A photo saved at quality 75 to 80 looks practically identical to the original on a screen and is often a fifth of the size. I built a free image compressor and image resizer that run in your browser, without uploading your photos anywhere, for exactly this job.
• Use modern formats. WebP and AVIF are typically much smaller than JPEG or PNG at the same visual quality, and all current browsers support them. You can convert existing images with the image converter.
• Serve different sizes to different screens. Done properly, a phone gets a phone-sized image and a desktop gets a larger one. This is what the srcset attribute does, and modern frameworks generate it for you automatically.
• Lazy-load images below the fold, so the browser only downloads them when the visitor scrolls near them. Use loading="lazy" on the <img> tag.
• But don't lazy-load the hero image. This is a very common mistake, often made by optimisation plugins that lazy-load everything. Your main above-the-fold image is usually your LCP element, and you want it to start downloading as early as possible. If anything, mark it as high priority with fetchpriority="high".

Here's what a well-behaved hero image looks like in plain HTML:

<img
  src="/images/shop-front-1200.webp"
  srcset="/images/shop-front-600.webp 600w,
          /images/shop-front-1200.webp 1200w,
          /images/shop-front-1800.webp 1800w"
  sizes="100vw"
  width="1800" height="1012"
  alt="The shop front on Residency Road at opening time"
  fetchpriority="high">

The width and height attributes matter too, but we'll get to that under layout shift.

Also check for background videos. An autoplaying video behind your hero text can be 10 or 20 MB on its own. If you must have one, compress it hard, give it a lightweight poster image, and consider not loading it at all on mobile.

Cause 2: Hosting that can't keep up

If your TTFB is over a second, the problem is on the server, and no amount of image compression will fix it.

A server rack in a dark room lit by green status lights, with bundles of network cables running down its side. Where your site is hosted, and how that server is set up, decides how quickly the very first byte reaches a visitor

Cheap shared hosting

Budget hosting plans put hundreds, sometimes thousands, of websites on one physical server. When your neighbours get busy, your site slows down. Resources like CPU and memory are capped tightly, and the cheapest plans are often running older software. For a brochure site with a few visitors a day this can be acceptable. For a shop, a booking system or anything you run ads to, it's usually a false economy. The difference between a ₹2,000-a-year plan and a properly configured one is small next to the enquiries a slow site quietly loses.

A server on the wrong continent

Distance still matters. A request from a phone in Srinagar to a server in the United States and back crosses a lot of ocean, and a page needs many such round trips. If most of your customers are in India, your server, or at least a copy of your content, should be close to them. Most cloud providers have data centres in Mumbai, and a good CDN (more on that below) has locations across the country.

Pages built from scratch on every visit

Many websites, WordPress and other CMS-based sites especially, generate each page on demand: run PHP, query the database for the content, the menu, the widgets and the settings, assemble the HTML and then send it. For a page whose content changes once a month, doing that work for every single visitor is pointless. Page caching stores the finished HTML and serves it instantly. On a site without it, turning it on is often the single biggest improvement you'll see in TTFB.

Slow database queries and backend code

For custom web applications, dashboards and online stores with large catalogues, the slowdown is often in the code itself: a product listing that runs a separate database query for every item, a missing index on a table that's grown to hundreds of thousands of rows, or a report that recalculates everything every time someone opens it. These problems don't show up when the database is small and appear gradually as the business grows, which is why a system that felt fast at launch can crawl two years later. Fixing them is proper development work rather than a setting, and it's a big part of what I do on custom software projects.

Cause 3: Too much JavaScript

JavaScript is what makes pages interactive, and modern websites ship a lot of it. The trouble is that JavaScript is expensive twice. It has to be downloaded, and then the phone has to read, compile and run it. A file that downloads quickly on good Wi-Fi can still lock up a mid-range phone's processor for a second or more while it executes. During that time, taps and scrolls feel stuck, which is exactly what INP measures.

Lines of JavaScript code in bright syntax colours on a dark screen. Every line of script shipped to the browser has to be downloaded, parsed and run on the visitor's phone before the page responds properly

Where does it come from? The usual suspects:

• Sliders and carousels. Often a whole library to rotate three banners that most visitors never see past the first slide.
• Animation libraries used for a few fade-ins that CSS could handle on its own.
• Page builders that wrap every element in layers of extra markup and load their full script bundle on every page, used or not.
• jQuery and its plugins, still loaded on many sites even though nothing modern depends on them.
• Frameworks shipped whole. A single-page app that sends the code for the entire site before showing the first screen.

Fixing this is about subtraction. Remove what isn't earning its keep, load the rest only on pages that need it, and defer anything non-essential so it doesn't block the first paint. In modern frameworks like Next.js, a lot of this happens by design: components render on the server by default and only the genuinely interactive parts send JavaScript to the browser. I explained how that works in the Next.js architecture guide, and it's one of the main reasons I build client sites that way.

Cause 4: The pile of third-party scripts

This deserves its own section because it's where the most well-meaning damage happens.

A typical small business site I audit has some combination of: Google Analytics, Google Tag Manager, a Meta pixel, a LinkedIn insight tag, a live chat widget, a WhatsApp button that loads its own script, an embedded Google Map on the homepage, an Instagram feed, a reviews widget, a cookie banner, a pop-up email tool and, occasionally, a heatmap tool that someone installed for a month in 2023 and forgot about.

Each was added by a different person at a different time for a sensible reason. Together, they can account for more than half the JavaScript on the page, from a dozen different servers, none of which you control. A chat widget alone can be several hundred kilobytes and is frequently one of the heaviest things on the page.

Here's how I approach it:

1. List every third-party script on the site. The Network tab in DevTools, filtered by domain, makes this quick.
2. Ask of each one: who uses this data, and when did they last look at it? If nobody can answer, remove it.
3. Delay what you keep. A chat widget doesn't need to load before the visitor has even seen the page. Loading it after a few seconds, or when someone clicks a placeholder button, keeps most of the benefit and removes most of the cost.
4. Replace heavy embeds with lightweight facades. A YouTube video can show a still thumbnail with a play button, and only load the real player when clicked. Same for maps: a static image of the map linking to Google Maps is often all a visitor needs.
5. Consolidate. Several tracking tags can usually be managed through one tag manager, with rules about where they fire.

This is also where performance and marketing need to talk to each other. Tracking matters, and I'd never tell a business to fly blind. But a digital marketing setup that measures everything on a page nobody waits around for isn't measuring much.

Cause 5: No caching, no compression, no CDN

These three are infrastructure, and they're often missing entirely on sites that were set up quickly.

Browser caching tells a visitor's browser it can keep files like your logo, CSS and fonts for a while, so the second page they visit doesn't download them again. It's controlled by Cache-Control headers on your server. Without them, every page view starts from zero.

Compression shrinks text files (HTML, CSS, JavaScript) before sending them. Gzip has been standard for years, and Brotli usually does better. It's a server setting, it's free, and it routinely cuts text file sizes by 70% or more. You can check whether your site uses it in the Network tab by looking at the content-encoding response header.

A CDN, or content delivery network, keeps copies of your site's files on servers around the world and serves each visitor from the nearest one. Cloudflare's free plan is enough for many small sites. Modern hosting platforms like Vercel and Netlify include a CDN by default, which is part of why sites built for them tend to be fast out of the box.

If none of these are in place, setting them up is usually a few hours of work with an outsized effect.

Cause 6: WordPress, plugins and page builders

I want to be fair here, because WordPress gets blamed for a lot. A WordPress site can be fast. I've seen lean, well-built ones that score beautifully. But the typical WordPress site isn't built that way, and the reasons are structural.

The common pattern: a premium multipurpose theme that supports every possible layout (and loads the code for all of them), a visual page builder like Elementor or WPBakery, and twenty to forty plugins. Each plugin may add its own CSS and JavaScript to every page, whether that page uses the feature or not. A contact form plugin loading on your blog posts. A slider plugin loading on pages without sliders. Then a caching plugin and an optimisation plugin are added on top to try to undo the damage, sometimes conflicting with each other.

If you're on WordPress and want to improve things without rebuilding:

• Audit your plugins. Deactivate anything you don't actively use. Fewer is nearly always faster.
• Install one good caching plugin and configure it properly, rather than stacking several.
• Update PHP to a currently supported version through your host's control panel. Newer versions run noticeably faster.
• Use an image optimisation plugin that converts uploads to WebP and resizes them automatically.
• Consider moving off a page builder for your most important pages if they're the ones failing Core Web Vitals.
• Check your hosting. Managed WordPress hosting with server-level caching often fixes more than any plugin can.

Whether WordPress is the right foundation for your business at all is a bigger question, and I've written about it honestly in custom build vs WordPress vs no-code and, for businesses here, custom websites vs WordPress in Kashmir.

Cause 7: Fonts that hold your text hostage

Custom fonts make a brand feel like itself, and I'm not going to tell you to give them up. But they're often loaded in a way that slows everything down.

The usual problems: loading four or five font families, each in six weights, when the design uses two families and three weights. Pulling them from an external server, which adds extra connections before any text can show. And not telling the browser what to do while it waits, so on a slow connection visitors see a page with no text at all for a second or two.

The fixes are simple:

• Use fewer fonts and weights. Two families and three or four weights cover almost every design.
• Self-host them on your own domain, in the compact WOFF2 format.
• Use font-display: swap so the browser shows text immediately in a fallback font, then swaps in your custom font when it arrives.
• Preload the one or two fonts used above the fold.

Cause 8: Layout shift, the page that won't sit still

You've had this happen: you go to tap a link, an image above it finishes loading, the whole page jumps down, and you tap an ad instead. That's layout shift, and it's measured as CLS.

It doesn't make the page slower, but it makes it feel broken, and on a checkout or a form it causes genuine mistakes. The causes are almost always:

• Images and videos without width and height attributes, so the browser doesn't know how much space to save for them until they arrive.
• Banners, cookie notices and promo bars inserted at the top of the page after it has rendered.
• Embeds and ads that load into containers with no fixed size.
• Fonts swapping in with noticeably different sizes from the fallback.

The fix is to reserve space for everything that will appear. Give images their dimensions, give embeds a container with a set aspect ratio, and make banners overlay the page rather than pushing it down.

The mobile reality, especially here

Everything above gets worse on mobile, and in Kashmir mobile is the main event. Most people who find a local business online here do it on a phone, and a large share of those phones are mid-range Android devices. Signal across the valley varies a lot: excellent in parts of Srinagar, patchy on the highway, weak in many villages and in the basements and back rooms of old buildings.

A person in a dark jacket holding a smartphone in both hands, thumb on the screen. Most visitors meet a local business's website on a phone like this, often on mobile data rather than Wi-Fi

Two consequences follow. First, a slow phone suffers from heavy JavaScript far more than a laptop does, because its processor is much weaker. A script that takes 200 milliseconds to run on your MacBook might take a second and a half on a budget phone. Second, every extra network round trip hurts more on a mobile connection, so a page that pulls files from fifteen different servers feels much slower than one that loads from one or two.

This is why I build and test everything at phone size first, on a throttled connection, and treat desktop as the easy case. If a page is fast on a mid-range phone on 4G, it'll be fast everywhere. The reverse is not true.

What you can fix yourself this week

Not everything needs a developer. Here's a practical list for a business owner with a bit of time and access to the site's admin panel:

1. Run PageSpeed Insights on your homepage and your two or three most important pages. Note the LCP, INP and CLS for mobile.
2. Find your heaviest images. Re-export them at a sensible size, compress them, convert to WebP, and replace the originals.
3. Remove what nobody uses: old tracking tags, forgotten plugins, the slider on the homepage, the Instagram feed that hasn't updated since last year.
4. Replace the embedded map on your homepage with a static image and a "View on Google Maps" link. Keep the full map on your contact page.
5. Check your hosting plan and server location. If you're on the cheapest shared plan with servers abroad, ask your host about moving to an Indian data centre or upgrading.
6. Turn on caching and compression if your host or CMS offers them as a setting.
7. Connect Search Console if you haven't already, so you can watch the Core Web Vitals report improve over the following weeks. Field data updates over a rolling 28 days, so give changes time to show up.

These steps alone fix a surprising number of slow sites. If you've done them and things are still sluggish, the remaining problems are usually deeper ones: server configuration, the theme or framework itself, backend code, or how the front end is built. That's the point where a developer earns their fee.

When patching stops making sense

There's a stage some websites reach where every fix is a workaround for the last workaround. The theme is heavy, so you add an optimisation plugin. That breaks the menu, so you add an exclusion. Speed improves a little, then the next plugin update undoes it. You're paying, in money or in hours, to hold back a tide.

Here's my honest rule of thumb for deciding between optimising and rebuilding:

Optimise the existing site if:

• The site is reasonably modern, and the problems are mostly images, caching, hosting and a few heavy scripts.
• It does what your business needs, and you're happy with the design and content.
• Fixing the top issues would get you into the "good" range for Core Web Vitals.

Consider a rebuild if:

• The theme or page builder is the bottleneck, and every page carries its weight regardless of content.
• You've already been through one or two rounds of "optimisation" with little lasting change.
• The site needs other significant work anyway: a redesign, new features, better structure for SEO, or online ordering.
• It was built years ago on technology that's hard to maintain or secure.

A rebuild isn't automatically the expensive option. If a site needs ongoing performance patching, a new design and new functionality, doing all three properly once can cost less than doing them badly three times. If you want a sense of numbers, I've broken down what websites actually cost in Kashmir in 2026, including what drives the price up and down.

How I approach a slow website

Since this is the work I do, here's what it looks like when a business brings me a slow site, so you know what a sensible process is, whether you hire me or someone else.

I start with measurement, not opinions. Field data from Search Console and PageSpeed Insights where it exists, lab tests on a throttled mobile profile, a waterfall from WebPageTest, and a test on a real mid-range phone on mobile data. I look at your most valuable pages first, not just the homepage: the service pages people land on from search, the product pages, the checkout, the contact form.

Then I write down what's wrong, in order of impact. A short, plain-English report: what's slowing each page, what fixing it involves, roughly how long it takes, and what improvement to expect. Some of it you'll be able to do yourself. I'll say so.

Then we agree a target in writing. Something concrete, like LCP under 2.5 seconds and CLS under 0.1 on mobile for your key pages, measured in field data. That's the definition of done, so nobody is arguing over a single lab score later.

For new builds, performance is part of the design from the start. When I build a web application or a business website, I work to a budget: LCP under two seconds on mobile, minimal JavaScript, images optimised automatically, fonts self-hosted, and hosting on a platform with a global CDN. It's far cheaper to build a fast site than to rescue a slow one later. You can see the kinds of sites I build, including online stores like Nahal Foods and Payam Naturals, in my portfolio, and longer write-ups in the case studies.

And after launch, I keep checking. Speed tends to decay. New plugins, a marketing team adding tags, a 6 MB banner for Eid. A quarterly check against the original targets catches that before it costs you anything noticeable.

If your site feels slow, or your enquiries have dipped and you're not sure why, send me the link. I'll take a look and tell you plainly what's slowing it down and whether it's a quick fix or something bigger. If it's a quick fix, I'll tell you that too.

Frequently asked questions

Why is my website slow on mobile but fine on my laptop? Your laptop is probably on fast Wi-Fi, has a much more powerful processor, and may already have the site cached from a previous visit. Phones on mobile data have slower, less reliable connections and far weaker processors, so heavy images and JavaScript hit them much harder. Always test on a mid-range phone using mobile data, or use the throttling options in Chrome DevTools.

What is a good page load time for a website? Aim for the main content to appear within 2.5 seconds on mobile, which is Google's "good" threshold for Largest Contentful Paint. Under two seconds is better. The page should also respond to taps within 200 milliseconds and shouldn't jump around while loading.

Does website speed affect Google rankings? Yes, but modestly. Core Web Vitals are part of Google's page experience signals, which work more like a tiebreaker than a major factor. Relevant, useful content matters more. The bigger effect of speed is on what visitors do once they arrive: slow pages lose more people before they enquire or buy.

How do I check my website speed for free? Use Google's PageSpeed Insights for a quick report that includes real-user data when your site has enough traffic, and the Core Web Vitals report in Google Search Console for a site-wide view. WebPageTest and the Network tab in Chrome DevTools are useful for finding exactly which files are slowing a page down.

Why is my WordPress site so slow? Usually a combination of a heavy multipurpose theme, a page builder, too many plugins each adding their own scripts, unoptimised images and cheap shared hosting without server-level caching. Removing unused plugins, adding proper caching, optimising images and improving hosting fixes many WordPress sites. If the theme or builder is the bottleneck, a rebuild may be more cost-effective.

Will a better hosting plan make my website faster? It will if your server response time (TTFB) is slow, which is common on budget shared hosting or when the server is far from your visitors. If your TTFB is already good and the problem is large images or heavy JavaScript, better hosting alone won't change much. Check the numbers before you upgrade.

Do images really make that much difference? Often more than anything else. An unoptimised phone photo can be 4 to 6 MB, larger than an entire well-built page. Resizing, compressing and converting images to WebP or AVIF commonly cuts a page's weight by more than half.

What is a CDN and do I need one? A content delivery network stores copies of your site's files on servers in many locations and serves each visitor from the closest one. It reduces the distance data travels and takes load off your main server. For any business with visitors across different cities or countries it's worth having, and many good options, including Cloudflare's free plan, cost nothing to start.

How long does it take to speed up a website? Quick wins like image optimisation, removing unused scripts and enabling caching can be done in a day or two. Deeper work such as fixing backend code, replacing a heavy theme or restructuring how a site loads JavaScript can take one to a few weeks. Field data in Search Console takes about 28 days to fully reflect improvements.

Is it better to fix my current website or build a new one? If the site is reasonably modern and the problems are images, hosting, caching and a few scripts, fix it. If the theme or page builder itself is the bottleneck, you've already tried optimising without lasting results, or the site needs a redesign and new features anyway, a rebuild is often better value over the next few years.

Fast is a feature your customers notice without noticing

Nobody ever emails a business to say, "Your website loaded quickly, thank you." People simply stay, read, scroll to the price, tap the call button, and complete the order. Speed works quietly, which is exactly why its absence is so easy to miss.

The fixes are rarely glamorous. Smaller images, fewer scripts, a server that's closer and better configured, a bit of discipline about what gets added to the page. But they compound, and they keep paying back every day the site is live.

Start with the measurements. Run your key pages through PageSpeed Insights, test on a real phone, and work through the list above. Compress your images today with the free image compressor. And if you'd rather have someone experienced look at it, or you're planning a new site and want it fast from day one, ask for a quote. I'll tell you what's worth doing, what isn't, and what it'll take.