Custom ecommerce website development
in Seattle

Shop pages are slow for reasons that are easy to name and hard to refuse: images, third-party scripts, and a category page that loads sixty products because somebody removed the pagination.

A budget makes the argument concrete. Before the build we agree a page weight and a timing target per template, and every later request is measured against it.

Images are usually the largest line. Product photography arrives at print resolution and gets served at print resolution. The fix is plain. Resize on upload, serve modern formats, set explicit dimensions so the layout stops jumping, and load what is below the fold only when it is needed. A grid of thirty products should not ship thirty full-size photographs.

Third-party scripts are the line nobody owns. Analytics, two chat widgets, a review service, a heatmap tool, a personalisation tag, and a consent banner that loads ahead of all of them. Each was added for a reason and none were removed. We audit them by measuring the page with each one switched off, then hand the list to whoever asked for them and let them choose.

Category pages deserve their own rule. Filtering that reloads the whole page is slow and loses the shopper's place. Filtering that rebuilds the grid in the browser is fast and often invisible to search engines. We do both on purpose: server-rendered results at a real URL for the filters that matter for search, in-browser refinement for the rest.

Checkout gets the strictest budget, because that is where a lost second has a price. Fewer scripts, no chat, no marketing tags that block the form.

The numbers we watch are the ones Google publishes from real visits, not the ones a testing tool produces on a fast connection. A lab score is useful for finding the cause. Field data tells you whether the fix mattered.

One thing gets forgotten. The budget has to survive the next marketing campaign. That means a review step before a new tag goes live, and a monthly report showing the trend. Without those two, page weight climbs back within a quarter.

Overselling is the most expensive small bug in retail. The order is taken, the money is captured, and then somebody has to write the email saying the item is not there.

Accuracy is a system question, not a field in the product record. Four things decide it.

Where the number comes from. If the warehouse system owns stock, the shop should read it and never guess. If the shop owns it, everything that moves stock must write back: returns, damages, transfers, counts. Two systems both believing they own the number is the usual cause of drift.

How often it moves. A nightly sync is fine for a slow catalogue and dangerous on a launch day. Near-real-time costs more and earns it for the few hundred products that sell fast. We split the catalogue rather than pay for the whole of it.

What happens between cart and order. Stock reserved at add-to-cart protects the shopper and hides inventory from everyone else. Stock reserved at payment risks the race. We usually reserve at checkout start with a short hold, and make the hold visible so nobody wonders where the units went.

What the page says when the number is low. “Out of stock” ends the visit. A date, a back-in-stock notification, or a nearby size keeps it. This is a design decision with revenue attached, and it deserves more than a default label.

Several locations make all of this harder in one specific way. The shop has to decide which location will ship before it can promise a date. That logic belongs in one place, written down, with a fallback for when the preferred location is short.

Cycle counts are the boring part that keeps the rest honest. A shop that counts fast movers weekly and the long tail quarterly can trust its own numbers. A shop that counts once a year cannot, and no amount of integration work fixes that.

We instrument it as well: oversell attempts, reservations that expired, and the products where shop and warehouse disagreed. Those three reports tell you whether the plumbing works before a customer does.

Pre-orders and backorders sit next to this and are worth deciding early. Selling something you do not have yet is fine when the page says so and the date is real. It goes wrong when a backorder looks like normal stock, because the shopper finds out at the delivery estimate rather than at the product page. If you take pre-orders, the cart has to keep them apart from stocked items, and a mixed order needs a rule: ship what is ready, or hold the lot.