• Websites

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.

See how it works
Price
after a free audit
Guarantee
30 days after project sign-off
What do we measure?
first response, HTML weight, images, third-party scripts, cache — on three types of pages
Price
after a free audit
Guarantee
30
days after project sign-off
What do we measure?
first response, HTML weight, images, third-party scripts, cache — on three types of pages
Spread of the first answer in its own dimension
126.3–1,544.6
ms, 16 sites, July 31–August 1, 2026
HTML weight distribution is the same
102.1–751.2
KB; the heaviest document is four times larger than the median
A typical find
the main is four times slower than the card: 1,544.6 vs. 391.4 ms
Term of works
6–20
working days, depends on what we find
Before the estimate
free measurement with analysis of reasons, 2-3 working days
What we do not promise
a specific score in a synthetic test
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
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 audit

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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 and paperwork

We work officially

Contract, act and invoice — for every project, not just large ones.

Trusted by6 brands

Trusted by: Kvant Energy, GYPSUN, Naturel Cosmetics, Pancer Protection, LUGI, BeeTech

Terms fixed in writing8 points

  • 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.

  • Sites in nine countries

    Our sites run in nine countries: besides Ukraine — Poland, Germany, Austria, England, 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.

  • 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.

  • Sites in nine countries

    Our sites run in nine countries: besides Ukraine — Poland, Germany, Austria, England, 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.

We sign NDAs on request. After completing the work, we delete our access to your services ourselves.

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.

Viola

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

  1. Access to the site and hosting with the right to change the server configuration — without it, part of the work is simply not available.
  2. Access to the platform admin: part of the reason is hidden in the modules, not in the code.
  3. List of pages that are critical for you: main, category, card, shopping cart.
  4. Access to analytics and Search Console, if connected.
  5. The answer is which third-party scripts and widgets should definitely remain, and which ones can be decided by us.
  6. One 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?

6–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

View cases
  • Reply within 2 hours
  • No commitment
  • We work under a contract

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.