You’re working out who should build your store, and the guides that come back all read the same way. Shopify’s walkthrough of ecommerce website development hands you six steps: choose a host, register a domain, design the site, configure shipping, build and launch, then maintain it. Near the end there’s a list of what successful stores have in common, and “site speed” and “mobile optimization” each get a single line on it. BigCommerce’s version has the same six-step shape with a functionality checklist bolted on, where site speed, SEO, and security appear as bullets with a sentence or two each and no implementation detail, followed by a long pitch for BigCommerce itself. Testing, on both pages, is about one sentence. ScienceSoft’s ecommerce development page ranks for this search too, and it leads with credentials and a founding year, lays out a menu of solution types, posts its price tiers, and says nothing anywhere about page speed, rendering, images, or what all the marketing tags do to a store once they’re installed.

So across all three, speed and findability show up as items on a feature list. Both are actually settled by decisions made during the build, often in the first few weeks, and a store that got them wrong doesn’t get rescued later by installing an optimization app. It’s worth knowing what those decisions are, and what to ask about each one, before you hire anybody.

“Fast” has a measurable definition now, which is useful when you’re evaluating somebody’s work. Google’s Core Web Vitals set three thresholds. Largest Contentful Paint, the moment the biggest element on the screen finishes drawing, should happen within 2.5 seconds of the page starting to load. Interaction to Next Paint, which measures how long the page takes to visibly respond after someone taps or clicks, should be 200 milliseconds or less. Cumulative Layout Shift, the amount the page jumps around while it assembles, should stay at or below 0.1. All three are measured at the 75th percentile of real visits, and mobile and desktop are scored separately, so the number that counts comes from your slower quarter of shoppers on their phones. A single run on a laptop over a fast connection tells you almost nothing about it.

The largest single lever on those numbers is where your product and category pages get assembled. If the page arrives in the browser as a mostly empty shell and JavaScript then fetches the product data and builds the page, the browser has to download the bundle, execute it, request the data, wait for the response, and only then paint the product image and the price. Every one of those steps sits on the path to Largest Contentful Paint, and on a mid-range phone over cellular they add up quickly. If the server sends finished HTML instead, with the product name, price, and image already in the response, the browser starts painting right away and the JavaScript arrives afterward to make the page interactive.

That choice, whether product and category pages are rendered on the server, pre-rendered ahead of time, or assembled in the browser, gets made early by whoever picks the front-end architecture, and it’s often made by default instead of on purpose. It drives the second number too, because a page that ships a large JavaScript bundle to reconstruct itself in the browser is still busy running that code when the shopper taps a size selector, and that delay lands directly on Interaction to Next Paint. Reversing it later means changing how every page type fetches its data and re-testing every interactive piece of the storefront, so raise it while the architecture is still being planned.

Product photography is almost always the heaviest thing on an ecommerce page, and on product and category pages the main product image is usually the Largest Contentful Paint element itself. That makes the image pipeline the difference between landing inside 2.5 seconds and missing it, and three decisions inside that pipeline do most of the work.

The first is format. A photographer delivers JPEGs or PNGs at print dimensions, and a build that serves those files straight through moves several times more bytes than one that converts them to a modern format on the way out. The second is sizing: whether the site generates appropriately sized versions for phone, tablet, and desktop, or ships one large file and lets CSS scale it down in the browser after the full download has already happened. The third is loading behavior, meaning which images the browser is told to fetch immediately and which it can defer until the shopper scrolls. Deferring everything below the fold genuinely helps, though deferring the main product image is a common mistake that can push Largest Contentful Paint out by a second or more on the page you most need to convert.

What makes this compound is catalog size. A few hundred products with several photos each is already a few thousand source files, and a store that’s been running for a while has retired products, seasonal shoots, and a handful of people who have uploaded images over the years. If the original files went in at whatever size they arrived and get served directly, correcting it later means reprocessing the entire library, updating every template that references an image, and sorting out whatever caching sits in front of it. A build that puts a processing step between upload and delivery, generating the formats and sizes it needs and serving them from a CDN, gives every product the same treatment without anyone having to remember the rules.

Marketing pixels, analytics, review widgets, live chat, A/B testing, personalization, affiliate tracking, and the loyalty program all arrive the same way, as a snippet somebody pastes in. Each one looks free at the moment it’s added, and together they’re a large part of why a store that launched fast feels sluggish a couple of years on.

