Why Is My Website Slow? A Technical Checklist for Marketing and Ecommerce Teams

The web keeps getting heavier. In 2025, the median desktop home page hit 2.9 MB and the median mobile home page reached 2.6 MB, and over the past decade mobile pages have grown by 202.8% (HTTP Archive). Networks have improved enormously, but many pages have become heavy enough to cancel out those gains.

For ecommerce teams, that weight costs money faster than it used to - buyers compare and leave before a slow page finishes loading. The causes are predictable, though, and you can diagnose most of them without a developer.

This checklist is built for marketing, ecommerce, and growth teams that need to understand why a website is slow, what they can diagnose themselves, and when the fix needs a developer, performance engineer, or full website performance audit.

Why is my website slow?

Your website is slow because something in the page delivery chain is doing too much work. That work may happen on the server, inside the CMS, in the ecommerce platform, across third-party tools, or in the browser after the page starts loading.

In practice, most slow websites come down to a few recurring causes:

• oversized images and videos,

• heavy JavaScript from frameworks, apps, or page builders,

• third-party scripts such as tags, pixels, chat widgets, and personalization tools,

• slow hosting, weak caching, or high Time to First Byte,

• CMS or Shopify bloat from plugins, apps, themes, and legacy templates,

• uncached API calls, database queries, or dynamic content logic.

Don't just ask what is slow. Ask where the slowdown lives – a slow ecommerce website usually has the problem sitting in a specific template, not the whole site

Some problems are page-level. One landing page may have an oversized hero image, an embedded video, or a campaign script that was added for a single promotion and never removed. These issues are often visible in PageSpeed Insights or Chrome DevTools and can sometimes be fixed by marketing or ecommerce teams.

Other problems are template-level. If every product page is slow, the issue is probably not one bad image. It may be the product-page template loading large galleries, review widgets, recommendation engines, variant logic, tracking scripts, and app code on every product detail page. If every category page is slow, the bottleneck may sit in filtering, product-card rendering, image loading, search scripts, or merchandising tools.

Then there are architecture-level problems. These are harder to isolate because they affect the whole site. A slow CMS setup, old Shopify theme, poorly configured CDN, weak caching strategy, bloated frontend framework, or inefficient API layer can make every new page slower before the content team even touches it.

That distinction matters because each level needs a different fix.  Page-level problems may be solved with image compression, script cleanup, or better content rules. Template-level problems usually need development work. Architecture-level problems may require a deeper performance audit, rebuild, or replatforming decision.

A homepage performance issue may look like a design problem at first, but the real bottleneck is often a heavy hero image, unused JavaScript, too many tracking scripts, or poor server response.

On product pages, the platform itself is rarely the main cause. Performance often suffers because of review widgets, product galleries, personalization scripts, variant logic, or inventory APIs.

A slow Shopify store doesn’t automatically mean Shopify is at fault. More often, the problem sits in app bloat, Liquid theme debt, uncompressed media, page-builder code, or too many global scripts loading on every template.

Headless architecture doesn’t guarantee speed either. Common bottlenecks include high hydration costs, inefficient data fetching, uncached API calls, oversized JavaScript bundles, or a weak CDN and edge-rendering strategy.

Diagnose before you touch anything. Before compressing another image, removing another app, or blaming the platform, find out whether the problem lives on one page, one template, or the architecture itself.

What does a slow website cost you?

A slow website costs you attention first. Revenue usually follows.

For ecommerce teams, that matters because buyers have more alternatives than ever. U.S. retail ecommerce reached $326.7 billion in Q1 2026, growing 9.8% year over year and reaching 16.9% of total retail sales (U.S. Census Bureau). In a market that crowded, speed becomes part of the buying experience. If a product page loads slowly, a filter freezes, or checkout-adjacent pages hesitate, the customer does not need to wait. They can compare, leave, and buy somewhere else.

Ecommerce sites are especially exposed to performance problems because they carry more moving parts than a standard marketing website. Category pages may load dozens of product images, filters, banners, tracking tags, search scripts, and recommendation widgets. Product pages often add galleries, reviews, variant logic, personalization tools, inventory data, and app code. That weight adds up. Only 39% of ecommerce sites pass all three Core Web Vitals, below the 42% global average, largely because ecommerce pages are structurally heavier than simpler content pages (Ighenatt).

The business impact is real, but it isn't a universal formula. Reported case studies show that performance improvements can support stronger conversion and revenue metrics, but every result depends on the site, traffic quality, market, product, and scope of the optimization.

