13 → 0
render-blocking resources
Drampek Nekretnine · performance rebuild
16.6 MB to 0.7 MB, without cutting the film
The situation
The site's whole argument is a cinematic flight through an apartment. That is nine video sections, nine poster images and a full-screen photographic hero — and it was costing 16.6 MB on first load. PageSpeed gave it 70 on mobile, 88 on desktop. Accessibility, Best Practices and SEO were already at 100, so performance was the only thing left.
The owner's instruction was that the cinematic introduction stays. So the job was not "make it lighter by making it less" — it was to make the same experience arrive fast.
What I did
Stopped downloading things nobody had asked for yet.
A flag now blocks every video clip and thumbnail strip until the visitor actually moves the page — scroll, wheel, key or touch. Of nine poster images, only the first is fetched up front, with the second at two viewport-heights in. If someone lands and leaves, they download almost nothing.
Unblocked the render path.
334 lines of critical CSS moved into the real document head. Fonts self-hosted — the Google Fonts stylesheet alone was blocking rendering for 750 ms. Scripts deferred. That took render-blocking resources from 13 to 4.
Then removed React from the homepage.
The page had been exported from a design tool that shipped a React runtime to render a page that never changed after load. The template was unpacked into plain HTML and the component became an ordinary class with its method bodies untouched — a mechanical port, not a rewrite. React and React-DOM disappeared entirely. With the five above-the-fold stylesheets inlined, render-blocking resources went from 4 to 0.
AVIF beside every poster,
offered through <picture>, with only the AVIF announced in the head — announcing both would download both. The hero image went from 170 KB to 91 KB.
170 → 91 KB
LCP image weight
34
requests on first load
Deliberately not done
JavaScript minification would have saved 32 KB over gzip. The scripts are deferred, so they block nothing, and Lighthouse records this as a diagnostic that does not affect the score. Shipping separate minified files would mean every future content edit silently fails to reach the site if someone forgets a build step. A 32 KB saving is not worth a class of bug that is invisible when it happens.
Deliberately not done
Non-composited animations, forced reflow, and a DOM of 1,411 elements against a 1,400 threshold — all diagnostics, none scored, and the last would mean deleting content or hand-building an icon sprite.
Deliberately not done
A Lighthouse-detection workaround. I told the owner 100/100 on mobile was not reachable with a full-screen photographic hero, before starting, along with the realistic range. There is a known trick — detect Lighthouse and skip the intro for it — and I refused to use it. The number would have been real and the experience it described would have been a lie.