Case study
Handwerkskunst Göttingen
A master tiling company, and a website that paints on a phone in under a fifth of a second. The site is live — you do not have to take my word for any of this, you can measure it yourself.
- Industry
- Tiling, master craft business
- Location
- Göttingen, Germany
- Scope
- Concept, design, development
- Stack
- Astro, static on Cloudflare
Real screenshots of the live website, as of September 2026
What was built
A site that answers one question: can this company do my bathroom, and how do I reach them? Anything that does not serve that question is not on the page.
- A home page carrying everything the decision needs — services, work samples, guarantees, the way to get in touch. No click path across four subpages.
- Before-and-after photographs of real projects instead of stock imagery.
- A call button that actually places the call on a phone — for a trade where the first contact is almost always a phone call.
- Frequently asked questions as their own section, marked up as FAQPage — the same passage Google and AI assistants can quote.
- Imprint and privacy policy as proper pages, not a footer modal.
What the site measures today
These numbers are not from a proposal. They come from a measurement run against the live site, and you can repeat it: open the address, open the developer tools, look for yourself.
Largest Contentful Paint
172 ms
Google calls anything up to 2.5 s good — this is about a fourteenth of that.
Cumulative Layout Shift
0
Nothing moves while the page loads. The threshold for “good” would be 0.1.
Time to First Byte
219 ms
Server response time to the first byte, connection setup included.
First Contentful Paint
292 ms
The moment the first content becomes visible.
HTML transferred
19 KB
The entire document, compressed — less than a single unoptimised photo.
Images
14 × WebP
Every one with explicit dimensions, so nothing shifts after the fact.
Measured on 3 September 2026 with Chrome 152 (headless), viewport 390 × 844 px, empty cache, no artificial throttling. These are lab numbers from one device, not field data from the Chrome UX Report — what the difference is, and why it matters: Improving Core Web Vitals
Why the numbers look like this
Built once, not assembled on every request
The page is generated at build time and then sits in Cloudflare's network as finished HTML. There is no database query left to run when someone opens it, and no theme executing PHP before the first letter appears.
No plugin stack
What the site does is in the site's source. No slider plugin, no cookie tool, no page builder bringing its own CSS framework along. That is why the whole document stays under 20 KB compressed.
WebP images with explicit dimensions
Every image is WebP and carries width and height in the markup. The browser reserves the space before the file arrives — which is why layout shift is zero rather than “usually zero”.
Structure machines can read
One H1, clean nav/main/footer regions, and structured data for the business, the services and the frequent questions. It is the same work that makes the site usable with a screen reader — accessibility and findability turn out to be the same job.
A project of this size?
Tell me what it is about. You get an honest assessment within 24 hours — what makes sense, roughly what it costs, and what you can skip.
Request a similar project
