• Technical SEO · gzip and brotli

Response headers and cache: the cheapest part of speed

Configuring caching and HTTP headers is work with the server configuration, not with the page: enable response compression, set cache rules separately for markup and separately for statics, declare a secure connection. At the same time, we do not touch the template and code at all. The detail that is most often confused: no-cache and no-store are different things. The first means "save, but ask every time", the second - "don't save anywhere", and it is the second that stands on half of the pages, which are then considered slow.

See how it works
Price
after a free audit
Guarantee
30 days after project sign-off
What do we read first?
compression, protocol version, cache rules for HTML and statics, term of transport protection
after a free audit
Price
30
Guarantee

days after project sign-off

compression, protocol version, cache rules for HTML and statics, term of transport protection
What do we read first?
143.6
Measured compression effect

KB of markup comes as 22.5 KB — a difference of 6.4 times, irrigation systems store, measurement 08/01/2026

2-10
Term of works

working days; long edge — when the cache ban is set by the CMS itself

free title check, 1-2 business days, no credits required
Before the estimate
do not shrink the page itself: 554 KB of category markup leaves 554 KB to compress
What headlines don't do
items and conversion growth is about cleaning up extra bytes, not creating demand
What we do not promise
What's included

Complete list of work and what you get as a result

  • We turn on compression and check it separately on markup, styles, scripts and fonts - the browser pulls many times fewer bytes for the same page
  • We transfer the site to HTTP/2, if the server supports it: resources go in parallel with one connection, and not in a queue one at a time
  • We set cache rules separately for markup and separately for statics - the page is checked every time, files with a stable name lie in the browser for months
  • We remove the caching ban where it was set just in case and forgotten
  • We leave without cache what really cannot be cached: shopping cart, registration, personal account, personal prices
  • We set up a check for relevance through ETag and Last-Modified — updates reach the visitor without manually resetting the cache
  • We add a version to the static file names: the updated file has a new address, and the outdated copy cannot be physically displayed
  • We announce strict transport protection with a reasonable time limit - the browser stops making the first unprotected request
  • We install a basic set of security headers: it costs nothing and removes some of the typical risks
  • We measure before and after on the same pages and give the difference in bytes and milliseconds together with the finished configuration fragment
When this service isn't right

What's not included — so there are no surprises at delivery

  • Setting up external cache services as a separate infrastructure
  • CMS code optimization
  • Transfer to another hosting
  • Work with page content
Who it's for

Situations where this service delivers results

Scenario 1 of 5

The page takes a long time to open, but everything is fine with the code

The classic situation is when the server gives the markup without compression. In the watering shop, the same document weighs 143.6KB raw and 22.5KB compressed—six and a half times the difference obtained by a checkmark in the configuration rather than by reworking the template.

We'll review your situation in a free audit

Free response header checker

Headers are what your server tells the browser about each page: to compress or not, to cache or not, to require a secure connection or not. They are checked in minutes, and the effect of the correction is greater than that of reworking the pages.

What we measure

  • Response compressionIs it on and which one. Measured example: a 143.6KB page in compressed form takes 22.5KB, a six-fold difference from the server's configuration.
  • Protocol versionDoes the modern version work with parallel resource transfer. It is not present everywhere in the measured sample.
  • Caching rulesWhat the server says about the return visit. A page with a complete prohibition of caching is overloaded every time from scratch - we encountered this on the main page of a large store.
  • Static cachingDo images, styles and scripts have a long shelf life. This is the cheapest way to increase return visits.
  • A secure connection is requiredHas strict transport protection been declared and for what period. In the sample, we recorded the correct value per year.
  • Security headersA basic set that costs nothing and removes some of the risks.

What you get

  • A table of current headings by resource type with an explanation of what each means in practice.
  • A ready set of rules for your server.
  • An estimate of how many bytes and time each change gives.
  • A short conversation about the finds.

Timeline: 1-2 working days

Why is it free

Because the check takes minutes, and your administrator will make some of the changes himself according to our list. We will not sell hours where the configuration is sufficient.

What's next

