A site speed audit is about measurements and explanations, not a synthetic test score. We capture the server's first response, full load, and document weight separately on main, category, and card, multiple iterations with the median, and then tie each slow number to a cause: server, template, image, or someone else's script. The output is a list of works in the order of influence. We also know how to correct, but this is a separate estimate: the audit ends with a document. In the 24 sites we measured, the first response ranged from 126.3 to 1,544.6 ms.
measurements on three types of pages, analysis of causes, list of works by influence
after a free audit
Price
30
Guarantee
days after project sign-off
measurements on three types of pages, analysis of causes, list of works by influence
What are we doing?
3-7
Audit period
working days, depends on the size of the site
free speed measurement, 2-3 working days
Before the paid audit
126.3–1,544.6
Spread of the first answer in its own dimension
ms, 24 sites, measurement 07/31/2026
102.1–751.2
HTML weight distribution is the same
KB is a huge difference
report and raw measurements with date, even if another contractor fixes
What is left with you?
neither Google rankings nor a specific test score
What we do not promise
Free speed measurement before talking about money
The complaint that the site is slow is a feeling, not a diagnosis. The server can slow it down, it can be a template, it can be one picture of 4 MB, it can be a third-party script that takes five more. We take the numbers before offering anything: without them, any evaluation of the work will be a guess.
What we measure
Server First Response (TTFB)Median from several measurements on the main page, in the category and on the internal page - separately, because they often differ. In our sample, the range was from 126.3 ms to 1,544.6 ms on live sites.
Full HTML downloadHow much time passes from the request to the last byte of the document. The difference between this number and the TTFB tells you whether the server or the markup size is holding you back.
HTML weight and compressionDocument size without compression and in gzip/brotli. Measured sampling benchmarks: 102.1 KB on the lightest site and 751.2 KB on the heaviest — a difference across the board in the same class of sites.
Redirects at the entranceDoes the visitor reach the final address immediately? One extra 301 on the main one is added to each first visit — in one of the measured stores, it's sitting inside 789.4ms.
Pictures and delayed loadingHow many img tags are on the page, how many are loading="lazy" or are there WebP. Measured benchmarks: 0% to 96% lagging images on various sites.
Third-party scriptsHow many counters, chats and widgets are connected and what they entail. This is a part of the weight that no one deliberately ordered - it has been accumulating for years.
Caching headersWhat the server tells the browser about the return visit. A page with no-store is reloaded every time from scratch, even if it has not changed.
What you get
Metrics table: TTFB, full load and HTML weight separately for main, category and internal pages - with date and number of repetitions.
List of found causes in order of impact: which are cured by server configuration, which by template edits, and which require rework.
Comparing your numbers to the range we saw at the 24 sites we measured - to see if it's bad at all or just feels bad.
The conversation lasts 30–40 minutes, where we go through the document point by point.
Timeline: 2-3 working days from the moment we receive the site address
Why is it free
Because the measurement costs us several hours, and the guessed estimate is more expensive for both of us. Half of the reasons for slow returns can be seen already at this step, and it happens that the correction takes a day - then we say so, instead of selling a monthly project.
What's next
After the measurement, we name the list of works, cost and term by stages. If it is clear from the numbers that your site is fast and the problem is not in it, we will also say so - and the document will remain with you.
Short form: your contact and site URL
Contract, act and 30-day warranty
Every project gets a written contract: scope, deadlines, amount, acceptance procedure. After delivery — act and invoice, then 30 calendar days of warranty.
Sole proprietor & bank transfer
The contractor is a registered sole proprietor. Payment by invoice with closing documents.
Rights & access — yours
Code, design and materials transfer to you after full payment. Domain, hosting, repository and analytics are registered to you.
Client portal instead of email chains
During the project you get access to a portal: contracts, invoices, acts and project status in one place.
European clients
Among our work — projects for Norway, Bulgaria, Moldova and Spain.
Verifiable numbers
Every case in the portfolio comes with a link to a live site and a technical measurement.
Audit first, then pricing
There is no price list on the site intentionally: the scope of the same work differs multiples between clients.
We say "no" when unsure
If the task isn't ours or the deadline is unrealistic — we tell you upfront.
What affects the price
Why two seemingly identical tasks are priced differently
How many types of pages to measureA single page site is one set of measurements. Store - at least three: main, category, card, and they diverge. At one of the measured sites, the main was rendered four times slower than the item card, and a single run would show either of those two numbers.
Is there access to the server?Without it, the reasons are visible, but their source is not. With an nginx or Apache configuration in hand, the parsing is shorter and the report becomes a list of specific edits instead of a list of hypotheses.
Is there field dataSearch Console adds the Core Web Vitals report to our metrics—what real devices and networks have seen. Our curl doesn't see that, and it's better to say it before than after.
Language versions and subdomainsEach branch is measured separately, because the redirect to the language version can eat hundreds of milliseconds of the first visit. In one measured store, 301 per language branch sits within 789.4ms of the first response.
"After" measurement requiredFixing the difference is a second cycle of measurements a week or two after the edits, with the same tools and from the same points. The same document does not cover it.
Who it's for
Situations where this service delivers results
Scenario 1 of 5
There are complaints about braking, but there are no numbers
"Site slows down" is a phrase from the manager's letter, not a diagnosis. You open the same site from your laptop and it opens fine. The audit turns the complaint into numbers: the median of several measurements on three types of pages, date, method. Next, you can see if the delay is consistent or if someone caught one failed network hop.
We'll review your situation in a free audit
Scenario 2 of 5
The developer says one thing, the free test says another
The developer refers to a score of 90, the marketer shows a red scale from another service, and you decide who to pay for the work. We give a third measurement with a recorded method: how many repetitions, from which point, at what time. This is not an examination or an arbitrage - these are numbers that can be checked and repeated.
Scenario 3 of 5
The catalog has grown, and everyone is sure that it is the number of products
Suspicion is common and often false. In the measured professional cosmetics store, the catalog for 5,561 items gives the first response in 801.2 ms with a markup weight of only 153.8 KB. A light document and a slow response mean one thing: the server is waiting, not the browser. These are different jobs and different money.
Scenario 4 of 5
A redesign or move is ahead and a "before" shot is needed
After the launch of the new site, there is nothing to compare it with: no one has removed the old numbers, and the conversation "it has gotten worse" is based on feelings. The measurement for work takes several days and closes months of disputes.
Scenario 5 of 5
Advertising is running, but it is not known whether people reached the first screen or not
In the measured landing page of the SaaS platform, we found zero counters on the page. The speed there was the best in the sample - 220.6ms to the first byte - and registrations are not measured at all. The meter itself does not improve anything, it only makes it possible to see; without it, neither losses nor gains are visible.
What's included
Complete list of work and what you get as a result
Measurements of the first response and full download on the main, in the category and in the card - several repetitions each with a median so that the number does not depend on one run
Weight of the document before and after compression, checking if gzip or brotli are enabled at all
Analysis of the chain of redirects from the bare domain to the final address: every extra step is added to every first visit
A list of other people's scripts with an assessment of the contribution of each one, so that the decision to "remove or leave" is made by you, and not by the person who put it
Core Web Vitals report in Search Console, if available - field data of real visitors next to our measurements
A written report with numbers and reasons, ranked by impact, not complexity: you can go to any developer with it
Raw measurements with date and method — so that six months later there is something to compare with
Re-measurement after corrections with the same tools: the difference is in the numbers, not in the feeling
When this service isn't right
What's not included — so there are no surprises at delivery
Correcting what was found is separate work with a separate assessment
Optimization of the code of other people's modules and plugins, which were not written by us
Moving to another hosting and paying for servers
Rewriting the template from scratch
Advertising and purchasing traffic
Process steps
Transparent stages with approval at every step
Total duration:3–7 days
1
Measurements without access
1 working day
The first answer, the full download and the weight of the document on three types of pages, several repetitions at different hours. Right here — redirects at the entrance, headers and compression.
2
Page inventory
1 working day
Images: how many, in what formats, how many with delayed download. Other people's scripts: what is connected and what it entails. This part accumulates over the years and is almost never reviewed.
3
Field data and configuration
1-2 working days
Search Console, Core Web Vitals report, server settings — if access is granted. Here, our measurements meet what real visitors saw on their devices.
4
Analyzing the reasons
1-2 working days
Each slow number is tied to a reason: server latency, markup weight, images, someone else's code. What is not explained by the collected data remains in the report as unexplained, not as a guess.
5
Report and conversation on it
1 working day
A document with numbers, reasons and a list of works in order of impact. Then 30-40 minutes of point-by-point conversation — with your developer, if you have one.
6
Re-measurement after corrections
in a separate step, after works
Same pages, same method, new date. Without this step, the difference will have to be negotiated on the basis of feelings, not numbers.
Did not find your case?
Describe how it works on your side — we will tell you whether “Site speed audit” fits and what it means in your situation. No brief and no call: one question, one answer.
Cases
Tasks and results in numbers — all metrics measured by us
the Ukrainian SaaS platform for rewriting product descriptions is our technical dimension of the current website
Task
Check if the landing page does not lose registration pending.
Solution
We measured the first response of the server, the full download and the weight of the document; separately checked the response headers and the list of connected scripts.
Result
A TTFB of 220.6ms and a full load of 329.8ms with 140.8KB of HTML is the fastest response of the 16 sites measured. Speed isn't an issue here, and we said so. Instead, the measurement showed something else: there is no counter on the landing page, so registrations are not measured at all, and robots.txt refers to sitemap.xml, which returns a 404. Measurement 07/31/2026.
a one-page website of a consulting company is our technical dimension of an operational site
Task
Understand how difficult a one-page site turned out to be after filling.
Solution
Measurement of the first response, complete download and weight of the document; along the way, we checked robots.txt and the presence of structured data.
Result
TTFB 254ms, full load 342.6ms, HTML 102.1KB, the lightest document among the 16 sites measured. Analytics works here: GA4 and gtag are connected, which is rather an exception in the sample. The defects found lie beyond speed: robots.txt refers to sitemap.xml with a 404 code, and there are no structured data blocks on the site. Measured on 07/31/2026.
online store of professional cosmetics, catalog of over 5,000 items — our technical measurement of an operating store
Task
Find out why the catalog opens noticeably slower than other stores on the same platform.
Solution
They measured the main and issuing catalog, compared the weight of the markings with other measured stores, checked the site map and the presence of counters.
Result
TTFB of 801.2ms and full load of 930.7ms with only 153.8KB of HTML - the latency is on the server side, not the page size. The catalog was calculated by regular store search: 5,561 products. By the way: /sitemap.xml returns 200 with an empty body, there are no counters on the main one. Measured on 07/31/2026.
Technologies & integrations
What we build on and what it connects to
Stack
curl with repetitions and median - separates stable delay from random spike
Chrome DevTools — resource loading order; numbers depend on the car from which we look
Lighthouse is like a checklist; the score is not included in the report, it jumps between runs
PageSpeed Insights is for the CrUX field data, not the score
WebPageTest - measurements from other points: checking whether it's not a matter of geography
Core Web Vitals report in Search Console - Real devices, requires verified rights
nginx or Apache configuration - without access, the reasons remain conjecture
gzip / brotli and caching headers is the cheapest thing to disable
HTTP/2 - we check the version, but it does not save the slow server
Integrations
Google Search Console
GA4
Google Tag Manager
Cloudflare
PageSpeed Insights API
CrUX
Measurement by hand against the score of the automatic test
How this option differs from the alternative
PageSpeed score or SEO service auto-reportOur approach
Where does the number come from?one run of one page at the time you clicked the buttonmedian of multiple replicates on three page types, with date and method described
What is done with reasona list of recommendations generated without knowledge of your engine and your moduleseach number is tied to a reason in your server, template, or script set
Order of workby the weight of the item in the score formulaby impact on your pages
What can't be touchedadvises to remove everything that slows down, including what brings applicationsbefore the advice to remove the script, we ask who uses it and what is tied to it
Checking the resulta new score that changes even without any changes from youre-measurement by the same method — difference in milliseconds and kilobytes
What we need from you
We can't start without this — best to prepare in advance
1Site address - nothing else is needed for the first measurement.
2Access Search Console if you want to see field data from actual visitors in your report, not just our measurements.
3Access to hosting or administrator contact: without it, some of the reasons are visible, but it is not visible what caused them.
4Understanding which pages are important to you - it makes sense to measure where the money is coming from, not a random address.
5One person from your side who can give access and answer why each of the other people's scripts is on the site.
If something is missing — let us know, we'll help you gather it or do it as a separate task.
FAQ
Most frequently asked questions — with concrete answers
How is your audit different from the free PageSpeed Insights?
PageSpeed provides a score and an automatically generated recommendation list. He doesn't know what kind of engine you have, what modules are there and which of the listed items can't be touched. We measure several types of pages by hand several times, take the median, read the response headers and configuration, and then say that this is really your problem. A score of 90 at the first server response in one and a half seconds is a very real situation.
How long does the audit last?
3-7 business days depending on site size. Measurements are the first day; then there is analysis of the reasons, reading the configuration and writing the report. We make a free preliminary measurement in 2-3 days.
What numbers are considered normal?
There is no universal norm, and we do not name it. Instead, let's put your numbers next to the range we measured ourselves: in a sample of 24 sites, the first response ranged from 126.3 to 1,544.6 ms, and the HTML weight ranged from 102.1 to 751.2 KB. If you are at the upper end of both ranges, it is no longer a feeling.
What access do you need and why?
For the first measurement, only the address. Search Console is needed for the Core Web Vitals report: this is the only source of data about the real devices and networks of your visitors, our curl does not see it. Access to the hosting is required to read the configuration and see the cause of the delay, not just its effect. If there are no accesses, the audit is done anyway - just part of the points in the report will be formulated as an assumption, and we will sign it.
And if after the audit it turns out that there is nothing to fix?
It also happens, and we say it directly. In the sample, there were sites with the first response of 220-254 ms and the easiest markup - there speed is not a problem, and you need to look elsewhere: in the offer, in prices, in the fact that a person does not find what he needs. Selling a month of optimization in such a situation is not fair.
Are you correcting or just measuring?
Both, but these are different works with different estimates. The audit ends with a report and a list of works in order of impact. Then you can give this list to your developer - the document is yours. If we fix it, each item has its own rating, and you see what you're paying for.
Our site is fast, but it still takes a long time from the phone - why?
Because the server's first response is our part of the measurement, not the entire human experience. It includes its network, its device, the weight of pictures and the time it takes to execute scripts. The mobile viewport on the site is a necessary minimum, not a proof of convenience: only live sessions show whether the checkout is done with a thumb. In B2B directories, by the way, part of the buyers are actually sitting at a desktop, and there mobile speed is not the first priority - it is more honest to say than to sell mobile optimization to everyone equally.
Will speed affect Google rankings and sales?
No one promises positions, and we will not. Speed is one of the signals, and Google confirms it, but no one publishes the weight of an individual signal. There is an industry benchmark for sales: according to the Google/SOASTA study "The State of Online Retail Performance" (2017), when loading time increases from 1 to 3 seconds, the probability of abandonment increases by approximately 32%. This is a market average, not our promise: your audience and your product may behave differently. And the limit here is obvious — speed removes technical loss, but does not create demand.
Why do you measure multiple times instead of just one?
Because one measurement catches randomness: a neighboring process on the server, a cold cache, a jump in the network. We take the median of multiple replicates on each page type. The difference is significant - on one of the measured sites, the main one was delivered four times slower than the product card, and one measurement would have shown either of these two figures.
How do you know if the fix really helped?
Re-measurement with the same tools, from the same points and on the same pages, a week or two after the edits. We leave you with the raw numbers of the first measurement with the date just for that. If the method in the second measurement is different, there is nothing to compare: two different services will give different numbers on the same site.
Send the site address - we will take the rest for the first measurement ourselves.
The answer is a table of measurements for three types of pages, the causes found in the order of influence and a direct answer, whether there is anything to fix here. If the site is fast, that's what you'll hear.
From measured casesA TTFB of 220.6ms and a full load of 329.8ms with 140.8KB of HTML is the fastest response of the 16 sites measured
There is no price list on the site on purpose: the same work differs several times over between two clients, and a “from” figure explains nothing in that case. First a free audit — we count your pages, duplicates and speed — then we name the sum and the deadline and fix both in the contract.