How we measure

Every agency says it builds fast, accessible, secure software. The claim is worth exactly as much as the threshold behind it. This page publishes the budget we hold work to, what our own two public surfaces score against it, and the method — so the numbers can be repeated by anyone who disagrees with them.

1. The budget

These are the thresholds a build has to clear before we call it finished. They are stricter than the median of the field, deliberately: a budget set at the average only guarantees an average result.

2. What this site scores

A budget nobody applies to themselves is a sales slide. Here is www.inger.sk, measured with the method in section 5 on the date at the top of this page.

312 ms

LCP, mobile, cold

4 KB

JavaScript

9

Requests

0

Third-party requests

The four KB of JavaScript is the theme toggle, the mobile menu and the scroll reveal. There is no framework on this site, no analytics, no tag manager, no chat widget and no font CDN — which is why the third-party count is zero rather than low. You can confirm that number without trusting us: open the network panel and count the hosts, or read the content-security-policy header printed on our trust page, which is default-src 'self' and would block a third party even if one were added by accident.

The honest caveat, stated before anyone else states it for us: this is a static marketing site and the comparison set in section 4 is e-commerce. It is not a like-for-like contest, and we are not claiming to be faster than a shop that has to render a cart. The defensible claim is narrower and more useful: we hold our own surfaces to the same budget we sell, and we publish the result. For the e-commerce version of that proof, see the next section.

3. What an e-commerce build scores

TruckerShop is a B2B storefront we rebuilt on PrestaShop 9 — a real shop, with a real catalogue, payments and search, measured the same way on the same day.

Scope, so the table is not read as more than it is: these are front-end performance and transport-security measurements of the storefront homepage, taken from outside with no access to the shop. They are not a full audit — accessibility, checkout, PDP behaviour and back-office are separate work and are not represented here. The three third-party requests are the shop's error monitoring and analytics, which are deliberate.

4. What the field looks like

In July 2026 we measured 25 European award-winning e-shops — Heureka ShopRoku, Shopping Awards, Digital Commerce Award and Netcomm winners — with the same tool, to find out whether an award means the engineering underneath is sound.

Two things follow from that, and only two. First, an award is not an engineering audit — the winners are rewarded for merchandising, logistics and customer care, and the numbers above show the build underneath is frequently not what a technical buyer would sign off. Second, the budget is achievable: the best performer in the set, Bergzeit, runs on 37 requests and 2 third parties and won its category, so a heavy front end is a choice rather than a cost of doing business.

We publish this set aggregated and unnamed on purpose. A single cold homepage measurement is a snapshot, not a verdict on a shop — it does not touch the consent flow, it is one page and one product page, and axe reliably covers only part of WCAG. That is enough to hold ourselves to a number, and not enough to publish someone else's name beside a bad one. Names appear here only when the result is good.

5. Method

• Tool — Playwright with Chromium, driving the browser's own PerformanceObserver for LCP, FCP and CLS, and the CDP network layer for transfer sizes. Not Lighthouse scores; the underlying measurements.
• Device — mobile emulation, 412 × 915, DPR 2, touch, Android UA, sk-SK locale.
• Network — real-world, no synthetic throttling, cold cache, fresh browser context per run. Throttled numbers are a different measurement and would be several times higher; where a page is measured under throttling we say so.
• Runs — three per URL, median reported. A single run is noise: on this site's own measurements the slowest run of three came out three times the median.
• Accessibility — axe-core against WCAG 2.1 A/AA and 2.2 AA, in both light and dark theme, with reduced motion forced on so no colour is read mid-transition.
• Headers — read from the live response rather than from configuration. The two are not the same document; ours are printed in full on the trust page.

The accessibility scan is worth one more sentence, because it is the metric most often quoted without its limits. Automated tooling detects roughly a third of the WCAG success criteria; it will not tell you whether your alt text is meaningful, whether the tab order makes sense, or whether an error message is understandable. Zero violations means zero of the machine-detectable class, which is a floor and not a certificate.

6. What we do not measure, and therefore do not claim

Two figures a buyer might expect on a page like this are missing, and their absence is the point.

• Uptime. An external monitor does watch this site from outside our network, and it has caught real outages in the hosting layer - so the gap is not that nobody is looking. What we will not print is a tidy availability percentage. A free-tier check from a single region, at five-minute resolution, cannot tell a ten-minute outage from a fifteen-minute one, and a figure quoted to two decimals off that basis would be more precise than the measurement behind it. We would rather say what the instrument can and cannot see than round it into a number that sounds like an SLA.
• Field data. Everything above is a lab measurement from one connection. It is reproducible, which is its strength, but it is not what your users in aggregate experience over 28 days. Where field data matters for a project, that is Chrome UX Report territory and needs enough traffic to exist at all.

Both of those are measurement limits, not oversights, and this page changes when they do.

7. Reproducing this

Nothing here needs our cooperation to check. The performance figures come from a public URL with a public browser; the security headers come from curl -sI https://www.inger.sk/; the accessibility result comes from axe-core, which is open source, against pages that require no login. If you measure any of it and get a materially different answer, we would rather hear about it than not — info@inger.sk.