lucas/anywhere

Case study, client project

Apartment Jestrab

A mountain apartment in Janské Lázně, Czech Republic. I built its website at the end of 2025, then rebuilt it for speed in 2026. This page is mostly about the second part: what I changed and what it measured, before and after.

apartmanjestrab.cz → WordPress · Polylang · Booking Calendar · 2025–2026

Late 2025 · version one

The site and the booking system

The full site, built in Divi so the owner could start taking bookings quickly. Four languages, and a booking calendar with my own Booking.com sync: a scheduled job keeps bookings matched in both directions, so the apartment can't be double-booked. Plus the print side: a poster and business cards for the apartment.

2026 · version two

The speed rebuild

The page builder had made the site slow. I rebuilt the front end by hand and left the booking system running untouched. The rest of this page is that rebuild.

Business cards for Apartmán Jestřáb: a white front with the gold AJ15 monogram and the tagline U nás je nejlíp, and a back with the apartment's contact details and a QR code.
The print side: business cards for the apartment, front and back. Czech tagline: U nás je nejlíp, "it's best at our place".

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.

apartmanjestrab.cz/en
The rebuilt homepage: warm oak palette, large photography, key facts on a card overlapping the hero.
The original Divi homepage: grey type, a flat inline fact bar, the same hero photo.
Before · Divi After · hand-coded

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.

  1. 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.
  2. 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.
  3. 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.

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.

Kept the booking system running

The booking calendar, my Booking.com sync and the contact mailing all kept running untouched through the whole rebuild. A calendar holding real reservations is not the place to experiment.

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.

Homepage HTML
238 KB 33 KB
Inline CSS inside that HTML
154 KB 0 KB

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.

Start a project See other work →