When people talk about site speed, they almost always talk about the customer. Conversion rate, bounce rate, Core Web Vitals. All of that holds and this article gets to it as well.
But half the value of a fast online shop is hidden where no marketer ever looks: in the admin. Where your team puts in eight hours a day. Where products are created, prices corrected, returns handled and stock received. And where a slow system costs you money you will never see in a report, because it has no line of its own.
This article is an attempt to work that line out.
Why nobody ever talks about admin speed
There are three reasons and all three are mundane.
Nobody measures it. The speed of the public site is measured for you by PageSpeed Insights, Lighthouse and Google Search Console. The speed of the admin is measured by nobody, because it sits behind a login. No public tool can reach it.
It never shows up as spending, only as „we are behind“. While an administrator waits for a screen, the salary keeps running. The cost is paid, you just do not get an hour of work for it. In the books it looks exactly like productive time.
People get used to it. After three months nobody says „the system is slow“. They say „that is normal, we have a big catalogue“. And they start opening their inbox while things load.
And here is the uncomfortable part: the admin is more sensitive to performance than the public site. A public site can hide behind caching and a network of servers, so a visitor often gets a finished page generated an hour ago. The admin has no such option. Every click is a fresh database query, for the current stock level, for the current state of an order. It cannot be prepared in advance. Either the system works it out fast, or your employee sits there and waits.
How many times a day does an administrator click
Running a catalogue of fifty thousand items and variants means constant movement between orders, product records, stock, pricing and filters. The number of loading actions, meaning a click that fires a new request to the server rather than just scrolling, depends on the role.
| Role | Typical work | Loading actions per day |
|---|---|---|
| Customer support and order handling | Finding an order, opening it, changing its state, writing to the customer | 200 to 400 |
| Standard administrator | Stock, product edits, prices, orders | 500 to 800 |
| Catalogue manager and data entry | Listing products, variants, attributes, descriptions, photos | 1,200 to 2,000 |
Those numbers look high until you break down a single routine. Creating one product with ten variants in a typical off the shelf admin goes like this: open the list, create the product, save, move to variants, walk through ten steps of generating and saving, move to stock, move to prices, move to categories, upload photos, save, check the preview.
At twenty new products a day you are at five to eight hundred actions from that one activity alone. And that is only the work you planned, without a single return and without a single price correction.
A model calculation for a slow and a fast system
I work with 220 working days a year, an ordinary year with weekends, public holidays and leave taken out. Response time is taken as the middle of the range I see in practice: three to five seconds per action on slow systems, half a second to a second on fast ones.
Slow system: 4 seconds per action on average. Across an eight hour shift that adds up to tens of minutes that appear nowhere as a cost.
Fast system: 0.75 seconds per action on average. The saving on one single click is 3.25 seconds.
| Type of user | Actions per day | Waiting on a slow system | Waiting on a fast system | Saved per day | Saved per year | In working weeks |
|---|---|---|---|---|---|---|
| Occasional operator | 300 | 20 minutes | 3.75 minutes | 16 minutes | 60 hours | 1.5 weeks |
| Standard administrator | 600 | 40 minutes | 7.5 minutes | 32.5 minutes | 119 hours | 3 weeks |
| Catalogue manager | 1,500 | 100 minutes | 18.75 minutes | 81 minutes | 298 hours | 7.5 weeks |
Read the middle row again. On a slow system an ordinary administrator spends forty minutes a day purely waiting. Not working with the catalogue, waiting for the catalogue to appear on screen.
And now the worse news: four seconds is an optimistic figure for a slow system. On an overloaded shop with a large catalogue the product list routinely takes eight or fifteen seconds and a bulk operation over a thousand items dies on a timeout. At that point the numbers in the table do not double, they triple.
What that is in money
The average gross wage in the Czech Republic is set at 48,967 CZK a month for 2026. On top of it the employer pays 24.8 percent for social insurance and 9 percent for health insurance, so the total cost lands around 65,500 CZK a month. Against roughly 168 hours that is about 390 CZK an hour.
Shop roles tend to sit below the national average, so I also run the conservative variant at 300 CZK an hour of total employer cost.
| Role | Waited per year | Cost at 300 CZK an hour | Cost at 390 CZK an hour |
|---|---|---|---|
| Occasional operator | 60 hours | 18,000 CZK | 23,400 CZK |
| Standard administrator | 119 hours | 35,700 CZK | 46,400 CZK |
| Catalogue manager | 298 hours | 89,400 CZK | 116,200 CZK |
A team of five made up of two operators, two administrators and one catalogue manager waits 657 hours a year. That is 197,000 to 256,000 CZK paid out for watching a loading spinner. Every year. Without a single invoice you could dispute.
And that is still only the visible part.
What the research says
This is not marketing theory invented to sell websites. The link between system response time and operator productivity is one of the best documented effects in human computer interaction. It was being measured back when people worked on terminals.
The one second limit
Jakob Nielsen of the Nielsen Norman Group summarised three thresholds of how people perceive response time, unchanged since Miller's research in 1968.
- 0.1 seconds. The user feels the system reacts instantly and that they manipulate objects on screen directly.
- 1 second. The limit within which the flow of thought stays unbroken. The delay is noticed, but the thread is not lost.
- 10 seconds. The limit of keeping attention. Beyond it the user turns to something else and has to find their place in the task again afterwards.
Nielsen adds one point that matters for the web: for a user to feel they are moving through a system freely, a new page has to appear within one second. With slower responses people click through fewer screens.
Notice where your four seconds sit on that scale.
Four seconds is exactly the band where the user does not leave yet, but is no longer in flow. The worst possible place to be
IBM: productivity does not rise linearly, it rises faster
In 1982 Walter J. Doherty and Arvind J. Thadhani published a study in the IBM Systems Journal called The Economic Value of Rapid Response Time. At its core is a finding cited today as the Doherty threshold: when a person and a computer interact at a pace where neither waits for the other, productivity rises sharply, the cost of the work done falls and the quality of the output improves as well.
The key point of the study is this: productivity rises faster than the drop in response time. Until then it was believed that a two second response did no harm, because the user was thinking about the next step anyway. The data showed otherwise. People hold a sequence of steps in short term memory and waiting breaks it, so after every delay they have to go back to the plan.
The specific figures are worth listing.
- Transactions per hour. At a 3 second response a user managed roughly 180 transactions an hour, at 0.3 seconds they managed 371. Cutting the response by 2.7 seconds saved 10.3 seconds of the user's time, not 2.7. The rest is the mental restart.
- The task grows more than the response. At the computing centre of the National Institutes of Health rising load pushed the response to an average of 4 seconds, and the average length of one work task grew from 32 to 48 minutes. Users spent 22,500 more hours a month at terminals without producing more work.
- Quality, not just speed. A programming team in Portsmouth had its response time improved from 2.3 to 0.84 seconds. The project finished four weeks early and used 39 percent fewer person months. Error reports fell from 6.9 to 3.0 per hundred function points, less than half.
- It holds for clerical work too. A critic might object that this concerns engineers and programmers. So the study also covered staff planning component stock, work very close to receiving goods and running a catalogue. At a usual response of five seconds or more they averaged 99 transactions an hour, at under one second 336.
Doherty and Thadhani set 400 milliseconds as the target, against the two seconds accepted at the time. In forty years hardware has become orders of magnitude faster. Yet the real response time of large shop admins still sits above two seconds in plenty of operations, because software ate all of it.
Cutting the response by 2.7 seconds saved 10.3 seconds of the user's time. The difference is the mental restart that waiting charges on top
The hidden costs that never show up in hours
Time on a stopwatch is only the visible tip. Below the surface are four effects that are harder to count and hurt more.
Broken concentration
The brain treats a response under one second as a smooth continuation of its own activity. At four or five seconds attention wavers, and four seconds is exactly the interval in which a person can switch to chat, email or their phone but cannot get anything done there.
Coming back to the original task then does not cost those four seconds. It costs tens of seconds more, because the context has to be rebuilt: which product was I on, what price did I mean to set, how many units did I still have to receive. The psychologist Sophie Leroy named this effect attention residue: part of your attention stays attached to the previous activity even after you have left it.
The IBM data describes exactly that. Saving 2.7 seconds of system response returned 10.3 seconds of the user's time, almost four times as much. That difference is the mental overhead waiting creates.
More mistakes
A slow system changes how people behave, and not for the better.
- They open ten tabs at once so they can wait in parallel. Then they lose track of which tab held which product.
- They rush to make up the lost time. They do not check what they are saving.
- They pile work into batches and do it tired at the end of the day instead of as it comes.
- They avoid verifying. When checking means another four second load, the check simply does not happen.
Across fifty thousand variants that means typos in prices, wrong product codes, swapped attributes, incorrect stock. Each of those costs either margin on a wrong price, or a return and postage on a wrong variant, or the customer's trust.
With a fast response the Portsmouth team at IBM produced less than half the error reports of a comparable earlier project. Speed is not only about speed, it is also about accuracy.
It multiplies across the team
The loss does not add up, it multiplies. Three to five people in the admin means 300 to 1,000 hours a year burnt on waiting, roughly 90,000 to 390,000 CZK depending on wage costs.
Then the season arrives. At Christmas you hire temporary staff who are slower in the system simply because they do not know it, and their inexperience is compounded by the slowdown from higher server load. At the exact moment you need to ship three times the orders, the system gives you its worst response time of the year.
And one more cost: people
This one appears in no table at all. Working in a slow system is tiresome. A catalogue manager who spends an hour and a half a day watching a spinner does not feel they are doing meaningful work, they feel they are fighting the tool. Doherty and Thadhani list higher employee satisfaction with their own work among the explicit benefits of a fast response. Turnover in a role where a person has to learn your catalogue costs tens to hundreds of thousands of crowns.
Why admins are slow
So that this article is not only about numbers, here are the real causes behind a slow admin on a large catalogue. If somebody offers to fix them with better hosting, they are offering you an aspirin for a broken leg.
An admin cannot be cached
A public product page can be generated once and served a thousand times from cache. The admin has no such option by definition, it needs the current state. Every click therefore means a full pass through the application and fresh queries to the database.
That is why on a shop that has outgrown its technology the admin slows down first. It is the most sensitive warning signal available to you, and most owners ignore it because the customer cannot see it.
A data model that was never built for a catalogue
The most widespread open source solutions store product properties in an EAV model, meaning entity, attribute, value: every property is a separate row in one big table. In WooCommerce that is the wp_postmeta table, where one product commonly generates dozens of rows and a variable product can have hundreds.
The result: a product list that has to show price, stock and product code and let you sort by price must join several tables together, and the database cannot use its indexes efficiently while doing it. Developers in the WooCommerce issue tracker describe the product listing query alone stretching into seconds on catalogues above ten thousand items.
This is nobody's individual fault. It is the consequence of using a general purpose content system as a transactional product database. The flexibility that is excellent at a thousand products becomes the brake at fifty thousand.
Other typical causes
- An extra query per row. Listing a hundred orders fires one query for the list and then a hundred more for customers, a hundred for items, a hundred for shipping. Instead of three clever queries, three hundred go out.
- Missing or wrong indexes. The database walks the whole table row by row, because nobody told it where to look.
- Filters computed on the fly. Every time the list opens it recounts how many products sit in which category, brand and price band.
- Add-ons. In ecosystems where features arrive as modules, every module loads on every single admin request. One badly written add-on can add one to three seconds to every click on its own.
- Bulk operations inside one request. Repricing five thousand items tries to finish within a single request and dies on the timeout. It belongs in the background, in a queue.
- Undersized infrastructure. Shared hosting with a slow disk and a database without enough memory for cache. On a catalogue that does not fit in memory, every query becomes a read from disk.
- Images processed while you wait. Ten product photos are resized into every format while the user stares at a spinner. This belongs in the background too.
How to tell whether your admin is holding you back
Take a stopwatch and run these seven tasks in your own admin, ideally on a Tuesday morning rather than a Sunday evening.
- 1Opening the product list, first page. Target under 1 second.
- 2Finding a product by part of its name. Target under 1 second.
- 3Opening a product with twenty variants. Target under 1.5 seconds.
- 4Saving a price change on a single variant. Target under 1 second.
- 5Opening the order list filtered to unpaid. Target under 1 second.
- 6Jumping to page fifty of the product list. Target under 1.5 seconds.
- 7Bulk changing the category on five hundred products. It has to run in the background and must not freeze the screen.
Items six and seven are the diagnostic ones. If page one flies and page fifty takes ten seconds, your problem is the data model, not the hosting. And it gets worse as the catalogue grows.
One follow up question tells you the most: how many people in your company keep a second tab open while working in the admin? If most of them do, the system is slow. They did not get used to it, they worked around it.
How I build fast admins
Here is my answer to all of it, and it will not please everyone, because it is not „we will install a template“.
I write bespoke solutions, with my own code and my own data model. Not because I want to reinvent the wheel, but because on a catalogue with tens of thousands of variants the data model is the one thing that really decides speed. And in an off the shelf system it cannot be changed.
In practice that means:
- A database designed for your catalogue. Products, variants and attributes in structured tables, with indexes built for the queries your team actually runs. No assembling one product out of fifty rows of a universal table.
- Your own server, your own control. Running on dedicated capacity, with a database that has enough memory to keep your working data in RAM. No neighbours taking your performance on a Monday morning.
- An interface that asks only for data. The admin is a separate application and a click does not fetch a whole page, only a few kilobytes of data. The difference between three seconds and two hundred milliseconds usually lives right here.
- Instant feedback. A price change appears in the table immediately and travels to the server in the background. The user does not wait for confirmation before carrying on. This is the cheapest route below the Doherty threshold of 400 milliseconds.
- Work in the list, not across ten screens. Editing price, stock and state right in the row, bulk edits over a selection, keyboard shortcuts. The goal is to cut the number of actions, not only to make one faster. That is the second half of the equation from the table above and in practice the more rewarding one.
- Long operations in the background. Imports, repricing, variant generation and photo processing go into a queue. The user watches the progress and does something else meanwhile. Nothing dies on a timeout.
- Search and filters on something built for them. Full text and faceted filtering through a search engine, not through dozens of joins in a relational database.
- Measurement in production. I collect response times for the key screens. When a slow page shows up, I know about it before your team does and I know why.
Objections I hear
It is only a few seconds, surely we can live with that?
That is exactly why it is expensive. If it were five minutes you would have dealt with it long ago. A cost that is negligible on its own and repeats six hundred times a day is the hardest kind of cost to spot in a company. Go back to the table showing 119 hours a year for one single person.
Would a more powerful server not fix it?
Sometimes it helps, when raw capacity really is the bottleneck. But if the product list is assembled from thousands of small queries because of the data model, a processor twice as fast gives you a bad approach running twice as fast. Four seconds become two and a half. The target is 0.3 seconds and you will not get there by doubling the hardware.
Is an off the shelf system not cheaper?
On the purchase price, almost always. The question is what happens in year three, once the catalogue has grown. A team of five that waits 657 hours a year burns 600,000 to 770,000 CZK over three years, and that is the waiting alone, without mistakes, without turnover and without the conversions lost on the customer side. A bespoke system is therefore not a cost item but an investment with a return you can calculate.
How do you even measure admin speed when it sits behind a login?
The simplest route is a stopwatch and the seven tasks described above, which anyone in the company can run in ten minutes. A more precise answer comes from measuring inside the application itself, recording response times of the key screens for real users. Public tools such as PageSpeed Insights cannot get past the login, so they do not work on an admin.
Can I tell from the behaviour whether the problem is the data model or the hosting?
Fairly reliably. If the first page of a list opens quickly and page fifty slowly, it is the data model and the way paging is done, because both run on the same server. If everything including the login is uniformly slow, the infrastructure is the more likely suspect. The final answer comes from looking at the queries, though, the behaviour is only the first clue.
And yes, the customer sees it too
Admin speed and public site speed are usually not two separate things. They share the same cause, the data model and the architecture. Fix that and both improve. And on the customer side the data is harder still.
A Deloitte and Google study called Milliseconds Make Millions analysed real traffic from 37 brands across Europe and the United States. Improving mobile site speed by a single tenth of a second brought retail 8.4 percent higher conversions and a 9.2 percent higher average order value, and travel 10.1 percent higher conversions.
One tenth of a second. In your admin you are dealing with a difference thirty times larger.
Summary
- An admin cannot hide behind cache, which is why it slows down first and is the best warning signal that a shop has outgrown its technology.
- The difference between a four second and a 0.75 second response is 60 to 300 hours a year per person, meaning 1.5 to 7.5 working weeks.
- For a team of five that is 200,000 to 260,000 CZK a year on waiting alone, before you add mistakes and turnover.
- Research from 1968 to today says the same thing: the limit of uninterrupted work is one second, the target threshold is 400 milliseconds, and productivity rises faster than the response time falls.
- Speed is not a hosting question but a data model and architecture question. And that is decided at the start of a project.
Want to know what it costs you specifically
I offer an admin speed audit. We measure the real response times of your key screens, count how many actions your team makes a day, and you get a concrete figure in crowns per year, along with what causes it and what can be done about it.
If the audit shows that optimising what you already have is enough, I will tell you so. And if it shows it is time for a system of your own, you will know exactly how long it takes to pay for itself.
Write to me and we will arrange a no obligation consultation.
Sources
- Nielsen, J.: Response Times, The 3 Important Limits, Nielsen Norman Group
- Nielsen, J.: Powers of 10, Time Scales in User Experience, Nielsen Norman Group
- Doherty Threshold, Laws of UX
- Doherty, W. J., Thadhani, A. J.: The Economic Value of Rapid Response Time, IBM Systems Journal, 1982, full text published with IBM's permission
- Why wp_postmeta Slows Large WooCommerce Stores, Webkul
- Slow on 100k+ Products, WooCommerce, issue 11913
- WooCommerce Admin Slow, 6 Fixes That Actually Work, WPBundle
- WooCommerce Admin Slow, 5 Signs to Watch, Woosa
- Minimum, average and guaranteed wage 2026, Accace CZ
- Milliseconds make millions, web.dev, Google