Online Store Is Slow and Losing Sales: Diagnose and Fix It

A slow store usually loses sales for one of three reasons: a heavy front end that renders late, slow server responses from unindexed database queries, or third-party scripts that block the page. Measure Core Web Vitals on real visitors first. Google's "good" thresholds are Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint at 200 ms or less, and Cumulative Layout Shift of 0.1 or less.

If you would rather have the slowness diagnosed and fixed for you, see how RAITHub would fix this below. First, find where the time actually goes.

How do you know the slowness is costing you sales?

Match the slow pages to where buyers drop off. A store can feel fine on your own laptop and still be slow for buyers on mid-range phones and mobile networks, which is where most retail traffic is. The signal is a conversion rate that falls as the page gets slower, not a single speed score. Measure the three Core Web Vitals on real page loads at the 75th percentile, which is Google's documented way to judge whether an experience is good (web.dev, Web Vitals).

Metric	What it measures	Good	Usual cause when it fails
LCP	How fast the main content, often the hero or product image, appears	2.5 seconds or less	Slow server response, oversized or lazy-loaded hero image, render-blocking scripts
INP	How quickly the page responds to a tap or click	200 ms or less	Too much JavaScript running on the main thread
CLS	How much the layout jumps while loading	0.1 or less	Images without dimensions, banners and widgets injected late

Which metric fails tells you where to look. A poor LCP points at server time, images and blocking scripts. A poor INP points at JavaScript. A poor CLS points at things arriving late.

Is it the front end, the server, or third-party scripts?

Split the page load into three parts and measure each, so you fix the one that costs the most rather than guessing. In Chrome DevTools, the Network panel shows the server's first response time (time to first byte), and the Performance panel shows what runs on the main thread after that.

• Server time (time to first byte). If the first byte takes over a second before anything downloads, the problem is on your server or database, not the browser. This is common on category and search pages that run heavy queries.
• Front-end render. A large JavaScript bundle, a hero image downloaded late, or web fonts that block text all delay what the buyer sees.
• Third-party scripts. Analytics, chat, reviews, upsells and pixels each bring their own code. Sort the Network panel by size and flag anything not served from your own domain.

If your store is on a hosted platform such as Shopify, the front end and third-party apps are usually the cause, and why your Shopify store is slow covers that path in detail. If it is a custom build, the server and database are more often to blame.

Why is my server slow to respond?

Most often because a query reads more rows than it needs, and no index covers it. A category page that filters thousands of products, or a search that scans every row, gets slower as the catalogue grows even when nothing else changes. The first check is to find the slow query and look at its plan.

-- Find the slowest statements (needs the pg_stat_statements extension).
SELECT left(query, 80) AS query,
       calls,
       round(mean_exec_time::numeric, 1) AS avg_ms,
       round(total_exec_time::numeric, 1) AS total_ms
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

-- Then read the plan for one of them.
EXPLAIN (ANALYZE, BUFFERS)
SELECT id, title, price_minor
FROM products
WHERE category_id = $1 AND is_active
ORDER BY created_at DESC
LIMIT 24;

A Seq Scan over a large table in that plan means the database reads every row. The fix is usually an index that matches the filter and sort, which lets PostgreSQL skip straight to the rows it needs. PostgreSQL's documentation explains that a matching index "might be usable" for a query's conditions and ordering, turning a full scan into an index scan (PostgreSQL, indexes and ORDER BY).

-- A partial, covering index for the active-category listing above.
CREATE INDEX CONCURRENTLY products_category_active_idx
  ON products (category_id, created_at DESC)
  WHERE is_active;

Build the index with CONCURRENTLY so it does not lock out writes while it is created. Re-run EXPLAIN ANALYZE afterwards to confirm the plan changed and the time dropped. One query at a time, measured before and after, is how you avoid adding indexes that never get used.

What order should you fix things in?

Start with the change that moves the failing metric most for the least effort. This order suits most stores.