If everything is set, let's say it directly. If not, let's call it robots; it's usually a few days, including checking that nothing is broken.

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

  • Who makes the headline?Server configuration - editing for a few minutes. The title, which is added by the CMS module or the external layer in front of the site, must first be found: it is this search, not editing, that eats up the main part of the term.
  • Is there access to the configurationWe make our own server. Cheap shared hosting often gives only part of the directives, and then we write a list to support the hoster, and the deadline starts to depend on their response queue.
  • How many pages cannot be cachedA shop with a basket and a cabinet are a few exceptions. The B2B catalog, where the price depends on the buyer's contract, requires analyzing each type of page separately, because an error here shows someone else's price.
  • The presence of a layer in front of the siteCloudflare or another proxy has its own rules and rewrites some of the headers. The work doubles: match the server configuration with the layer rules and verify that both say the same thing.
  • Static stateFiles with stable names are cached long and without risk. If the styles and scripts are overwritten over the old names, versioning must be introduced first - otherwise the long cache will give people the old layout.
Cases

Tasks and results in numbers — all metrics measured by us

store of automatic and drip irrigation systems, catalog of 300 items in 40 categories

Task
Check how efficiently the server is serving pages and where exactly bytes are lost.
Solution
Reading headings on the main page, in the category and in the product card, five measurements of the first response with the median, comparison of the weight of the document with and without compression.
Result
Brotli compression enabled: 143.6 KB of main markup comes to the browser as 22.5 KB - 6.4 times less without any template edit. nginx server with HTTP/2, first response 235 ms on median of five measurements with a spread of 226–238 ms, full document 262 ms; the product card gives the first byte in 186 ms. An unsecured address gives a permanent transition to a secure one. What compression doesn't do: A category page with 100 products weighs in at 554KB of markup, and that's already the template's job. Defects of another layer were found nearby: /sitemap.xml gives the code 200 and zero bytes, there are no blocks of structured data on the site, the www address is available without switching to the main domain. Measurement 01.08.2026.

online store of the official seller of garden tools

Task
Check the transport settings of the store with a valid certificate.
Solution
Read headers on multiple page types, check strict transport protection expiration and protocol version, measure first response and markup weights.
Result
Strict transport protection is declared with a term of 31,536,000 seconds - exactly one year, during which the browser will go to the site only with a protected connection, even if a person typed the address without it. HTTP/2 works, mobile viewport is set. The first response is 625 ms, the full document is 752.5 ms with a markup weight of 350.4 KB - and here the ceiling is no longer in the headers: on a PHP 7.3.33 server, without support since December 2021. The protection year header does not make the site secure, it only removes the unprotected first request. Separately, the sitemap has 1.18 MB and 4,236 records for 1,300 unique addresses — a layer that the headers do not touch at all. Measured on 07/31/2026.

Did not find your case?

Describe how it works on your side — we will tell you whether “HTTP headers and caching” fits and what it means in your situation. No brief and no call: one question, one answer.

Process steps

Transparent stages with approval at every step

Total duration:2–10 days

  1. Reading current headlines

    1 working day

    We record the answers on the main page, in the category, in the card and on statics. The output is a table: what's coming now, what it means for the browser, and how many bytes it costs. Access is not required at this step.

  2. Header source search

    1-2 working days

    We find out who exactly puts each header: server, CMS module or proxy in front of the site. The step is skipped most often — and then the configuration that is interrupted by the layer above is ruled.

  3. Protocol compression and versioning

    1-2 working days

    Enable compression for text types, check it on each of them separately, and switch to HTTP/2 if the server is ready. Here we fix the weight before and after for each type of page.

  4. Cache rules

    1-3 working days

    Markup — short and with a check of relevance, statics — for a long time, personal pages — without a cache at all. Along with file name versioning, without which long storage is dangerous.

  5. Transport protection and safety

    1 working day

    We turn on strict transport protection with an increasing term, and not once a year. We put a basic set of security headers nearby and check that none of them break widgets and payment forms.

  6. Repeat measurements and transfer

    1 working day

    Same pages, same method, difference in bytes and milliseconds. We give a fragment of the configuration in text, so that when moving to another server it can be easily transferred.

Technologies & integrations

What we build on and what it connects to

Stack

  • gzip and brotli — text compression on the fly. Markup and styles are compressed multiple times, and photos and videos are already compressed: there it is a useless consumption of the processor
  • HTTP/2 — parallel threads in a single connection. It does not cure a slow server: the first answer will remain the same as it was
  • Cache-Control is the main lever. Manages the browser and proxy, but not the internal cache of your CMS: these are two different layers that are easy to confuse
  • ETag and Last-Modified - short answer "not changed" instead of the full file. Nginx, when compressed on the fly, makes the ETag weak, and part of the proxy stops taking it into account
  • HSTS is a forward secure connection requirement. It is withdrawn only for a period of time: the wrong year will have to wait a year
  • Nginx, Apache, Cloudflare are where the header is born. If Cloudflare is on top, it has the final say, not your config

