The website took ten days, and then the work began

What comes after handover

The build was the predictable part: the material was there, the structure was there, and after a few emails the final layout was too. It took ten days, from the first email to the site being published for search engines.

After that, something kept coming up. The domain and hosting expire, the seasonal events list changes, browsers update, and now and then an email arrives that someone has to judge — serious or not. Since the launch this kind of work has added up to far more than the original build.

It does not mean daily attention. The owner writes when something is needed, and I look at it then — up to July 2026 that was a handful of occasions a year, spread fairly evenly.

A search campaign also ran for the launch, from the summer of 2025 to October. The first weeks were not about bookings but about filtering out the enquiries that had nothing to do with the property — there is more on that below, in the technical part.

When a bug refuses to show itself

In the spring of 2026 the page stuttered while scrolling, and here and there a light patch flashed where a photo should have been. The photos here show the rooms and the terrace — the very thing a visitor came for.

The problem never appeared in an automated browser, only during real use. After three attempts that did not solve it, I changed direction: I wrote a small measuring script that records, in the real browser, what happens during scrolling. Instead of guessing there was now data, and the data pointed to four separate causes — no single one of them would have explained the problem alone.

What this means if your situation is similar

If you run a holiday rental and bookings come through portals, a website of your own is not about replacing them. It is about having one place that you own, where there is no commission, and where there are as many photos and as much description as you see fit.

And you do not have to write the content from scratch. Most of the text already exists, just elsewhere: for this property I collected the amenities, the nearby sights and the services from the existing portal listings, and we started from there. What the owner actually had to produce was the photography.

The website

One page, seven galleries

The property sits on a single scrolling page, with galleries by location: bedrooms, living room, two bathrooms, kitchen, terrace and cellar. The owner asked for this structure — she wanted the simple layout of another rental site she knew, with few menu items.

The price of the gallery structure is that the front page carries many images at once. Most of the later performance problems trace back to this.

An email address on the domain

Alongside the website, an email address was set up on the domain, forwarded to the owner's existing mailbox. A guest writes to the property's address, and the message lands where the owner already reads mail — no new account to manage. On the evening before handover, two test messages arrived through the form: “próba” — Hungarian for “test” — and then “Mobilpróba”. Both landed within seconds.

The five text fields of every image

For every uploaded photo I filled in all five of WordPress's text fields: the file name, the alt text, the title, the caption and the description. This is partly an accessibility matter, and partly how search engines learn what a picture shows — and for a holiday rental, image search is a real source of traffic.

The search campaign that ran for the launch

The campaign ran from the summer of 2025 to October, and brought 10,228 impressions and 514 visits at an average of HUF 157 per click. In the first weeks, though, phone calls also came in that had nothing to do with the property: people looking for long-term housing, calls in the middle of the night, callers who had not checked which town the place was in. The system starts out with a broad idea of when to show the ad.

The narrowing was done with negative keywords, based on the actual searches. It turned out, for instance, that many people added “forest”-type words to their query, and those searches were not worth appearing for. This work cannot be done in advance, because there is no knowing beforehand what people will type. The campaign stopped in October; the site has run without ads since.

What the scroll measurement showed

Three guesses first, then measurement

My first three fixes were based on assumptions, and each was reasonable. I turned off lazy loading for the images, because that looked like the most obvious explanation. I turned off a page-transition effect that sometimes got stuck above the content. I capped the image sizes. The stutter shrank, but it did not go away.

At that point measuring beat more guessing. The measuring script only switches on when I add a flag to the page address, so visitors are not affected. While scrolling, it records frame timing, tasks blocking the main thread for more than fifty milliseconds, layout shifts, image loading events and GPU details. When a frame is noticeably slow, it also stores what is at the centre of the screen — so there is no guessing afterwards about which element caused it.

1. Measurement starts with a ?debug=1 flag in the page address — visitors never meet it.
2. From the first scroll it records frame timing, tasks blocking longer than 50 ms, layout shifts and image events.
3. On a noticeably slow frame it also stores what sits at the centre of the screen.
4. After ten seconds of scroll silence it saves the recording to the server on its own.

// WP core hook — runs whenever image attributes are generated.
add_filter(
    'wp_calculate_image_sizes',
    static fn() => '(max-width: 768px) 50vw, 25vw',
    PHP_INT_MAX
);

// Elementor and attachment image attrs may carry sizes too — override there as well.
add_filter(
    'wp_get_attachment_image_attributes',
    static function ( $attr ) {
        if ( isset( $attr['sizes'] ) ) {
            $attr['sizes'] = '(max-width: 768px) 50vw, 25vw';
        }
        return $attr;
    },
    PHP_INT_MAX
);

