Performance at Digitec Galaxus
How we turned web performance from an abstract SEO concern into an engineering system at Digitec Galaxus.
Loading article…
I'm based in Neustadt a.d. Weinstraße, Germany, and prefer remote work.
At Digitec Galaxus, I spent a lot of time working on web performance for one of the largest e-commerce platforms in the DACH region. The goal was not just to make the site faster. The real challenge was figuring out how to make performance measurable, attributable and actionable across a massive single-page application maintained by dozens of autonomous product teams.
This happened on a highly personalized e-commerce platform with millions of page views and hundreds of requests per second. I did not hold an official Tech Lead title for this specific initiative, but I naturally moved into that role: pushing the topic, maintaining internal tools, acting as a sparring partner for other teams and working on the architecture.
The biggest thing I learned: improving Web Vitals in a complex SPA is not mainly about clever technical tricks. It is about building the measurement, tooling and ownership model that empowers teams to actually fix things.
For an online shop, frontend performance is directly tied to business outcomes. Slow loads frustrate users. Layout shifts destroy trust. Core Web Vitals are also a meaningful SEO signal for Google, and organic traffic matters a lot in e-commerce.
Stack context: The foundation was a massive Next.js application behind Akamai. SSR in a highly personalized e-commerce environment is tricky: cache what is safe at the edge, then hydrate user-specific modules such as recommendations or cart state on the client.
Digitec Galaxus has many autonomous teams owning different slices of the shop: product details, search, checkout, community areas and more. Saying the shop has bad Web Vitals helps no one. We needed to know which route was failing, which team owned that route, whether the issue was global or an edge case and which element caused the problem.
Without that level of detail, Web Vitals are just abstract dashboard numbers. Everyone agrees they are important, but nobody knows what to do next. We did not just need optimization; we needed operationalization.
We used everything from the Chrome UX Report to synthetic testing tools and Datadog. They are great tools, but they all had blind spots in a personalized SPA.
Soft navigation: The experimental soft-navigation API was not reliable enough across browsers and the ecosystem, so we built our own lifecycle tracking around Next.js router transitions.
We built a custom library on top of the official web-vitals package. Instead of only logging the final page score, we captured and enriched mid-flight data: every new LCP candidate and every individual layout shift event as it happened.
Each event was enriched with application context: active Next.js route, product area, owning team, device class and DOM element information. A generic statement like 'we have layout shifts somewhere' became a concrete statement like: mobile users on this route group in the Swiss market frequently experience layout shifts, and that route belongs to Team X.
The first statement creates panic. The second creates ownership. We sent the enriched data into Datadog so teams could filter by their own areas and prioritize actual user pain over edge cases.
Production dashboards are useful, but the feedback loop is slow. We built a Web Vitals developer widget directly in the UI. Engineers could build a feature, navigate the app and watch LCP, CLS and interaction signals update in real time.
Everywhere, not only local: The widget was available across environments, even production. Engineers could open the live site, toggle the widget and debug real behavior with production data and assets.
One of the biggest wins was component-level attribution for both layout shifts and LCP elements. In a Next.js app with styled-components, a problematic element often appears as a generated class like div.sc-a1b2c3.
That was not completely useless. An engineer could search the codebase, inspect source and hope the generated class was still present in the current build. But it took time and made debugging unnecessarily manual.
We mapped generated class names back to source components using source maps and cached lookups. Suddenly a signal went from div.sc-a1b2c3 to ProductList or SharedBanner. That reduced debugging time for both CLS and LCP investigations.
LCP optimization in a multi-state e-commerce platform is wild. The LCP candidate changes constantly based on viewport, experiments and personalization. Our biggest issues were less on product detail pages and more on product lists and category pages.
Because grids were dynamic, the browser could flag a promotional banner, a deal tile or a product thumbnail as LCP based on small viewport differences. Knowing the component was not enough; we needed to know why it was slow.
We heavily sampled network resources alongside Web Vitals data. That let us distinguish between an image that rendered late because React mounted it late and an image that was actually delivered too slowly over the network.
Asset domain experiment: Moving static assets to a separate cookie-less domain initially backfired: saved cookie overhead was outweighed by extra DNS and TCP/TLS setup. Only aggressive preconnects and Akamai connection warming made it worthwhile.
A recurring theme with CLS was that stability often matters more than raw speed. E-commerce content is modular and unpredictable: recommendations, promotions, or categories that render with or without integrated magazine posts. If those modules pop in after hydration, the page shifts.
One classic example was a notification bar for logged-in users that pushed the whole page down. We fixed it not by gaming the metric, but by changing how the UI was introduced: intentional animation and reserved space instead of an unexpected jolt.
The best tooling does not help if nobody looks at it. To scale this across more than ten teams, we set up a Web Performance Guild with engineers, UX designers, data analysts and product managers.
We started by trying to improve three Google metrics. What we actually built was an engineering system that turned an abstract score into an everyday, team-owned practice. That was the real win.