Online store performance

Recorded in Polish and published on October 17, 2023. Below is an edited English translation; we removed repetitions and asides without changing the meaning. Shopify tools and features reflect that time; where something has changed, we add a dated November 2026 update.

Why store speed matters for the business

Tomek: Hi! Welcome to another episode of Flying with Shopify. Today we're talking about online store performance, and our guest is Kamil Patyk, CTO of the wecanfly agency. Let's get started. Hi, guys.

Kamil: Hi, Tomek.

Maciek: Hi, Kamil.

Tomek: Kamil, it's good of you to find the time to meet with us today. I'd like us to talk about how to even define store performance, why it matters, and why we think working on it is so important for the business. Guys, I think you'll agree there's nothing more frustrating in a store than slow loading. The customer will be the first to simply give up on the purchase. That's why poor performance is often called a conversion killer. What's more, when clients come to us for an audit, whether it's a UX audit or one meant to find potential problems in their store, performance is one of the main things we analyze, and often the main basis for what to do next and how to improve the store. So today, with your help, Kamil, I'd like us to keep it practical: how to approach it, how to work on store speed, and what that can mean for the business. Maciek, you're usually the one who answers my questions about definitions, so I'll ask you: what is store speed, or site speed? How do you measure it, and when can we say a store is fast, or the opposite?

When can we say a store is fast?

Maciek: I don't think anyone needs an explanation of what a fast store is. Everyone can feel when a site or an app is slow to work or slow to load. Google recommends that a page loads in two seconds at most. And what you said, that load time is a conversion killer, is confirmed by many studies and sources. It varies by site, but on average every extra second of load time means a drop in conversion of 0.3 percentage points, so it's a fairly significant metric. Our own experience shows it too: speed optimization has the biggest direct impact on user experience. But that's not all, because site speed has two more important aspects. First, it affects your site's position in Google. It's a significant factor the algorithm considers when choosing which pages to show in response to a query. Second, if you use Google Ads or other pay-per-click ads, the algorithms that decide how often to show your ads also consider how fast your page loads, again because their goal is to give the user the most relevant answer. So a slow site means you pay more for the same result. A fast site is simply good business. We can sum it up like that.

2026 update: Google doesn't give a single target for full page load time today. It measures three Core Web Vitals: LCP (time to show the largest element, good up to 2.5 s), INP (response to interaction, good up to 200 ms) and CLS (layout stability, good up to 0.1), at the 75th percentile of visits, separately for mobile and desktop (web.dev).

What really affects store performance?

Tomek: All right. Then a question for you, Kamil. What actually affects a store's performance? We'll get to whether it's good or poor in a moment, but what really makes it the way it is?

Kamil: First of all, it starts with the choice of platform. Shopify is built for fast performance and fast loading, thanks to a number of solutions it has developed, such as Shopify Storefront Renderer. It makes pages load two to even three times faster than on other e-commerce platforms. It works like a distribution network, similar to a CDN, but Shopify places not only the files the browser downloads in different locations around the world, but also the system that renders the page. That's why customers in Europe see a page much faster: it's rendered in their part of the world. Hosting as a whole matters too. During peaks like Black Friday, Shopify provides almost 100% uptime, meaning its services stay available. This infrastructure is very important, and it's largely responsible for how fast the store loads.

2026 update: in a post on its engineering blog from August 20, 2020, Shopify says Storefront Renderer responds on average 4 to 6 times faster than Shopify's previous implementation. That compares it with Shopify's own older engine, not with other platforms (shopify.engineering).

Maciek: Okay, but besides the infrastructure, meaning hosting and the rendering engine, the code architecture matters too: how the store was written.

Kamil: Yes, that's the second aspect, and here a lot more depends on us and how we build the store. Beyond the platform, we have to make sure the storefront is optimized to load fast. We can use a headless architecture, for example, to use any technology and load only the scripts we need at a given moment. But we can also use the traditional Liquid-based approach on Shopify. Then it's very important how we build the site and the theme and how we approach optimizing it. It's a very broad topic, but Shopify doesn't leave us alone here and provides a lot of tools that help build fast themes.