Every one of those tags is JavaScript the browser has to fetch, parse, and run on the main thread, and the main thread is the same one that has to respond when a shopper taps “add to cart” or opens a filter. That’s why accumulated tags hit Interaction to Next Paint hardest, and an unresponsive tap is the failure shoppers actually notice, because they read it as the site being broken. The other half of the problem is that tags get added constantly and removed almost never. The vendor who needed a pixel two years ago is gone and the person who installed it has moved on, so nobody left feels able to delete something marketing might still be using.

Handled during the build, this becomes a budget with an owner. Tags go through a single manager instead of being hardcoded into templates, so what’s installed stays visible in one place, and anything not required for the first paint gets deferred. Someone keeps a list of what’s running and who asked for it, and field measurements get checked after a batch of additions instead of once a year when traffic drops. None of that is complicated, but it has to be set up while the storefront is being built, because retrofitting it onto a store with a few dozen tags already hardcoded across its templates is a project of its own.

This is where the “SEO-optimized” bullet on those competitor pages actually lives, and most of it comes down to URLs. A category page with filters for size, color, price, and brand, plus a few sort orders, can generate an enormous number of distinct URLs that all serve substantially the same products in a different arrangement. Google’s own canonicalization documentation names sorted and filtered category pages as a source of duplicate content. When Google finds several URLs showing near-identical content it picks one to index, and it makes that choice from a range of signals; the canonical URL you declare is one of those signals rather than an instruction, so the URL Google settles on can differ from the one you named.

Two things go wrong when nobody decided this during the build. The first is that crawling effort gets spent working through filter combinations instead of picking up your new products and updated prices, which matters more the larger the catalog gets. The second is that the version of a category that ends up ranking may be a filtered slice nobody meant to promote, with a title and a product set that don’t match what the shopper searched for.

The decisions that prevent it all get made while the catalog is being built. Someone has to work out which filter combinations deserve real indexable pages, usually the handful with genuine search demand behind them, and which are parameters that point back to the base category. Pagination needs a structure that keeps deeper pages reachable. There’s a choice about whether filtered URLs are linked in the markup at all, since linking them is what invites crawling in the first place, and the sitemap has to list the canonical set and stay current as products come and go. Then there’s the product URL itself, which ought to survive a product being moved between categories, along with a decision about what happens when something is discontinued. Redirecting to the closest live product is defensible, and so is returning a clear signal that it’s gone for good. What tends to happen when nobody decides is a third thing: the page still loads with nothing on it, so crawlers keep working through it and shoppers who land there hit a dead end.

Two questions will tell you quickly whether a shop made these decisions deliberately or inherited them.

Ask to see real Core Web Vitals field data from a live store they built, at the 75th percentile, on mobile, broken out for product and category pages. A Lighthouse score from a demo site is a lab measurement on a clean machine with no catalog, no tags, and no traffic, so it tells you close to nothing about the store you’re about to pay for. A shop that runs stores in production either has this data already or can pull it in an afternoon.

Then ask how they handle filtered and sorted category URLs: which ones get indexed, which point back to the base category, and how that stays consistent as the catalog grows. Anyone who has taken a real catalog through a few years of Search Console will have an opinion here and will give you specifics. If both answers come back as platform certifications and a list of technologies, assume these decisions will get made by default on your project too.

Two smaller questions are worth adding. Ask what happens to a product image between the moment someone uploads it and the moment a shopper sees it. Then ask what’s currently installed in the tag manager of a store they operate, and who decides what goes in.

If you haven’t settled whether you need a platform store or custom development, start there, because it changes who makes these decisions and how much of the stack you control. We wrote that decision up separately in website ecommerce development. If that’s settled and what’s worrying you is the machinery behind the storefront, meaning payments, inventory sync, checkout reliability, and tax, that’s covered in web development for e-commerce. And if you’re planning a build from scratch, new products covers how we run one from architecture through the first year of real users.

Once a store is live, the measurement question widens out past page speed into sales across storefront, marketplace, and wholesale, which we covered in analytics engineering for e-commerce teams.

If you want to talk through a specific build, book an intro call. It helps to come with the size of your catalog, roughly how many images a product carries, and the marketing tools your team expects to plug in, since that’s usually enough for us to say where the performance and indexing pressure will land.