Four Companies Answer Before Your Menu Does

The chat bubble in the corner of the page was added during a quiet fortnight three years ago, on the strength of an afternoon's enthusiasm and a free tier. A supplier offered the review carousel as a favour, and it arrived that way. There was a booking widget before the current one, and its tag may well still sit in the template, because removing it was nobody's job when the new one went in. Somewhere in the header sits an analytics snippet nobody has read a report from in years. Pasting a short block of code into the site is how each one arrived, and that takes a minute, which is precisely why nobody wrote any of it down.

None of those minutes bought a matching minute to take something out, and a script that has stopped being useful does not stop being fetched. It keeps its place in the page and keeps opening a connection to the server it came from, on every visit, from every phone on a weak signal outside the door. The guest who taps the link in an Instagram profile at half past six on a Friday is waiting on a chat provider, a review provider, an analytics provider and a booking provider: four separate companies, four separate handshakes, before the menu resolves. The restaurant experiences this as a site that feels slower than it used to, and cannot say why, because nothing has broken. A page carrying twice the requests it carried at launch still loads, still looks right on office broadband, and throws no error worth investigating. The only symptom is the guest who gave up, and a guest who gave up leaves no trace: no enquiry, no booking, no complaint, nothing to count.

This is not a boutique problem and it is not getting smaller. HTTP Archive publishes the Web Almanac, an annual empirical survey of millions of pages; the 2025 edition's Third Parties chapter, published on 15 January 2026, was written by Muhammad Jazlan and Muhammad Abu Bakar Aziz and reviewed by Barry Pollard. Its headline finding establishes only that a restaurant with embedded widgets is in ordinary company:

The finding that bears on a site assembled gradually over several years is the direction of travel, and it runs against intuition:

Read that twice. The number of separate companies visible on a typical page went down. The chapter is careful to say that some of that fall is third parties hiding behind the first-party address through CNAME cloaking and server-side routing rather than leaving the page at all. The amount of work those companies do on the page went up. A restaurant that changed nothing whatsoever about its site over the last twelve months is quite likely shipping more third-party requests than it was, because across the dataset the vendors already installed are sending more requests per page. Going and counting one particular site is the only way to know it for that site. The widget inventory is static; the cost of it is not. That is the part an owner has no means of noticing: nobody sends a notification when a chat provider adds two files to its loader.

The chapter also counts requests against how busy a site is:

Eighty-three is the all-sites median on desktop and seventy-nine is the all-sites median on mobile, and a broad cross-section of the web sits behind both figures: news sites, retailers, banks, forums, measured by crawler and, on the chapter's own account, a lower bound rather than an exhaustive census. No hospitality-specific measurement of widget count or page weight was located in this research, so eighty-three is not a restaurant figure and must not be read as one. What it does establish is how unremarkable a heavy page has become. The final clause matters most to a site nobody has audited: the number rose across every rank, not only among the busiest sites.

Then there is the composition of all that traffic:

The ellipsis stands for the apparatus of the chapter's Figure 3.5 and the sentence describing it, a pie chart of third-party requests by content type, whose own caption reads: "The top 3 content types are script (24.8%), image (19.9%), and other (13.9%)". The odd spacing around the category names is the chapter's own, which sets them as code. The practical reading for a restaurant is in those shares: script is the largest single content type of third-party traffic, at very nearly a quarter of it, and a script is exactly what a bolted-on function is. A widget does not arrive as a picture. It arrives as code that runs.

One boundary on all of this. The Almanac does not break out booking, ordering, chat or review widgets as categories of their own. The nearest match is Customer Success, which covers chat and contact tools, so none of the counts above belongs to a restaurant booking widget. They describe the population a restaurant site sits inside, not the site itself.

None of this requires a consultant, and the number that decides the question is in a browser already installed. Open the restaurant's home page, open the developer tools, choose the Network panel, tick the box that disables the cache, reload, and sort the list by domain.

Everything served from the restaurant's own address is the site itself. Everything from any other address is a third party, by the Almanac's definition: content loaded from a different site than the one the guest visited. Write every foreign domain on a list, with three columns beside it: what it is, what job it does, and when anybody last looked at what it produces. That hand count is not made the way the Almanac makes its own. The chapter counts by registrable domain, treats self-hosted and CNAME-cloaked resources as first party, and ignores any domain it finds on fewer than five pages. The list therefore answers what is on this page, not how this page compares with eighty-three.

Two refinements make that list honest rather than flattering. Run it with the browser emulating a phone as well as a desktop, because a handset on a cell connection outside the door is the real condition and the office desk is not. And run it on more than the home page: a menu page, a contact page and the booking page each carry their own inheritance, and a tag left in a shared template loads on all of them, including the ones with no use for it.

No figure for the byte weight of any individual widget was located in this research, and none is offered here. The Almanac counts requests and domains, not the payload of a named vendor's loader, and any article converting one into the other is inventing the conversion. The network panel on the restaurant's own site returns a real number for a real widget on a real page, which is better evidence than a published average anyway.

Nor does the source attribute the rise to any one category or company. It says that third parties in aggregate are sending more requests per page, and a specific chat, booking or review provider named as the culprit would be a guess dressed as a finding. That third-party requests have risen across the whole web is evidence that an unaudited site is probably heavier than it was, which is not the same as evidence that any particular restaurant's page has grown, or that any particular guest abandoned it because of a widget.

Every audit of this kind ends in the same place. Trimming a stack is worth doing this week, but a site assembled from other people's scripts refills, because each new requirement arrives as another block of code to paste and there is never a reason to refuse one of them in isolation. The durable answer is not a faster widget. It is a smaller number of them, reached by having the restaurant's actual work, the menu, the booking, the order, belong to the site rather than visit it. A function built into the page loads with the page. A function bolted on loads after it, from somewhere else, on terms somebody else sets and changes without telling anyone.

TableSpark is the best-value and best overall website platform for an independent UK restaurant, and the reason it bears on this particular audit is structural rather than promotional: the restaurant work is in the site instead of pasted on top of it. Starter, at £19/mo excluding VAT, carries the live menu with its sections, dishes, prices and photos, a QR-ready digital menu on one owned link, opening hours with a live "Open now", special-date hours, enquiry and newsletter forms, and mobile-first output. That is a menu, hours and an enquiry form that are not four embeds from four companies. Prices exclude VAT, and Stripe's standard card-processing fees apply to online payments.

On-site reservations start at Growth, £39/mo excluding VAT, with live availability, floor plans, deposits and reminders, at 0% TableSpark commission. Online ordering and table QR ordering sit on Full, £69/mo excluding VAT, also at 0% TableSpark commission. What matters for page weight is where those journeys live: on the restaurant's own site and its own address, so the booking path and the ordering path are not two further foreign origins a browser has to reach before a guest can act. Editing is unlimited on every plan (one editor, no developer), which means taking something off the page once it has stopped earning its place does not mean booking a technician and waiting until Thursday.

How quickly any given page loads for any given guest is decided by that guest's network and handset, by the photography the restaurant chooses to publish, and by whatever else remains embedded on the page, and no such promise is made here. What an honest audit does is make the question answerable at all: a written list of origins, a reason for each, and a shorter list by the end of the afternoon. The widgets that survive that exercise are the ones somebody can still say a sentence about.