How do apps affect store speed?

Tomek: Good. We know Shopify's success rests not only on its built-in features but also on the apps a merchant can add, for example from the Shopify App Store. So the basic question is: how does installing apps, and especially too many of them, affect performance? What strategy should we take to balance the impact on performance against the features the apps give us?

Kamil: I think you've hit a very important point, because apps that extend a store's features very often have a significant impact on performance. Every such app adds extra resources to the store: JavaScript or additional styles. You have to keep that in mind when choosing an app, and sometimes ask whether you really need it, or whether you can replace its features with something Shopify offers natively, or build them yourself, with a developer of course, at the theme level. That will go a long way toward improving the store's performance.

How to measure store speed: tools

Tomek: All right. Now that we know how important performance is, what tools would you recommend for measuring it? Is Google PageSpeed Insights the only benchmark, or do you have better suggestions?

Maciek: That should be the next step: once we know it matters, we have to measure it. Most store owners know the most popular tool is Google PageSpeed Insights. There are alternatives too, like GTmetrix or Pingdom. The first one probably gives the most relevant pointers, because that data is used when the page is evaluated, for example for how it shows up in search results. Load time alone isn't as important as it was in the first versions of the tool. The focus is now on metrics Google calls Core Web Vitals. They cover speed on one hand and so-called perceived speed on the other: the page is still loading, but we can already use it or see what's going to be displayed. The key metrics are time to first byte, meaning how quickly the first signal arrives after we request the page. Cumulative layout shift, which shows whether sections jump around on the page while it loads. Largest contentful paint, which shows how big the largest resource needed to load the page is. And first contentful paint, meaning how long it takes to see the first image and understand what the page is about.

2026 update: on March 12, 2024, INP (Interaction to Next Paint) replaced FID in Core Web Vitals (Google Search Central). Core Web Vitals are now three metrics: LCP, INP and CLS. TTFB and FCP are supporting metrics that help diagnose a poor LCP. LCP measures how long it takes to show the largest visible element on the page (usually an image or a block of text), not the size of a file (web.dev).

What can merchants do to improve store speed themselves?

Tomek: So we shouldn't look only at one number with a score, because it's made up of several equally important factors Google considers when evaluating a store. All right. Kamil, now a question for you: how can merchants take care of performance and improve it? I suggest we point out what they can do on their own, what's in their hands, where they'll need a developer or an agency, and what they should remind that agency about.

Kamil: Sure. I think the key is to think about performance at the design stage. Ask whether you need that many animations and videos, whether the page should be that long and have that many elements, because all of it will have a big impact on how fast the site works and how we're perceived from the very start. That's definitely something we can do on our side. There are also many things we can take care of once the store is running. Images and videos are very important: they should always be optimized. That also depends on how the theme was built, on whether it uses solutions that fit images to the size of the elements they sit in. Loading too many images on content pages or product pages can hurt the results. Then there's what we mentioned earlier, the apps that extend Shopify's features. At this stage it's often worth asking whether we really need a given solution if it hurts performance. That's on us too, because these extensions install very quickly and easily and add features, but with each installation the store's performance unfortunately drops.

How many apps does a store really need?

Tomek: Let me share our experience here. We recently reviewed a fairly large share of our clients' stores to see how much they actually use the apps they've installed and how many are leftovers from trying out some new feature that still affect performance. Unfortunately, it won't surprise you: the vast majority of clients have 30% to as much as 50% too many apps. Nobody actually needs them. One of our clients had more than 20 apps installed and was actually using about seven. A small digression and a tip for merchants: it's worth going back to your list of installed apps. As you said, Kamil, they're easy to install and new solutions are very easy to test. But simply disabling an app doesn't always mean removing it.

