Skip to main content
PandaCodeGen
Back to Insights

Shopify performance

Shopify Dawn Theme Slow? Diagnose the Store

Dawn is Shopify's source-available reference theme and was built with performance in mind. A slow Dawn store needs route-level diagnosis. The theme name alone does not identify the cause, impose a Lighthouse ceiling or prove that headless is required.

Reviewed August 2, 2026 against current Shopify documentation and the Dawn repository.

Hassan Jamal·Mar 7, 2026·9 min read

The short answer

Dawn is slow on a specific store for one of four reasons, and all four are things you added rather than things the theme shipped with: oversized images and video, too many sections on a template, the apps and third-party code you installed, and custom code someone put in the theme. Shopify's theme performance best practices document those four, and separately document what the platform already handles for you, including CDN delivery, automatic image optimization, gzip on CSS and JavaScript, a one-year browser cache and HTTP/2. Read August 2, 2026. None of those last five is the thing you are about to fix.

Find your own cause in two moves. Open Shopify's Web Performance report and read the 75th percentile by page type and device to see which routes and which real visitors have a problem. Then reproduce the worst route in a repeated lab test and take the median. The same performance documentation gives a 16 KB target for a theme's minified JavaScript bundle, which is one number you can check in DevTools in about a minute.

Start with four evidence layers

Gather all four before changing anything, because each one answers a question the others cannot. Field data says which real visitors are affected but not why. A lab trace says why but not how common it is. The per-route inventory names the specific asset or script. And a clean Dawn preview is the only thing that separates what the theme does from what your configuration does to it. If the evidence does point to a rebuild, ours is a fixed price from $1,500 with no minimum project size, and you own the code at the end.

  • Shopify real-user LCP, INP and CLS by URL, page type, device and time.
  • Repeatable lab tests for representative home, collection, product and cart states.
  • A network, main-thread, media and third-party inventory for each affected route.
  • A controlled preview that separates base Dawn from the production configuration.

Field data

Find the users and routes with a real problem.

Apps

Trace embeds, scripts, pixels and dependencies.

Media

Inspect dimensions, formats and loading priority.

Theme

Compare custom code with a controlled preview.

What Dawn is in 2026

Shopify describes Dawn as an HTML-first, JavaScript-only-as-needed reference theme with performance and Online Store 2.0 features built in. It uses server-rendered Liquid HTML, progressive enhancement, sections, blocks, snippets and supporting assets. A merchant's production store can differ substantially after apps, sections, media, tracking and custom code are added.

Dawn shipped in 2021 as the reference theme for Online Store 2.0 and became the theme most new stores started from. Shopify has since introduced Horizon as the reference theme for new stores; check the current position in Shopify's theme architecture documentation rather than here, because default themes change. Dawn remains free and source-available, and the public repository was still active when read on August 2, 2026. If you are on Dawn today, you are not on a deprecated theme. You are on a supported one that has been customized for several years, and the customization history is where the evidence usually is.

Why there is no Dawn score ceiling here

You will not find a PageSpeed figure that Dawn supposedly cannot pass. Shopify publishes no such universal ceiling, and scores move with the route, the content, the code layered on top of the theme, the test environment and the individual run. Treating a headless rebuild as the only way past an imagined ceiling skips the diagnosis entirely. Measure your own routes across repeated runs, work out which layer owns the time, and decide from that.

What is actually in the page, and who owns it

Before you change anything, split the payload by owner. In the production Dawn stores we have traced, the bytes and the main-thread time belong to four different parties, and only one of them is the theme. This is the reason switching to another Shopify theme can change less than expected: three of the four layers travel with the store, not with the theme.

LayerWho controls itWhat to do about it
App scriptsApp vendors, via app embeds and injected storefront codeInventory, justify, restrict to the routes that need them, remove the rest
Platform scriptsShopifyBudget around them. They are not a theme-level lever
MediaYou, through uploads and section settingsSize, format and loading priority per rendered slot
Theme and custom codeYou and whoever has edited the themeCompare against a clean preview to isolate what was added
"The theme name alone never identifies the cause. What you installed on top of it usually does.

Audit the app layer by name

