Frequently asked questions
Frequently Asked Questions About Performance Optimization
From the fundamentals of load time optimization to Core Web Vitals, server configuration and ongoing monitoring: here you will find well-founded answers to the most important questions about website performance.
General Questions About PageSpeed Optimization
- What exactly is PageSpeed optimization? PageSpeed optimization covers every technical measure that improves a website's load time and responsiveness. It works on two levels: server-side optimization with caching, Brotli compression, PHP and database tuning, and frontend optimization with image compression, critical CSS, JavaScript bundling and streamlined rendering paths. The two are inseparable: a fast server helps little if the frontend slows it down with render-blocking scripts. We treat performance not as a one-off task but as a measurable state. In concrete terms, that means getting the Core Web Vitals (LCP, INP, CLS) into the good range and keeping them there. From 50+ projects (project experience) we know that the biggest lever almost always sits where no one expects it. That is why every project starts with a systematic analysis rather than blind standard fixes.
- Why is my website's load time so important? Load time is not a technical nicety, it acts directly on revenue. Three metrics react especially sensitively: conversion rate drops by up to 7 percent with each additional second of load time (Deloitte, 2020). Bounce rate rises sharply, because 53 percent of mobile users abandon a page that takes longer than three seconds to load (Google, 2022). And visibility suffers, since Google introduced Core Web Vitals as a ranking factor in 2021. The tricky part is that these losses are invisible. A visitor who leaves after two seconds files no complaint, they simply never appear in your statistics. That is exactly why our performance analysis measures not only lab values but also the real field data of your visitors. A faster website improves user experience, revenue and SEO rankings in one move, without you having to change a word of your content.
- What is the difference between PageSpeed Insights and actual user experience? PageSpeed Insights from Google delivers two fundamentally different kinds of data that are often confused. The lab data comes from a synthetic test in a controlled environment: a standardized mid-range device, a throttled network connection, a single page load. It is reproducible and ideal for diagnosing specific problems. The field data from the Chrome User Experience Report (CrUX), on the other hand, reflects how your real visitors experience the page over a 28-day window, with their actual devices, networks and locations. In practice the two often diverge: a page may look slow in the lab but show good field data because real visitors access it on fast connections. For Google, what ultimately counts is the field. That is why every performance analysis we run draws on both sources, using lab data to find root causes and field data as the measure of success.
- What PageSpeed score should my website achieve? A Lighthouse score of 90 or higher is considered good and signals green values across the essential metrics. However, the score is only a weighted summary of several lab values and can vary from one measurement to the next. More important are the individual Core Web Vitals: LCP below 2.5 seconds, INP below 200 milliseconds, CLS below 0.1. These thresholds decide whether Google considers your page fast. We explicitly warn against treating the score as an end in itself. A page with a score of 85 and excellent field data is in better shape than one scoring 98 whose real visitors wait on slow mobile devices. Our goal is therefore always a stable green range in the field data, with the Lighthouse score following almost automatically. In the initial consultation we put your current score into realistic perspective.
- How long does a typical performance optimization take? Duration depends on the starting condition and scope. A targeted frontend optimization of a single landing page is often completed within a few days. A full audit with subsequent implementation for a complex website typically takes two to six weeks, because each change is tested and measured on a staging environment before it goes live. For Shopware shops with deep server, cache and plugin optimization, more extensive projects may require four to eight weeks, especially when Varnish configuration and database tuning are involved. Importantly, we deliberately deliver the first measurable improvements early by starting with the most impactful measures. You will receive a realistic time estimate for your specific case in the free initial consultation.
- Can every website be made faster? In our experience from 50+ projects (project experience), every website so far could be noticeably accelerated, though the room to manoeuvre varies greatly with the starting point. A WordPress site with uncompressed images, a bloated page builder and blocking JavaScript can often be sped up by 60 to 80 percent, because many obvious brakes are at work here. An already partially optimized web application or a cleanly built shop benefits more from targeted fine-tuning, for example on TTFB, hydration strategy or third-party script management. There too, small gains add up to a markedly better user experience. The potential hidden in your website is revealed by our systematic analysis before any measure is implemented.
Core Web Vitals in Detail
- What are Core Web Vitals and why are they important? Core Web Vitals are three Google-defined metrics that measure the user experience from different angles. LCP (Largest Contentful Paint) captures how quickly the largest visible content appears, in other words when the page feels loaded. INP (Interaction to Next Paint) measures how promptly the page reacts to clicks, taps and input. CLS (Cumulative Layout Shift) rates how calmly the layout stays during loading, that is whether buttons jump away from under the finger. Since June 2021 these three values have been a confirmed ranking factor and therefore relevant to every website owner, not just SEO specialists. They translate abstract user perception into measurable numbers that can be improved in a targeted way. On our dedicated Core Web Vitals page we explain each metric in detail and show the typical causes of poor values.
- What thresholds apply for good Core Web Vitals? Google divides each metric into three tiers. LCP is good below 2.5 seconds, needs improvement between 2.5 and 4.0 seconds and is poor above that. INP is good below 200 milliseconds, needs improvement up to 500 milliseconds and is poor beyond. CLS is good below 0.1, needs improvement up to 0.25 and is poor above that. You will also find these values in the comparison table further down this page. The often overlooked detail is the measurement point: assessment is based on the 75th percentile of real field data. What counts is the value that the slowest 25 percent of your visitors still experience, not the average. A page only passes when all three metrics are simultaneously in the green range. This is exactly what we orient every performance analysis towards.
- How strongly do Core Web Vitals affect Google rankings? Core Web Vitals are a confirmed ranking factor, but one among many. Google has repeatedly emphasized that content relevance remains by far the strongest signal. So a page sitting at position 30 will not climb to the top through fast load times alone. In practice, the vitals act primarily as a tie-breaker: when two pages offer similarly relevant content, Google favors the faster, more user-friendly one. For highly competitive search terms in particular, this difference can determine whether you rank at position 3 or position 8, and thus a substantial share of the clicks. Across our projects (project experience), websites typically gain two to five positions on relevant terms after comprehensive optimization of their Core Web Vitals. This can never be guaranteed, because rankings depend on many factors, but performance is one of the few entirely within your control.
- What is the relationship between INP and the former FID metric? INP (Interaction to Next Paint) replaced the older FID (First Input Delay) metric as a Core Web Vital in March 2024. FID measured only the delay of the very first interaction, and only up to the start of the response, not the visible result. That was an easy test to pass and said little about the real interaction experience. INP, by contrast, measures all interactions across the entire page visit and reports the worst value (minus statistical outliers). For optimization this shifts the focus considerably: it is not enough for the page to react on the first click. Opening a menu, filtering a product list or submitting a form must all stay fluid too. To achieve that, we analyze long JavaScript tasks that block the main thread and break them up. More on this topic on the frontend optimization page.
- Why is my CLS value poor even though the page loads quickly? CLS measures something entirely different from loading speed, namely visual stability. A page can load lightning-fast and still have a poor CLS value if elements keep jumping around after the first render. Typical culprits are: images and videos without a fixed width/height attribute, late-loaded web fonts that trigger a font swap, dynamically inserted banners or cookie consent layers that push content downward, and animations that modify layout properties instead of the GPU-friendly transform property. The insidious part is that these shifts often only become visible on slower connections, exactly where you are not looking when testing your own site. In our performance analysis we track down every single layout shift, attribute it to the triggering element and fix the root cause in a targeted way, for example by reserving space for images and ads or preloading fonts.
- How do I improve my website's LCP value? LCP is the sum of four phases. First, the server response time (TTFB), reduced through optimized hosting, caching and, where appropriate, a CDN. Second, render-blocking resources such as non-critical CSS and synchronous JavaScript that delay the first paint. Third, the load time of the LCP resource itself, usually a large hero image. Fourth, the render time on the client, which can grow sharply in JavaScript-heavy frameworks without server-side rendering. In practice the biggest lever almost always lies in the first two phases. We reduce TTFB through server optimization, deliver the LCP image in modern WebP or AVIF format and prioritize it via preload so the browser fetches it immediately. Once render-blocking scripts are deferred and critical CSS is inlined, LCP often drops by more than half (project experience).
Technical Questions About Server and Frontend
- What role does hosting play in website performance? Hosting is frequently the single largest lever, because it sits right at the start of the loading chain. If the server delivers the HTML document with delay, the TTFB is high, and that delay is inherited by every subsequent resource. Even a perfectly optimized frontend can no longer make up for it. Typical brakes are overloaded shared hosting packages, outdated PHP versions, missing OPcache configuration and undersized memory. In many projects (project experience), targeted server tuning or a migration cut the TTFB by 50 to 70 percent, immediately improving all Core Web Vitals. Often a switch to a current PHP version with OPcache enabled and an appropriately sized cache is already enough. In the initial consultation we check whether your current hosting is the bottleneck.
- Does my website need a CDN? A Content Delivery Network is worthwhile above all when your visitors are geographically dispersed. The CDN keeps static resources like images, CSS and JavaScript on servers in many countries and serves them from the nearest location. The effect is a shorter distance and therefore lower latency, which is especially noticeable for the LCP resource. For a regional website with predominantly German visitors and a server located in Germany, the added benefit is limited, here caching and image optimization usually achieve more. For international websites or shops with a worldwide customer base, a CDN can cut load times for distant visitors by 40 to 60 percent (project experience). So we do not recommend a CDN by default but assess in the performance analysis whether your visitor distribution justifies it.
- What do image formats like WebP and AVIF provide? Modern image formats deliver significantly smaller files at the same visible quality than the classic JPEG and PNG formats. WebP typically saves 25 to 35 percent over JPEG (Google, 2023), and AVIF achieves savings of 40 to 50 percent. Since images make up by far the largest share of transferred data on most websites, this is one of the most effective single steps towards a better LCP. The key is clean implementation: we set up automated image pipelines that generate every uploaded image in the appropriate formats and in several responsive sizes, delivered via srcset. Older browsers automatically receive a compatible fallback. This way every device loads exactly the variant it needs, without oversized files. More on this on the frontend optimization page.
- How does JavaScript affect load time? JavaScript is one of the most common performance brakes, because it is more expensive than its file size suggests. Every script must be downloaded, parsed, compiled and executed before the page is fully usable, and parsing blocks the main thread while it happens. Synchronously included scripts additionally delay rendering. Particularly wasteful is unused code that is loaded but never needed, yet still costs bandwidth and processing time. We tackle this systematically: coverage analysis to identify dead code, code splitting so each page only loads its own scripts, tree shaking to remove unused functions, and deferring non-critical scripts until after the first render. This improves not only LCP but also INP, because fewer long tasks block interactivity. Details on the frontend optimization page.
- What is the difference between HTTP/2 and HTTP/3? Both protocols speed up transfer compared to the old HTTP/1.1, but they solve different problems. HTTP/2 introduced multiplexing, meaning several parallel requests over a single connection instead of opening a new one for every file. This removes much of the former connection overhead. One weakness remains, however: if a packet is lost, the entire TCP connection stalls (head-of-line blocking). HTTP/3 relies on the QUIC protocol over UDP and solves exactly this, because a lost packet only blocks the affected stream, not all of them. Connection setup is also faster. The biggest gain is felt by users on unstable mobile connections. As part of server optimization, we configure your server to offer both protocols, so every visitor automatically uses the fastest available variant.
- Can I perform performance optimization myself? Partly, yes. Basic measures like compressing images, removing unused plugins, enabling browser caching or updating the PHP version can be done with some basic technical understanding and already bring noticeable improvements. We recommend these first steps to every website owner. Things get more complex with server configuration, critical CSS extraction, JavaScript refactoring, database tuning or resolving INP problems, because these require specialist knowledge, and the risk of damaging SEO or functionality along the way is real. In our experience, companies achieve the best result when they handle the basic optimization themselves and engage a specialized partner for the demanding measures. We are happy to advise in the initial consultation on where that line sensibly runs.
Platform-Specific Questions
- What performance problems occur most frequently with WordPress? WordPress sites usually suffer from a recurring pattern. The most common brakes are: too many active plugins, each loading their own CSS and JavaScript files on every page even where they are not needed, uncompressed and unscaled images, missing or misconfigured caching plugins, outdated PHP versions, and bloated page builders generating hundreds of kilobytes of extra HTML and CSS. On top of that come databases grown over years, full of orphaned metadata, transients and post revisions. In a typical WordPress project (project experience), we reduce the number of HTTP requests by 40 to 60 percent and the total page size by more than half, without sacrificing functionality. The keys are selective asset loading, a cleanly configured server cache and a tidied-up database. Which measures have the greatest effect on your site is revealed by the performance analysis.
- How do you optimize the performance of a Shopware shop? Shopware CE comes with its own set of performance levers that differ from a classic website. The central ones are: the Elasticsearch configuration for fast product and faceted search, HTTP cache warming so that frequently accessed category and product pages are already in the cache, lean Twig templates for short render times, and a correctly tuned Varnish reverse proxy that serves finished pages straight from memory. On top of that come shop-typical topics such as the number of plugins, the generation of image variants (thumbnails) and database performance with large catalogs containing many variants. Especially during load spikes, for instance at a campaign launch, the caching strategy decides availability and conversion. Our dedicated Shopware performance page covers these topics in detail, and for shops with high order volumes our e-commerce solutions are worth a look.
- Can JavaScript frameworks like React or Vue also be optimized? Yes, and this is often where great potential lies. Single Page Applications based on React, Vue, Svelte or Angular typically struggle with three problems: a large initial JavaScript bundle, slow rendering in the browser and poor indexability, because the actual content is only created via JavaScript. This mainly weighs on LCP and INP. We address several points: Server-Side Rendering (SSR) or Static Site Generation (SSG) so the content is delivered as HTML right away, route-level code splitting, tree shaking, lazy loading of components and lean hydration strategies that activate only the genuinely interactive parts. For existing apps without SSR, we also evaluate a migration to modern meta-frameworks. For SaaS applications we describe the approach in more detail on a dedicated page.
- How does optimization for mobile devices differ? Mobile optimization is not a side issue but the main benchmark, because Google uses the Mobile-First Index and evaluates the mobile version of your site. Mobile devices also have weaker processors and often less stable networks than desktop PCs, so the same page is noticeably slower there. In concrete terms: JavaScript bundles must stay small, because parsing on mobile devices takes several times the desktop time. Images are served in responsive sizes so a smartphone never downloads a desktop resolution. Touch interactions must respond without delay to achieve good INP values, and the layout must load without shifts so CLS stays low. That is why we consistently test every optimization under throttled mobile conditions, not just on a fast office machine. More on this in the performance analysis.
- Can performance optimization cause SEO problems? Yes, if it is implemented improperly. That is one reason we do not blindly activate standard plugins. Typical risks are: overly aggressive lazy loading that prevents the Googlebot from seeing content and images, deferring JavaScript so that structured data only appears after the first crawl, URL changes from a CDN configuration without clean redirects, and excessive caching that serves outdated content. We therefore treat SEO as a fixed constraint of every measure, not as an afterthought. After implementation we verify with the official Google tools that content remains indexable, that structured data is recognized correctly and that no redirect chains have crept in. This way the performance gain stays a pure gain, without losing it elsewhere. For questions on this, the initial consultation is the place to start.
- Does my shop need to go offline during optimization? No. An online shop earns from every minute of availability, so we deliberately work without a blanket shutdown. All changes are first made in a staging environment, a copy of your shop, where we test them thoroughly and measure their effect. Only after successful validation do we transfer them to the live environment. Most measures, such as cache configuration, image optimization or CSS changes, can be deployed without any downtime at all. Only for deep server-side changes that require a service restart do we schedule a brief maintenance window during a low-traffic period, typically at night or in the early morning, and we agree the timing with you in advance. This keeps the risk to revenue and shop performance to a minimum.
Costs and Project Process
- What does professional PageSpeed optimization cost? The investment depends on scope and complexity, which is why we work with transparent ranges rather than flat rates. A targeted optimization of a single landing page or a clearly defined issue starts in the low four-figure range. A full audit with implementation of all identified measures for a medium-sized website falls in the mid four-figure range. Complex shop systems with deep server, cache and frontend optimization can reach the high four-figure to five-figure range, depending on catalog depth and plugin landscape. The crucial part is the counter-calculation: even a few percentage points more conversion or a handful of ranking positions often amortize the investment within a few months. You will receive a realistic budget indication for your specific case in the free initial consultation, after we have taken a brief look at your website.
- What does a typical performance optimization project look like? Every project follows a clear, transparent process. It begins with a comprehensive performance analysis: we measure the current state of all relevant metrics in lab and field, identify the biggest bottlenecks and create an action plan prioritized by impact. So you know from the outset what we are doing and why. During the implementation phase we work through the measures from the biggest lever downward, with each change first tested and measured on a staging environment before it goes live. On completion you receive a report with before-and-after comparisons of all metrics, so the success is verifiable. On request, we then set up ongoing monitoring that detects regressions early. Examples of our project approach can be found on the references page.
- Do you also offer ongoing performance monitoring? Yes. Performance is not a state you establish once and then forget, which is why we offer monitoring packages that keep your Core Web Vitals and other metrics continuously in view. This includes daily synthetic tests, ongoing evaluation of the CrUX field data, automatic notifications when values degrade, and regular reports with concrete, actionable recommendations. It is particularly worthwhile for websites and shops that are updated regularly, because a new plugin, an embedded marketing script or a design change can degrade performance unnoticed. With monitoring, such a regression surfaces within hours rather than weeks later through declining rankings. We are happy to discuss which scope of monitoring suits your website in the initial consultation.
- How do I measure the success of a performance optimization? Success has to be measurable, otherwise it is just a claim. We document it on two levels. The technical metrics are compared before and after: the Core Web Vitals (LCP, INP, CLS), the PageSpeed score, the TTFB, the total page size and the number of HTTP requests. These values can be captured objectively and reproducibly. More important in the long run are the business metrics, which show after a few weeks: a lower bounce rate, longer time on site, more pages per session and a better conversion rate, often accompanied by improved rankings on relevant search terms. Every project concludes with a documented report that transparently breaks down all measurable improvements. We also explain our measurement and working approach on the About page.
- Are there recurring costs after optimization? The one-time optimization itself incurs no mandatory costs afterwards, the improvements achieved remain yours. So you are not locked into a subscription model to stay fast. We nonetheless recommend optional monitoring, because website performance is not a static state: new content, plugin updates, CMS upgrades or changed third-party scripts can gradually degrade the values. These packages are billed monthly and can be adjusted at any time. Alternatively, many clients choose quarterly performance reviews where we assess the current state and make targeted adjustments as needed. Which option makes sense for you is something we discuss without obligation in the initial consultation.
- Can optimization be divided into phases? Yes, a phased approach is frequently the most economically sensible option, because it spreads the investment over several months and delivers results early. Phase one focuses on the most impactful measures with the greatest lever, typically server configuration, image optimization and critical CSS. Already here the improvements become measurable. Phase two addresses advanced topics such as JavaScript refactoring, refined caching strategies and the management of third-party scripts. Phase three covers fine-tuning of the Core Web Vitals and setting up long-term monitoring. The advantage: after each phase you decide on the basis of concrete numbers whether and how far to continue. We define the phase split that fits your budget together in the initial consultation.
Caching, Compression and Delivery
- What is the difference between browser cache and server cache? Both caches speed up delivery, but they act at different points. The browser cache stores resources like images, CSS and JavaScript locally on the visitor's device. When the same user opens another page, the browser loads these files straight from local storage without contacting the server at all. This is controlled via HTTP headers such as Cache-Control. The server cache, by contrast, keeps pre-rendered HTML pages or the results of expensive database queries on the server, so they can be served instantly even to new visitors. The two layers complement each other: the server cache accelerates the first load, the browser cache every subsequent load from the same visitor. As part of server optimization, we tune both so that content stays fast and yet up to date.
- What is Brotli compression and why is it better than Gzip? Brotli is a compression algorithm developed by Google, tailored specifically to web content and shipping with a pre-trained dictionary of typical HTML and CSS patterns. Compared to the older Gzip, it achieves 15 to 25 percent better compression for text-based resources like HTML, CSS and JavaScript (Google, 2023). Smaller transfer sizes translate directly into shorter load times, especially on slow mobile connections. In practice the switch is low-risk, because all modern browsers fully support Brotli. We configure the server to negotiate Brotli as the preferred algorithm and keep Gzip as a fallback for the rare older client. This way every visitor automatically benefits from the best possible compression, without anything in the content having to change. More on this on the server optimization page.
- How does a reverse proxy like Varnish work? A reverse proxy sits in front of the actual web server and keeps complete HTML pages in memory. When a visitor requests an already cached page, the proxy serves it directly from RAM, without PHP being executed or the database even being queried. This brings the TTFB down to a few milliseconds, even for elaborately generated dynamic pages, and at the same time relieves the server during load spikes. Varnish is therefore especially effective for Shopware shops with many category and product pages that change only rarely. The challenge lies in clean cache invalidation: a price change or an empty stock level must take effect immediately, while everything else stays in the cache. We configure exactly these rules per project, so that speed does not come at the expense of timeliness.
- What does Critical CSS mean and how is it implemented? Critical CSS is the minimum set of CSS rules needed to correctly render the immediately visible area of a page (above the fold). Normally the browser must first download and process the complete external CSS file before it is even allowed to draw anything, which blocks rendering. If the critical CSS is instead embedded inline directly in the HTML, the browser can render the visible area right away. The remaining, not immediately needed CSS is then loaded asynchronously. This is done through automated extraction: specialized tools analyze which rules the visible area actually requires for different screen sizes. The result is a significantly faster First Contentful Paint and usually a better LCP too. This technique is part of our frontend optimization and is particularly worthwhile with large CSS frameworks.
- How do I handle third-party scripts that slow down performance? Third-party scripts such as analytics tools, chat widgets, marketing pixels and social media embeds are among the most stubborn performance bottlenecks, because you do not control their code yourself and it often blocks the main thread. They are also a frequent cause of poor INP values and sudden layout shifts. We proceed in three steps. First, we inventory every included script and assess its genuine business value, since much of it runs purely out of habit. Second, we remove whatever is no longer needed. Third, we optimize the rest: delayed loading only after the first user interaction, self-hosting where possible, and facades that initially show only a lightweight preview for chat widgets or embeds and load the heavy script on click. This preserves the benefit without sacrificing your frontend performance.
- How do I ensure performance remains stable after optimization? An optimized website can slow down again over time, which is normal and no sign of poor work. Regressions usually arise from new content, plugin updates or third-party scripts added later, often without anyone noticing in day-to-day operations. To safeguard stability, we recommend three building blocks: automated monitoring that continuously measures the Core Web Vitals and alerts on degradation, a performance budget that sets binding maximum page sizes and script volumes, and regular reviews on a quarterly basis. This way a regression surfaces within hours and can be fixed before it shows up in the field data and thus in your rankings. We are happy to discuss the appropriate scope in the initial consultation.