Kamil: Exactly. I'd add that some apps we only need for a specific campaign or time of year. When an app is no longer needed, it's worth removing it from the store. It's also worth mentioning that the way apps deliver resources to a store has changed. In the past, apps could very often inject code into theme files, so uninstalling an app often left a lot of so-called junk all over the theme. Merchants testing various apps sometimes didn't realize they were cluttering their store. That has improved now, I'd say very clearly, because all the resources apps deliver are removed from the theme together with the app. We also have so-called theme extensions, which let apps add elements without adding snippets to the theme.

2026 update: under the Built for Shopify requirements, an app that works in the online store must build its elements as theme app extensions, whose blocks are removed when the app is uninstalled. It shouldn't add, remove or edit theme files, and it can't lower the store's Lighthouse score by more than 10 points (shopify.dev). This applies to apps with the Built for Shopify badge, so if you've ever installed apps that added code to your theme, it's worth reviewing the theme files after removing them.

Maciek: As for things a merchant can do on their own, one is definitely turning off all sorts of pop-ups, which also run on scripts. One or two pop-ups won't hurt. But if we have automations, promotional pop-ups, newsletter sign-ups, discount coupons, or exit-intent pop-ups running everywhere, every one of them, especially when an app handles it, adds seconds or fractions of a second of slowdown. Another popular feature that slows a page down quite a lot is so-called quick view, a product preview on the collection page. We haven't opened the product page yet, but when we hover over a product, a preview starts loading, and besides several images it has to pull in other information too. Very often it's poorly done, either in a ready-made theme or by a developer, and it puts quite a load on the collection page.

What rules should a developer follow?

Tomek: Since we've touched on the areas developers are responsible for: Kamil, what are the most important rules a developer building a store should follow? What advice would you give them?

Kamil: I'll pick up on Maciek's last words about something being badly written by a developer. That's very important, because features like pop-ups or quick view can be built so they don't have a big impact on performance. But that isn't always the case, and you have to check before you start adding more of these elements, thinking they extend the store's features while forgetting that they ruin your performance score. The developer is responsible for the whole theme, the whole architecture of the store. Shopify's technical documentation, for example on Liquid, is a great source of knowledge here. It has many solutions that help build a fast store, such as filters that control how assets like images are loaded. Shopify provides a lot of tools so that images, even when uploaded in very high resolution, are served on the page at the right size and in a format the browser supports. And without losing quality, which is very important, because you can overdo the compression, and that also hurts how the site comes across.

The next thing is using Shopify's CDN for hosting, so the assets needed to render the theme's pages don't sit somewhere outside Shopify's infrastructure, because it's designed to deliver the right performance. It's also important to avoid scripts that block the page from loading right at the start. That partly ties back to the first point, what merchants control, because extra tracking codes, all kinds of tracking and pixels affect how the site works. Even if a developer implements them correctly, every one of them hurts the site's performance. As for Liquid itself, meaning how pages load and render, you have to build the theme properly at that level and avoid all kinds of loops. Let me mention a case from a client who once came to us. His collection page on Shopify took about 30 to 40 seconds to load, which really surprised us. A quick analysis showed that the number of products per page was set to 1,000. Even though caching and rendering on Shopify are handled very well, that's how it turned out. Cases like that happen too.

2026 update: Shopify's CDN picks the image format for each browser on its own: WebP, and since August 29, 2022 also AVIF (changelog.shopify.com). The documentation for Liquid's paginate tag today allows 1 to 250 items per page (shopify.dev).

Preloading and lazy loading

Maciek: Kamil, could you explain two techniques that help optimize performance, especially perceived performance: what is resource preloading, and what is lazy loading?

Kamil: Sure. Lazy loading is a mechanism that holds off loading elements until they appear on the screen. That way images or scripts needed further down the page aren't loaded at the start and don't ruin your performance score. It's most often associated with images and videos, but Shopify has also added tools for developers to use lazy loading more widely. Preloading, on the other hand, lets you load resources in advance that will be needed a bit later but will significantly affect performance and how the page feels. The most common example is an image that should appear when you hover over a specific element. If it's loaded in advance, the experience is much better and nothing flickers on the screen.