Apps add storefront JavaScript through app embeds and theme app extensions. That code runs on your customers' devices. It is versioned by the vendor rather than by you, and it often loads on routes where the app has no visible interface. Go through your installed apps by category and write down what each one actually costs on the routes you care about. Do not take a vendor's word for its weight. Measure it in your own trace.

  • Reviews and user-generated content: Judge.me, Okendo, Yotpo, Loox and similar.
  • Live chat and helpdesk: Gorgias, Tidio, Intercom and similar.
  • Email, SMS and popups: Klaviyo, Privy, Attentive and similar.
  • Loyalty, referrals and rewards: Smile.io, LoyaltyLion and similar.
  • Upsell, bundling, subscription, currency, wishlist and search apps.
  • Tag managers, pixels, heatmaps, A/B tools and anything a marketer installed directly.

For each one, record the owner inside your business, the routes it needs, the routes it actually loads on, its measured transfer size and its main-thread cost in a trace. Apps that no longer have an owner are the easiest thing to remove. Uninstalling an app does not always remove its code, so check the theme for leftover snippets and script tags after every removal.

Why a theme swap rarely fixes this

Your app payload is attached to the store, not to the theme. Install the same apps on a different Shopify theme and the same third-party scripts follow you across. Test that claim on your own store with a duplicated theme before you pay anyone to re-theme for speed reasons.

What Shopify loads regardless of your theme

Some storefront JavaScript belongs to the platform. Analytics and web pixels, cart behaviour, payment and checkout-related code and Shopify's own performance instrumentation are managed by Shopify rather than by your theme. You can influence how much of your own work competes with them, but removing them is not a theme-level option on the standard storefront. Treat that as fixed cost in your performance budget rather than something a developer failed to fix.

Liquid is server-rendered on request. Shopify generates the HTML for each page view and returns it, so expensive loops, heavy section logic and large numbers of rendered products show up as server time before the browser starts work. A pre-rendered or cached custom frontend moves that work to build time instead. That is a real architectural difference, but it is not free: it moves work rather than deleting it, and it adds a codebase you have to own.

1. Read the field report first

Shopify's Web Performance reports use real-user data and show LCP, INP and CLS over time, by URL and by page type, with the summary at the 75th percentile. The reporting delay and retention window in the list below come from the same document, read August 2, 2026. Use the report to locate the affected population instead of treating one homepage Lighthouse run as the whole store.

  • Compare mobile and desktop distributions.
  • Separate home, collection, product and other page types.
  • Annotate app installs, theme releases, campaigns and media changes.
  • Wait before judging a release. Shopify documents that the report may be delayed by up to 36 hours.
  • Remember the window. Shopify keeps only the last 90 days of web performance data, so export before you need it.
  • Expect gaps on a new or password-protected store, and larger swings on a low-traffic store. Shopify says so directly.

2. Create controlled comparisons

This is the step that proves which layer owns the time, and it works by holding everything constant except the one thing you are testing. Duplicate the production theme, stand up a clean Dawn preview beside it, then keep the route, screen size, connection, cache state and consent choice identical across both. Repeat each run and take the median. A single run of two different pages proves nothing at all.

  • Duplicate the current production theme and preserve a rollback point.
  • Create a current clean-theme preview with representative content where practical.
  • Test the same pages and products, at the same screen size, on the same connection, with the same cache and consent state.
  • Repeat runs and use the median rather than selecting the best screenshot.
  • Compare one change at a time when isolating an app, section or custom feature.

Shopify's own theme guidance tests home, product and collection pages and recommends repeated runs. Your store may need additional routes such as search, cart, account and high-traffic landing pages.

3. Inspect JavaScript and third parties

Shopify advises theme developers to minimize JavaScript, avoid parser-blocking scripts and load noncritical resources on interaction where appropriate. It also advises app developers to use theme app extensions and limit resources to the pages where they are needed.

  • List every script by owner, purpose, route and consent category.
  • Measure your theme bundle against the 16 KB minified JavaScript target in Shopify's theme performance best practices, then list what else loads on top of it.
  • Check your fonts. Shopify notes that a system font avoids the client downloading another resource before text can render.
  • Find long tasks, duplicate libraries, synchronous work and global listeners.
  • Check whether an app embed loads on routes where its interface is absent.
  • Remove abandoned tags and residual theme code only after dependency review.
  • Preserve accessibility, analytics and purchase behavior when deferring work.

4. Fix media and loading priority