Four separate causes

The measurement showed this was not one bug but four, and they reinforced each other. That is why none of the earlier fixes brought a breakthrough on its own — each one solved a quarter of the problem.

The first was lazy loading: the twenty-six images on the front page only started downloading when the visitor got near them, and until then their slots showed the body background — on another site this same switch went the other way. The second was the sizes attribute, which made the browser download the largest image variant even for the smallest slot. The third was Chrome's deferred texture upload to the GPU, which caused a short freeze the first time each image appeared. The fourth was a translucent blur effect that returned corrupted pixels in that particular graphics stack.

2048 px wide variant:   9 files · average 546 KB
 768 px wide variant:  30 files · average  86 KB

Nine separate modules, not one big fix

The fixes went into nine standalone modules, each one switchable on its own. Partly this was convenience during the work, because it made each fix measurable separately. Mostly, though, it is because these fixes track browser behaviour, and browsers change. If a bug disappears in a later Chrome release, the matching fix can be removed by deleting a single file, without touching the rest.

• Lazy loading off better, not gone
• Transition off better, not gone
• Image size cap better, not gone
• Measurement in the real browser frames, tasks, images
• Lazy loading
• The sizes attribute
• Deferred GPU upload
• Translucent blur
• Nine standalone modules each switchable on its own browsers change, a fix can be removed

assumption · four identified causes · two of the three early fixes stayed in after the measurement

The parts that are not obvious

The next five things are not in the documentation. They come up in use, and each one is fairly easy to walk into.

The browser downloaded the largest image for the smallest slot

WordPress generates several sizes for every uploaded image and lets the browser choose. To choose, though, the browser has to know how much space the image will occupy, and an attribute called sizes tells it. The default value is calculated from the image's own dimensions, not from where it goes — so the browser believed every gallery tile was screen-wide.

Accordingly it downloaded the variants around two thousand pixels wide, at roughly half a megabyte each, into slots where the 768-pixel variant would have done at a tenth of the weight. The fix was overriding one attribute in three places: in WordPress's own calculation, on the gallery elements, and finally in the rendered HTML as well, so that nothing could slip through.

The translucent blur triggered a graphics bug

Seven places on the page had a layer that blurred whatever sat behind it, with a transparent background. In Chrome's graphics stack on Apple-silicon machines this misbehaved: while image textures were mid-upload, the blur sampled undefined pixels at the edges, and the body background bled through.

This had been present for months in every Chrome-based browser, but not in Safari — that one takes a different graphics path. The fix was switching the blur off in favour of a similar-looking solid translucent background colour. Visually close, and it does not depend on what the browser is doing with its textures.

The test email you send yourself never arrives

When I set up the forwarding from the domain address to the owner's mailbox, the obvious check would have been for the owner to write to her own new address. That does not work: forwarding systems typically do not deliver a message that would arrive back where it was sent from.

So the test shows a failure while the setup is fine. The check has to come from a different mailbox — I sent one from mine as well, to have something to compare against.

The font did not refresh because the cache key never changed

On the local copy, the original typeface refused to appear for a long time, even though the configuration was right. The reason: the version number attached to the font stylesheet's address was baked in at generation time. When the file's contents changed, the address stayed the same, and the browser kept serving the old, broken stylesheet from cache.

The fix is to derive the version number from the file's last-modified time. A content change then always means a new address, and the browser has to fetch it again.

The verification code that actually asked for access

In the summer of 2026 a company presenting itself as a booking platform contacted the owner. The reasoning sounded plausible: they only list real, working properties, so they verify ownership, and for that a code needs to be placed into the website source.

The code was not an identifier, though, but an executable program that would have given access to sensitive parts of the site. The genuine verifications I know work differently: they ask for a file upload, or a meta tag in the page head — something that does nothing, just sits there, checkable from outside. I find these approaches have grown more carefully crafted lately.

Questions about this project

Summary

A holiday rental website in Balatonfüred, Hungary, was built in ten days in June 2025: a one-page layout with seven galleries by location, an email address on the property's own domain, and text content collected from the existing portal listings. A search campaign also ran for the launch, from summer to October 2025, where the work of the first weeks was filtering out irrelevant enquiries with negative keywords. In May 2026 a scroll stutter was diagnosed with custom telemetry, because the bug never appeared in an automated browser; the measurement found four causes — lazy loading, a wrong sizes attribute, deferred GPU texture upload, a translucent blur — and the fixes went into nine standalone, individually switchable modules. Maintenance continues on hourly work with a yearly hosting and domain subscription.

← All case studies