In short and in plain language
Many firms ask: what does it cost to make the website faster? There is no fixed price for that. The work depends on the site.
These things matter: the shop system, the number of page types, scripts from other firms, the server and the images. A page type is, for example, the page for one product.
First, someone measures. Then it is clear what to do. Only then can there be a fair price.
You can agree on a fixed price or pay by the hour. A fixed price works well when it is clear what to do.
After the work, the site is measured again. It should also be watched after that. If not, it can slowly get slower again. We can help you with this.
"What will it cost to make our site faster?" The question usually comes up shortly before budget planning, and it is a fair one: only 48 percent (Web Almanac 2025) of mobile websites pass all three Core Web Vitals, so most sites still have work ahead. Even so, an honest answer is not a single number but a calculation with five unknowns: shop system, number of templates, third-party scripts, server and cache, and the image library. This article shows how to narrow down those unknowns in advance, why an analysis before implementation sets the price, when a fixed price fits and when time and materials is the better model, what an offer should contain and how to split your budget for 2027. We deliberately leave out prices here: they depend on exactly these factors and are listed with all terms on our pricing page.
Key takeaways
- Only 48 percent (Web Almanac 2025) of mobile websites pass all three Core Web Vitals. How much work the rest requires depends on shop system, templates, scripts, server and image library.
- Effort follows the number of templates, not the number of URLs. On mobile, 45 percent of home pages but 56 percent of secondary pages pass the Core Web Vitals (Web Almanac 2025).
- An analysis before implementation turns an estimate into an offer. It measures field data at the 75th percentile (web.dev) and uses the median of several lab runs instead of a single result.
- Fixed price and time and materials spread the risk differently. A cost estimate is, in case of doubt, not paid for (Section 632(3) BGB), and a foreseeable substantial overrun must be reported without delay (Section 649(2) BGB).
- A reliable offer names templates, measurement rules, exclusions, required input and the date of the re-measurement. Chrome UX Report field data only reflects a change fully over 28 days (Chrome for Developers).
- Three items belong in the 2027 budget: analysis, implementation, monitoring. PHP 8.2 only receives security updates until 31 December 2026 (php.net); a runtime upgrade can be bundled with the speed work.
Why there is no flat price
A flat price for "making the site faster" assumes that every site is equally slow and for the same reasons. That is rarely the case. The Core Web Vitals consist of three metrics, and each one fails in a different place: Largest Contentful Paint (LCP) depends on the server, images and loading order, Interaction to Next Paint (INP) on JavaScript and third-party code, and Cumulative Layout Shift (CLS) on missing placeholders and late-loading elements. A site that misses one of these values faces a different project from one that fails all three.
Field data shows where the work typically lies. On mobile, 62 percent (Web Almanac 2025) of websites achieve a good LCP, 77 percent (Web Almanac 2025) a good INP and 81 percent (Web Almanac 2025) a good CLS. So LCP is the mobile metric that most often needs work, and it happens to touch the most layers, from the server and caching through to image delivery. On desktop, by contrast, CLS is the lowest at 72 percent (Web Almanac 2025). The simple question of which metric fails on which device already shifts where the effort goes.
For the cost question, this means the price does not depend on the domain but on which metric fails on which page types, and why. The only way to find out is to measure. How better values affect revenue and bounce rates is covered in Page speed and conversion. This article is about the other side of the equation: the effort, and how to make it predictable.
Scope of this article
Five factors that drive the effort
Every cost estimate for PageSpeed optimization contains the same five factors. You can roughly assess them even without measuring, and that assessment should come before any conversation about an offer. Then both sides talk about the same scope, and offers from different providers become comparable.
Shop system and code base
A shop on a standard theme with few extensions can be optimized with manageable effort. A system that has grown over years, with its own theme, many plugins and undocumented customizations, needs more review work before anything can be changed at all. What matters is less the system itself than how far the shop has moved from its out-of-the-box state. Whether Shopware (Community Edition), WordPress or another system: every custom change has to be retested after an optimization, and every extension that brings its own scripts or database queries can be the bottleneck. We describe the typical spots on our Shopware performance and WordPress performance pages.
Number of templates
A shop with a very large number of products does not have a correspondingly large number of problem areas, only as many as it has templates: home page, category listing, product detail, search, cart, checkout, plus content pages and special cases such as campaign pages. Measurement and optimization happen per template. Field data shows that templates differ considerably: on mobile, 45 percent (Web Almanac 2025) of home pages pass the Core Web Vitals, while secondary pages reach 56 percent (Web Almanac 2025). An optimization that only looks at the home page leaves open what happens on the pages where people actually buy.
For planning, this means: count your templates before you ask for a price, and mark the few that carry most of your revenue. Every additional template in scope means its own measurements, its own causes and its own tests. How to structure your site by template and weight it by entry pages is covered in Template performance beyond the home page.
Third-party scripts
Analytics, advertising, chat and review scripts are the factor that technology alone influences least. The share of pages with at least one third party is 90 percent or more (Web Almanac 2025). Technically, deferring or replacing a script is often quick. What drives the effort is coordination: who needs the script, what does it measure, may it load later, is there a lighter way to embed it? These questions are answered not by development but by marketing, sales and data protection. So plan time for an inventory and for decisions. A step-by-step approach is shown in Trimming third-party scripts, and the technical work is part of frontend optimization.
Server and cache
Server response time (Time to First Byte, TTFB) is the base on which every other metric rests. On mobile, only 44 percent (Web Almanac 2025) of websites achieve a good TTFB, meaning under 0.8 seconds. Whether there is a lot to do here depends on hosting, runtime environment, database and cache configuration. Some causes are fixed with a single setting, such as a missing page cache. Others require a new PHP version, a move to different hosting or a rebuild of the caching strategy. This range makes server work hard to predict as long as nobody has measured how much of the load time passes before the first byte. More on our server optimization page.
Image library
On the median home page, images account for the largest share of transferred data, ahead of JavaScript and fonts (Web Almanac 2025). In addition, 62 percent (Web Almanac 2025) of mobile pages fail to set dimensions on at least one image, which encourages layout shifts. The effort here depends less on the number of images than on whether there is an image pipeline. If formats, sizes and dimensions are generated centrally, a switch is mostly configuration. If large libraries exist without consistent processing, it becomes a project of its own. What needs to be done is described on our image optimization page.
| Factor | Lower effort | Higher effort | How to spot it in advance |
|---|---|---|---|
| Shop system and code | standard theme, few extensions | custom theme, many plugins, little documentation | list of extensions and customizations |
| Templates | few page types with the same structure | many page types and special cases | page types in navigation and checkout |
| Third-party scripts | few, loaded asynchronously | accumulated over years, no clear owner | tag manager contents, consent banner |
| Server and cache | current runtime, page cache active | outdated runtime, no page cache | TTFB in field data, PHP version |
| Image library | central image pipeline with modern formats | unprocessed originals, missing dimensions | formats and sizes on a category page |
Analysis before implementation: why measurement sets the price
An offer without measurement is an estimate with a safety margin. If you measure first, you can name the effort per template and per cause and offer exactly what is needed. Two rules apply to the measurement itself, and they also determine the effort of the analysis.
First, field data from real visits is what counts, at the 75th percentile (web.dev), separately for mobile and desktop. This data is a rolling average over 28 days (Chrome for Developers). For smaller sites or individual templates there is often not enough field data; the analysis then has to work with lab values and its own field measurement. The difference between the two sources is explained in RUM vs. CrUX.
Second, lab values vary from run to run. The median of 5 runs (Lighthouse documentation) is twice as stable as a single run. An analysis that takes several runs per template and device therefore needs more time than a quick test. In return, it delivers baseline values against which the effect can later be measured honestly. A single Lighthouse audit is a good starting point but does not replace a view of all templates that matter for revenue.
- baseline values per template and device, in the field and in the lab, with date and measurement rules
- the cause of each failed metric, not just the metric itself
- a list of actions with expected impact and estimated effort per item
- an order based on impact, effort and the revenue weight of each template
- a clear statement of what was not examined, and why
With us, this path runs through the performance analysis: a free initial assessment for orientation, followed, depending on scope, by a quick check for one template or an audit across several templates. Analysis and implementation can be booked separately, so you can also work through the action plan with your own team. The prices for each level are listed with all terms on the pricing page linked at the start.
Fixed price or time and materials: two models, two risks
Under German law, the two models differ at their core. Under a contract for work, the contractor owes the production of the promised work (Section 631 BGB), in other words a result. Under a service contract, they owe the promised services (Section 611 BGB), in other words the activity. Performance work often contains both: an agreed target value on a specific template is a result, while hunting for the cause of a sporadic slowdown is more of an activity with an open outcome.
The law is also worth a look when it comes to cost estimates. A cost estimate is, in case of doubt, not paid for (Section 632(3) BGB). If an extensive preliminary analysis is to be paid, this has to be agreed in advance. That is a good reason to commission analysis and implementation as separate services. If it becomes apparent that a cost estimate will be substantially exceeded, the contractor must notify the customer without delay (Section 649(2) BGB). In practice, this means: if you commission work on a time and materials basis, set a threshold at which feedback is due and put the handling of it in writing. These notes are not a substitute for legal advice.
| Aspect | Fixed price after analysis | Time and materials | Hybrid |
|---|---|---|---|
| Fits when | causes and actions have been measured | the cause is still being searched for | part is known and part is open |
| Risk for you | extra costs only if the scope changes | final amount known only at the end | limited by an agreed cap |
| Risk for the provider | misjudgements are at their expense | low | shared |
| Prerequisite | analysis and a clear scope | feedback threshold, interim reports | fixed price for the proven, budget for the unknown |
A practical split
We usually work with a fixed price after the analysis. The scope is set before you commission the work, and anything that is not in the offer is not charged. If an issue outside the agreed scope turns up during implementation, we raise it before any work is done on it.
What an offer should contain
You can tell whether an offer for PageSpeed optimization is reliable by a few points. If they are missing, the price is not necessarily wrong, but it is not comparable: two offers with different measurement rules describe different services, even if they carry the same heading.
- Scope: the list of templates and device classes to be optimized, with one sample URL per template
- Measurement rules: field data at the 75th percentile or lab tests with a fixed profile, median of several runs, date of the baseline
- Actions: what exactly will be changed, with the expected impact per metric
- Exclusions: what is explicitly not included, such as a new theme or replacing an extension
- Your input: access, staging environment, decision makers for third-party scripts and dates for approvals
- Re-measurement: using the same rules as at the start and with a date; for field data only after the data window has passed
- Additional effort: the threshold at which the provider reports back and how extra work is approved
- Way back: a backup before every change and a documented rollback path
How to phrase target values and acceptance so that there is no dispute about measurement at the end is covered in the article on performance requirements listed at the start under “Scope of this article”. For the offer itself: the more precisely scope and measurement rules are described, the smaller the safety margin a provider has to build in for the unknown.
Ongoing monitoring: why speed gets lost again
An optimized site does not stay fast on its own. New campaigns bring new scripts, new product images arrive without dimensions, an update changes the loading order. The web as a whole is getting heavier too: the median home page grew by 7.8 percent (Web Almanac 2025) within a year. Without monitoring, a regression is often noticed only once it shows in the field data, and by then it has been in effect for weeks.
On top of that, field data is slow to react. If you start validation in Search Console after a fix, you wait 28 days (Search Console Help) while the report watches whether the problem still occurs before it lists it as fixed. If your budget only covers implementation, there is no line left for the confirmation. How to read the report and interpret validation is covered in Reading the Core Web Vitals report in Search Console.
There are two complementary ways to monitor: a performance budget in CI that stops regressions before they go live, and ongoing field data measurement that shows what reaches real visitors. We offer ongoing monitoring of the Core Web Vitals as a separate service; scope and terms are listed on the pricing page.
Planning the 2027 budget
If you are planning for 2027 now, PageSpeed should not be a single line in the budget but three. That keeps it visible which part can be planned firmly and which can only be quantified after the analysis.
Analysis
Can be planned firmly. It defines the scope of implementation and delivers the baseline values. Ideally done early in the year so that the results feed into implementation planning.
Implementation
Can only be quantified after the analysis. Keep it in the budget as a range with a reserve, not as a fixed figure based on gut feeling. Schedule larger changes before your peak sales months.
Monitoring
An ongoing item. It holds the level you have reached, reports regressions after updates and campaigns, and delivers the re-measurement that proves an implementation worked.
Two dates belong in your planning. After two years of active support, each PHP version is supported for two more years for critical security issues only (php.net). For PHP 8.2 this period ends on 31 December 2026 (php.net), for PHP 8.3 on 31 December 2027 (php.net). A runtime upgrade requires a test run across all templates anyway; bundling performance work with it means testing once instead of twice. What the runtime itself contributes to speed is covered in PHP runtime tuning.
The metrics themselves also change. In March 2024 (web.dev), Interaction to Next Paint replaced First Input Delay as a Core Web Vital. Sites that had previously met every threshold had to be reassessed afterwards. A budget that includes a small reserve for re-measurement after such changes does not need to be renegotiated during the year.
And finally: your highest-revenue weeks are the least suitable time for rebuilds. Larger changes belong in quieter months. Before campaigns, preparation is then enough, for example warming the cache for a sale launch.
The honest answer to "What will it cost?"
What honest planning saves you
Honest planning takes time at the start: counting templates, listing scripts, commissioning an analysis before the first line of code changes. In return, it saves elsewhere. It prevents budget from flowing into actions that improve the wrong metric, and it makes offers comparable because everyone involved looks at the same baseline values. Above all, it delivers the evidence management wants to see in the next budget round: baseline, action, result.
If you are planning for 2027, an analysis of your most important templates is the smallest sensible step. We measure in the field and in the lab, identify the causes and present an action plan with the effort per item. An overview of all services, from analysis to monitoring, is available under Services.
Sources
Related Articles
How to Read the Core Web Vitals Report in Search Console
The Core Web Vitals report bundles URLs into groups. Learn to read status, group value and example URL, and turn them into a work order for the template.
Adding Black Week Promo Banners Without Layout Shift
Add Black Week notice bars, countdowns, pop-ups and badges without anything jumping: reserve space, deliver from the server and keep CLS at 0.1 or below.
View Transitions API: Seamless Page Navigation in Shops
Native, GPU-accelerated page changes in your shop without a JavaScript framework: how cross-document view transitions smooth the jump from category to product.