In early August 2026 we launched a new online store: picli.co.il, an Israeli photo-printing and photo-gift shop. This post is a case study of how we built it, and mainly of one architectural decision that determined nearly everything else: splitting the store in two.
What you will learn here
- What a split store architecture is, in one sentence and without jargon
- What was actually measured on Picli after the build, and what it means for a visitor
- Three decisions we made along the way, including one that runs against the norm
- A short checklist to help you decide whether this approach fits your own store
Who this is for: owners of an existing online store that feels slow without a clear reason, and anyone weighing up a new store who wants to understand why there is more than one way to build one. If you want the full technical explanation rather than the case study, this post is the right place to start.
The definition, in one sentence
A split architecture (Headless WooCommerce) is a store where the admin system and the storefront the customer sees are two separate things: WordPress and WooCommerce stay behind the scenes running products, stock, orders and payment, while the visible side is rebuilt and served ready-made from a global network.
The name sounds intimidating, but the idea is simple: the engine stays, the wheels change.
Why it was worth the effort
An online store is slow for a structural reason, not because of one bad plugin. A brochure site shows everyone the same page, so it is easy to serve it ready-made. A store computes a personal page for every visitor: what is in their cart, which price applies to them, what is in stock right now. Every load fires database queries.
This is exactly why a caching plugin hits a ceiling. It stores a finished page and serves it to everyone, but in a store it must not do that on cart, checkout and account pages, and usually not on a product page showing stock either. So it works precisely in the least critical places and is switched off where the customer decides whether to buy. We covered this in why WooCommerce stores are slow.
At Picli this mattered even more, because the store is aimed at people uploading photos from their phone. A visitor waiting for a page on a mobile network does not wait long.
What was actually measured
We ran PageSpeed Insights on the home page on 11 August 2026, three spaced runs, and took the median:
| Metric | Result |
|---|---|
| Performance score, mobile | 99 |
| Performance score, desktop | 98 |
| JavaScript files the home page serves from our own code | 0 |
| Products in the catalogue | 49 |
| Categories | 7 |
The third row explains the first two. Picli’s home page ships none of our own JavaScript. The only script that downloads is a small Cloudflare one that hides email addresses from harvesters. The order page, where things genuinely happen (uploads, cropping, resolution checks), is the only page that loads a real UI library.
⚠️ A note on numbers: a PageSpeed score is a lab measurement and it moves between runs. A single run is not a measurement. We always take a median of three to five, and in this very series desktop returned both 98 and 100.
Three decisions from the build
1. The catalogue lives in code and is synced to WooCommerce
This is the decision that runs against the norm, so it is worth explaining. Usually WooCommerce is the source of truth for the catalogue and the site pulls from it. At Picli we reversed the direction: the catalogue is defined in code and pushed from there into WooCommerce with a single command.
Why? Because Picli’s catalogue barely changes, but prices must stay consistent across display, cart and calculation. When they live in one place in code, they cannot drift apart silently. For a store whose stock changes hourly, the decision would have gone the other way.
That is the point worth taking away: a split architecture is not one recipe, and anyone offering it to you without asking how your catalogue behaves is not really listening.
2. The cart survives a refresh, photos included
A Picli customer uploads real photos from their phone. If the cart were wiped on every refresh, all that work would be gone. The cart is stored in the browser itself, files and all, so closing a tab by accident does not delete fifteen minutes of work.
3. A Shabbat gate
The site closes to visitors on Shabbat and Jewish holidays and reopens by itself afterwards. Search engine crawlers keep passing through, so rankings are unaffected.
Common mistakes worth avoiding
- Assuming stronger hosting will fix it. A faster server does the same work faster; it does not remove the work. The upgrade moves the ceiling, it does not lift it.
- Chasing a score of 100 instead of the moment content paints. What matters to a customer is when they see something, not what a report says.
- Splitting a store with no traffic. If revenue from the site is low, a few percent of conversion is a small sum, and the same budget will do more in advertising or product photography.
- Promising everything will carry over one to one. Plugins producing complex product-page behaviour live in exactly the layer being rebuilt, and need checking individually before anything is promised.
Checklist: does this fit your store?
Tick these off. The more that are true, the better the approach pays:
- There is real traffic, not a few dozen visits a month
- Revenue from the site is high enough that a conversion gain is a meaningful sum
- Server response time is high and visitors wait before seeing anything
- You already tried the usual fixes (images, plugins, hosting) and hit a ceiling
- You have no critical plugins doing complex real-time work on the product page
- You are not about to change your business model substantially
Four or more, it is worth looking into. One or two, probably not, and the money is better spent elsewhere.
Where this works best
A store with a stable catalogue and high traffic. Exactly Picli’s case: products barely change, but every waiting visitor costs money.
A store fed by paid advertising. Every second of delay raises cost per lead, and here the improvement translates straight into money.
A store whose visitors are mostly on mobile. The gap between a server computing a page and a ready-made file from an edge network is felt most sharply on a mobile network.
In summary
Picli is a full online store with 49 products across seven categories, and an ordering flow that includes photo uploads, cropping and quality checks. It is managed in WooCommerce like any other store, but the side the customer sees loads instantly, scoring 99 on mobile.
This is not magic and it is not new technology. It is one decision: let each side do what it is genuinely good at. WordPress is excellent at running a store and less good at serving pages fast. So we let it do the first, and moved the second to something that does it well.
And the other side deserves saying: this does not fit every store, and we say so even when it costs us the work. If your store is small and quiet, your money will work harder somewhere else.