PRIVACY BY DESIGN / A GROWING NOTE
Privacy from the start.
How can a website respect its visitors’ time, attention, and data? We collect experiences, explain our choices, and leave questions open.
A growing note. This page will develop with our experiment.
The starting point: Mario’s experience
Mario speaks here as a consumer. Repeated confirmations, crowded pages, and further purchase recommendations sometimes make the actual content harder for him to reach. He does not reject advertising or recommendations in principle. His concern is when their combined volume reduces usability.
Security measures can be necessary and still create hurdles: for example, when access requires a mobile phone that is unavailable. This observation is not a blanket judgment about the necessity of individual measures.
What we do on this website
- We use no visitor tracking, advertising profiles, or analytics scripts.
- Fonts come from the device; images and scripts are delivered with our website.
- We embed no third-party videos, social feeds, or advertising.
- Reading requires no account. Language and scene choices are not stored in the browser.
Hosting still involves processing technically necessary connection data. Minimising data does not mean no data is processed at all. Details are in our privacy notice.
A question remains open
How can privacy, security, and straightforward usability work together?
Mario cannot give a definitive answer from his perspective as a user. Nor do Mario and Aik together claim a definitive expert answer. We leave the question open instead of claiming a finished solution.
Speed: measure before promising
Data-conscious design alone does not guarantee a fast website. We therefore measured the public homepage with PageSpeed Insights, separately for mobile and desktop. Our illustrations are part of that examination.
Here is our first snapshot: our own SVG graphics, unchanged measurements, and open questions.
COMPARISON / 3 NOVEMBER 2026
New measurement. A mixed picture.
On 3 November 2026 at 14:53 CET we tested the public German homepage again using PageSpeed Insights. One lab run per device profile, before publishing the November additions. Both language editions document the same measurement; the English homepage was not tested.
| Metric | Mobil / Mobile 09.10. | Mobil / Mobile 03.11. | Desktop 09.10. | Desktop 03.11. |
|---|---|---|---|---|
| Performance /100 | 75 | 100 | 72 | 78 |
| FCP | 0.9 s | 0.9 s | 0.2 s | 0.2 s |
| LCP | 35.9 s | 0.9 s | 3.8 s | 4.4 s |
| TBT | 0 ms | 0 ms | 0 ms | 0 ms |
| CLS | 0 | 0.001 | 0.181 | 0 |
| Speed Index | 0.9 s | 0.9 s | 0.2 s | 1.1 s |
| Payload | 6986 KiB | 7334 KiB | 7104 KiB | 7590 KiB |
Higher scores, but not every metric improves
Mobile performance rises from 75 to 100; the previously anomalous LCP of 35.9 seconds is 0.9 seconds in this run. The cause of the old anomaly remains unresolved. Desktop performance rises from 72 to 78 while LCP increases from 3.8 to 4.4 seconds and Speed Index from 0.2 to 1.1 seconds. Desktop CLS falls from 0.181 to 0; mobile CLS is now 0.001 rather than 0. Transferred payload increases in both profiles.
The new report estimates potential image savings of 7,177 KiB on mobile and 7,425 KiB on desktop. These are tool estimates, not achieved savings. Images remain a concrete opportunity for future improvements.
Limits of the comparison
The URL and named profiles are the same, but page content, files and Lighthouse versions differ: 13.5.0 in October, 13.6.0 in November. Both reports name HeadlessChromium 153.0.8010.36. Mobile: emulated Moto G Power, slow 4G; desktop: desktop emulation with custom throttling. Each uses a first page load. No CrUX field data from real visitors are available.
These are two lab snapshots, not a controlled before-and-after experiment. Individual runs vary. Scores establish neither a general speed improvement nor a causal effect of avoiding visitor tracking. An automated accessibility score does not establish fully accessible use.
Reports and unchanged metrics
BASELINE / 09 OCT 2026
First measurement. Not a final result.
On 9 October 2026 at 08:03 CEST, we tested the public German homepage. This measures the published version before the updated break scene. Both languages of this note show the same measurement; the English homepage was not tested separately.
| Metric | Mobile | Desktop |
|---|---|---|
| Performance / 100 | 75 | 72 |
| First content (FCP) | 0.9 s | 0.2 s |
| Largest visible element (LCP) | 35.9 s | 3.8 s |
| Blocking time (TBT) | 0 ms | 0 ms |
| Layout shifts (CLS) | 0 | 0.181 |
| Speed Index | 0.9 s | 0.2 s |
| Transferred data | 6,986 KiB | 7,104 KiB |
What we learn
The first content appears quickly. The desktop report identifies Mario’s iPad illustration as the largest visible element. On mobile it identifies the heading instead; the unusual 35.9-second LCP needs further investigation. We retain the value unchanged without claiming a proven cause.
The image audit estimates potential savings of 4,822 KiB on mobile and 4,920 KiB on desktop. The desktop test also records layout shifts. Our next task is to investigate image sizes and layout stability, make targeted improvements, and measure again under comparable conditions. The characters do not need to be redrawn.
Test conditions and context
One lab run per device profile, first page load, Lighthouse 13.5.0 / HeadlessChromium 153.0.8010.36. Mobile: emulated Moto G Power with slow 4G throttling. Desktop: desktop emulation with custom throttling as labelled in the report. These are different profiles; scores are not a direct device comparison. No CrUX field data from actual visitors is available. Individual runs vary and do not establish a causal link between privacy and speed.
CLS has no time unit: it describes visible shifts during loading. TBT describes blocking work on the main thread; 0 ms does not mean the whole page loaded instantly.
Mobile report · Desktop report · PageSpeed Insights: methodology
Why Mario chose Cloudflare
Mario cites available security features and worldwide delivery as reasons for his choice. In his personal experience, working with the service encourages more deliberate, lean design. This is his assessment as a user, not advertising for Cloudflare or a general provider recommendation.
Our static files are delivered and cached through a globally distributed network. Updates can become available worldwide quickly; we do not promise an instantaneous update for every visitor. Privacy depends on our concrete choices and settings, not automatically on the provider.
Room to develop
Next, we will review these measurements together and compare improvements with a new measurement. Mario’s experiences, Aik’s wording, and verifiable results should remain distinguishable.
Illustrations are visual examples, not records of actual events. Captions were written for these scenes.
