Rebuilt the front end
A custom WordPress theme: one stylesheet, one small script, self-hosted fonts, no jQuery except on the booking page where the plugin needs it. The homepage went from 238 KB to 33 KB of HTML.
Case study · client project
Apartment Jestrab
A mountain apartment in Janské Lázně, Czech Republic. It rents through its own site and through Booking.com, in four languages. The site worked — it was just slow, and the owner knew it. This is what I changed and what it measured, before and after.
The result first
Twice the speed score, a seventh of the code.
- 73 → 93
- Google PageSpeed, mobile
- 85 → 98
- Google PageSpeed, desktop
- 7.2 s → 1.7 s
- Speed Index on mobile — how long until the page looks done
- 238 KB → 33 KB
- homepage HTML, as served
- 14 s → 0.15 s
- worst measured load time for a single gallery photo
- 5 min
- total downtime for the server migration
Before: PageSpeed Insights on the live site, 16 August 2026. After: Lighthouse 12, medians of three runs on the same live site, 24 August 2026, after the rebuild, the server move and the CDN.
Before / after
Same photos, same words, same booking system.
Drag the handle. The content is identical — the owner's copy and the owner's photographs, moved onto a layout that gets out of their way.
What was wrong
Three separate problems wearing one coat.
"The site is slow" turned out to be three unrelated causes. Measuring first meant fixing the right ones, in the right order.
- A page builder shipping 238 KB of HTML. Divi inlined 154 KB of CSS into every single page — two thirds of the document — including a full Google Fonts stylesheet with every weight of two families, re-downloaded on every page view because inline CSS can't be cached.
- An overloaded server. Static files came down at 100–300 KB/s; a 20 KB cached page once took 11.7 s. I documented it and sent the measurements to the host, who confirmed the cluster was overloaded and moved the account to a healthier machine.
- Images built for desktops only. Every phone downloaded full-width photos, and the hero image was a CSS background — invisible to the browser's preload scanner, so it only started downloading 1.3 s into the page load.
What I did
A theme written by hand, and nothing else touched.
Left the money alone
The paid Booking Calendar plugin, the hourly Booking.com availability sync and the contact mailing all kept running untouched — a live site with real reservations is not the place to rewrite what already works.
Four languages, properly
Czech, English, Polish and German, each with its own text file. I audited every page for Czech leaking into translations, and the site now picks the visitor's language from their browser — cache-safe, so it works on cached pages too.
Fixed the delivery
Migrated to a healthier server (5 minutes of downtime), put a free CDN in front so photos come from the nearest edge, and generated every photo at three widths so a phone never downloads a desktop-sized image.
Measured, not asserted
Every number here came from a tool, not a feeling.
One honest note: the booking page scores 86 on mobile rather than 93. A live availability calendar can't be cached ahead of time, and the plugin brings its own jQuery. I left it that way on purpose — a working booking system beats two points.
Want the same treatment for your site?
I measure first, tell you what's actually slow, and rebuild only what needs it.