One article, three languages, ten points apart
On 24 August 2026 we published the same article in English, Italian and Romanian — identical images, an identical style block character for character — and measured all three in one session. They scored 82, 87 and 77. Nothing was wrong with any of them. That ten-point spread, and the thirteen-point spread we recorded on a single unchanged page five days earlier, are the reason a speed score should be read as a range rather than a grade.
The finding. One page, one tool, one hour: 79, then 74, then 87. Across five days in August 2026 the gap between two consecutive runs of an unchanged page was 3, 6, 8, 13 and 3 points.
Why it matters to you. The threshold people act on — usually 80 — sits inside that range. Half your measurements will say you have a problem and half will say you do not. The method that settles it takes five minutes and is called a witness.
What we bring. We measure every article we publish, in three languages, every day, and we keep the numbers. They are here with their dates, including the two occasions the method stopped a pointless repair and the one occasion a hypothesis of ours was falsified by a controlled test.
- You get the width of the range from five dated measurements rather than an impression.
- You get the witness method, which separates your problem from a busy machine in five minutes.
- You learn why the same page in two languages returns two numbers, and by how much.
- You learn what does not move the score, because we tried it and were wrong.
Nobody weighs a parcel once and then argues about twenty grams. With website speed everybody does: you open the tool, a number comes out, and that number becomes a fact in a meeting. This is the log of what happens when you take the number seriously enough to measure it more than once.
One article, three languages, one session
Same images. Same style block, character for character. Same structure, same day, same machine, measured back to back on mobile:
| Version | Performance | First contentful paint | Requests | Bytes |
|---|---|---|---|---|
| English | 82 | 1.7 s | 25 | 909 KB |
| Italian | 87 | 1.3 s | 25 | 909 KB |
| Romanian | 77, then 80 | 2.9 s, then 1.1 s | 26 | 970 KB |
The Romanian row has a precise cause, measured nine separate times before we wrote it down: the language's diacritics force the browser to fetch one extra font file of 59.8 KB. The Romanian page ends up 61 KB heavier over one extra request — 970 KB across 26 requests against 909 KB across 25 — and scores five to seven points lower on an otherwise identical page.
The operational lesson is less exotic than it sounds. The score does not belong to the site; it belongs to the page served to that visitor. Anyone running a multilingual site who measures only the homepage in one language is not measuring their site — they are measuring a third of it.
What a speed score actually is
A speed test is a simulation: the tool loads your page on a simulated mid-range phone over a throttled network and times a handful of moments in the load.
That definition is already half the answer. The score is not a property of the site the way weight is a property of an object. It is the outcome of an experiment run on a shared machine, at a particular instant, over a network that was more or less busy at that instant. Change the instant and you change the result — and the surprising part is not that it changes but by how much.
Three runs, thirteen points
On 19 August 2026 we published an article and moved on to the usual measurement. First run: 79. Below our threshold, so a second run, per the rule. 74. Worse. The temptation at that point was obvious — compress the opening image, defer a script, find something to cut. Third run, before touching anything: 87.
Thirteen points between worst and best, on the same page, inside one hour, with nothing changed. It was not an isolated episode:
| Date | Language of the page | Runs | Gap |
|---|---|---|---|
| 14 August | all three | 2 | ~3 points |
| 17 August | Romanian | 2 | 76 → 82, 6 points |
| 19 August | English | 3 | 79 → 74 → 87, 13 points |
| 21 August | Italian | 2 | 78 → 86, 8 points |
| 24 August | Romanian | 2 | 77 → 80, 3 points |
On 21 August the interesting part is not the gap itself but what had moved inside it: the same request count (25), the same byte total (898 KB), a machine that was essentially idle. Only the timings moved — first paint from 2.6 to 1.5 seconds, largest element from 2.7 to 1.6. Neither measurement was wrong. They were two samples from one distribution.
The witness
The third run on 19 August settled the case, but by luck rather than method. What actually decided it was measuring, in the same session, an article we had not touched: published the day before, measured then at 89. That day it returned 81.
Eight points lost by a page nobody had opened. From then on the question was not "what did I break" but "how busy is the machine" — and the answer was in the server load, 2.19 against 0.2 on an ordinary day.
Pick a page on your site that you are not editing and measure it every time you measure the page you care about, in the same session. If both fall, it is the environment. If only yours falls, it is yours. It costs one extra run and saves half-days. The rule works in both directions: on 24 August our witness returned 85 against 83 the day before, so the 77 on the new page was not the machine's fault — and it genuinely did deserve a second run, which returned 80.
The hypothesis we tested and lost
This section exists because we were wrong and the test proved it.
On 21 August we had formed a reasonable hypothesis about layout shift: the headline was too long, so when the web font swapped in it reflowed onto more lines and pushed the image down. The next day we tested it properly — shortening the English headline from 61 to 47 characters as the only change in a publish, so that exactly one variable moved.
The result of two identical runs: layout shift went from 0.210 to 0.207, and the score from 79 to 79. The hypothesis was false. The follow-up hypothesis — "it is the amount of text above the image" — broke on the data just as fast: 108 words produced 0.062 and 105 words produced 0.167.
The real cause was named by the tool itself, and it was not in the content: web font loaded, four files. Across four untouched articles the shift measured 0.010, 0.034, 0.046 and 0.062, with style blocks identical character for character. So: no site regression, no repair available from inside an article, and one more line on the infrastructure list.
What you need to measure properly
- The same tool, every time. Comparing one tool's number against another's measures the gap between two laboratories, not your progress. Our free website speed test tool exists for exactly this: a consistent starting point with nothing to install.
- At least two runs on the page you care about. Below threshold on the first, you do not repair — you re-measure.
- A witness: an unedited page measured in the same session.
- The absolute date written next to the number. "80 on mobile, second run, 24 August 2026" survives six months. "The site scores 80" does not survive a single day.
- The page that matters, not the homepage. A homepage and a product page are often twenty points apart, and the homepage is nearly always the light one.
What the score does not tell you
- It does not tell you what a real visitor experiences. It is a laboratory simulation. Field data lives elsewhere and can say the opposite, in either direction.
- It does not separate your choices from your defects. On cittago.com measurement and advertising tags account for around 490 KB of the 909 KB total and cost roughly nine measured points. Not a bug — a commercial decision paid for in performance.
- It does not tell you whether a drop is yours. Only the witness does.
- It is not comparable across devices. Mobile and desktop scores for one page can be twenty points apart; quoting one without saying which is the source of half the misunderstandings in a meeting.
- It does not improve because you measure more often. Measuring well tells you what to repair; it does not do the repairing.
Badly and well, in a table
| Habit | How it is usually done | How it is worth doing |
|---|---|---|
| Number of runs | One, and it gets written down | Two on the page, plus a witness if you are below threshold |
| Reaction to a drop | Start hunting for something to cut | Re-measure, then read the witness |
| How it is recorded | "The site scores 80" | "80, mobile, second run, 24 August 2026" |
| What gets measured | The homepage, in one language | The pages that receive traffic, in every language served |
| What gets compared | Different tools against each other | One tool against itself over time |
The words, in a table
| What it measures | In plain words |
|---|---|
| First contentful paint | When the first piece of content appears on screen. The moment the visitor understands the page exists. |
| Largest contentful paint | When the biggest element in the first screen appears — usually the headline or the opening image. The closest measure to "now I can read". |
| Total blocking time | How many milliseconds the browser stays busy running code instead of answering a finger on the screen. |
| Cumulative layout shift | How far things move while the page finishes loading. The reason you tap a button that has just walked away. |
Where you stand, in three thresholds
First threshold — you have never measured, or you did once last year. The useful thing is not the number, it is the baseline: measure your highest-traffic page twice, write both numbers down with the date, and file them. From then on every discussion has something to compare against.
Second threshold — you measure occasionally, the number jumps around, and you have stopped trusting it. This is the common case and the one this article settles: the jumping is normal and it is wide. Add the witness and the second run, and the noise stops looking like a problem.
Third threshold — you measure properly, the range is stable, and it still sits where you do not want it. Here the problem is no longer measurement, it is decisions: which third-party scripts stay, what the fonts weigh, what the theme loads. This is the point at which website speed optimisation is worth opening with someone who has the numbers in front of them rather than impressions.
On the infrastructure underneath the score we have written separately, in how much speed matters when an AI is the reader and in why mobile and desktop return different numbers.
Questions nobody has actually asked us
None of these arrived by email. They are the questions we had to answer ourselves in order to keep the log, and the answers are short because the numbers are short.
How much does the score of one unchanged page move?
In our own daily runs, between 3 and 13 points. The widest case: the same English page, three runs inside one hour, 79 then 74 then 87, with no code change between them. A single number is a sample, not a finding.
Why does the same article score differently in three languages?
Because the browser is not loading the same page. Our Romanian version pulls one extra font file for the diacritics, 59.8 KB, giving 26 requests and 970 KB against 25 and 909 KB. On 24 August 2026 the same article with identical images and an identical style block scored 82 in English, 87 in Italian, and in Romanian 77 on the first run and 80 on the second.
What exactly is a witness page?
A page you are not editing, measured in the same session as the page you care about. If both drop, the environment is busy. If only yours drops, it is yours. On 19 August 2026 our witness fell from 89 to 81 with nothing changed, which stopped an afternoon of pointless optimisation.
Is a score of 100 worth chasing?
Rarely. A page that loads analytics, a chat widget and custom fonts will not reach 100 without dropping one of the three. The useful question is not how far you are from 100, but which of the three the visitor is paying for and whether it earns its place.
Can I compare my score against a competitor's?
Only loosely. For the comparison to mean anything, both measurements need the same tool, the same day, and pages with the same job — a product page against a product page, not against a homepage. Otherwise you are comparing two laboratories.
What usually weighs most on an ordinary site?
In our experience, tracking code. On cittago.com the tag manager and two advertising tags account for roughly 490 KB of the 909 KB total and cost about nine measured points. That is a commercial decision paid for in performance, not a defect.
Does the lab score match what real visitors experience?
No. The score is a simulation on a throttled mid-range phone. Real visitor data lives in field reporting and can say the opposite, in either direction. The lab is good for diagnosis; the field is good for decisions.
How do I record a score so it still means something in six months?
Put the absolute date, the tool, the device type and the run number next to it. “80 on mobile, Lighthouse, second run, 24 August 2026” can be checked. “The site scores 80” cannot be checked a day later, because nobody will remember whether it meant mobile or desktop.
My score is low. Where do I start?
Not with images, which is where most people start. Open the network request list in the report and sort by bytes: in most cases the top three lines are third-party scripts, not pictures. Compression is worth discussing only after you know what those three lines are.
Does measuring more often make the site faster?
No, and it is worth saying plainly. Measuring well tells you what to repair and stops you repairing noise. The repair itself is a separate piece of work, and usually a smaller one than the measuring taught you to expect.
Last updated: 25 August 2026. Every measurement quoted here is ours, run with Lighthouse in mobile mode on a virtual machine we control, against pages on cittago.com, on the dates written beside each number. The gaps between consecutive runs come from the log we have kept since 14 August 2026: 14, 17, 19, 21 and 24 August. The controlled headline test was run on 22 August 2026 as the only change in a publish, verified against our publish script's own log, which reported a single changed file. The cost of the extra font file for Romanian was measured nine times between 11 and 24 August 2026. The weight of the measurement tags comes from the network request list of the same measuring session. We did not compare our results against PageSpeed Insights on the same URLs, so we claim nothing about the relationship between the two tools beyond what is written here: compare a tool only against itself.
Sources: Chrome for Developers — Lighthouse performance scoring · web.dev — Web Vitals · Cittago — website speed test
