A guest couldn't open our booking page. Here's what we fixed that night.
The thread on Sunday 14 September: the guest's screenshot at 7:13 PM, the fix message at 12:03 AM.
At 7:13 on the evening of Sunday 14 September a guest messaged Mara Hilltop, our lodge in the Maasai Mara, with a screenshot. Chrome on his iPhone, an error page in Spanish, and an apology for the Spanish. He had picked his dates on marahilltop.com and pressed Continue, and the page died. He tried again and it died again. That, he said, was why he was writing to us on WhatsApp at all: he couldn't go forward on the website.
I couldn't reproduce it on my laptop, which I think is how most booking-page problems stay unfixed: the owner checks on a desktop, it works, and the guest on a phone gives up and books somewhere else. This one got fixed that night, and fixing it turned up a second problem that had been making every screen in KaribuKit, the software we build and run the lodge on, slower than it should be.
Why his phone gave up
The error he sent is what an iPhone shows when a page has used so much memory that the browser kills it, twice in a row. Our booking page was the reason. It loaded the original camera files for every room photo, and the moment the rooms appeared it fetched the full gallery of every room type, whether the guest opened a gallery or not. I downloaded the same 36 files the page pulls and measured them: 47 MB to download, and 3.9 GB once a phone unpacks them into pixels to draw them. Fifteen of the photos are 8,000 pixels wide or more. One tent interior on its own is 186 MB unpacked.
A laptop has the memory to hide that. A phone does not.
The fix was ready before the guest wrote. We had hit the same crash on a different page in August and written the change: serve resized copies of each photo instead of the originals, and stop preloading galleries nobody asked for. It sat unmerged for nineteen days because my own notes said it was done. It went live that night. The page now loads no original files at all, and the largest image on it is 1,024 pixels wide.
The second problem, which was worse
While checking the fixed page I timed the availability request, the call that asks the system which rooms are free for the guest's dates. Ten seconds. Not on a slow connection in the Mara either, but on the server itself.
The cause was one line of database setup, wrong since launch week in March. Because of it, every question the system asked the database took about a quarter of a second instead of the fifty milliseconds it should. The booking page asks 38 questions in a row to build one availability result: six room types, and for each one, is a room free, what is the rate, are there overrides for these dates. Thirty-eight quarter-seconds is where the ten seconds came from.
We had measured that cost in March, four days after go-live, and blamed the distance between the server and the database. We then spent months trimming how many questions each screen asked, which helped, without touching what each question cost. The engineering version, with the database statistics and the exact setting, is on the SimbaStack blog: Every database query cost us four round-trips for six months. The owner's version is that the fix was one setting, changed at 23:40 Nairobi time, with no code touched.
What changed
Medians from the system's own logs, the three days before the change against the eighteen hours after it:
| Screen | Before | After |
|---|---|---|
| Booking page availability (what the guest waits on) | 8.1 s | 1.9 s |
| A reservation's history | 1.7 s | 0.7 s |
| Guest folio (the bill) | 1.4 s | 0.4 s |
| A reservation's overview | 1.3 s | 0.4 s |
| Today's arrivals and departures | 0.9 s | 0.5 s |
| Calendar | 0.6 s | 0.2 s |
Nothing else changed: same server, same code. The setting is shared, so every screen got it at once, not just the booking page. Next is asking those 38 questions at once instead of one after another, which should put the booking page under a second.
How to check your own booking engine in two minutes
You don't need a developer for this.
- On your phone, on mobile data rather than the office wifi, open your own website and go through to the point where you pick dates and see rooms with prices. Count the seconds from tapping Continue to seeing rooms. Under three is where I'd want to be. Ours was eight, and the guest who wrote to us got a crash instead of a room list at the end of it.
- Open a room's photo gallery and swipe through it. If the phone gets warm, the page reloads itself, or each photo takes a second or two to sharpen, the page is loading original camera files.
- Ask your vendor for the number. Any system can log how long the availability call takes. "What was the median availability response time for my property this week" is a fair question, and if your vendor can't produce the number for your property, that is itself the answer.
Borrow a phone that isn't yours for step 1. The phones that fail belong to guests, and the one that failed here had 81 tabs open.
What this doesn't prove
Running our own lodge on the software didn't stop us shipping an eight-second booking page to our own guests for six months. It got caught because one guest bothered to message, and we had lived with the second problem the whole time without finding it. It doesn't prove the software is fast now, only that most screens are three to four times faster than they were last week, and the one the guest waits on 4.3 times; under a second is the target and we are not there. And I don't know whether he booked. He had a reply at 7:14, the page fix was live that night, and he had a message saying so at 12:03 AM.
If you run a lodge in Kenya and want to time our booking page against yours, message us on WhatsApp via karibukit.com. We'll show you ours first.
— NJ
NJ runs Mara Hilltop, a lodge in the Maasai Mara, and builds KaribuKit, the property-management system it runs on.