For example:

• Vodafone recorded an 8% increase in sales after improving Largest Contentful Paint by 31%.

• Rakuten reported 33% higher conversions and 53% higher revenue per visitor after optimizing all three Core Web Vitals.

• NDTV cut its bounce rate by 55% after reducing Largest Contentful Paint by 55%.

Treat these as individual company results, not guaranteed benchmarks. The pattern that holds: when speed problems hit pages that carry revenue, leads, or paid traffic, performance stops being a technical detail and becomes a commercial one.

We have seen the same pattern in our own work. Our rebuild for Nanobébé delivered a 117% performance increase and an 80% reduction in Total Blocking Time. For Capitalise, performance work improved mobile LCP by 31% and preceded 48% monthly traffic growth.

The cost of a slow website is rarely one dramatic failure. More often, it shows up as lower conversion rates, weaker campaign efficiency, higher bounce rates, more abandoned journeys, and more internal debate about whether the problem sits in content, design, tracking, hosting, or architecture. That is why speed should be diagnosed on the pages that matter most commercially, not treated as a generic technical cleanup.

What should you check first when a website is slow?

When a website feels slow, check it in layers. Each layer helps you isolate a different type of problem: user experience, page weight, browser work, server response, platform bloat, or dynamic data.

Start with evidence before changing the site. A structured check will show whether the slowdown lives on one page, across one template, or deeper in the architecture.

1. Start with Core Web Vitals and field data

Begin with Core Web Vitals because they show how real users experience your website. PageSpeed Insights and Google Search Console can tell you whether the problem is loading speed, interactivity, visual stability, or a combination of all three.

This matters because each metric points to a different type of fix. Poor LCP often leads you to images, server response, or above-the-fold rendering. Poor INP usually points to JavaScript and third-party scripts. Poor CLS often means layout space, fonts, banners, or injected widgets need attention.

2. Check the templates that matter commercially

Test the pages that carry revenue, leads, paid traffic, or important customer journeys. For marketing and ecommerce teams, that usually means product pages, category pages, landing pages, checkout-adjacent pages, and high-value content templates.

A slow blog post and a slow product page carry different business risks. Start with the pages where speed can affect conversion, campaign efficiency, sales conversations, or lead quality.

For a slow ecommerce website, that almost always means product and category pages first – they carry the most images, scripts, and dynamic data of any template on the site.

3. Check images, videos, and other media

Images are often the fastest issue to diagnose and one of the easiest to fix. Look for oversized hero images, uncompressed product photos, heavy galleries, embedded videos, and images loaded at much larger dimensions than they display on the page.

For ecommerce sites, check product and category templates especially carefully. They often load dozens of images before the user has interacted with the page.

4. Check JavaScript weight

JavaScript is often the reason a page appears to load but still feels slow. Heavy JavaScript can delay clicks, filters, menus, search, add-to-cart actions, and form interactions.

Look for large bundles, unused code, page-builder scripts, frontend framework overhead, and features that load globally even when they are only needed on specific templates.

5. Check third-party scripts

Marketing tools can become a hidden performance tax. Tags, pixels, heatmaps, A/B testing tools, chat widgets, review widgets, personalization scripts, and consent tools all compete for browser resources.

The issue is rarely one script alone. The problem is accumulation. Every new vendor script should have an owner, a purpose, and a clear reason to keep loading.

6. Check hosting, TTFB, caching, and CDN setup

If the server responds slowly, front-end optimization can only go so far. High Time to First Byte may point to hosting, backend processing, database work, cache misses, or poor CDN configuration.

Check the delivery layer early because it affects every page. If the server, cache, or CDN setup is slow, every page starts with a performance handicap.

7. Check CMS, Shopify, and platform bloat

CMS plugins, Shopify apps, old themes, page builders, and legacy templates can load code across the site even when specific features are not used on the page.

For Shopify stores, check whether apps are loading globally. For CMS-driven websites, check whether templates include unused components, scripts, styles, or plugin code by default.

8. Check fonts and CSS

Fonts and CSS are usually not the biggest performance issue, but they can block rendering and cause layout shifts. Watch for too many font weights, unoptimized custom fonts, render-blocking stylesheets, and components that move after loading.

This is especially important when CLS is failing or when the page appears blank before content renders.

9. Check API calls and dynamic content

If search, filters, personalization, pricing, inventory, or localized content loads slowly, the bottleneck may sit in API calls rather than static assets.

