Performance profile · Handmade Sellers & Maker Stores
Web hosting for handmade sellers — Your photographs are the page weight
The images that justify your prices are also the heaviest thing you ship — so the job is keeping both true at once, and measuring it rather than guessing.
The short answer
On a maker's store the Largest Contentful Paint element is a product photograph, so that is where the work is: export at the dimensions the page actually renders, let built-in WebP conversion handle the format, and re-run a throttled Lighthouse pass. Google's good threshold is 2.5 seconds and anything past four is poor, and one oversized hero image is usually the whole difference.
The cart and checkout are a separate problem, because they can never be cached — every request builds a personalised page. That half runs on CPU, NVMe and an object cache, on WooCommerce tiers from Sprint Store upward, and cPanel's Resource Usage graph is how you tell a busy shop from an overloaded one.
By the HostingFast team · Reviewed 24 August 2026
99.9%
Uptime target, monitored
24/7
Support, any hour
Free
SSL, every plan
NVMe
Drives, all tiers
Handmade selling is a visual trade, so the photographs are not decoration — they are the argument for the price. That makes the usual advice to cut images useless. The real advice is to ship the same photograph at a tenth of the bytes, which is a technical job with a measurable outcome.
Start with one throttled Lighthouse run: Chrome DevTools, Mobile, Slow 4G, three passes, median. It will name your LCP element. Then open the network panel and sort by transfer size. If the top row is a 4 MB JPEG straight out of a camera, you have found your afternoon's work and it costs nothing but time.
The second half is the shop mechanics: a catalogue query that grows with your listings, and a cart that is uncacheable by design. Neither is visible in a homepage score, and both are what a buyer meets at the moment they were going to pay you.
One photograph, a tenth of the bytes
Resize before you compress. A 4000-pixel image rendered into an 800-pixel slot is wasting three quarters of every byte before format even comes into it, and the browser still has to decode all of it. Export at the rendered size, then let the platform's built-in WebP conversion do the format work — no second image plugin, no subscription, no argument about which one wins.
Then measure. Three throttled Lighthouse passes before, three after, medians compared. A product page that was over four seconds usually lands well under 2.5 after this one change, and if it does not you have learned that your problem was elsewhere — which is a cheaper thing to learn from a test than from a rebuild.
The cart is slow by design, so measure it separately
Cart, checkout and account pages are personalised, so no page cache will ever store them. Every request runs PHP, hits the database and works out totals, stock and shipping. That is why a shop with modest traffic can feel slower than a blog with far more of it, and why the honest test is timing an add-to-cart and a checkout rather than a landing page.
Redis object caching helps because it stores repeated query results rather than whole pages, and it ships on every WordPress tier. Watch entry processes in Resource Usage during a busy hour: if you are at the ceiling, that is capacity, and Turbo Store or Nitro Store applies in place.
What a growing catalogue costs the query
One-off pieces mean lots of products with a stock quantity of one, and the shop pages sort, filter and count them on every uncached request. The WooCommerce tiers here are sized in product counts — 5,000 on Sprint Store, 25,000 on Turbo Store, 100,000 on Nitro Store — so the plan question is answerable with a number rather than a guess.
Keep sold work published rather than deleting it: it demonstrates that people buy from you and gives commission enquiries something concrete to point at. Just make sure the shop query filters those out of the default listing, because a catalogue that sorts over years of sold items every time is paying for history nobody is browsing.
Prove the change, then keep the number
After any change — image pipeline, theme, a plugin that promises speed — re-run the identical tests at the same time of day and write the medians next to the old ones. Lab figures from Lighthouse move immediately; the Core Web Vitals block in PageSpeed Insights is field data from real Chrome users and will take weeks to agree with you.
That habit is what separates real optimisation from the cargo-cult version. A plugin that improved a score you never recorded has proved nothing, and a change that made the product page faster while the checkout got slower is a trade you would rather notice now.
A stack that keeps photographs cheap
The two halves of a maker's shop need different things. The catalogue wants a cache and an image pipeline; the checkout wants CPU, NVMe and an object cache. Both come with a HostingFast account.
And the measurements come with it too — Resource Usage graphs, real logs over SSH, staging copies for trying a theme, and per-site PHP switching for the version bump you would rather test than discover.
- Built-in WebP conversion, aimed at the photograph that owns your LCP
- LiteSpeed page caching for the catalogue a visitor browses
- Redis object caching for the cart and checkout that cannot be cached
- Store tiers sized by product count: 5,000, 25,000 or 100,000
Why HostingFast
Standard on every plan
Photographs at a tenth of the weight
WebP conversion is built into the platform, so the image that sells the piece stops being the thing that delays the page.
A cached shopfront
LiteSpeed serves product and category pages from stored HTML, so browsing costs the server almost nothing.
Real CPU for the checkout
NVMe storage and Redis object caching behind the pages that can never be cached, which is where a sale is actually made.
A plan sized in products
5,000 on Sprint Store, 25,000 on Turbo Store, 100,000 on Nitro Store — a number to choose against rather than a promise.
Somewhere to try a theme
Staging copies let you measure a new shop template before a customer meets it, and roll back if the numbers got worse.
Restores you can run yourself
Daily backups with self-service restore from the panel, so a bad plugin update on a launch weekend is a ten-minute rewind.
Quick Start
From order to online
- 1
Find the file that owns your LCP
One throttled Lighthouse pass names the element; the network panel sorted by transfer size names the file. They are usually the same photograph.
- 2
Export at rendered size, then convert
Resize first, let built-in WebP conversion handle the format, and re-run the same three passes to see what it actually bought you.
- 3
Time the cart, not the homepage
Add to cart, go to checkout, time both. Then watch entry processes during a busy hour to see whether capacity is really the issue.
Built In
Loaded onto every plan
- Built-in WebP conversion for product photography
- Server-level LiteSpeed caching for catalogue and category pages
- Redis object caching and AccelerateWP on the WordPress tiers
- NVMe storage on every tier for the uncached cart and checkout
- cPanel Resource Usage: CPU, memory and entry processes over time
- Staging copies for testing a shop theme before it goes live
- Per-site PHP version switching from the control panel
- Daily backups with self-service restores from the panel
- Free SSL on every plan, reissued before it can lapse
- Store tiers from Sprint Store up to Nitro Store, sized by product count
Frequently Asked
What people ask us most often
How do I keep my photographs looking good but load fast?
Resize before you compress. Export at the pixel dimensions the page actually renders, then let built-in WebP conversion handle the format. A 4000-pixel image in an 800-pixel slot wastes most of its bytes and still has to be decoded in full. Measure with a throttled Lighthouse pass before and after so you know what the change bought.
Why is the checkout slower than the rest of the shop?
Because it cannot be cached. Cart, checkout and account pages are personalised, so each request runs PHP and the database to work out totals, stock and shipping. That is normal. What matters is whether it is fast enough: time an add-to-cart and a checkout directly, and use Resource Usage to see if you are at your entry process ceiling.
How many one-off products can a plan carry?
The WooCommerce tiers are sized in product counts: 5,000 on Sprint Store, 25,000 on Turbo Store and 100,000 on Nitro Store. For a maker selling single pieces the count grows with every listing, so keep sold items published for credibility but filter them out of the default shop query.
Do speed plugins help a small shop?
Sometimes, and you will only know if you measured first. The cache already lives in the server here, so a second caching plugin usually creates conflicts rather than gains. Record a median TTFB and a throttled Lighthouse run before installing anything, then repeat it after. A plugin that moved nothing you measured has proved nothing.
Keep reading
Churches & Faith Groups — Hosting Guide
A volunteer-run site with the same image problem and nobody technical to fix it.
Esports Teams — Hosting Guide
A brand-led site where photography and a merch store sit on the same account.
SSL Certificate (Glossary)
How to check a certificate is doing its job on a checkout page you take money through.
DirectAdmin Reseller Hosting — Built for Handmade Sellers
A lighter DirectAdmin reseller account if you end up hosting stores for other makers.
WordPress Hosting
Managed WordPress with LiteSpeed, Redis, staging copies and daily backups.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Weigh your photographs.
One throttled run and the network panel name the file that is costing you the sale — and WebP conversion is included.
View DirectAdmin Reseller Hosting — Built for Handmade Sellers plans