The columns the screen never reads
The Menu screen was one hop deep and three reads wide, and still slow from London. It was carrying 197 KB of columns it reads four fields from.
Two mornings ago the back-office Menu screen was the worst row on our speed board with enough loads to trust: five opens, just under a second and a half on average. We had already fixed that screen once that week, and the board showed the fix had landed, because the call that used to be slowest had dropped off the list. What was left at the top was the dish list, the call the Menu screen uses to put a cost and a margin beside every item.
We have a test that pins how deep that route is. It waits on the database once after the front door, and it has done since the spring. It makes three statements, which is not many. By the two measures we had been using all week, depth and width, there was nothing to take. From this side of the ocean, sitting beside the database, it answered in thirty milliseconds. From London it was taking a thousand.
Bytes are the third measure
The route reads every dish in the company with every column on the row: the description, the thumbnail, the channel overrides, the price groups, the notes on why a cost is what it is. Then it reads every ingredient line, joined to its product's name and code and unit. All of that comes out of a database in Virginia and crosses to a worker in London, which adds it up and hands the screen four cost fields per dish. The answer the Menu screen received was 197 kilobytes for 183 dishes.
Months ago somebody had noticed the screen did not need the ingredient lines and added a brief mode that deleted them, along with the placeholder images, before the reply went out. That was a real saving on the wire to the browser. It was no saving at all on the read, because the deleting happened after the columns had already made the trip from the database.
Trim at the source, not at the door
Brief mode now names its columns. Eight on the dish, four on the ingredient line: the id, the name, which venue and company it belongs to, what it yields, its sell price, and for each line the product, the quantity and the cost. The arithmetic that walks house-made products inside other recipes is the same code, and the nine cost fields it produces are the same figures. The reply is 61 kilobytes for the same 183 dishes. The Recipes screen and the menu-engineering report ask without the brief flag and get the full row, which is what those two screens are for.
A test runs both modes over a seeded kitchen, a salsa made ten portions at a time inside a taco, a dish with an unpriced product, fries with no lines, and asserts every cost field matches between them while the brief reply carries no description and no ingredients and the brief statement contains no select-everything. One of the first drafts of that test compared a response object to a menu because a wait was missing. The harness caught it before the code did.
Beside the database the change is barely visible, a few milliseconds. That is expected and it is not the claim. The claim is that a wide result crossing to a London worker was what made the screen slow there, and the only thing that confirms it is the next real load of that screen from London. The board will say.