This is especially important for headless websites and ecommerce platforms. Slow CMS responses, uncached API requests, inefficient data fetching, or backend dependencies can make a technically modern site feel slow.

10. Decide whether the problem is page-level, template-level, or architecture-level

Finish by identifying where the issue lives. If one page is slow, you may have a page-level issue. If every product page or every category page is slow, you probably have a template-level issue. If the whole site is slow, or if performance problems return after every cleanup, the issue may be architectural.

Once you know whether the issue is page-level, template-level, or architecture-level, use the symptoms below to guide the next conversation. The goal is to narrow the investigation before marketing, ecommerce, and development teams start changing the site.

Core Web Vitals checklist: which metrics should you check first?

The checklist starts with Core Web Vitals, but the value is not in the score itself. The value is in what the failed metric tells you to inspect next.

If LCP is failing, check what loads above the fold

Poor LCP means the most important visible element takes too long to appear. On marketing and ecommerce sites, that element is often a hero image, product image, banner, headline block, or large content section.

Start by identifying the LCP element in PageSpeed Insights or Lighthouse. Then check whether it is too large, loaded too late, blocked by CSS or JavaScript, or delayed by slow server response.

For ecommerce sites, product and category pages need special attention. Large product images, sliders, promotional banners, and page-builder sections can delay the first meaningful view of the page.

If INP is failing, check JavaScript and third-party scripts

Poor INP means the page responds slowly after a user interacts with it. This is why a page can seem loaded but still feel broken. The user clicks a menu, filter, variant selector, search box, or add-to-cart button, and the page hesitates.

The usual cause is too much JavaScript competing for the browser’s main thread. That can come from frontend frameworks, page builders, Shopify apps, personalization tools, A/B testing platforms, analytics tags, review widgets, or chat tools.

For marketing teams, this is where script ownership matters. Every tracking tag or widget should have a current business purpose. If nobody owns it, understands it, or uses the data it collects, it should be questioned.

If CLS is failing, check layout stability

Poor CLS means the page moves while loading. This often happens when images, banners, cookie notices, fonts, ads, embeds, or widgets appear without reserved space.

For users, layout shifts are more than a visual annoyance. They can cause misclicks, interrupt reading, and make forms or checkout-adjacent pages feel unreliable.

Start with elements that load late: announcement bars, promotional banners, review widgets, product recommendations, consent tools, embedded videos, and custom fonts. Then check whether the page reserves enough space before those elements appear.

Use field data before lab scores

Core Web Vitals are most useful when they reflect real users. PageSpeed Insights includes both field data and lab data when enough traffic is available. Google Search Console groups URLs by real-user performance and helps show whether the issue affects one page, one template, or a larger part of the site.

Lighthouse is still useful, but it is a lab test. It runs in controlled conditions. A page can score well in Lighthouse and still feel slow for users on weaker devices, crowded networks, or script-heavy customer journeys.

Use lab tools to inspect causes. Use field data to understand impact.

Once you know which metric is failing, use the tools below to confirm whether the issue affects one page, one template, or a wider part of the site.

How do I check if my website is slow? Tools and steps

You can collect the first useful signals in about ten minutes, without developer time. Run these checks in order:

1. PageSpeed Insights: paste your URL and read the field data at the top. That section reflects real Chrome users, not only a lab simulation. Test your homepage, a category page, and a product page separately.

2. Google Search Console: open the Core Web Vitals report to see which URL groups fail in the field. Check mobile and desktop separately, because mobile usually exposes performance problems first.

3. Lighthouse: run a mobile audit in Chrome DevTools and review the opportunities list. It can help identify heavy images, render-blocking resources, unused JavaScript, and layout shift issues.

4. Chrome DevTools Network tab: reload the page and sort requests by size. Multi-megabyte images, large JavaScript files, or dozens of third-party requests are usually the first suspects.

5. GA4: compare bounce, engagement, and conversion data for slow and fast landing pages. This helps connect technical performance with business impact.

6. Ahrefs Site Audit or Sitebulb: crawl the site to find slow templates at scale instead of testing pages one by one.

These tools will not fix the website for you, but they will show where to look first. If several tools point to the same template, script group, or performance metric, you have enough evidence to start a focused technical investigation.

What can marketing teams fix without a developer?

More than you might expect. These are marketer-owned fixes:

• compressing and converting images before upload,

• auditing and deleting orphaned tags in your tag manager,

• uninstalling unused Shopify apps and CMS plugins,