Media is where most Dawn stores lose their largest paint, and the fix is two rules rather than a compression setting. Size every image to the slot it actually renders into, and never lazy-load the one image that is the largest element on screen, because deferring it defers the metric you are trying to improve. Everything below follows from those two.

  • Serve responsive images sized for their rendered slot.
  • Do not lazy-load the likely above-the-fold LCP image.
  • Lazy-load below-the-fold media and reserve dimensions to prevent layout shift.
  • Question the hero itself, not just its priority. A banner repeated across every template is a cost paid on every route.
  • Embed video from an external host rather than uploading large video files into the theme.
  • Replace animated GIFs with a static image, or with video if the motion earns its place.
  • Avoid large autoplay video or carousel work unless measured business value justifies it.
  • Host theme assets through Shopify's supported delivery path where applicable.

5. Review Liquid, sections and custom code

Use Shopify Theme Check and browser traces to find large assets, blocking resources and expensive custom work. Review layout-level inclusions because they affect every route. Inspect product and collection loops, section settings and repeated snippets using the actual production data that triggers the problem.

6. Validate the fix

A change is validated across four layers, and each carries a guardrail that has to survive it. Lab evidence shows the mechanism moved, field evidence shows real visitors felt it, functional testing shows the store still takes orders, and the business layer shows whether it was worth doing. That last guardrail is the strictest: measure what changed, and do not convert it into a causal revenue claim you cannot support.

LayerBefore and afterGuardrail
LabRepeated representative route testsSame profile and page state
FieldP75 LCP, INP and CLS after enough trafficDevice and route distribution
FunctionalBrowse, variant, cart and checkout flowsNo broken feature or event
BusinessDefined funnel and operating metricsNo unsupported causal claim

What moves the number, and what only feels like it does

The left column is the work. The right column is how you prove it on your own store rather than taking anyone's word for the size of the effect. Measure before and after on the same route, the same profile and the same page state.

Swipe to see more

ActionWorth doingHow to verify on your store
Remove apps with no current business ownerYesTrace the route before and after, then check for leftover theme snippets
Resize and compress hero and section images before uploadYesCompare delivered file size against the rendered slot size in DevTools
Stop lazy-loading the above-the-fold LCP imageYesConfirm the LCP element and its request timing in a trace
Restrict app embeds to the routes that use themYesLoad a product page and a policy page, then diff the script list
Remove unused sections, snippets and legacy trackingYesDiff against a clean theme preview, and regression-test the purchase flow
Switch to another theme marketed as fastRarelyDuplicate the theme, keep the apps, and test before you buy anything
Install a speed-optimizer appRarelyCheck whether it added a script of its own, and test with it disabled
Add a third-party CDN in front of the storefrontNoShopify already serves the storefront through its own CDN
Upgrade the plan to fix storefront renderingNoA plan change does not remove app scripts or oversized media from your routes

When to keep Dawn, change theme or go headless

Keep Dawn when the measurement points at your own media, sections and apps, because those travel with the store and a new theme inherits them. Change theme when the customization history has made the current one unmaintainable, which is a code-quality reason rather than a speed one. Go headless only when you have done the first two and the remaining constraint is how Shopify renders and delivers the page, and only if you are prepared to own a codebase.

  • Keep and optimize Dawn when the required experience fits the theme model and measured issues are removable.
  • Consider another theme when its tested capabilities better match the merchandising and editorial requirements.
  • Consider custom theme work when the business needs a controlled Shopify-native experience and can maintain it.
  • Consider headless when requirements, integrations and ownership justify a separate storefront, not as a default speed patch.

Is a rebuild right for your store?

A rebuild is not automatically the right answer for a store that asks about it. Use your own numbers, not a theme name, to decide. These are the signals we look for before we will quote a headless or custom storefront project at all.

A rebuild is worth costing out when:

  • Your Shopify field report shows a failing Core Web Vitals distribution on high-intent routes, not a single bad lab run.
  • You have already removed the removable apps and media problems and the constraint is still there.
  • The experience you need does not fit the section and block model without fighting it every release.
  • You have enough traffic that a small conversion or crawl change is measurable rather than noise.
  • You have someone, internal or contracted, who will own a codebase after handover.

Stay on Dawn and fix it in place when:

  • The store is new, traffic is low and you have no conversion baseline to improve against.
  • You have not yet run a controlled clean-theme comparison, so you do not know what is causing the problem.
  • Your catalogue and merchandising fit the theme model and the pain is a handful of specific routes.
  • You depend on apps whose functionality you are not prepared to rebuild or replace.
  • Nobody in the business wants to own a separate frontend, its releases and its incidents.
Honest answer

