"Slow" is three different problems
A screen that takes half a second is waiting on the work, the distance, or the drawing. They have three different fixes, and guessing which one costs a week.
"The orders screen is slow." Everyone has said it. Almost nobody follows it with the only question that leads anywhere, which is: slow doing what?
A screen that takes half a second to appear is spending that half second in three quite separate places, and they have three quite separate fixes. Until you know the split, any change you make is a guess, and guesses on performance have a habit of being expensive and useless at the same time.
The three
The work. Somewhere, something is looking things up: counting today's orders, finding which dishes have no photo, checking whether the venue is open. That takes however long it takes.
The distance. The question and its answer have to travel. Between a laptop in Hampshire and a database in Virginia that is about ninety milliseconds a round trip, and it does not matter in the least how simple the question is. A question so easy the answer is already known still costs the journey.
The drawing. Once the answer arrives, the device has to put it on the screen. A phone three years old does this noticeably slower than the machine it was designed on.
Why the split changes what you do
Here is a real one from our own back office. A page that took about 520 milliseconds for a returning user. Split: roughly 250 milliseconds of actual work at our end, about 200 of travel, about 70 of drawing.
Now: if you had guessed, you would probably have gone after the work — it is the biggest number, and it is the part you control. But look again. That 250 milliseconds of "work" was itself mostly travel, because the work was three separate questions asked one after another, each one waiting for the previous answer to come back across the ocean before it could start. The actual thinking was a few milliseconds. The rest was distance, counted twice.
So the fix was not to make the questions faster. It was to ask fewer of them separately. We got one of the three journeys removed this week by folding a question into a trip that was already being made.
Had we optimised the queries themselves — the obvious move, the one that feels like engineering — we would have shaved a few milliseconds off a few milliseconds and reported an improvement nobody could feel.
Getting the split without instruments
You do not need our tooling to do this on your own operation. The same three-way split applies to any process that feels slow, and you can usually estimate it with a stopwatch and some honesty.
A guest waits eleven minutes for food. How much of that is cooking, how much is the ticket sitting in a queue, and how much is it waiting on the pass for a runner? Those are the work, the distance and the drawing. Buy a faster grill and you have attacked the first one — which may be four minutes of the eleven.
A stock order takes an hour to place. How much is deciding what to buy, how much is finding the numbers to decide with, and how much is typing it into three suppliers' websites? Very often the decision is ten minutes and the hunting is forty.
Measure first, and say what you measured
The rule we try to hold ourselves to: do not improve anything you have not first split. And when you report the result, say which part you changed and which part you did not, because the number on the outside will not move as much as the number on the inside and somebody will notice.
Our page is faster than it was. It is still over the budget we set ourselves, because the distance is still the distance, and that is a different decision about where our database lives. Saying so is better than pretending the job is done.