transparent globe
Get in Touch
Heading image on the Roundup page

Why website performance matters so much

A fast website is essential today, for user experience, conversion rate and search engine ranking. At KOMMERS we therefore place great value on measuring website performance. In this article we show which tools and methods we use to analyse website speed, how we integrate real-world tests into our workflow, which typical performance problems we frequently find at clients, and how we solve them. Finally, we share concrete learnings and best practices from our projects.

17.04.2025

Blog

Fast load times are no longer a "nice to have", they are a decisive success factor. Studies show, for example, that bounce rates rise by 32% when the load time grows from one to three seconds, and by as much as 90% at five seconds. For online marketers this means: every additional second of load time potentially costs visitors and leads. Google has also taken page speed, or rather the Core Web Vitals, into account as a ranking factor for some time now. In short: a high-performing website offers users a better experience, improves search engine visibility and increases the likelihood of conversion.

From an IT perspective, an optimised website pays off as well, it often needs fewer server resources and runs more stably under load. As an agency, we pay attention to performance from the very start, so that your website launches fast and stays fast.

Analysis with Google Lighthouse and Core Web Vitals

To make performance measurable, we rely on proven tools and metrics. One of our main tools is Google Lighthouse, integrated into the Chrome browser and into various audit tools. Lighthouse creates a performance report of your website and gives a score along with detailed notes on what costs load time (for example uncompressed images or blocking scripts). We run such audits regularly, in particular before and after relaunches, to check the effect of optimisations.

A central concept here is Google's Core Web Vitals. These metrics measure real user experiences in three areas: the load time of the main content (Largest Contentful Paint, LCP), visual stability (Cumulative Layout Shift, CLS) and input responsiveness (First Input Delay / Interaction to Next Paint, FID/INP). By analysing these values, we identify bottlenecks in the user experience. For example, LCP should ideally be under around 2.5 seconds so that users do not get impatient. If a value exceeds the thresholds defined by Google, we prioritise the corresponding improvements.

Besides Lighthouse, we also use other tools as needed, such as PageSpeed Insights (for a comparison of lab and field data) or WebPageTest for detailed network analysis. It is important to us to interpret the results correctly: not every "perfect" lab value is relevant in practice. We focus on the optimisations that bring noticeable improvements for your visitors.

Real tests anchored in the workflow

Lab measurements are important, but we do not rely on them alone. Real tests under real conditions are a fixed part of our workflow. What does that mean in practice? For one thing, we test websites on various real devices, from the high-end desktop to the average Android smartphone. That way we make sure the site also runs smoothly on a typical customer device. We simulate different network situations (for example 3G mobile) and check how higher latency plays out. We build these device and network tests into the development phase already, so that performance problems are spotted early.

Where possible, we also bring real user monitoring (RUM) into projects. That means: after go-live we collect anonymous performance data from real users, for example via Google Analytics or dedicated monitoring tools. This field data shows us, for instance, whether real visitors hit bottlenecks that did not show up in the lab (such as regional differences or particular browser problems). Combined with automated regression tests (for example Lighthouse in the CI/CD pipeline), we keep an eye on performance throughout the entire course of the project. The result: we see not only theoretical values but know exactly how your site performs in the real world, and can optimise on that basis.

Typical problems and how we solve them

In our performance audits we frequently come across similar drags at clients. Here is an overview of typical problems, and how we tackle them at KOMMERS:

Problem 1: unoptimised images and media

Modern websites thrive on images, videos and graphics, but unfortunately these are among the biggest performance killers when they are not optimised. We often see several high-resolution photos on the home page, for instance, loaded at full 4K size even though they are only displayed small. Our solution: we optimise all media consistently. That means, for example, delivering images scaled to an appropriate resolution, compressing them without loss and providing them in modern formats like WebP/AVIF. Where it makes sense, we use lazy loading so that images and videos are only loaded once they actually appear in the user's viewport. These measures reduce the data volume drastically without sacrificing visual quality, an immediately noticeable effect on load time.

Problem 2: too many scripts and render-blocking resources