If the second list describes you, keep Dawn. A focused repair on the routes that are failing is cheaper, faster and lower risk than a rebuild, and it is the work we will recommend even when you came in asking to go headless.

What to check before you accept a Shopify speed quote

Speed engagements disappoint more often at the scoping stage than at the engineering stage. A cheap quote is usually cheap because it leaves some of these out, and you find out at handover.

  • Which routes are in scope. Home, collection, product, search, cart and account behave differently.
  • Which devices and profiles the acceptance test uses, and how many runs are recorded.
  • What happens to the apps: which are kept, which are replaced, which functionality disappears.
  • Who owns analytics, consent, pixels and conversion tracking continuity through the change.
  • URL, redirect, structured data and Merchant Center continuity if the storefront layer changes.
  • Who owns the code, the repository and the deployment account after handover.
  • Third-party running costs after launch: hosting, image delivery, search, reviews and monitoring.
  • What the rollback plan is on a revenue-generating route, and who executes it.

What our engagements cost

Engagements start at $1,500 and run to $10,000 for integration-heavy commerce work, in the three tiers below. Those are planning anchors, not a quote. The accepted written terms control the final price, the page inventory and the acceptance protocol.

$1,500
Starter
Small, clearly bounded scope
$3,500
Growth
Larger migration, CMS or content-continuity scope
$5,000+
Scale
$5,000 for integration-heavy commerce work

Where a 90-plus Lighthouse result is included, it is written as a handover target on mobile and desktop for the representative pages named in the scope, verified across three recorded runs under stated conditions before handover. It is a lab acceptance target. It is not a promise about rankings, traffic or revenue, and no honest supplier can give you one of those.

Not sure whether your Dawn store needs a repair or a rebuild?

Run the audit on your own URL first, or bring the store to a call and we will trace it with you and tell you which of the two it is.

Run the free audit

Key takeaways

  1. The theme name is not a diagnosis. Dawn is a performance-oriented reference theme, and a slow Dawn store is a store-level question about apps, media, custom code and content.
  2. Start with field data. Shopify's Web Performance reports tell you which real users and which routes have a problem. One homepage Lighthouse run does not.
  3. Most of the payload is not the theme's. App scripts and platform scripts travel with the store, which is why re-theming for speed disappoints so often.
  4. Prove every change on your own store. Same route, same profile, same page state, repeated runs, median rather than best run.
  5. Headless is a requirements decision. Choose it when experience, integration and ownership requirements justify it, not as a default fix for a slow route.

Tell us what you have

We will audit representative routes, trace the production configuration and show whether a focused Dawn repair, theme change or SEO-conscious headless migration fits the evidence. Our e-commerce development service covers the full transition, including analytics, redirect and structured-data continuity.

Primary sources

Related reading

For the full diagnostic playbook across any Shopify theme, see our Shopify speed optimization guide. For what a headless build actually involves, read headless Shopify on Next.js. For the same question on the enterprise plan, see why Shopify Plus can still be slow. To reason about conversion impact with your own data rather than borrowed statistics, see Shopify conversion rate and speed and is a slow Shopify store losing sales. For the cost comparison over a multi-year horizon, see Shopify versus a custom website and what your Shopify app stack really costs each month.

Frequently Asked Questions

Why is my Shopify Dawn theme slow?

Dawn is a performance-oriented reference theme, but production results also depend on media, apps, tags, third-party code, custom sections, content and user conditions. Use Shopify's real-user reports and controlled route tests to identify the actual contributor.

What PageSpeed score does Shopify Dawn get?

Dawn has no universal PageSpeed score or fixed ceiling. Test representative home, collection, product and cart states under a recorded mobile and desktop profile, repeat the runs and use field Core Web Vitals where enough traffic exists.

How can I speed up my Shopify Dawn theme?

Prioritize affected routes, correct media loading, remove or defer noncritical JavaScript, review app embeds and tags, inspect layout-level theme code and validate each change against functional, analytics, accessibility and field-performance guardrails.

Is Dawn always faster than other Shopify themes?

Shopify built Dawn with performance in mind, but the final result depends on each theme version, configuration, content, apps and custom code. Compare candidates with the same representative data and test profile instead of assigning a permanent rank to a theme name.

Should I switch from Dawn to a headless storefront?

Choose headless when accepted experience, channel or integration requirements justify a separate frontend and its lifecycle cost. A slow route alone is a reason to diagnose the current store, not proof that headless is required.