--- title: "Web performance | Digital Cuisine" description: "Loading time, response time and visual stability made verifiable: Core Web Vitals in the field, lab budgets in the release gate and a scoped performance check." url: "https://cuisine.digital/en/services/web-performance" lang: en generated: cuisines-markdown-v1 --- Web performance # Fast is not a feeling. It is a measurement. We make loading time, response time and visual stability verifiable. With field data from real visits, clearly labelled lab budgets in the release gate and an implementation that meets both. [Discuss a project](https://cuisine.digital/en/contact)[View our work](https://cuisine.digital/en/references.md) ## Three metrics describe what visitors experience Google assesses Core Web Vitals in the field, during real visits. The 75th percentile of page views is what counts, measured separately for mobile and desktop. Three out of four views must reach the good range. An average is not enough. **Largest Contentful Paint** When the largest visible content appears, usually the main image or heading. A value of up to 2.5 seconds is considered good. What matters is the moment the page is there for the visitor, not the moment the server responds. **Interaction to Next Paint** How long it takes for the page to respond visibly to an input. A value of up to 200 milliseconds is considered good. Measurement covers the entire visit, including the filter clicked only after scrolling. **Cumulative Layout Shift** How much the layout shifts while the page loads. A value of up to 0.1 is considered good. Fonts loaded later, images without fixed dimensions and notice bars inserted late are the most common causes. ## The lab and the field measure different things A Lighthouse run is a lab test. It loads a page once from cold, on a simulated mid-range device, with a throttled connection, no history, no warm cache and no signed-in user. That alone causes values to vary between two runs of the same page. Some of the score also comes from metrics that do not arise during real visits. A standard run represents the page load, not the visit. We therefore also test scrolling, forms, consent dialogues and the first touch on a phone, using our own user flows in the lab and field data. Lighthouse can measure these flows; a page-load score alone simply does not show them. Field data is what counts for the assessment. Where the Chrome UX Report has enough data, we use it, supplemented by our own measurements in your visitors' browsers. We report the 75th percentile because that is what Google assesses. We also look at the 90th percentile to see how bad the slowest visits get. We label the two values separately. ## Our own release gate This website is our test bed. Every change goes to a staging environment first and is measured there via the PageSpeed Insights API: a sample across all page types, for desktop and mobile. The median performance score must reach at least 95 on desktop and at least 90 on mobile. Accessibility, best practices and SEO must score 100. Only with this result do we approve the version for the live site. At night, the pipeline also measures every published page for a report. The gate is a lower limit, not a reporting target. The thresholds allow for variation between measurement hosts without counting it as a regression, while a real drop is immediately visible. It forces us to test every new page under the same conditions as the first. It does not tell us what your visitors actually experience. That is what field data is for. Lab budgets ## What these numbers are, and what they are not Desktop performance of at least 95, mobile performance of at least 90, and accessibility, best practices and SEO at 100 each. These are budgets from a lab test and the approval threshold of our pipeline. They are not field data, a current measurement or a statement about how fast an individual visit was. A reliable measurement always states the date, profile, scope of pages tested and software version. Wherever we show results, these details accompany them. Where they are missing, it is a budget. ## Where speed comes from Performance is not an afterthought. It comes from architectural decisions that are expensive to correct later. **Rendering on the server** We build with React Server Components. Anything that does not need to be interactive is rendered on the server and arrives as finished HTML. Only JavaScript that has a job to do in the browser reaches it. **Images in the right order** The image that forms the largest visible content is prioritised for loading and delivered in suitable sizes. Everything below the viewport comes later. Every image includes its dimensions so that nothing shifts. **Fonts without shifts** We host our fonts ourselves, preload the most important style and provide a fallback font with matched metrics. Text is immediately readable and does not shift when the final font takes over. **Third-party systems with a budget** Every external script costs loading time and responsiveness. We integrate third-party systems asynchronously, give them a performance budget and check it in the gate. Anything that fails to meet the budget is replaced or removed. **Delivered at the edge** This website runs as a Next.js application on Cloudflare Workers, close to the visitor, with image optimisation at the same edge. Prerendered pages come from the cache at that same edge, without a dedicated server having to start up. **External systems with caching and fallback** Search, forms, prices or stock levels often come from systems we do not control. We cache their responses, set time limits and keep a fallback ready. If the external system is slow, your page remains usable. ## An example from this website The hero on our homepage includes an animation. It only starts once the page has been painted and the browser has capacity, which on mobile is noticeably after the first image. The static hero is in place beforehand, leaving the measured loading value unaffected. That is precisely why the work starts afterwards. We check whether the page still responds to input while the animation runs, whether the movement can be paused and whether it respects the system setting for reduced motion. A good page-load value does not describe the entire visit. ## Accessibility is part of implementation We set WCAG 2.2 AA as the implementation target. That means landmarks and a sound heading structure, sufficient contrast, full keyboard operation, visible focus states, labelled form fields and understandable error messages. Testing is automated and manual. Automated checks find some problems; the rest can only be found by using the page with a keyboard and a screen reader. A Lighthouse accessibility score of 100 is therefore not proof of conformance. And an overlay widget does not replace accessible implementation. ## This website loads no trackers We do not include analytics or advertising scripts on cuisine.digital. That is why there is no consent dialogue here. This is a decision for our own website, not evidence that marketing measurement can do without consent. As soon as you want to measure campaigns, you need consent and an architecture that respects it. That is a separate topic and does not belong in a performance budget. ## The performance check A scoped check with a result you can put to further use. Beforehand, we agree which pages, templates and journeys we will test and what access we need. **A documented baseline** Measured values with date, profile, device and scope tested. Where field data is missing, for example because the Chrome UX Report does not have enough data for your pages, the report states this explicitly. **Findings ranked by impact** What slows things down, where it originates and which visitors it affects. We distinguish between issues in the template and those caused by individual content or third-party systems. **Budgets for your templates** Limits per page type for loading time, response time, layout stability and script weight, each with a test criterion. As a lab budget in the gate and a field target in operation, clearly separated. **A proposal for your pipeline** How the check fits into your build, which pages it covers, when it blocks and who receives the reports. With an effort estimate and acceptance criteria. ## Where performance belongs The pages where the same rules apply. [Websites & content platforms](https://cuisine.digital/en/services/websites.md) Structure, design and content management with performance as a requirement from the outset. [Next.js](https://cuisine.digital/en/services/nextjs.md) The framework behind this website, with Server Components and delivery at the edge. [Certifications](https://cuisine.digital/en/certifications.md) The management system behind our review and approval steps. [IT services](https://cuisine.digital/en/it-services.md) Operations, monitoring and updates, so that good scores stay good after go-live. ## Web projects from our work ![iF Design: Website relaunch](https://cuisine.digital/images/projects/master/if-design-website/image.webp) iF Design ## Website relaunch [View project](https://cuisine.digital/en/projects/if-design-award-website-relaunch.md) ![OSMA Aufzüge: Website with its own component library](https://cuisine.digital/images/projects/master/osma/image.webp) OSMA Aufzüge ## Website with its own component library ![RECARO: Website relaunch](https://cuisine.digital/images/projects/recaro-website/devices.webp) RECARO ## Website relaunch ![BAHLSEN: Websites for strong brands](https://cuisine.digital/images/projects/master/bahlsen/image.webp) BAHLSEN ## Websites for strong brands ![FriEnt: Making publications easier to find](https://cuisine.digital/images/projects/master/frient/image.webp) FriEnt ## Making publications easier to find ![Gartenheim: A new web presence for the cooperative](https://cuisine.digital/images/projects/master/gartenheim/image.webp) Gartenheim ## A new web presence for the cooperative ![Linde: Global web presence](https://cuisine.digital/images/projects/master/linde-worldwide/image.webp) Linde ## Global web presence 40 international Linde websites: Sitecore implementation, content migration, Azure operations and ongoing technical development since 2014. ![SAP: Corona-Warn-App support](https://cuisine.digital/images/projects/master/corona-warn-app/image.png) SAP ## Corona-Warn-App support ![SCHMIDHUBER: Custom website components](https://cuisine.digital/images/projects/master/schmidhuber/image.webp) SCHMIDHUBER ## Custom website components ![Vimcar: Corporate website & checkout](https://cuisine.digital/images/projects/master/vimcar/image.webp) Vimcar ## Corporate website & checkout The next step ## How fast is your website really? Tell us about your idea or challenge. Together we work out what makes sense and how we can support you. [Book a call (30 min)](https://outlook.office.com/book/AIcuisine@cuisine.digital/) --- [Original page](https://cuisine.digital/en/services/web-performance) · [Contact and project enquiry](https://cuisine.digital/en/contact)