Many agencies write on their website that performance, accessibility, best practices and SEO matter to them. That sounds good, but at first it is only a claim. It becomes interesting when quality can be checked.
With our new website, we wanted exactly that: a site that feels like hafencity.dev, but does not work against its own technical promise. So we did not "add SEO at the end". Performance, accessibility and technical structure were part of the implementation from the beginning.
The Lighthouse check of our homepage on May 9, 2026 showed 100 points in Performance, Accessibility, Best Practices and SEO. That is not a certificate and not a guarantee for every real user environment. But it is a useful signal that the fundamentals are in place.
Why one score is not enough
A Lighthouse test is a lab measurement. It runs under specific conditions, with a specific device profile, connection profile and page state. Values can change when content, tracking, images, external scripts or components change.
So it would be wrong to say: "The website is perfect." The more professional statement is: the score shows that the technical foundation is clean and that the most important quality areas were not patched in later.
For us, this type of report is mainly a hygiene check:
- Does the page load fast enough?
- Is the main content visible early?
- Does JavaScript block interaction?
- Does the layout shift while loading?
- Are contrast, focus states and structure accessible?
- Are metadata, sitemap, structured data and canonicals set up sensibly?
- Are there technical patterns that unnecessarily slow down browsers or search engines?
If a website is already weak in its baseline state, it rarely becomes better once real content, forms, tracking and growth are added.
Performance: speed is an architecture decision
Performance does not start by compressing a file at the end of a project. It starts with architecture decisions.
For a modern website, these points matter most:
- Less unnecessary JavaScript: Not every interaction needs a large client bundle.
- Stable layouts: Images, cards and sections need clear aspect ratios so nothing jumps.
- Optimized media: AVIF/WebP, correct image sizes and clean
sizesvalues reduce transfer. - Sensible fonts: Few font weights, preloading where it matters and no unnecessary external dependencies.
- Clear components: UI should be reusable without creating custom logic everywhere.
In the measured run, First Contentful Paint was 0.5 seconds, Largest Contentful Paint was 0.7 seconds, Total Blocking Time was 0 milliseconds and Cumulative Layout Shift was 0. Those are strong lab values because they show that the page paints early, blocks very little and remains stable while loading.
In practice, performance remains a process. New images, integrations or analytics can change the numbers. That is why performance should not be treated as a one-time task, but as a standard check before larger releases.
Accessibility: not an afterthought
Accessibility is often discussed only when an audit is due. That is too late. Many accessibility problems start in small design and code decisions:
- weak contrast
- missing focus states
- menus that cannot be used with a keyboard
- unclear link text
- incorrect heading structure
- missing form labels
- content that only works visually
We treat accessibility as part of normal UI quality. That includes semantic HTML, useful headings, visible focus states, keyboard support, robust form labels and text that works not only in a visual design, but also in screen readers and on small viewports.
A Lighthouse accessibility score does not replace a full WCAG audit. It does not catch every real-world usage situation. But it does catch many baseline issues and forces the interface to be taken seriously at a technical level.
Best practices: the invisible quality layer
Best practices are rarely the part of a website that users consciously notice. That is exactly why they are often neglected. Still, they influence security, maintainability and trust.
For us, they include:
- HTTPS and clean security fundamentals
- current framework and dependency versions
- no unnecessary browser errors
- useful error pages
- valid links and redirects
- stable forms with understandable validation
- clear separation of content, layout and behavior
- robust image and font strategy
These points do not automatically make a website beautiful. But they prevent good design from sitting on a fragile technical foundation.
SEO: not keyword decoration, but technical clarity
SEO is often reduced to copy and keywords. Both matter, but technical SEO starts earlier.
A website should clearly tell search engines:
- Which URL is the canonical version?
- Which pages should be indexed?
- Which languages and alternate versions exist?
- Which content is an article, reference, organization, service or contact page?
- Which images and metadata should appear in previews?
- Which old URLs need clean redirects?
That is why metadata, Open Graph, structured data, sitemaps, redirects and localized paths are part of our implementation. Not as an "SEO plugin at the end", but as normal technical work.
Good SEO is not about tricking search engines. Good SEO means structuring content so clearly that people and machines can understand what it is about.
What the new website says about our way of working
With the new website, we did not only want to build a better interface. We wanted to show how we generally approach digital products:
- Design and engineering belong together.
- Quality should be verifiable.
- Performance is a product decision.
- Accessibility is part of professional implementation.
- SEO starts in information architecture.
- Clean details are not luxury; they reduce friction later.
That is also the standard we bring to client projects. Not every page needs the same technical depth. Not every project needs to maximize every metric. But every project benefits when quality is not only claimed, but systematically built in and checked.
What we do not infer from the score
It would be unserious to conclude from one Lighthouse report that a website is permanently perfect. Good values can become worse after later changes. Mobile field data can differ from desktop lab data. External tools can add load. New content can change layout and image behavior.
The most important point is not the score itself. The most important point is the workflow behind it: measure, understand, improve and avoid waiting until problems become visibly expensive.