Integrations

  • Cloudflare
  • Google Search Console
  • GA4
  • hosting panel
Headers on the server against the caching module in the admin

How this option differs from the alternative

Where the result livesin the server configuration - going through a CMS update and moving to another hosting
Acceleratingtransfer: fewer bytes in transit and fewer re-downloads on the second visit
Risk of errorincorrect term on statics; treated by file name versioning
What can be seen on inspectionthe header in the answer is read from the outside, without access, in seconds
What we need from you

We can't start without this — best to prepare in advance

  1. Site address for preliminary verification - accesses are not required for it.
  2. Access to the server configuration or contact the administrator who changes it.
  3. List of pages that cannot be cached according to business logic: shopping cart, checkout, office, personal prices.
  4. Allow a short test period: cache rules are tested on a live site, not a copy.
  5. The answer is whether there is an external proxy in front of the site - it depends on where exactly to rule.

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 noticeable is the compression?

Multiple, and precisely on the text. In the measured irrigation store, the main weighs 143.6 KB raw and 22.5 KB compressed - a difference of 6.4 times obtained by the server tuning, not by reworking the template. There will be no gain: photos, videos and archives are already compressed internally, and re-compression will only waste the processor. Therefore, we turn it on selectively - for markup, styles, scripts and fonts.

Are no-cache and no-store the same thing?

No, and confusion costs the most here. No-cache means "keep a copy, but before showing it, ask the server if it is still up to date" - the server replies with a short "no change", and the page is drawn from the disk. No-store means "do not store anywhere at all" - each visit collects a page from scratch. They put the second when they want the first, and then wonder why the second visit is not faster than the first.

Which pages cannot be cached?

Those where the content depends on a specific person: shopping cart, checkout, personal account, and in B2B — pages with a negotiated price. Everything else can and should be cached. The most common mistake is to disable the cache on the entire site just in case. We met a large store, where the main page was given with a complete prohibition of caching and at the same time it was the slowest page of the site.

How will updates reach the visitor if everything is cached?

Two ways, and they are different for markup and for statics. The markup is cached with an up-to-date check: the browser asks the server if the page has changed and receives a short answer instead of a full download. We sign statics with the version in the file name — styles, scripts, images. The updated file receives a new address, and the old copy simply ceases to be necessary, so the storage period can be set long without risk.

Should you turn on HSTS once a year and add preload?

Our recommendation: increase the term, take your time to preload. First, we set a few minutes, make sure that the entire site and all subdomains really work over a secure connection, then a week, then a year. The reason is simple: the title is removed only from time to time. If you declare a year, and a week later a subdomain is found without a certificate, visitors' browsers will still refuse to open it. The measured garden tool store has the correct year - this is a normal final value, but it is better to get to it by stairs. Preload is a list in the browser itself; it takes longer to get out than to get in.

We have Cloudflare - do we still need to configure the headers on the server?

Yes, and in two places at the same time. The proxy in front of the site has its own rules and overwrites some of the headers, so the server configuration and the layer rules must say the same thing, otherwise you're controlling something that will still be broken. The first step is to find out where each headline comes from. And separately: an external cache service on top of an unconfigured server is to pay twice, first it makes sense to squeeze out what is already there.

Will it raise the bar?

No one promises items, and we will not. The mechanism here is different: a person who left without waiting for the page, saw neither the product nor the price, cannot be converted by any offer. Headlines remove the technical loss, they do not create demand: if the price is higher than the market, the fast page will simply show the reason to leave faster. And one more limit: what we are measuring is the server side. The time until the page is fully ready for a real visitor also depends on his phone, network and image weight.

How long does the work last and what does the deadline depend on?

From two days, if the headers are set by the server and there is access to the configuration. It takes longer in two cases: the prohibition of caching is sewn into the logic of the CMS, or there is a layer in front of the site that rewrites the responses. Then the main time is spent not on editing, but on finding the person who puts the title. The upper limit in our practice is ten working days, and they include a check that the shopping cart, forms and widgets are not broken after the changes.

Send the site address - headers are read from the outside, access is not required.

The answer is a table of current headers by resource type, an estimate in bytes and milliseconds for each change, and a ready-made set of rules for your server. If everything is already set up, let's say so in the first email.

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.