A speed measurement in the browser looks harmless: a small script, a handful of millisecond values, no names, no addresses. That very harmlessness leads to a shortcut – the assumption that a measurement without personal data may run without consent. The relevant yardstick, however, is not the General Data Protection Regulation first, but Section 25 of the German Telecommunications Digital Services Data Protection Act, and it does not ask about personal data. It asks about the terminal device. Anyone collecting field data therefore answers two questions in sequence: is something stored on the device or read from it – and only afterwards, on what basis the resulting data may be processed. This article sorts the common measurement methods into those two questions, traces the narrow path of the statutory exemption and names the data sources that retain their value without consent.
Key takeaways
- Section 25(1) TDDDG ties consent to the terminal device, not to personal data (TDDDG). Assess the storage or read operation first and the legal basis for the processing only afterwards.
- A measurement script that sends locally computed values back to a server counts as gaining access to information already stored (EDPB). The fact that the calculation happens on the device changes nothing – what matters is the return trip.
- For the strictly necessary exemption the supervisory authorities name 4 assessment criteria (DSK): timing, content, storage duration and readability. Audience measurement is therefore not exempt across the board, only in a precisely described configuration.
- Aggregated third-party data remains usable without your own consent flow but costs resolution: the public field archive averages over 28 days (Chrome for Developers) and only covers users who meet four conditions at the same time.
- Design the measurement setup so that a baseline survives without consent: server-side timing, regular lab samples and the 75th percentile (web.dev) as the threshold are independent of the consent rate.
Two questions to be answered in sequence
A common short circuit in measurement concepts runs like this: if no personal data is involved, no consent is needed. That shortcut misses the applicable rule. Section 25(1) sentence 1 TDDDG turns on whether information is stored in the terminal equipment or whether information already stored there is accessed (TDDDG). Whether that information can be attributed to a person is irrelevant at this first stage: the supervisory authorities state in their guidance that the consent requirement exists independently of any personal reference in the information (DSK). Only once that first question is answered does the second follow – on what basis the resulting data is processed further. Both questions have their own standards, their own exemptions and their own documentation duties, and in practice they regularly come apart. Which metrics are even up for discussion is summarised on our page about the Core Web Vitals.
The origin of the rule explains its reach. Section 25 TDDDG implements Article 5(3) of the ePrivacy Directive, which ties the storing of information in terminal equipment and the gaining of access to it to consent given on the basis of clear and comprehensive information (ePrivacy Directive). The European Data Protection Board has described the technical scope of that provision in guidelines adopted in their second version on 7 October 2024 (EDPB). According to those guidelines the notion of information covers both non-personal and personal data, regardless of how it was stored and by whom (EDPB). The frequent counter-question – whether a millisecond value is personal data at all – is therefore irrelevant at the first stage. It becomes relevant again at the second, where purpose, legal basis and retention period are decided.
The order of the questions decides
What Section 25 TDDDG actually requires
The wording is deliberately technology-neutral. It covers every method that stores information on a device or reads it from there – cookies are merely the familiar standard case. The supervisory authorities explicitly name local storage and session storage objects, the reading of hardware identifiers and the server-side construction of a fingerprint from browser properties (DSK). For performance measurement one further sentence from the same guidance is instructive: it also counts as access when properties of a device are actively read out – for instance by means of JavaScript code – and transmitted to a server for the creation of a fingerprint (DSK). The authorities are describing fingerprinting there, not every measurement. The technical shape is the same as in a field measurement, though – reading in the browser, transmitting to a server – and for the general case the European Data Protection Board takes that thought one step further, as the next section shows.
The law provides two exemptions. Under Section 25(2) no. 1 TDDDG consent is not required where the sole purpose is carrying out the transmission of a message over a public telecommunications network. The practically more important one is no. 2: consent is not required where the operation is strictly necessary in order for the provider of a digital service to supply a service explicitly requested by the user (TDDDG). Both terms are narrow: strictly necessary, not merely useful, and explicitly requested from the user's perspective, not the operator's. The table below sorts the common measurement paths into that framework. It does not replace a legal assessment of the individual case, but it shows where the assessment starts.
| Measurement path | Operation on the device | Consent under Section 25 | Reason |
|---|---|---|---|
| Counting page requests in the server log without recognition | not included | not applicable | The counter runs in the backend (DSK) |
| Server-Timing in the response header | not included | not applicable | The value is created before delivery |
| Script reads timing values in the browser and sends them | included | required unless an exemption applies | Sending them back is access (EDPB) |
| Identifier in local storage for session context | included | required unless an exemption applies | Storage in the terminal device (DSK) |
| Evaluation based on the IP address alone | depends on its origin | required in case of doubt | IPv6 is partly formed by the device (EDPB) |
The last row surprises many readers. The Board notes that access to IP addresses triggers the provision where that information originates from the user's terminal equipment – which can be the case for a static IPv4 address of a router and for IPv6 addresses, because these are partly constructed by the device itself (EDPB). Unless an entity can ensure that the address does not originate from the terminal equipment, it has to take all the steps required under Article 5(3) (EDPB). In practice that means an apparently purely server-side evaluation leaves the safe zone as soon as it recognises individual visitors by their address. Plain counting of page requests without recognition is untouched by this.
Why a Vitals measurement is access
For a field measurement of the Core Web Vitals one passage of the guidelines is decisive. It sounds technical at first glance and settles almost everything. Under the heading on local processing it says: if at any point the processed information is made available to a third party, for example sent back over the network to a server, that operation constitutes a gaining of access to information already stored (EDPB). That is precisely what every measurement library does: it observes events in the browser, derives a metric from them and sends it to an endpoint. Under this reading the fact that the calculation happens on the device and that only a number leaves it is not a counter-argument but exactly the case described. How such a metric can be broken down further is shown in LCP in four subparts.
Reading counts like storing
Section 25(1) TDDDG names both operations on equal footing: the storage of information in the terminal equipment and access to information already stored there (TDDDG). A measurement without cookies is therefore not automatically a measurement without consent – it only shifts which of the two operations is being assessed.
Local computation only moves the place
Moving the evaluation into the browser is a good idea for data minimisation and a poor one for the legal question: as soon as the result travels to a server, access has been gained (EDPB). The benefit remains, because less raw data leaves the device and the second assessment stage becomes easier to pass.
No personal data, still access
The supervisory authorities make clear that Section 25(1) TDDDG creates a consent requirement independently of any personal reference and therefore reaches beyond the scope of the General Data Protection Regulation (DSK). Anonymisation is an argument for the second stage, not for the first.
A second point is often overlooked in measurement concepts: for tracking links and tracking pixels the guidelines hold that their distribution to the terminal equipment already constitutes storage, at the very least through the caching mechanism of the client-side software, and it does so even if the storage is not permanent (EDPB). Anyone reporting measured values through a counting pixel or a prepared link therefore has an operation on the device not only when it is read out but already when it is delivered; with a script-based measurement, by contrast, the decisive operation is sending the locally computed values back (EDPB). In practice this is less an extra hurdle than a clarification: the question is not whether an operation takes place on the device, but whether an exemption carries it. Anyone gating the measurement behind a consent layer should gate the delivery path as well – otherwise the decision exists on paper while the network traffic has long overtaken it. How that layer affects speed itself is covered in our article on cookie banners and Core Web Vitals.
The core in one sentence
The narrow path of the exemption
That leaves the exemption. Section 25(2) no. 2 TDDDG requires two things at once: a digital service explicitly requested by the user and an operation that is strictly necessary to provide it (TDDDG). The supervisory authorities have published two lists of criteria for this. For the requested service, what counts is a granular determination of which storage or read operation belongs to which function, plus a decision on whose interests that function primarily serves (DSK). For strict necessity they name 4 assessment criteria (DSK). The cut is narrow: the point is not whether a cookie is set, but what information it holds and how long that information stays readable.
On the obvious follow-up question – whether audience measurement may therefore run without consent across the board – the authorities deliberately give no blanket answer. Their reasoning is particularly instructive for performance measurement because it turns on purpose rather than technology. A determination that audience measurement is lawful without consent can only be made for a precisely defined configuration and purpose, and it stops being valid as soon as further information or a further evaluation result is added (DSK). And further: even simple visitor counting is not per se part of the basic service but depends on the specific purpose pursued in each case (DSK). A speed measurement that serves only the delivery of the page thus stands differently from the same measurement once it carries segments, campaign identifiers or session histories.
- Timing of the storage: the operation may only begin once the function is actually being used (DSK). A measurement script that starts in the head of every page is therefore harder to justify than one bound to a specific event.
- Content of the information: what matters is not that something is stored but which information is stored or read (DSK). A timing value without an identifier is a different case from the same value with a recognisable session number.
- Duration of storage: the period may only be as long as the granularly determined function requires (DSK). For a speed measurement that typically means session length rather than months.
- Readability of the information: the assessment covers who can read and use the information from the device (DSK). As soon as another recipient reads along, the evaluation shifts even if your own purpose stays the same.
- Granular attribution: for every function it is recorded individually which storage or read operation belongs to it (DSK). A blanket justification covering the whole measurement tool does not carry this assessment.
- Attribution of interests: it is determined whose interests the function primarily serves – those of the users, your own or those of third parties (DSK). This is the point where a speed measurement and a marketing evaluation part ways.
What the exemption typically does not carry
What remains without consent
So what remains without consent? More than first impressions suggest – though at a different resolution. The authorities themselves describe what plain counting looks like: it is sufficient to increase the counter for a page by one on every request of that page (DSK). In the same passage they also name a simple counting pixel – but that triggers an operation on the device again, whereas the counter in the server log does not reach the first assessment stage at all. Server-side timing sits at the same level. The Server-Timing response header carries values created in the backend before delivery; nothing is retrieved from the device. That cleanly separates database time, render time and waiting time inside the application without ever reaching the first assessment stage – how to set this up is described in our article on Server-Timing in the backend. What is missing is the view of the visitor's device: computation time, layout stability and interaction latency arise there and cannot be reconstructed on the server.
The second source that needs no consent of your own is the browser's public field archive. It supplies aggregated distributions per page and per origin, and the operator of the website triggers no operation on someone else's device in the process. The price is resolution and delay. The data is a rolling average over 28 days (Chrome for Developers), values are published per metric as a histogram and as a percentile value (Chrome for Developers), and the dataset only includes users who meet four conditions at the same time: usage statistic reporting enabled, browser history synced, no sync passphrase set and a supported platform (Chrome for Developers). The proportion of users meeting these criteria is not published (Chrome for Developers). Comparing that source with your own measurement is therefore not a contradiction but two sections of the same distribution – we took this apart in field data versus lab data.
// Keep the two measurement paths apart: one runs without consent,
// the other starts only after a documented opt-in.
// 1) No operation on the device -- the value is created in the
// backend and travels in the response header:
// Server-Timing: db;dur=41, render;dur=88, total;dur=143
// 2) With an operation on the device -- start only after consent.
// buffered:true replays entries that already exist, but the
// read operation itself happens right here.
function startMeasurement() {
const values = [];
new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
values.push({ name: entry.name, value: Math.round(entry.startTime) });
}
}).observe({ type: 'largest-contentful-paint', buffered: true });
addEventListener('visibilitychange', () => {
if (document.visibilityState !== 'hidden') return;
if (values.length === 0) return;
navigator.sendBeacon('/measurement', JSON.stringify(values));
values.length = 0;
});
}
// The call hangs off the consent state, not off the page view.
// Loading the library belongs behind the same condition.
if (consent.granted('measurement')) {
startMeasurement();
}From the legal frame to the measurement setup
The legal question turns into a measurement setup once you accept that the consent rate is a metric and not a side note. If half the visitors agree, that does not merely halve the volume of data, it shifts the distribution: those who consent differ in device, network and behaviour from those who decline. A percentile drawn from the consenting half is therefore not the percentile of your visitors. A workable setup has two layers: a baseline that exists without consent and stays comparable over time, and a detail layer that arrives after opt-in and shows causes. The first layer answers whether something changed, the second answers why. Which thresholds apply is summarised in Core Web Vitals 2026.
- Classify every measurement path individually by whether it triggers an operation on the device. That classification belongs in the same table as the technical description, not in a separate document.
- Define the baseline without consent: counting in the server log, Server-Timing for the backend phases and regular lab samples against the same configuration.
- Place the aggregated third-party source alongside it as a control and factor its window of 28 days (Chrome for Developers) into the evaluation – an improvement made today appears there delayed and smoothed.
- Put the detail layer behind consent, including the loading of the library, and carry the consent rate as a metric of its own. Without it you cannot tell later whether a value rose or the population changed.
- For the exemption, keep a written justification per function along the four criteria (DSK) and review it again at the next rebuild instead of carrying it forward.
- Fix the threshold as a percentile rather than an average: assessment happens at the 75th percentile (web.dev), split by mobile and desktop. How that translates into an acceptance clause is covered in writing speed into a tender.
This separation has a pleasant side effect: it makes the measurement itself lighter. A detail layer that loads only for consenting visitors costs the rest neither transfer nor computation time. Moving the return of the values into idle time additionally removes their influence on interaction latency – we described the patterns for that in sending beacons without costing speed. In applications with client-side navigation there is the added problem that attributing metrics to views needs a pattern of its own; how that works without extra identifiers is covered in measuring Core Web Vitals in SPAs.
The uncomfortable question in every measurement concept is not whether the data is anonymous. It is: what exactly does this script retrieve from the visitor's device – and would the page work worse without that operation?
That makes the question in the headline answerable without answering it in a blanket way. What is allowed without consent is anything that triggers no operation on the terminal device, plus anything carried by a narrowly drawn exemption. Everything else needs an opt-in – and whoever does not get one keeps working with a baseline of server data and an aggregated third-party source instead of abandoning measurement altogether. This classification is part of every technical performance analysis we run: we describe which measurement path triggers which operation, which metric stays sound without consent and where an opt-in actually adds value. Which metrics converge in the process is set out on our page about the Core Web Vitals; how speed is held during ongoing operation is covered by the look at regressions in the build pipeline. For the measurement points where sales genuinely get tight, the article on checkout speed in the final seconds is worth reading; if the brake sits in the runtime of your styling instead, style recalculation as a CSS runtime cost helps.
Sources and studies
Related Articles
RUM vs. CrUX: Using Field Data Right for Speed
Lighthouse lab scores do not affect ranking. Google rates Core Web Vitals via CrUX field data at the 75th percentile. How to use RUM, CrUX and budgets.
When an API Stalls: Foreign Systems in Page Rendering
When your server waits on a foreign system while assembling a page, timeouts, caching tiers and fallback values decide whether the page stands or stalls.
TYPO3 Performance: Caching and Load Times Under Control
How the TYPO3 page cache works, which settings switch it off, and how the cache hash, the backends and the deployment decide the load time of a page.