Page Speed ROI Calculator
What faster pages are worth when marketing tags leave the browser. Same model finance can check by hand.
Frequently asked questions
What is the difference between Quick estimate and Detailed?
Quick estimate asks for four things: your industry, annual online revenue, mobile load time and how many browser tags you would remove. Everything else starts at typical values for a Fortune 500 company in that industry. Detailed shows every input: conversion rate and order value, desktop speed, the evidence behind the speed effect, measurement value, AI agent share, costs, timing and ranges. Both modes use the same model and the same inputs, so switching never changes the result, and fields you have changed are marked Edited.
What is server-side tagging?
Instead of loading a separate script from every analytics and advertising vendor in each visitor's browser, the page sends one stream of events to a collection endpoint, and a server forwards the data to each tool. It is also called server-side event forwarding. Less third-party code can run on the visitor's device, and you control exactly which fields each vendor receives.
Does moving tags server side make pages faster?
Only when vendor JavaScript is actually removed from the page. If the same scripts still run in the browser and only the data is routed through a server, there is no speed gain, and the calculator shows zero. Several common setups keep a browser tag next to the server feed, so count only the tags you truly remove. Best of all, measure field LCP before and after on a share of traffic and enter it under Bring your own measurements.
How much revenue is 100 milliseconds worth?
Less than the famous headlines suggest. Controlled experiments point to an elasticity of about 0.05 to 0.26: a 10% faster Largest Contentful Paint gives roughly 0.5% to 2.5% more conversions, with 0.13 (about 1.3%) as the central value. Bing's randomized test found about 0.6% more revenue per 100 ms, and a Vodafone A/B test found 8% more sales from a 31% faster LCP. Correlational studies that report 7% to 10% per 100 ms are available in the calculator but labelled as not recommended.
Why is the default effect smaller than many published statistics?
Most widely quoted figures are correlational, old, or misquoted. Applied linearly, 8% per 100 ms would mean about twice the conversions for one second, roughly ten times what any controlled experiment has found. The calculator starts from experiments, caps the conversion effect at 10%, and counts less value for gains on pages that are already fast. The Myths section of the guide traces the best-known claims to their sources.
What if most visitors become AI agents shopping for people?
Step 6 handles it. Enter the share of sessions that are AI agents, or pick Today, 2028 forecast or Agent-heavy. Speed value is multiplied by the human share, because the speed experiments measured people; no study shows that a few hundred milliseconds change what an agent does. Ad-blocker and cookie-limit signal is also counted for people only. Today's share is a labelled assumption (1% for retail, media and travel, 0.5% elsewhere) because no published source gives it by industry; 2028 uses 5% and Agent-heavy 25%, based on published forecasts of agents' share of online sales by 2030. Two effects are off by default because they are unmeasured: agents responding to speed like people, and recovering agent conversions that browser tags miss. Replace the share with your own count from server logs, using declared user agents and signed requests.
Why are the headline numbers the central case, and what is the likely range?
The headline numbers use every input at its central value, so finance can reproduce them by hand in the Reproduce box. The likely range under each one comes from 10,000 simulations with every uncertain input drawn from its evidence range: P10 means 9 in 10 simulations did better than this value, and P90 means only 1 in 10 did better. The simulated median (P50) is shown in the Range of outcomes chart and sits close to the central case, because each input is drawn with its median at its central value. The chance of payback is the share of simulations in which cumulative cash flow turns positive within the horizon.
What does the Cautious, Central and Strong switch do?
It sets how strongly conversions respond to speed, based on the range of controlled experiments: an elasticity of 0.05 (Cautious), 0.13 (Central) or 0.26 (Strong). It is not a made-up percentage of a study. For the media preset it sets page views per 100 ms instead, from a publisher A/B test.
Which speed metric does it use?
Largest Contentful Paint (LCP) at the 75th percentile of real visits. Interaction to Next Paint (INP) is shown for context but not monetized separately, to avoid counting the same improvement twice. Bounce rate changes are shown as context only, because bounce, engagement and conversion are one chain.
Is the measurement value counted on top of the speed benefit?
It is on by default but always shown as its own bucket, next to speed value, with speed only, measurement only and the combined total, so you can judge speed value alone or turn measurement off in step 5. It values recovered signal (from ad blockers and short cookie limits, after consent) only as more efficient media spend on the spend it affects. It is never counted as extra revenue, because those conversions already happened; better measurement only makes them visible.
Does server-side tagging get around consent or ad blockers?
It must not get around consent: your consent platform still decides what is collected, and the calculator multiplies recovered signal by your consent rate. Some requests that ad blockers stop can be recovered with a first-party endpoint, but common filter lists also block well-known first-party paths, so recovery is partial. Longer cookie life in Safari only applies when the endpoint is served first party from the same IP range as your site.
What does it cost?
Plan for a license or subscription (enter your own quote; no vendor pricing is assumed), implementation hours, hosting, and ongoing maintenance. Hosting is estimated from your traffic: at least two servers at about $45 each per month, more at high request rates, plus any logging cost. You can replace it with a quote. The results show the highest annual license that still breaks even.
Where do the industry presets come from?
Margins come from Professor Aswath Damodaran's US margins by sector (NYU Stern, January 2026). Conversion rates, traffic, order values and speed values are labelled assumptions; no reliable public conversion benchmark exists for most industries. Replace them with your own analytics, ideally backend orders per session.
Can I save or share my numbers?
Yes. Copy share link puts your inputs in the web address, so anyone with the link sees the same case. Nothing is stored on a server. You can also copy the executive summary or print the page to PDF.
How to use the calculator
- Start with Quick estimate. Pick your industry, then set annual online revenue, mobile load time and the number of browser tags you would remove. The result updates as you drag. Switch to Detailed to see every input; your numbers carry over and the result is identical.
- Pick your industry. Defaults reflect a typical Fortune 500 company in that industry, built from public annual reports and traffic estimates. In Detailed, each one is marked Sourced or Assumption. Fields you change are marked Edited.
- Replace traffic and value with your own data. Monthly sessions, backend orders per session, average order or booking value, and gross margin.
- Enter today's speed from real visits. Use the 75th percentile LCP from the Chrome UX Report, PageSpeed Insights (field data section) or your own real-user monitoring. Lab scores are not the same thing.
- Count only the tags that leave the browser. List every vendor script on your key templates. Count a tag only if a server event fully replaces it. Consent, testing, chat, replay and any pixel a platform asks you to keep stay in the browser and save nothing.
- Better: bring your own measurements. Remove the tags for part of your traffic, compare field LCP before and after, and enter the result. The speed gain is the weakest input until you do.
- Read the evidence switch. Cautious, Central and Strong show the range of controlled experiments. Keep Central for the base case.
- Set the AI agent share. Keep Today unless you have your own count, or switch to the 2028 forecast or Agent-heavy to see how speed and measurement value shift. Speed value counts human sessions only. Count agent sessions in your server logs to replace the assumption.
- Add every cost. License or subscription quote, implementation hours, hosting (estimated from your traffic or your quote) and maintenance.
- Read the central case and its range. The headline numbers are the central case, which you can reproduce by hand. The likely range under each one is P10 to P90 of 10,000 simulations. Check the chance of payback, the value-by-speed chart and the "How defensible is this?" panel.
- Share it. Copy the executive summary, print to PDF, or copy a share link that carries your inputs. The "Reproduce the central case" box shows every step of the arithmetic.
Things to consider
- Only removed browser code saves time. Routing the same scripts through a server changes where data goes, not what the browser runs. Several ad platforms recommend keeping their browser pixel next to the server feed, which limits the speed gain.
- Work done after the page loads barely matters. In a randomized test, a 250 ms delay after page load had no detectable effect. Tags that already load late save little.
- Consent still rules. Server-side tagging is not a way around consent or privacy law. Keep your consent platform as the entry point and document what each destination receives.
- The endpoint setup matters. Longer-lived first-party cookies in Safari need an endpoint served first party from the same IP range as your site. Behind a third-party CNAME or a different IP range, cookies are still capped at 7 days.
- Ad-blocker recovery is partial. Common filter lists block well-known first-party collection paths too.
- Better measurement is not more sales. Recovered conversions already happened. Use backend orders as your baseline, because analytics rates rise after a migration when measurement improves.
- You become the data processor in the middle. The server sees every event. Plan access control, logging costs, retention and security reviews.
- Plan for measurement continuity. Run old and new collection in parallel for a few weeks, deduplicate events, and reconcile key numbers before switching off browser tags.
- Someone has to own it. Server-side setups need ongoing rule changes, new destinations and monitoring. Budget maintenance time.
Myths, misquotes and outdated statistics
Many page-speed numbers in sales decks are old, correlational or misquoted. Here is what the sources actually say, and how to cite them safely. Grades: A experiment or primary documentation, B A/B test or large dataset, C observational or platform-reported, D anecdote.
Famous speed statistics
"Amazon loses 1% of sales for every 100 ms"
One slide in a 2006 talk by a former Amazon engineer. Amazon never published the test: no method, sample, period or device split, and it reflects desktop shopping in 2006. Dollar totals are later extrapolations. Cite it as an unpublished anecdote, grade D.
"Google: half a second slower means 20% less traffic"
A 2006 test that showed 30 results instead of 10, so it changed the page as well as the speed. Google's clean 2009 delay experiment found 0.2% to 0.6% fewer searches for 100 to 400 ms of delay. Cite that instead.
"A 0.1 second faster site lifts conversions by 8%"
From a 2020 study commissioned by Google (Deloitte, "Milliseconds Make Millions"). It is correlational, used four lab metrics rather than field LCP, covered 37 mobile sites over four weeks, kept only significant coefficients, and found lead-generation conversions fell as speed improved. Applied linearly it implies about twice the conversions per second, roughly ten times any experiment. The luxury page-view figure in that report is 8.0%, not 8.6%. Grade C.
"A 100 ms delay cuts conversions by 7%"
Akamai's 2017 report measured 7.1% on phones as the slope right at the peak of its curve, where the fastest pages were mostly error pages. Its own figure for one second is about 20%, not 71%. Cross-sectional data, grade C.
"53% of mobile users abandon a site that takes more than 3 seconds"
A 2016 analysis of mobile site visits, not a survey of users, from the 3G era. If you quote it, say "visits" and "2016".
"Mobile pages take 15, 19 or 22 seconds to load"
Lab tests in 3G emulation from 2016 to 2018. Today 62% of mobile origins have good LCP of 2.5 seconds or less in real-user data (Web Almanac 2025). Outdated.
"Bounce rate rises 32% when load time goes from 1 to 3 seconds"
A 2017 model of the probability of bounce, not a measured bounce rate, and a relative change, not 32 points. The original page has been retired. Grade C.
"Every second of delay costs 7% of conversions"
An 18-year-old figure from a 2008 analyst report, known only second hand. Avoid it.
"Walmart: every 100 ms means 1% more revenue"
A 2012 internal deck says "up to" 1% per 100 ms and "up to" 2% conversion per second. Correlational, and the two numbers disagree by five times. Grade C.
"The BBC loses an extra 10% of users for every second"
An interview remark from 2016 with no method or data. For publishers, the Financial Times A/B test is better evidence: one second of delay cut articles read by 4.9% over seven days.
"Conversion drops 4.42% per second"
A 2019 agency study that did not define its speed metric, contains an arithmetic error, and compares buckets that likely mix speed with page type and intent. Grade D.
"A 2-second delay costs 4% of revenue"
Unattributed on the page that popularized it. It matches Bing's 2009 search experiment, which is about search revenue per user, not online stores.
"Every second of mobile delay can cut conversions by 20%"
"Up to" 20%, the peak of a correlational curve, from a 2018 launch post that also said faster pages do not guarantee more revenue. The tools it promoted have been retired.
"Pinterest made pages 40% faster and got 15% more signups"
It was 40% lower perceived wait time, a custom metric, during a rewrite that also changed features. Say "perceived wait time" and "rewrite".
"Rakuten 24 made its site faster and earned 53% more revenue per visitor"
A one-month A/B test on one landing page with many bundled changes; load time was only 0.4 seconds faster. A good Core Web Vitals case, not a speed elasticity.
"80% faster LCP" and "250% better CLS"
LCP from 4.5 to 2.5 seconds is a 44% improvement, and CLS from 0.25 to 0.09 is 64%. Quote the raw values instead.
Server-side tagging claims
"Server-side tagging makes your website faster"
Only if browser code is removed. A major tag platform's own server-side example still loads its browser tag, and a major social platform recommends keeping its browser pixel next to the server feed. A synthetic benchmark found routing alone gave no speed gain, while consolidating scripts cut lab LCP by 29% on a test page. Safe wording: server-side tagging can make pages faster when it replaces client-side scripts; routing the same scripts through a server does not.
"Server-side tracking recovers 30% to 40% of lost conversions"
Vendor marketing with no published method. Recovery is bounded by ad-blocker use (15% in North America in one survey, 33% in the US in another), how many blockers stop your collector, late conversions in Safari, and consent. Recovered conversions are reported conversions, not new sales.
"A tag-serving feature increases conversions by 11%"
The platform reported 11% more signals, meaning tag loads over one week in 2025. That is not conversions or revenue.
"A server-side conversion feed cuts cost per action by 13%"
A platform-wide average for advertisers who chose to adopt it. Adopters self-select, so it is not a controlled estimate for any one advertiser. Use platform figures as upper anchors only.
Search, ads and browsers
"Chrome is phasing out third-party cookies"
Outdated. In October 2025 Google confirmed Chrome keeps third-party cookies with user choice. Safari and Firefox remain the main measurement constraints.
"Core Web Vitals are a major ranking factor"
Google says they are used by its ranking systems, but good scores do not guarantee rankings and relevance comes first. Treat them as a tiebreaker; the calculator does not monetize SEO by default.
"Faster landing pages raise Quality Score and lower your cost per click"
Google describes Quality Score as a diagnostic that is not an input in the ad auction. Landing page experience matters, but there is no published conversion from speed to cost per click.
"Mobile converts X% worse than desktop"
Benchmarks disagree because they count sessions, users or orders differently: some show desktop far ahead, one recent benchmark shows mobile slightly ahead by users, another shows them equal. Always state the definition and the source.
"Ad blocking is declining" or "ad blocking is growing"
Both, depending on the cut. Global survey usage fell from 37% in 2021 to about 32%, while total users grew on mobile and in lower-income countries and fell on desktop and in high-income countries. Use values for your region and devices.
AI agents: what is proven and what is a hypothesis
"Most of your visitors will soon be AI agents"
Not supported today. Automated traffic is large, but most of it is crawling for search and model training. Visits that an AI agent makes in real time for a person are a fraction of a percent of page requests in public network data, and traffic referred from AI assistants is about 0.3% of site visits in a study of more than 100,000 sites. Published forecasts put agents at 10% to 25% of US online retail sales by 2030, which is a share of sales, not of visits. Use the Today, 2028 forecast and Agent-heavy scenarios to see what changes.
Hypothesis: "Faster pages will win the AI agents too"
Unproven. Controlled benchmarks show agents fail far more often when pages stall for 10 seconds or scripts hang for more than 5, but no study tests the 100 to 500 ms gains that removing tags can deliver. Agents wait for page events with timeouts of several seconds. The calculator therefore applies speed value to human sessions only, and offers "agents respond to speed like people" as a hypothesis switch that is off by default.
"Server-side tracking will capture every AI agent purchase"
Partly. Agents that run a full browser fire browser tags and look like people, so they are counted already, sometimes mixed into human data. Agents that fetch pages without scripts, or check out inside an assistant, never fire browser tags; a server sees their requests, declared user agents and signed requests, and the backend sees their orders. How much media efficiency that recovers has not been measured, so it is an optional scenario that is off by default, valued as efficiency and never as revenue.
Pros and cons of server-side tagging
Pros
- Less third-party JavaScript on the page when tags are actually removed, which can improve LCP and INP
- One event stream instead of many vendor requests
- Control over exactly which fields each vendor receives
- Some signal recovered from ad blockers and cookie limits, with consent, which can make media spend more efficient
- Easier to enrich events with business data before forwarding
- Fewer scripts that can read the page, which reduces data-leak risk
Cons
- License, hosting, logging and maintenance costs
- Implementation effort and new skills for the team
- No speed gain if the same tags keep running in the browser
- Not every vendor or feature works server side
- A new system that processes personal data and needs governance
- Cookie and blocker benefits depend on careful first-party, same-IP setup
Methodology and sources
How this calculator works
Moving marketing tags from the browser to a server can create value in two separate ways, and the calculator keeps them apart.
1. A faster site. If tags are actually removed from the page, the browser has less code to download and run, and pages can load faster. If tags are only routed through a server while the same scripts still run in the browser, there is no speed gain, and the calculator shows zero. The speed gain is estimated from the tags you remove, or, better, from what you measured in a pilot.
A faster load (Largest Contentful Paint) turns into more conversions through an elasticity: by default, a 10% faster LCP gives about 1.3% more conversions. This value comes from controlled experiments: Bing's slowdown test (100 ms worth about 0.6% of revenue), Google's search delay test, Vodafone's A/B test (31% faster LCP, 8% more sales) and a peer-reviewed study of retailers (Gallino, Karacaoglu and Moreno, Operations Research 2023). Correlational studies that report 7% to 10% per 100 ms are available but never the default, because they imply effects about ten times larger than any experiment. The effect is capped at 10%, and gains on pages that are already fast count for less.
2. Better measurement. Ad blockers and Safari's tracking prevention hide some conversions from ad platforms. Server-side collection can recover part of that signal, with consent, which helps ad platforms optimize. This is valued only as more efficient media spend on the spend it affects, never as extra sales, because the conversions already happened. Published figures come from the platforms themselves, so the default is deliberately modest: about 0.75% of the media spend it affects. The bucket is on by default but always shown on its own line, next to speed value, with speed only, measurement only and the combined total, so speed value can be judged alone.
What is not counted by default: SEO ranking gains (Core Web Vitals are a ranking signal, but relevance dominates), ad Quality Score (described by the ad platform as not an auction input), bounce rate (shown as context only, because bounce, engagement and conversion are one chain), higher order values, and platform-reported uplift.
3. AI agent visitors. Some sessions are AI agents acting for a person, such as research and shopping assistants and agentic browsers. The speed experiments behind the elasticity measured people, so speed value is multiplied by the human share of sessions (1 minus the agent share). Ad-blocker and cookie-limit signal also affects people only, so those points are multiplied by the same human share. No published source gives the agent share of sessions by industry, so the defaults are labelled assumptions. Today is 1% for retail, media and travel and 0.5% for restaurants and B2B. That is a few times the declared real-time agent requests in public network data, because agentic browsers that look like ordinary browsers are not counted there, and because more than 95% of agentic traffic goes to retail, media and travel. 2028 forecast is 5%, a straight line from today to the likely 10% share of US online retail sales forecast for 2030. Agent-heavy is 25%, the top of published 2030 forecasts. Two effects stay off by default because they are not measured: agents responding to speed like people (hypothesis), and agent conversions that browser tags miss being recovered server-side (scenario, valued as media efficiency, never revenue).
Uncertainty. The headline numbers are the central case: every input at its central value, so anyone can reproduce them by hand in the Reproduce box. Every uncertain input also has a range. The calculator runs 10,000 simulations with a fixed seed. The likely range under each headline number is P10 to P90, and the chance of payback is the share of simulations that pay back. The simulated median (P50) is shown in the Range of outcomes chart. Each input is drawn so that its own median equals its central value. Where a sourced upper bound sits further from the central value than the lower bound, the extra width shows up in the upper half of the range only, so it does not pull the median up.
Formulas
Evidence behind the defaults
| Source | Grade | What it found | How it is used |
|---|---|---|---|
| Kohavi et al. 2014, Bing slowdown experiment | A | Randomized: each 100 ms faster gave about 0.6% more revenue. A 250 ms delay after page load had no detectable effect. | Elasticity range; the "late tags save little" rule. |
| Brutlag 2009, search delay experiment | A | Randomized: 100 to 400 ms of delay cut searches 0.2% to 0.6%. | Low end of the elasticity range (Cautious). |
| Vodafone A/B test, web.dev (2021) | B | 31% better LCP gave 8% more sales in a 50/50 test (elasticity about 0.26). | High end of the elasticity range (Strong). |
| Gallino, Karacaoglu and Moreno, Operations Research 2023 | B | Quasi-experimental retail panel: conversion elasticity to load time about 0.2. | Supports the central elasticity of 0.13. |
| Financial Times A/B test (2016) | B | One second of added delay cut articles read 4.9% over seven days. | Media preset: 0.3% page views per 100 ms. |
| Renault field data, web.dev (2021) | C | 10 million visits: 1 s faster LCP linked to 13% more conversions; bounce 14 points per second below 1.6 s, 5 above. | Optional high case for lead generation (1.3% per 100 ms). Bounce shown as context only. |
| Deloitte, Milliseconds Make Millions (2020) | C | Correlational, 37 brands, four lab metrics: 0.1 s associated with 8.4% more retail conversions. | Available, labelled correlational and not recommended. Never the default. |
| Akamai, State of Online Retail Performance (2017) | C | 7.1% per 100 ms on phones at the curve peak, where the fastest pages were mostly errors. | Available, labelled correlational and not recommended. Never the default. |
| Independent synthetic tagging benchmark (2026) | C | Consolidating browser tags cut lab LCP 29% (656 ms). Routing the same tags through a server saved nothing. | High end of the speed range; zero for routing only. |
| third-party-web, HTTP Archive data | B | Lab main-thread time for common ad, social and analytics scripts is about 100 to 1,800 ms per page on mobile. | Context for the 25 ms per removed tag assumption. Lab time is not field LCP. |
| Web Almanac 2025 and 2022 | A/B | Median mobile blocking time 1,916 ms vs 92 ms on desktop; third-party blocking barely affects desktop. 62% of mobile origins have good LCP. | Desktop gain at 30% of mobile. |
| GWI ad-blocker research (2025) and an ad-filtering industry report (2026) | B | 15% of North American internet users block ads in one survey; 33% in the US in the other. | Default 15%, simulated range 10% to 33%. |
| StatCounter Global Stats (Sep 2026) | B | US Safari share: 46.3% on mobile, 30.4% on all devices. | Safari share per device (desktop about 15%, derived). |
| WebKit tracking prevention and Chrome 400-day cookie cap | A | Safari caps script-set storage at 7 days, and cookies set through a CNAME or third-party IP at 7 days. Chrome caps all cookies at 400 days. | Cookie-limit recovery only with same-IP first-party serving. |
| Damodaran, margins by sector (NYU Stern, Jan 2026) | B | US gross margins: hotel/gaming 60.85%, restaurants 32.24%, specialty retail 35.30%, publishing 50.44%, software 71.72%. | Travel preset margin (conservative); cross-checks for the other presets. |
| Annual reports (Form 10-K) of one reference Fortune 500 company per industry, Fortune 500 list (2025) and third-party traffic estimates (2026) | A / C | Revenue, digital share, margin and advertising expense from the latest filings; monthly visits from traffic panels. The 2025 list starts at about $7.4B in revenue. | Preset scale: traffic, margins and affected media spend. Companies are not named. Conversion rates and order values are labelled assumptions, cross-checked against reported digital sales. |
| Public setup guide for a self-hosted tagging server (2026) | A | About $45 per server per month, at least 2 servers, about 35 to 350 requests per second on 2 to 10 servers; logging can be costly. | Hosting estimate from your traffic. |
| State of AI traffic benchmark (bot-security vendor, 2026) and a bad bot report (2026) | C | Agentic traffic grew about 79-fold in 2025 from a low base; retail 46.6%, media 28.5%, travel 19.2% of it; 77% on product and search pages, 2.3% on checkout. Bots are over half of all traffic. No share of each industry's sessions is published. | Today agent share (assumption): higher for retail, media and travel. |
| Investment bank forecast (Dec 2025) and consulting forecast (Dec 2025) | C | AI agents could reach 10% (likely) to 20% of US online retail spend by 2030; another forecast says 15% to 25%. | 2028 forecast (5%, interpolated) and Agent-heavy (25%) scenarios. A sales share used as a stand-in for a session share. |
| WAREX, web agent reliability under faults (2025) | B | 10-second network delays cut agent task success by 70% or more; script delays above 5 s hurt some agents. Sub-second gains were not tested. | Why "agents respond to speed" is a hypothesis, off by default. |
| Web Bot Auth, signed agent requests (IETF draft) | A | Agents can sign HTTP requests with a published key, so a server can identify them. Browser tags cannot see agents that run no scripts. | How to replace the agent share assumption with your own count from server logs. |
| Core Web Vitals, web.dev | A | Good: LCP 2.5 s or less at the 75th percentile. A user-experience target, not a measured business threshold. | Thresholds next to your inputs; taper knee (labelled assumption). |
Every default is either backed by a primary source above or labelled as an assumption in the calculator. Vendor marketing figures are never the only source for a default. This is an estimate to support a decision, not a guarantee or financial advice. Validate it with your own test.
Version 2.4, October 2026. Built by Martin Goetzinger.