Another common performance culprit is overloaded pages with too many CSS and JavaScript files, as well as third-party scripts. Every script and stylesheet can delay how the page builds, especially when they are not loaded asynchronously. Such files often pile up through plugins, trackers or ad integrations, suddenly the browser has to work through 50 or more requests before the page appears in full. Our solution: first we analyse all embedded resources. Unnecessary or outdated scripts we remove entirely. Indispensable scripts we load asynchronously or at the end of the page where possible, so that they do not block rendering. We combine CSS files and minify the code to reduce file size. For critical styles we use techniques like Critical CSS, where the most necessary styles at the top of the page are loaded directly and the rest is loaded afterwards. That way the user quickly sees something while background tasks are still allowed to run. We also examine third-party services critically: every external widget is questioned on whether its benefit outweighs the performance loss. We often find savings potential here, for example by using a tag manager to load scripts with a delay.

Problem 3: missing caching and slow server response

Sometimes the problem lies not only in the frontend but also on the server side. We see, for example, pages that are completely regenerated on every request instead of being cached, which leads to unnecessary delays. Or no browser caching headers are set, which means returning users have to reload the same files again and again. Our solution: we implement consistent caching wherever possible. On the server side we use the caching mechanisms of the CMS or framework, so that frequently requested content is served directly from memory. For files such as images, CSS and JS we enable browser caching via HTTP headers, so that these are cached on the user's device. We also recommend using a content delivery network (CDN) where needed: content is then served from a server that is geographically closer to the user, which shortens response times worldwide. Not least, we also check the server performance itself (database access, hosting plan and so on) and advise if an upgrade or an optimisation of the server environment makes sense.

Problem 4: bloated code and too many features at once

Especially with websites that have grown over the years, more and more features, libraries and code fragments creep in over time. In addition, relaunches often use extensive themes or page-builder systems that bring along a lot of ballast the specific website does not even use. The result: unnecessarily large and complex code that slows the site down. Our solution: we approach this with a minimalism principle, as much as necessary, as little as possible. In the audit we identify superfluous code (for example unused CSS classes, never-called script functions) and remove it. We pay attention to a lean structure from the start: if a feature does not clearly add value, it goes. Instead of one huge all-in-one library, we deliberately use smaller, faster libraries for individual purposes. We also often implement functions modularly, so that only the modules currently needed are loaded (keyword: code splitting). Through this "slimming down" and focus on the essentials, we reduce load times considerably. Another aspect is the prioritisation of content: important content first, detail features later. That way the user can already interact while less urgent components are loaded in the background.

Learnings and best practices

From our projects we have learned: performance optimisation is teamwork and should be considered from the start. Here are our most important best practices at a glance:

  • Early measurement: ideally we start performance analysis as early as the prototype or beta stage. Performance problems spotted early are far easier to fix than after launch. We therefore integrate Lighthouse checks and the like into our workflow during development already.
  • Mobile first: mobile users often have slower connections, so we consistently optimise for mobile devices first. If the website loads quickly on a smartphone over 3G, it will be lightning fast on the desktop. This principle shapes our decisions on design and technology (for example we avoid heavy animations that would not run cleanly on mobile).
  • Core Web Vitals as a compass: the Core Web Vitals give clear guidance on which performance areas have priority. Our experience is that improvements in LCP, CLS and FID/INP usually improve the overall user experience as well. It pays to review these metrics regularly, for example via Google Search Console, and to adjust where needed.
  • Continuous improvement: performance is not a one-off to-do but an ongoing process. After go-live we keep monitoring load times. Regression tests make sure new features do not slow the site down again. If they do, we react quickly. This continuous tuning keeps the website on course in the long term too, even as content grows or requirements change.
  • Holistic approach: finally, we have learned to always see performance in the context of the whole project. Design, content, functionality and technology interlock. Close coordination between developers, designers and marketing is therefore essential. That way we strike a balance between aesthetics and speed, because the most beautiful website is of little use if no one gets to see it because it loads too slowly. With the right balancing act we achieve both: compelling content and fast load times.

Let's get started!

We support you and your new project from A to Z, from concept to go-live.
 If you are looking for specialists who, like you, aim for a high quality standard and keep pace with the current zeitgeist, you have come to the right place.

Ready for Your Next Project?

Write to us or book an initial consultation directly. We reply within 24 hours, usually faster on weekdays.

Start Project Now