A slow website does not usually announce itself. Nobody emails you to say the page took six seconds. They just leave, and the order you never got looks exactly like the order that was never coming. This guide explains what "slow" actually means, what causes it in real small business sites, and what to fix first.
"Slow" means two different things
When a developer says a site is slow, they usually mean a number on a report. When a customer says a site is slow, they mean something much simpler: nothing is happening yet.
Those are not the same. A page can finish loading in four seconds and feel fine, if the product photo and the name and the price appeared in the first second and the rest filled in quietly underneath. Another page can finish in three seconds and feel broken, because for the first two of them the customer stared at a white screen or a spinning circle.
What people react to is the wait before anything useful appears, and then whether the thing they are reaching for stays still. Everything else is bookkeeping.
The first second or two is the whole first impression
People form an opinion about a website extremely fast — faster than they could explain why. Long before anyone reads your copy, they have decided whether this looks like a real, working business. A blank screen for two seconds reads as "broken." A page that snaps in and then jerks around as pictures land reads as "amateur." A page that appears immediately reads as "these people are organized."
That judgment is unfair and it is not going to change. For a heimish business it is especially costly, because so much of the trust you have built is offline. The customer who has driven to your store for fifteen years will wait. The new one, who got your link in a WhatsApp group and is checking it while standing in someone else's kitchen, will not.
What actually makes small business sites slow
In practice the causes are boringly consistent, and they show up in roughly this order.
1. Enormous images straight off a phone or camera
This is the culprit in the large majority of slow small business sites, and it is not close.
A photo from a modern phone is typically around 4000 pixels wide and somewhere between 2 and 8 megabytes. It was built to be printed or cropped, not to be shown in a 400-pixel box on a product grid. When that file goes straight into the website, the customer's phone downloads all of it and then shrinks it down on screen. They paid for every one of those megabytes in waiting time and in data.
Do the arithmetic on a category page with 24 products. At 4 MB each, that is roughly 96 MB of images for one page. Properly prepared, the same 24 photos come to somewhere around 2 or 3 MB total. That is not a tweak. That is the difference between a page that works on a bus and a page that does not.
2. Plugins and third-party scripts
A third-party script is a piece of code loaded from another company's server that runs inside your page — a chat bubble, a Facebook pixel, a reviews widget, an analytics tag, a font service, a popup tool. Each one is a separate trip to a computer you do not control. If their server is having a slow morning, your page waits.
The common advice is "use fewer plugins," which is half right. The count is not the problem. A plugin that only does something in your admin area costs your customers nothing. The problem is plugins and scripts that add code to every page for every visitor. Live chat widgets are usually the heaviest single thing on a small store. Marketing popups, review carousels, and tag managers stacked with old tags nobody remembers adding are next.
A fair question to ask about every one of them: what did this earn us last month? A chat widget nobody answers is pure cost.
3. Cheap, oversubscribed shared hosting
On shared hosting, your site is one of many on the same machine. At $4 a month, "many" can mean hundreds. When the neighbors get busy, you get slow, and there is nothing on your site you can fix to change it.
The symptom is a long pause before the page even starts — the browser has asked, and the server has not answered yet. Developers call that time to first byte. Google's guidance is that under about 0.8 seconds is acceptable; a healthy server on an uncrowded machine is often well under 0.2. If your site sits at two or three seconds before a single pixel appears, no amount of image work will save it. That is the host.
This bites hardest exactly when it hurts most. A kosher grocery's traffic is not flat. It spikes Thursday, and it spikes hard erev Yom Tov, and a cheap shared plan that coasts along on a Tuesday can fall over on the one afternoon of the year that matters. If you take orders around Shabbos and Yom Tov deadlines, your hosting needs to survive your busiest hour, not your average one.
4. No caching
Caching means saving a finished copy of a page so the server can hand it over immediately instead of rebuilding it from scratch for every visitor.
Without it, every single visit makes your server assemble the page again — query the database for products and prices, run the theme, run every plugin, generate the HTML. That work is identical for the hundredth visitor as it was for the first. Turning on page caching is usually the cheapest large improvement available on a WordPress or WooCommerce site, and on a well-configured site it is close to free.
One honest caveat: cart, checkout, and account pages cannot be cached the same way, because they are different for every person. So caching makes your storefront fast but does not rescue a slow checkout. Checkout speed comes from the host and from keeping junk scripts off those pages.
5. Heavy page builders and themes
Drag-and-drop builders are genuinely useful — they are why an owner can change a price or swap a photo without calling anybody. They are also, in most cases, the heaviest layer on the site. They tend to wrap simple content in many nested layers of markup and load large bundles of styling and code on every page, whether that page uses the fancy features or not. Multipurpose themes bought from a marketplace, the ones that ship with twenty demo layouts and five slider plugins, are the same story.
This is a real tradeoff, not a villain. If a builder is the reason your staff keeps the site current, it may be worth its weight. But if the site is rarely edited, you are paying a speed tax every day for a convenience you use twice a year. That is one of the questions worth thinking through in choosing between WordPress and a hand-built static site.
Images: what to actually do
Four steps, in order. None of them require you to touch code.
Step one: make the picture the size it will be shown
Find out how wide the image appears on screen, then save it at roughly double that. The doubling is for high-resolution screens, which pack two physical dots into every design pixel — that is why a photo saved at exactly its display size can look slightly soft on a phone.
| Where the image is used | Save it about this wide | Sensible file size |
|---|---|---|
| Product thumbnail in a grid | 800 pixels | Under 60 KB |
| Main product photo (zoomable) | 1400–1600 pixels | Under 150 KB |
| Full-width banner across the top | 1800–2000 pixels | Under 200 KB |
| Photo inside an article | 1000–1200 pixels | Under 120 KB |
| Logo | SVG if you have one, otherwise twice its display size | Under 20 KB |
These are practitioner rules of thumb, not laws. But if your product photos are 3 MB each, you are roughly twenty times over budget, and the customer is paying that bill in seconds.
Step two: use a modern file format
JPEG and PNG are decades old. WebP is a newer image format that produces meaningfully smaller files at the same visual quality — Google, which developed it, puts the saving at roughly 25 to 34 percent versus a comparable JPEG. Every browser in current use supports it. AVIF is newer still and usually smaller again, and is now supported by current versions of Chrome, Firefox, Safari, and Edge.
Practical advice: convert to WebP. It is the safe default in 2026, the tooling is everywhere, and the gain over JPEG is real. AVIF is worth it on image-heavy stores where somebody is willing to keep a JPEG fallback in place for very old devices.
Step three: compress
Compression throws away detail your eye will not miss. On a JPEG, quality around 75 to 82 is usually indistinguishable from the original at normal viewing size, at a fraction of the file size. WebP behaves similarly around quality 75.
You do not need software for this. Squoosh (squoosh.app), which is free and made by Google, runs in your browser and shows you the before and after side by side with the file sizes. Drag a photo in, pull the quality slider down until you can see the difference, then push it back up two notches. That is the whole skill.
If you are shooting your own product photos, doing this at export time is far less painful than fixing 400 images later — see the product photography guide for the shooting end of it.
Step four: lazy loading, with one exception
Lazy loading means the browser only downloads a picture when the customer scrolls near it. On a long category page, that can mean loading six images instead of sixty. It is a single instruction in the page, and on most modern sites it is on by default.
The exception matters: do not lazy-load the big image at the top of the page. That is the one image the customer is waiting for, and delaying it makes the page measurably worse. This is a common mistake — a plugin gets switched on site-wide, and the main banner gets slower.
While you are there, every image should declare its dimensions, like <img src="kugel.webp" width="800" height="600" loading="lazy">. Those two numbers let the browser reserve the right amount of space before the picture arrives, which is what stops the page from jumping. More on that below.
What a CDN is, and whether you need one
A CDN — content delivery network — keeps copies of your images and files on servers in many cities, so each visitor is served from one near them instead of from your single server.
When it matters: when your visitors are spread over a wide area, when you have a lot of images, or when your host is far from your customers. When it matters less: a Brooklyn butcher whose customers are almost all within twenty miles of a server in New Jersey. The distance saving is small there.
That said, a CDN today usually comes bundled with things that help everyone — automatic compression, better caching of static files, and a buffer against traffic spikes. Cloudflare's free plan covers all of that. It is generally worth turning on. Just do not expect it to fix a slow site on its own; a CDN delivers your problems faster, it does not remove them.
Mobile is where the damage happens
For a local business, most of the people looking you up are on a phone. They are looking you up in a car, in a store, in a waiting room. And a phone on a cellular network is working with less bandwidth, more latency, and less processing power than the desktop your site was designed on.
So the mobile version is the real version, and it is the one Google grades. Google uses the mobile version of a site as the primary basis for indexing and ranking. If the mobile experience is slow, that is the experience being judged — not the desktop one you approved.
Core Web Vitals, in plain terms
Google needed a way to measure "does this page feel good to use" without a human watching. Core Web Vitals are the result: three measurements, taken from real Chrome users visiting real sites. They are one input among many into search rankings — content and relevance matter far more — but they are also simply a good description of what annoys people.
| Measurement | In plain English | Good | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | How long until the main thing on the screen — usually the big photo or headline — actually appears | 2.5 seconds or less | Over 4 seconds |
| INP (Interaction to Next Paint) | When someone taps a button, how long until the page visibly responds | 200 milliseconds or less | Over 500 milliseconds |
| CLS (Cumulative Layout Shift) | How much the page jumps around while it loads | 0.1 or less | Over 0.25 |
Two details worth knowing. These are scored at the 75th percentile of visits, meaning three out of four of your visitors need to have a good experience, not just the average one. And INP replaced an older measurement called FID in March 2024, so any advice written before then that talks about "First Input Delay" is out of date.
The annoying one: the page that jumps
CLS is the measurement of the thing everyone hates and nobody has a name for. You go to tap a link, and at that exact moment an image finishes loading above it, everything slides down, and your finger lands on something else.
It has a small number of causes, and they are all fixable:
- Images without declared dimensions. The browser does not know how tall the picture will be, so it leaves no room, then shoves everything down when it arrives.
- Banners and notices inserted at the top after load — cookie bars, free-shipping announcements, holiday closing notices. They push the whole page down. Reserve their space in the layout instead.
- Fonts swapping. The page draws in a fallback font, then the real font arrives and everything re-flows because the letters are a different width. Hebrew and Yiddish sites are more exposed to this, because Hebrew webfonts carry large character sets — especially with nikud — and are often heavier than their English equivalents. Subsetting the font to the characters you actually use is the fix.
- Ads and embedded widgets with no fixed height.
How to measure your own site, free
You do not need anyone's permission or a paid tool.
- PageSpeed Insights (pagespeed.web.dev). Paste your URL. Read the mobile tab, not desktop. The top section, if it appears, is real data from real Chrome visitors over the past 28 days. The section below it is a simulated lab test.
- Google Search Console. If you have it connected, its Core Web Vitals report shows you which pages are failing across your whole site rather than one URL at a time. Free, and it is the closest thing to Google telling you directly.
- WebPageTest (webpagetest.org). Free tests that let you pick a location and a simulated slow connection, and give you a filmstrip of what the page looked like second by second. The filmstrip is the single most persuasive thing you can show a web person.
- Chrome's own tools. Right-click a page, Inspect, Lighthouse tab, run it. Same engine as PageSpeed Insights, works on a site that is not public yet.
Two things nobody tells you about the score
Small sites often show no field data. PageSpeed Insights only reports real-visitor data when a site has enough Chrome traffic. A new store, or a quiet one, will often show only the lab test. That is normal. Use the lab number as a rough guide and trust the phone-on-cellular test more.
The score out of 100 is not the goal. It is a lab estimate on a simulated slow device, and it bounces around between runs. Going from 40 to 75 is a real improvement your customers will feel. Going from 92 to 98 is usually somebody billing you for nothing. Fix the things the report lists; do not worship the number.
What this actually costs a store
The mechanism is not mysterious. Every second of waiting is another second in which a person can reconsider, get interrupted, or decide the other store looked easier. The losses stack at every step: fewer people wait for the homepage, fewer of those wait for a category page, fewer still make it through a checkout that stalls after they hit the button.
There is published research on the size of this. A 2020 study by Deloitte with Google, "Milliseconds Make Millions," reported that a 0.1 second improvement in mobile site speed was associated with roughly an 8.4% increase in conversions for retail sites. Figures from other people's sites should always be treated as indicative rather than a promise — but the direction is not in dispute, and it has been measured the same way many times.
The version that matters is your own arithmetic. If your store takes 200 orders a month at an average of $85, that is $17,000. You do not need a study to tell you what a 10% swing in completed orders is worth, in either direction. Run that number on your own store's real figures before you decide image optimization is not urgent.
Checkout is where layout shift turns into refunds
Layout shift on a blog post is irritating. Layout shift at checkout costs money in a specific, traceable way.
A customer's thumb is already moving toward "Place Order." At that instant a delivery-fee line, or a coupon box, or a shipping-method block finishes loading and pushes the button down 40 pixels. The tap lands on a different delivery day. Or on "remove item." Or it lands nowhere, and they tap again, and now you have a duplicate order and a phone call.
For a grocery with delivery windows, this is not hypothetical — a mis-tapped shipping option means the wrong delivery zone or day, and somebody in your office has to sort it out by hand. A stable checkout page is worth more than a beautiful one.
The fix list, in order
Hand this to whoever maintains your site. It is ordered by return on effort, not by difficulty.
- Fix the images. Resize everything to display size, convert to WebP, compress, set width and height on every image, lazy-load everything except the top banner. Usually a few hours of work for the biggest single gain on the site.
- Turn on page caching and compression. A caching plugin or a host-level cache, plus Brotli or gzip compression. Often an afternoon, sometimes an hour.
- Audit third-party scripts. List everything loading from someone else's server. Delete anything that has not earned its place — dead tracking tags, an unanswered chat widget, a review service you stopped paying for. Load what remains after the page, not before it.
- Check the server response time. If time to first byte is consistently over a second, move hosts. A managed WordPress plan in the $20 to $60 a month range is a different class of machine than a $4 plan, and this is one of the few places where paying more reliably buys speed.
- Put a CDN in front of it. Cloudflare's free tier, an hour to set up, helps with spikes even if your customers are all local.
- Handle fonts. Serve them from your own site rather than a third party, limit yourself to two or three weights, subset Hebrew fonts, and set them to display text immediately in a fallback rather than showing nothing while they load.
- Reduce the builder, or plan to leave it. The heaviest structural fix, and the only one that is a real project. Worth costing out honestly rather than doing in a panic.
Steps 1 through 3 solve most slow sites. If you have done those and the site is still slow, the answer is almost always the host or the theme, and pretending otherwise wastes money.
Questions owners actually ask
"It's fast on my computer. Is it really a problem?"
Almost certainly yes. Your browser has already stored copies of your site's files, your connection is good, and you know exactly where you are going. Test on a phone, on cellular, in a private browsing window. That is the honest view.
"Will making it faster make it uglier?"
No, in almost every case. Properly compressed images are not visibly different from the originals at screen size — that is the entire point of compression. What sometimes goes is an autoplaying background video, a homepage slider rotating through six banners nobody scrolls past the first of, or a decorative animation. Losing those tends to improve the site rather than damage it.
"Do I have to rebuild the whole site?"
Usually not. Images, caching, and script cleanup are all done inside the site you already have. A rebuild is warranted when the theme or builder is the bottleneck and the site is also dated, awkward on phones, or hard for you to update — at which point you are solving several problems at once and the speed gain is a bonus, not the reason.
"My host says the problem is on my end."
Ask for one number: time to first byte, measured for your site, on mobile. WebPageTest will show it to you independently in about a minute. If that number is over a second on a page with caching enabled, it is the host, whatever they say. If it is 0.2 seconds, they are right and the problem is in the page.
"What about the Facebook pixel — I need it for ads."
Keep it if you actually run ads and actually read the results. Set it to load after the page has rendered rather than blocking it. What to delete is the archaeology: the tags from the marketing company you used in 2021, the two analytics tools measuring the same thing, the pixel for a platform you no longer advertise on. Also worth knowing that tracking scripts carry legal obligations around disclosure and consent, which is a separate subject with its own rules.
"How fast is fast enough?"
A reasonable target for a small store: the main content visible in under 2.5 seconds on a mid-range phone on cellular, no visible jumping, and taps responding immediately. That is achievable on ordinary hosting with ordinary tools. Chasing beyond it has sharply diminishing returns for a business that sells food, books, or services rather than advertising.
If you would rather have someone measure it and tell you plainly what is wrong, that is a small, well-defined piece of work — get in touch and we can look at the actual numbers for your site rather than guessing.
The short version
- Customers judge you on how long until something useful appears, and on whether it then holds still. The first second or two decides the impression.
- Oversized images are the cause in most slow small business sites. Resize to display size, convert to WebP, compress, lazy-load everything except the top banner, and set width and height on every image.
- After images: caching, then deleting third-party scripts that are not earning their keep, then the host if time to first byte is over a second.
- Measure on a phone on cellular data, and with PageSpeed Insights on the mobile tab. Aim for the main content in under 2.5 seconds and a Cumulative Layout Shift under 0.1. Do not chase a score of 100.
- Layout shift during checkout is the most expensive kind of slow — mis-taps become wrong delivery days, duplicate orders, and phone calls.
- Run the arithmetic on your own monthly orders before deciding this can wait.