Step	What to do	Effort	Metric it usually moves
1	Remove third-party scripts you no longer use; defer the rest	Low	LCP, INP
2	Stop lazy-loading the hero image; set fetchpriority="high"	Low	LCP
3	Serve responsive images with width, height and srcset	Low to medium	LCP, CLS
4	Add indexes for the slow category, search and listing queries	Medium	LCP (through server time)
5	Cache category and product pages that rarely change	Medium	LCP
6	Split the JavaScript bundle; load rarely used features on interaction	Medium to high	INP

After each change, wait for the real-user data to catch up before judging it. A lab test in DevTools is the quick check; the field data is the proof.

Buy, build or hire?

Option	What you get	Choose this when
Platform settings and a theme specialist	Image, script and theme tuning inside your platform	You are on a hosted platform and the cause is apps, images or the theme
A one-off performance audit	A ranked report of where the time goes and what to fix first	Sales are leaking and you want the cause named before you spend on fixes
Fix it with your own team	Full control, if you can read query plans and measure the front end	You have the skills and time to measure one change at a time
A custom build or rescue	A front end and database tuned for your catalogue and traffic	The slow parts are features your business depends on and the platform cannot do faster

How long does it take to find and fix this yourself?

Measuring and diagnosing is usually a day or two: read the field data, split the load into server, front end and scripts, and find the one or two biggest causes. Fixes vary. Deferring a script or fixing the hero image is an hour each; a missing index is often an afternoon including the before-and-after measurement; splitting a large JavaScript bundle or caching dynamic pages can take days. The main risk of doing it yourself is fixing a metric that was not the one losing sales, so always tie the slow page to where buyers actually drop off first.

How RAITHub would fix this

• Scope: measure Core Web Vitals on real visitors, split the load into server, front-end and third-party time, find the slow database queries and the blocking scripts, fix the biggest causes behind tests, and confirm the metric moved on the pages that lose sales.
• Timeline: a focused performance fix sits inside the 2 to 4 weeks of the code rescue service; a fuller rebuild of a slow store is scoped separately.
• What you receive: a before-and-after on the failing metrics, the query and front-end changes behind tests in your CI, runbooks, the IP assigned to you and an NDA as standard.
• Next step: a free 15-minute technical audit, then a written fixed quote.

RAITHub built and runs TheSkinProof, the founder's own marketplace venture rather than a client project, a custom Next.js store that uses edge caching, content-addressed image caching and active cost tuning, with 217 API endpoints and 750+ tests. For the wider context see the eCommerce industry page; if the slowness is tangled up with other problems, replatforming without losing SEO covers when a rebuild is the answer. To get your store diagnosed, read about a custom build or book the free 15-minute audit with your field data and slowest pages.

Documentation checked on 11 October 2026.

Frequently asked questions

Why is my online store slow and losing sales?

Usually one of three things: a heavy front end that renders late, slow server responses from database queries with no matching index, or third-party scripts that block the page. Measure Core Web Vitals on real visitors, split the load into those three parts, and fix the biggest one first.

How slow is too slow for an e-commerce page?

Google's "good" thresholds are Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile of real page loads. A page that misses these loses buyers before they reach the cart.

How do I tell if the problem is my server or the browser?

Look at the time to first byte in your browser's Network panel. If the server takes over a second to send the first byte before anything downloads, the problem is on your server or database. If the first byte is fast but the page still appears late, it is the front end or third-party scripts.

Can a database query make my whole store slow?

Yes. A category, search or listing query that scans every row instead of using an index gets slower as the catalogue grows, and it slows every page that runs it. Find the slow statement, read its plan with EXPLAIN ANALYZE, and add an index that matches the filter and sort.

Will moving to a custom build make my store faster?

Not automatically. A custom front end can hit the same problems as any other if it is not measured and tuned. A rebuild pays off when the slow parts are features your business depends on and the platform cannot make them faster, not as a general speed fix.

How do I prove a performance fix actually worked?

Measure the failing metric before and after, on the same pages and device profile, and wait for the real-user field data to catch up. A lab test in DevTools is the quick check during the work; the field data over the following days is the proof that buyers saw the change.