First screen takes longer than 3 seconds
Half of mobile visitors leave without waiting. You pay for this traffic with ads but never see it in your enquiries.
We find what exactly is slowing the site down and remove it. With before-and-after measurements visible in Google PageSpeed and in Search Console.
Half of mobile visitors leave without waiting. You pay for this traffic with ads but never see it in your enquiries.
In the Core Web Vitals report pages are marked as "needs improvement" or "poor". This is a direct ranking factor.
On mobile the score is in the red zone. Usually it is heavy images, a dozen plugins and third-party scripts.
Content shifts, people miss the button. Google counts this as CLS and lowers the page's score.
Google Ads lowers the quality score for a slow landing page — you pay more per click than competitors with the same offer.
The filter page thinks for several seconds on every click, and people leave before they reach the product.
Load speed affects the business in two ways at once. The first is obvious: a person on a phone does not wait — by various measurements about half of visitors leave a page that loads longer than three seconds. If you bring this traffic with ads, you pay for every one of them.
The second way is less visible. Since 2021 Google has taken Core Web Vitals into account — three metrics describing a real user's experience: LCP (when the main content appeared), CLS (how much the layout jumped) and INP (how fast the page responds to actions). These data are collected from real visitors of your site, not from a lab test, and they affect positions in the results.
Advertising is a separate matter. Google Ads calculates a landing page quality score, and speed is part of it. A slow page means a higher cost per click for the same offer. So you pay twice: you lose part of the visitors and overpay for those who got through.
A 4 MB photo straight from the camera where 150 KB in WebP would do. The most common cause and the cheapest to fix.
Each drags its own CSS and JS onto every page, even where it is not used.
Chats, pixels, review widgets — they load synchronously and block the page from rendering.
The server assembles the same page from scratch every time.
Server response time over a second — there is no point optimising further until you move.
Several weights from an external source, which make the text appear with a delay.
We look at the site in PageSpeed, in Search Console and by hand. We tell you what exactly is slowing it down and how much it can realistically be sped up. On the day you get in touch.
We fix the target numbers before the work starts: what mobile score and which Core Web Vitals we are to reach.
Images, scripts, caching, fonts, database queries — one by one, with a measurement after each step. 3–10 days.
We show not only the PageSpeed score but the real time to the first screen. A report with screenshots.
Core Web Vitals are collected from real users and do not update immediately. For a month we watch until the numbers in Search Console turn green.
The price depends on what exactly is slowing things down. The measurement is free — after it we name the exact figure.
When one obvious thing is slowing the site down: images, cache, fonts.
The most common format: we work through every cause and reach the green zone.
Catalogues with filters, thousands of products and heavy pages.
If the measurement shows that the main cause is the hosting, we will be the first to say so. Optimising code on a server with a two-second response time is wasted work: first the move, then the optimisation.
The quick package — $150 for 2–3 days, if one obvious thing is slowing things down. Full optimisation — from $400, delivery in 3–10 days. Stores with a catalogue — from $900. We name the exact figure after the free measurement.
We fix the target numbers before the work starts, after the measurement — when it is already clear what exactly is slowing things down. If the agreed result is not reached, we refund the money. Promising 90+ before looking at the site would be dishonest: on some systems the ceiling is lower.
We work on a copy and check every step separately. Before rolling out to the live site we make a backup. If something stops working, we restore it as it was and look for another way.
Yes, and it is the most common case. We look at which plugins are actually used, which duplicate each other, and which drag their scripts onto every page for no reason. Often half of them can be removed without losing functionality.
We will say so right after the measurement. If the server response time is over a second, optimising the code is pointless — first the move. We can do the migration ourselves; it is separate work.
PageSpeed shows two different data sets: a lab test (run fresh every time, so it jumps) and field data from real users over 28 days (updated slowly). We go by the field data — that is what Google takes into account.
Core Web Vitals are calculated over 28 days of real traffic, so after the fixes the numbers in Search Console do not change immediately. Usually the first shifts are visible in two to three weeks, the full picture in a month to a month and a half.
Measure my site
Start a project