• cropping and sizing hero banners to their display dimensions,

• questioning every new script a vendor asks you to install.

These need a developer:

• code splitting, hydration fixes, and JavaScript refactoring,

• server, caching, and CDN configuration,

• database indexing and API optimization,

• theme rebuilds and template-level changes.

The dividing line is simple. If the fix happens in a dashboard, marketing can own it. If the fix happens in a repository, hand it to engineering with the audit data you have already collected.

How do you fix a slow website without wasting time?

PageSpeed Insights, Lighthouse, and site crawlers can surface dozens of recommendations, but not every issue deserves the same priority. A minor image warning on a low-traffic blog post matters less than slow interaction on a product page, category page, paid landing page, or checkout-adjacent template.

Start with three questions:

1. Which templates matter most commercially?Focus first on pages that affect revenue, leads, paid campaigns, product discovery, or sales conversations.

2. Which metric is failing?LCP, INP, CLS, TTFB, and JavaScript execution problems point to different fixes. Treat the failed metric as a diagnostic clue, not just a score to improve.

3. Who owns the fix?Marketing can usually handle image cleanup, script review, tag manager hygiene, and unused app/plugin checks. Development should own rendering, caching, JavaScript, API calls, theme work, and platform-level changes.

The point is to avoid random acts of optimization. A good fixing plan should tell your team which pages to start with, which metric matters most, which cause is most likely, who should act, and which fixes are likely to change business results.

A small B2B website with a slow server may need hosting and caching work first. A Shopify store with 30 apps may need app cleanup before image optimization. A headless ecommerce site may need a rendering and API audit before anyone touches media files.

The right order depends on the site. Let the evidence set the priority, not the length of a tool's recommendation list.

When do you need website speed optimization services?

You need website speed optimization services when the team can see the symptoms but can’t safely identify the cause. 

A single oversized image doesn’t need a full audit. You can fix it directly. But a slow website across multiple important templates is different. That usually means the problem sits deeper: JavaScript architecture, Shopify app bloat, CMS setup, rendering strategy, third-party scripts, hosting, CDN configuration, API calls, or database performance.

A performance audit makes sense when:

• Core Web Vitals fail across important templates

• mobile performance is much worse than desktop

• product or category pages underperform despite qualified traffic

• a redesign made the website slower

• PageSpeed Insights gives unclear or conflicting recommendations

• Shopify apps have accumulated over time

• a headless website feels slower than expected

• developers fix one issue, but performance problems keep returning

• paid campaigns send traffic to pages that load or respond too slowly

• marketing can’t tell which scripts are still needed

A good audit should separate symptoms from causes, show which templates are affected, identify the likely owners, and turn performance work into a prioritized backlog rather than a series of disconnected fixes.

When is a slow website an architecture or redesign problem?

A slow website becomes an architecture or redesign problem when focused fixes no longer hold. If the same symptoms return after every cleanup, every campaign launch adds new performance risk, or developers avoid changes because the codebase is fragile, the issue is probably deeper than one image, script, app, or template.

At that point, speed is often the visible symptom of a stack that no longer fits the business. The problem may sit in the CMS model, Shopify theme, frontend architecture, rendering strategy, API layer, caching setup, or platform limitations. It may also overlap with UX, technical SEO, content management, and day-to-day publishing problems.

A redesign, rebuild, or replatforming decision becomes more realistic when:

• the current CMS forces bloated templates,

• Shopify theme debt blocks meaningful cleanup,

• a headless frontend was built without strong caching or rendering discipline,

• product and category templates cannot support ecommerce requirements cleanly,

• Core Web Vitals fail repeatedly after smaller fixes,

• developers avoid changes because the codebase is fragile,

• marketing depends on workarounds for routine publishing,

• technical SEO, performance, and UX problems overlap.

In our own projects, the biggest gains came when performance work addressed the stack, not only the symptoms:

• For Best IT, a rebuild took the Lighthouse score from 24 to 100,

• for FGS Global, moving off a bloated legacy stack made the platform load 4x faster,

• for Nanobébé, a Shopify rebuild cut Total Blocking Time by 80%.

Modern stacks reach those numbers by shipping less by default: static or edge-rendered pages, framework-level image optimization, cleaner templates, stronger caching, and code splitting built into the architecture rather than patched in later. If a rebuild is on the table, plan the migration so you keep your rankings; our guide to redesigning a website without losing SEO covers the checklist we run on every replatform.