Speeding up site loading: measurements, causes, fixes
Speeding up site loading begins with measurements, not with a list of favorite techniques: first we measure the first response of the server, the weight of the markup and the composition of the page separately on the main page, in the category and in the card, and only then we call the works. Each line of the estimate is tied to the found cause. In our own sample of 16 measured 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, with the slowest and fastest stores being on the same engine. It is usually not the platform or the volume of the catalog that slows down, but the theme, set of modules and images.
first response, HTML weight, images, third-party scripts, cache — on three types of pages
after a free audit
Price
30
Guarantee
days after project sign-off
first response, HTML weight, images, third-party scripts, cache — on three types of pages
What do we measure?
126.3–1,544.6
Spread of the first answer in its own dimension
ms, 16 sites, July 31–August 1, 2026
102.1–751.2
HTML weight distribution is the same
KB; the heaviest document is four times larger than the median
the main is four times slower than the card: 1,544.6 vs. 391.4 ms
A typical find
5-20
Term of works
working days, depends on what we find
free measurement with analysis of reasons, 2-3 working days
Before the estimate
a specific score in a synthetic test
What we do not promise
Process steps
Transparent stages with approval at every step
Total duration:5–20 days
1
Measurements and analysis of reasons
2-3 working days
First response and full load on three page types with multi-attempt median, markup weight before and after compression, image and third-party script inventory, cache headers. The output lists the reasons in order of influence.
2
Server part
1-2 working days
Compression, correct cache headers, protocol version, chain of transitions at the input. The cheapest gain during operation: almost nothing breaks here, and the difference is visible in the same measurement.
3
Image
1-3 working days
Delayed loading everywhere except the first screen, modern formats, sizes for real containers. Separately, we check whether it has become visually worse: photo compression has a limit beyond which it is noticeable to the buyer.
4
Revision of third-party scripts
1-2 working days
A list of what is loading on the page, with an explanation of how much time each item costs. Leave it or remove it is your decision - we show the price of each in milliseconds and check that nothing is broken after disconnection.
5
The most difficult pattern and base
2-8 working days
Category page with full list, query duplicates, indexes. The longest and least predictable stage is the one that stretches the upper limit of the term, so it stands in separate lines in the estimate.
6
Repeat measurements and document
1 working day
Same methods, same pages, same number of attempts. A "before and after" comparison for each point and a brief instruction on how not to lose the result after six months.
Technologies & integrations
What we build on and what it connects to
Stack
nginx - brotli or gzip compression and cache headers. The fastest win, but only for access to the server configuration
HTTP/2 — parallel transfer of files in one connection. It does not reduce the number of requests: it is not felt on a page with 118 images
WebP / AVIF - image formats. Photo catalogs give the most; for a dozen pictures, the savings are imperceptible
loading="lazy" — delayed loading. In the images of the first screen, it is harmful: it delays what a person sees immediately
Cloudflare caches and returns static closer to the visitor. It will not speed up the page with no-store
Cache of pages and fragments. The limit here is business, not technical: balances and prices cannot be cached for a long time
MySQL / PostgreSQL — indexes and query plan. Works when time is sitting in the base; if in the template, the indexes will not change anything
Integrations
Cloudflare
Google Search Console - Core Web Vitals Report
GA4
Google Tag Manager
PageSpeed Insights
Prometheus / Grafana — monitoring after works
What's included
Complete list of work and what you get as a result
Measurements for works on three types of pages - a median of five to seven attempts, not one random run: otherwise, there is nothing to compare with in a week
Server-side compression, brotli or gzip: In a measured watering store, 143.6KB markup goes over the network as 22.5KB, and this is a tweak, not a code rewrite
Page cache audit: The no-store header on the main page means that it is re-collected for each visitor, which is what we found in Measured Lingerie Store
Images: delayed loading, modern formats, dimensions for real containers — so that the browser does not drag to the first screen what a person has not yet seen
Revision of third-party scripts with your decision on each: what to remove, what to postpone, what to load by event
The hardest page to optimize for a template is usually a category with a full list of products
Removing duplicate requests to the database and viewing indexes when the time is spent in the database, not in return
HTTP/2 and ingress chain validation: redundant redirect sitting inside the first response and looking like a slow server
Repeated measurements using the same methods and a document with a "before and after" comparison for each point
The rule for your team to follow: a new script has been added - remeasure it; if necessary, we monitor the response time
Guarantee of 30 calendar days for completed works
When this service isn't right
What's not included — so there are no surprises at delivery
Design change - Acceleration works within the existing view
Transfer to another hosting and permanent server administration
Rewriting the site to another platform
Optimization of third-party services that you do not control
Guarantee of a specific score in synthetic tests
Who it's for
Situations where this service delivers results
Scenario 1 of 4
Slow main with a normal directory
The most frequent layout we've seen in dimensions. In a lingerie retail store, the card is rendered in 391.4 ms, the category page in 473.2 ms, and the main page in 1,544.6 ms. The problem was not with the server: the main one was served with no-store, that is, without page cache, and was assembled anew for each visitor. As long as the "site in general" is measured in one run, such a difference is not visible at all.
We'll review your situation in a free audit
Scenario 2 of 4
The site has been covered with widgets for several years
Chat, another pixel, feedback widget, banner carousel, call tracking. Each was added separately and with a drive, together they eat up the time to the first screen. Revising this list does more than any style minification — but it's not about code, it's about consistency: one of your contractors needs every single one of these scripts.
Scenario 3 of 4
The catalog has grown, and everyone is sure that it is the number of products
We measured the store for 54,302 products — the first response was 413.8 ms. And a store for 300 items — 235 ms. There is a difference, but it does not explain the second. The volume of the catalog hits on the page of the category and on the internal search, and not on the site in general: in the same watering shop, the main one weighs 143.6 KB, and the category with 100 products is 554 KB.
Scenario 4 of 4
Pay for traffic that doesn't reach the first screen
Advertising brings a person to a page that he did not expect. We should be honest here: speed does not make the offer more attractive - if the price is higher than the market or the product is not available, a fast site will simply show a reason to leave faster. It determines something else: how many referred people will be shown your offer in general.
Acceleration by measurements against performance "under the score" of the synthetic test
How this option differs from the alternative
Optimization for PageSpeed scoreOur approach
Where does the work begin?one test run on the main pagethe median of several measurements on the main, in the category and in the card
What is considered a resulta score increase that jumps from measurement to measurementthe same numbers before and after: first response, HTML weight, number of scripts
What is done firstrecommendations of the test from top to bottom, including cosmetic oneswhat gives you the most on your site is often a page cache or a dozen redundant scripts
Risk to the siteaggressive delaying of scripts breaks the chat, analytics or payment button, and it is not immediately noticedeach change is tied to a cause and verified by repeated measurement
Free speed measurement with analysis of reasons
We do not show the synthetic test score as a diagnosis. Instead, we measure the actual numbers on your pages and attribute each slow number to a specific reason in your code or server configuration.
What we measure
The first response from the server on three types of pagesMain, category or section, card. Median of multiple measurements, not one random one. In our sample, the spread was from 126.3 ms to 1,544.6 ms — and the main one is often the slowest.
The weight of HTML and what creates itWe measure the document before and after compression. The measured watering store yielded 143.6KB of HTML and 22.5KB of brotli; another sample project — 751.2 KB on the main, four times more than the median.
ImageHow many of them, how many with delayed download, how many in modern formats. On one site measured, out of 118 images, none had delayed loading and none were in WebP; on another, 66 out of 69 were loaded delayed.
Third-party scriptsCounters, chats, widgets, remarketing. Often half the time to interactivity is something that has been added over the years and forgotten to be removed.
Caching and compression on the serverCache headers, gzip or brotli, protocol version. The site we measured served the main page with no-store — that is, no page cache at all, and each visitor collected it anew.
The most difficult page of the catalogA category with a full list is usually where the problem lies. On the measured store, a category page with 100 products weighed 554 KB, compared to 143.6 KB on the main page.
What you get
Document with measurements for three types of pages: first response, full load, weight before and after compression.
The list of causes in order of influence - from the one that gives the most to the smallest.
An assessment of what can be done quickly and what needs to be reworked.
A 30-minute conversation with an explanation of what exactly is holding you back and why.
Timeline: 2-3 working days
Why is it free
Because the measurement takes two or three days, and it is impossible to make a decision "to accelerate or not" without numbers. The document remains with you even if the work is done by another contractor.
What's next
After measurements, we give an estimate for a specific list of works with the expected effect for each. After completion, we measure again using the same methods and show the difference.
Short form: your contact and site URL
Did not find your case?
Describe how it works on your side — we will tell you whether “Acceleration of site loading” fits and what it means in your situation. No brief and no call: one question, one answer.
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
What exactly will we find on the measurementIt takes days to disable three modules and compress the image. It takes weeks to rewrite a 554KB category template. That's why we don't call the forks to measure: it would coincide with reality only by chance.
Server access levelThere is access with the right to change the configuration - compression, cache headers and the protocol are closed in an hour of operation. There is none - we act through the hoster and rely on what the tariff allows.
How many third-party scripts and who is responsible for themRemove the counter - a minute. To agree with the marketer, the advertising contractor and the owner, which five of the twelve remain, is a separate week of the calendar, and it is also on time.
Template statusThe topic, which for years was ruled by appending to the end of the file, must first be analyzed. A clean build with separate files for each page type gives the same result faster.
Number of page types and language versionsEach unique pattern and each language branch is a separate before and after measurement and a separate check. A store in three languages requires three times more measurements than a one-page site.
Does the base slow down?When time is spent on queries, work with indexes and query plan is added. This is the least predictable part, so in the estimate it goes on a separate line, and not inside the "optimization".
Cases
Tasks and results in numbers — all metrics measured by us
a store of automatic and drip irrigation systems with landscape services
Task
Maintain the rate of return on the technical catalog of a small nomenclature with deep nesting of categories.
Solution
OpenCart 3 under nginx with HTTP/2 and brotli compression. The catalog is expanded to 4 nesting levels, the filter module works in categories, images are loaded delayed, canonical on all types of pages leads to a domain without www.
Result
Measurement 08/01/2026: First server response 235ms - median of five measurements, full HTML 262ms. The weight of the main HTML is 143.6 KB, in Brotli it is 22.5 KB, that is, six times less goes on the network. Catalog of 300 products in 40 categories on 4 levels - a figure confirmed by two independent methods with a 0% discrepancy. The stock is immediately visible: a category page with 100 products weighs 554 KB compared to 143.6 KB on the main page. Defects found: the sitemap gives 200 and zero bytes, zero JSON-LD blocks, no analytics at all - so any acceleration here will be visible in our measurements, but not in conversion, because no one measures conversion.
Ukrainian SaaS platform for automatic rewriting of product descriptions
Task
Keep the public part of the product light: a page for paid traffic is not allowed to load for a long time.
Solution
Public part on Next.js with eight pages, markup SoftwareApplication, Offer, Organization, WebSite and FAQPage, PWA manifest.
Result
Measured on 07/31/2026: First server response 220.6ms, full load 329.8ms with 140.8KB HTML - fastest response among 16 sites measured. There are also defects: robots.txt refers to the site map, which does not exist, and the analytics counters on the landing page are zero — there is speed, but there is nothing to measure conversion.
wholesale store of underwear with a catalog of more than 13,000 items
Task
Check if a large directory really makes the site slow.
Solution
A store with a card and categories for 13,590 site map addresses, store markings with a list of accepted payment methods, a connected tag manager.
Result
Measured on 07/31/2026: First server response of 289ms is the third fastest response of the 16 sites measured, and that's with 13,428 product pages. But the main HTML weighs 751.2 KB — the heaviest document in the sample, four times larger than the median. The server responds quickly, and the browser receives four times more than it should: a typical case when you need to speed up the page, not the hosting.
What we need from you
We can't start without this — best to prepare in advance
1Access to the site and hosting with the right to change the server configuration — without it, part of the work is simply not available.
2Access to the platform admin: part of the reason is hidden in the modules, not in the code.
3List of pages that are critical for you: main, category, card, shopping cart.
4Access to analytics and Search Console, if connected.
5The answer is which third-party scripts and widgets should definitely remain, and which ones can be decided by us.
6One person from your side, with whom you can coordinate the disconnection of the excess in a day.
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
Why don't you focus on PageSpeed score?
Because the score is an aggregate, not a diagnosis, and it jumps from measurement to measurement even on an unchanged site. We measure things that can be tested and repeated: first server response, complete document download, weight before and after compression, number of delayed loading images, number of third-party scripts. These numbers are the same for us and for you, and they show exactly what has changed after the works. The score usually also grows, but it is a consequence, not a goal: you can adjust the page to it in such a way that a person will not be faster.
We have only the main one that is slow, and the rest is normal - does that happen?
It happens, and this is a typical case. In the measured underwear store, the product card was rendered in 391.4 ms, the category in 473.2 ms, and the main page in 1,544.6 ms, i.e. four times slower than the rest of the site. The reason was not ironic: the main one was given with the no-store header, without the page cache at all, and was assembled anew for each visitor. Plus 118 images, none of which loaded delayed. That is why we measure the three types of pages separately: one figure "per site" hides such a difference.
How much can you win on compression?
Sometimes a lot at once. The irrigation store measured by us gives 143.6 KB of markup, which is compressed to 22.5 KB in brotli — six times less goes over the network, and it is done in an hour by configuring the server. But if there are 118 uncompressed images on the same page, compressing the document will solve a small part of the problem. That's why we start with measurements, not with techniques: the order of work is determined by what we found, not what we can do most quickly.
Does the site slow down due to the large number of products?
Less often than it is written off. The store with 54,302 products we measured gives the first response in 413.8 ms, and the store with 300 items in 235 ms; at the same time, a furniture site with a catalog of 76 cards gave 374 KB of markup on the main page. Directory volume affects category page and internal search, not overall site speed. In the same watering shop, the main one weighs 143.6 KB, and a category with 100 products - 554 KB: the difference is there, not in the number of cards in the base.
Is it possible to speed it up without changing the design?
In the vast majority of cases, yes. Compression, cache, delayed loading of images, revision of third-party scripts and optimization of the most difficult template do not change the appearance of the page. The design rarely needs to be touched - when it itself requires a dozen fonts and a full-screen video on the first screen. In this case, we show how much each element costs in milliseconds, and the decision is up to you: it's a choice between appearance and speed, not a technical issue.
How long does the work last and why does the deadline shift?
5-20 working days. Measurements 2-3 days, backend 1-2, images 1-3, script revision 1-2, hardest template and base 2-8, repeated measurements 1. The upper limit is reached in two cases: you have to redo the category template or deal with the base. We call both separate estimate lines so you can see exactly what you're paying for. It is often not the code that pushes the calendar deadline, but the agreement: decisions on third-party scripts are not made by the developer.
Will the result be preserved?
If you don't add new widgets without checking, yes. The most common reason why a site becomes slow again after six months is a new set: chat, another pixel, feedback widget, banner. We leave the document with measurements and one rule: we added a script — remeasure and compare with the number in the document. If necessary, we monitor the response time so that the growth is visible immediately, and not after a quarter after a complaint.
Will there be more orders after the acceleration?
There will be no such promise. The mechanism works differently: a visitor who left before the first screen appeared did not see a product, price, or button - he cannot be converted by any offer. Speed does not create demand, it removes technical loss. Industry research ties in—Google/SOASTA (2017) on increasing load times from 1 to 3 seconds, Deloitte and Google (2020) on mobile speed—but that's a market average, not our promise to you. And separately: you can see a change in orders only where analytics is located. In the watering shop from our sample, it is not available at all, so the result there will be visible only in measurements.
Submit the site address and tell us which pages are critical for you.
The answer is measurements of three types of pages, a list of reasons in order of influence, and an estimate of what is done per hour and what needs to be revised. If it turns out that the site is fast, but the matter is different, you will hear about it in the first email.
From measured casesMeasurement 08/01/2026: First server response 235ms - median of five measurements, full HTML 262ms
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.