2026 update: since June 2025, Shopify turns on Speculation Rules for every Liquid storefront: the browser prefetches the page a customer is about to open as soon as they touch the screen or press the mouse button. It works in Chromium-based browsers (shopify.dev). According to Shopify's A/B tests, described on August 29, 2025, this made loading about 130 ms faster on desktop and about 180 ms faster on mobile on average (performance.shopify.com).

What does Shopify do for merchants when it comes to speed?

Maciek: We've talked about what a store owner can do alone and what they can do with a developer. Let's also mention what the platform itself does, in this case Shopify of course. What can the platform do for us?

Kamil: On Shopify, it's mainly everything I mentioned earlier: optimizing images and preparing them in the format that gives the best performance. There's the CDN, which delivers the page's assets so the wait is as short as possible from anywhere in the world. There's Shopify Storefront Renderer, which I mentioned at the start, preparing the page depending on location. And there's minification of scripts and CSS, so they take up less space and load faster.

2026 update: since Shopify Editions Summer '25, the Horizon family, built on theme blocks, has been the foundation of Shopify's new free themes (shopify.com/editions/summer2025). Shopify doesn't publish separate speed results for Horizon. Every Theme Store theme must have an average Lighthouse performance score of at least 60 across the home, collection and product pages, on desktop and mobile (shopify.dev). How to move to the newer theme architecture is covered in Migrating to Shopify 2.0 in 2026.

How to keep store speed up over time

Maciek: I'd like to share one more observation about how merchants approach optimization. Often they use their own store and at some point say: "No, this site is terrible, everything loads slowly, we have to speed it up." Then a performance audit gets organized in a rush, and the site gets faster. A few months, half a year, a year later, we're back where we started: the site is slow again. That's probably because as complexity grows, as we add new features, connections, integrations and apps, we make the code that has to load more complicated again. Kamil, since we've agreed it's a critical factor, how do we make sure performance stays at a good level all the time?

Kamil: I think it has to be monitored on an ongoing basis. Shopify itself has reports that let you track performance. They're scores based on data Google provides. They include the home page, collection page and product page, and they're combined into an averaged score. We also very often see clients subscribe to tools like GTmetrix, which, with the right plan and settings, can deliver daily or weekly reports for specific pages of the site. That's also a very good practice for keeping an eye on how the store is doing on performance.

2026 update: on January 31, 2024, Shopify replaced the old Speed Score with a Web Performance report based on Core Web Vitals (performance.shopify.com). The summary is on the Online Store > Themes page, and the full reports are in Analytics > Reports. They show LCP, INP and CLS from real visitor data over the last 30 days, at the 75th percentile, broken down by page type, URL and device (help.shopify.com).

Tomek: I'd just add that when we monitor results on an ongoing basis, we shouldn't get subjective about them. As you mentioned, Maciek, sometimes someone decides the store is slow, and that's why they want to improve its performance. As merchants, it's worth setting specific KPIs: what results in each area we're satisfied with. Then it's much easier to hold the monitoring results up against concrete numbers and know when, and especially in which area, to react.

Maciek: Absolutely. I think what Kamil said is very valuable: design and build with performance in mind. Users will appreciate a faster, cleaner interface much more than one that's overloaded and full of bells and whistles. That one will look impressive, but it won't be effective.

Summary

Tomek: That sounds like a great punchline for this episode, so let me sum up briefly. We agree that performance has a significant impact on the business and on running an e-commerce store, so we should measure it, study it and improve it. We can do that ourselves as store owners, but we can also require the agencies and developers we work with to follow good practices. Just as important, it's not a one-time job. Improving performance and optimizing the store has to be an ongoing process that we keep working on and keep monitoring.

Maciek: Totally agree. What gets measured gets done, and with performance we'll definitely see a direct impact on the business.

Tomek: Sure. Guys, thank you very much for today's episode, and Kamil, thank you for finding the time and sharing your knowledge with us. And thank you all for listening and watching. As always, we invite you to comment, suggest new topics, and we'll talk again in the next episode. Thanks a lot.

Maciek: Thanks.

Kamil: Thanks.