# fastmon: full site text > The complete text content of https://fastmon.eu/ in one file, for LLM consumption. English pages first, then German. Generated at build time from the same page set as the XML sitemaps. Structured overviews: https://fastmon.eu/llms.txt (English) and https://fastmon.eu/de/llms.txt (German). Documentation: https://docs.fastmon.eu/ --- ## https://fastmon.eu/ Your Lighthouse score says 95. # How fast is your site, really? Your visitors already know. fastmon shows you: real load times from real devices in real networks, with the numbers Google ranks you by. Start for free All features No credit card ~5-minute setup Hosted in Germany Read-only by default* Live: this page is measuring itself your visit TTFB FCP LCP CLS Same browser APIs the fastmon script uses. No cookies* involved. Nav type ··· New to this? ## LCP, FCP, TTFB: just buzzwords to you? No problem. On the blog we explain every metric in plain language: what it measures, why Google cares and how you improve it. The fastmon blog Metrics in plain language Visit the blog The product ## One platform. Sixteen instruments. Five areas, one script, the same beacons. The full list of all sixteen is further down this page. - Real User Monitoring Core Web Vitals p75 · 7d LCP (p75) 0.44 s Besuchererlebnis 90% gut Gut 90% VB 4% Schlecht 6% INP 56 ms CLS 0.00 TTFB 0.18 s FCP 0.28 s Page Load 0.9 s Fehlerrate 0.00 % Core Web Vitals, errors and network timing from every real visit, evaluated at the p75 against Google's thresholds. More on Real User Monitoring - Synthetic Monitoring Lighthouse Desktop · alle 24h 82 Performance 96 Barrierefreiheit 100 Best Practices 92 SEO Metriken First Contentful Paint 0.9 s Largest Contentful Paint 1.8 s Total Blocking Time 120 ms Cumulative Layout Shift 0.01 Potenziale Render-blocking Ressourcen entfernen 50 ms sparen Ungenutztes JavaScript reduzieren 250 ms sparen Bild-Auslieferung verbessern 51 kB sparen Scheduled Lighthouse audits for desktop and mobile every 24 hours, TTFB checks every 5 minutes. Lab and field side by side. More on Synthetic Monitoring - Web Analytics Aktuelle Besucher 385 in den letzten 5 Minuten Top-Quellen Direkt 1.2M Google 198.6K Instagram 17.0K YouTube 10.1K Live visitors in the last five minutes, sources, campaigns, UTM and ad click IDs. One less tool in your stack. More on Analytics - fastmon AI fastmon AI Beta Wie hat sich LCP in den letzten 7 Tagen entwickelt? lcp_p75 (ms) · 7d 2.800 2.100 1.400 700 0 13. 14. 15. 16. 17. 18. 19. 20. LCP p75 lag meist im gut -Bereich (136 bis 382 ms), mit einem Ausreißer am 19.07. ( 2.681 ms ). Ursache lohnt einen Blick. Ask about a test or an error in plain language and get a grounded answer. No query building, no dashboard hunting. More on fastmon AI - EU & Privacy Datenpfad 100 % EU 01 Besucher Browser-Beacon IP + User-Agent 02 Edge (Falkenstein) IP verworfen, < 1 s → Ländercode (DE) 03 Backend EU Hetzner, Deutschland keine rohe IP Kein Cloudflare Kein AWS Kein GCP Kein US-Anbieter IP address and User-Agent are removed at the edge, before any application code sees them. No Cloudflare, no AWS, no GCP: the entire data path stays in the EU. More on EU & privacy Core Web Vitals p75 · 7d LCP (p75) 0.44 s Besuchererlebnis 90% gut Gut 90% VB 4% Schlecht 6% INP 56 ms CLS 0.00 TTFB 0.18 s FCP 0.28 s Page Load 0.9 s Fehlerrate 0.00 % Lighthouse Desktop · alle 24h 82 Performance 96 Barrierefreiheit 100 Best Practices 92 SEO Metriken First Contentful Paint 0.9 s Largest Contentful Paint 1.8 s Total Blocking Time 120 ms Cumulative Layout Shift 0.01 Potenziale Render-blocking Ressourcen entfernen 50 ms sparen Ungenutztes JavaScript reduzieren 250 ms sparen Bild-Auslieferung verbessern 51 kB sparen Aktuelle Besucher 385 in den letzten 5 Minuten Top-Quellen Direkt 1.2M Google 198.6K Instagram 17.0K YouTube 10.1K fastmon AI Beta Wie hat sich LCP in den letzten 7 Tagen entwickelt? lcp_p75 (ms) · 7d 2.800 2.100 1.400 700 0 13. 14. 15. 16. 17. 18. 19. 20. LCP p75 lag meist im gut -Bereich (136 bis 382 ms), mit einem Ausreißer am 19.07. ( 2.681 ms ). Ursache lohnt einen Blick. Datenpfad 100 % EU 01 Besucher Browser-Beacon IP + User-Agent 02 Edge (Falkenstein) IP verworfen, < 1 s → Ländercode (DE) 03 Backend EU Hetzner, Deutschland keine rohe IP Kein Cloudflare Kein AWS Kein GCP Kein US-Anbieter For developers ## Live before your coffee is done One script tag, no build step, no configuration. index.html 1 < script defer src = "…/f26b….js" > 2 → 204 No Content ✓ 01 ~5 minutes Add the tag Vanilla JS, ~40 KB compressed, loads with defer. Works with any stack. Network Name Status f26b593f08…js 204 c/collect 204 204 No Content ✓ 02 After your deploy Verify in DevTools The collector answers with 204 No Content. One look at the network tab is enough. Live gerade eben 1 erster Besucher Direktzugriff · Deutschland LCP 0.4 s 03 +60 seconds Watch data arrive About a minute later your first visitors show up in the dashboard. Works with any stack - WordPress - Shopify - Shopware - Lovable - TYPO3 - Webflow - Next.js - React and anywhere else you can add a script tag. Installation guide in the docs The index ## Everything fastmon measures - 01 Core Web Vitals LCP, INP, CLS from real users: the metrics Google ranks you by. - 02 Web analytics Live visitors, pages, sources, campaigns and UTM attribution included. - 03 Error tracking JavaScript errors with type, frequency and origin. From production. - 04 Network waterfall DNS, TCP, TLS, server, transfer: where the time actually goes. - 05 Sessions & Visitor Explorer Individual visits with per-page performance, duration and device context. - 06 Geo & devices Traffic and Web Vitals by country, browser, device, connection. - 07 Performance alerts Threshold and regression rules, routed to email, Slack, Discord or webhook. - 08 Release tracking Deploys marked on charts: regressions get a timestamp. - 09 Explorer Ad-hoc analysis, p50 to p99, filter and group without SQL. - 10 Ask about a test New Ask about a test or an error in plain language and get a grounded answer. - 11 Synthetic monitoring Beta Lighthouse every 24 h and TTFB checks every 5 minutes, next to your field data. - 12 Server-Timing Backend phases like database, cache and render in every real request. - 13 Cache monitoring Browser, CDN and origin layers, bfcache hit rates, resources by type. - 14 API & fetch monitoring Every fetch and XHR call: slow requests, failures and tail latency. - 15 REST API Full access with token auth and OpenAPI schema. - 16 Teams & roles Multi-org, owner and member roles, partner clients for agencies. All features in detail Why it pays off ## Performance is revenue. One tool Slow pages lose customers before your conversion tracking even notices them. fastmon measures the Core Web Vitals of your real visitors and shows what every tenth of a second of load time is worth in revenue. - Google ranks by real Core Web Vitals (CrUX), not lab scores - p75 instead of averages: you see the visitors who actually suffer - What every tenth of a second costs you, modelled with your own numbers What slowness costs you Who it's for ## Built for the whole team Four roles, one dashboard: everyone sees the numbers they actually need. Analytics ### Marketing - Campaigns, sources and UTM attribution - Load times right next to conversions - Live visitors in the last five minutes - Ad click IDs like gclid included More on Analytics API & docs ### Developers - JavaScript errors with type and origin - Network waterfall and Server-Timing - REST API with OpenAPI schema - Release markers via curl from your CI/CD To the docs EU & privacy ### CTOs - Entire infrastructure in the EU - No US provider in the data path - IP removed at the edge, country code only - DPA included, 90-day retention EU & privacy Plans ### Founders & C-level - Experience Score: one grade from A+ to F - One tool instead of three in the stack - Transparent pricing from €29 a month - Team access with owner and member roles View pricing Privacy ## Designed inside the GDPR. Not retrofitted to it. That is the difference between a monitoring tool from the EU and one with an EU region. Here is the data sheet: the honest version, footnote included. * In Minimal and Standard mode fastmon sets no cookie and stores nothing on the device; what it reads are status values the browser generates at runtime. Full mode writes an identifier, and there consent under § 25 TDDDG is required. Assessing this is the responsibility of the respective website operator embedding fastmon. Data sheet Cookies 0* strictly storage-free: no localStorage, no sessionStorage IP address removed at the edge before any application code ever sees it Location country only two-letter ISO code, nothing more Data path 100% EU no Cloudflare, no AWS, no GCP Retention 90 days default, configurable per website Fingerprinting none no canvas, no font enumeration The comparison ## Lighthouse, GA4, or Datadog? Synthetic tools don't measure what users feel. Analytics tools measure traffic, not performance. Enterprise RUM like Datadog does far more and loads a ~60 KB script; list pricing is per-session and modular. fastmon sits in between, cookieless* by default and hosted in the EU. | Capability | fastmon Performance RUM | Lighthouse Synthetic testing | GA4 Traffic analytics | Plausible Web analytics | Datadog RUM Enterprise RUM | Real User Monitoring (field data) | ✓ Yes | No | No | No | ✓ Yes | Core Web Vitals (LCP, INP, CLS) | ✓ Yes | Synthetic | No | No | ✓ Yes | Network & resource timing | ✓ Yes | Synthetic | No | No | ✓ Yes | JavaScript error tracking | ✓ Yes | No | No | No | ✓ Yes | Geo & device breakdowns | ✓ Yes | No | ✓ Yes | ✓ Yes | ✓ Yes | Works without cookies* | ✓ Yes | N/A | No | ✓ Yes | No | EU-hosted | ✓ Yes | N/A | No | ✓ Yes | Optional | Entry price | from €29/mo | free | free | from $9/mo | usage-based per session As of 14 July 2026: list prices / documented default configuration; individual terms may differ. *: see the footnote at the end of the page. FAQ ## Frequently asked The honest answers, including the cookie-banner question everyone else dodges. Everything else lives in the docs. Read the docs ### Do I need a cookie banner for fastmon? No, not in Minimal and Standard mode. Nothing is stored on the device, and the values that get read were not there beforehand: they come into being at the moment of the page view. Naming fastmon in your privacy policy is enough. In Full mode you do need consent, because an identifier is written into sessionStorage. This classification has been reviewed with our external data protection officer; a residual risk remains, because no court has ruled on this constellation. The full derivation, with the statutory text and the opposing reading ### Does fastmon store IP addresses? No. The IP address is removed at the edge before any application code ever sees it. What remains is a two-letter country code. The User-Agent header is removed at the edge as well. No canvas fingerprinting, no font enumeration, no identifier that survives a domain boundary. The full privacy page ### Where does my data live? The entire infrastructure runs in the EU, with no US-jurisdiction provider anywhere in the data path: no Cloudflare, no AWS, no GCP. Data is retained for 90 days by default, configurable per website. A DPA is available. Data storage in the docs ### How fast can I go live? One script tag, about five minutes from signup to first data points. Your first visitors show up in the dashboard roughly a minute after the tag is deployed. Verify it in seconds: the collector answers 204 No Content in the network tab. Installation guide ### Will the script slow my site down? The script is vanilla JS, about 40 KB compressed, loads with defer and reads the browser's native Performance APIs instead of doing work of its own. Data goes out through navigator.sendBeacon in batches across the page lifecycle, on a deliberately lean wire format. How the pipeline works ### What exactly does fastmon measure? The five Web Vitals (LCP, INP, CLS, FCP, TTFB), evaluated at the p75 against Google's thresholds, plus JavaScript errors, page load time and network timing. Everything is condensed into the Experience Score: 0 to 10, graded A+ to F, from seven weighted indicators. Metrics & thresholds ### Can I see whether a deploy made things worse? Yes. Tag releases from your CI/CD pipeline, a single curl in the deploy step, and fastmon marks them on every chart. Compare the 24 hours after a release against the 24 hours before it, in the dashboard or via API. CI/CD release guide ### Do I still need Lighthouse? Keep it for development, and let fastmon run it for you in production: Synthetic Monitoring runs scheduled Lighthouse audits (desktop and mobile) and TTFB checks every 5 minutes next to your field data, so you can compare lab against reality in one view. Synthetic monitoring docs Plans ## The full platform, from €29 a month. Two usage-based plans, no feature matrix per instrument. Light for monitoring, Standard for everything, both hosted in Germany. Light €29 /month 200,000 pageviews included. Start for free See all plans - 200,000 pageviews a month, then €10 per extra 200k - Core Web Vitals and real-user monitoring - Web analytics: traffic, sources, campaigns - One prod and one dev application included, domain count irrelevant - Hosted in Germany, 100% EU data path Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans What's new ## Changelog View all ### Early Hints and store phases The head start from 103 Early Hints becomes measurable, and search and key-value stores count as backend phases of their own. Aug 27, 2026 ### Checkout in the explorer Funnel stage and cart actions as a dimension and a metric: group, filter and drill down to the single pageview. Aug 26, 2026 ### Checkout funnel fastmon recognizes cart, checkout and completion from the URL patterns of the common shop systems, with no tracker change. Aug 26, 2026 ### Response breakdown A waterfall at the percentile you picked: DNS, connection, wait and transfer, then the LCP phases. Aug 25, 2026 View all --- ## https://fastmon.eu/en/accessibility/ Legal # Accessibility Statement Last updated: July 2026 fastmon labs UG (haftungsbeschränkt) strives to make the fastmon.eu website and the fastmon web application accessible, in line with the German Accessibility Reinforcement Act (BFSG) and the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA. ## Scope This statement applies to the website https://fastmon.eu/ and, in addition, to the fastmon web application (the dashboard at app.fastmon.eu). ## Status by company size fastmon labs UG (haftungsbeschränkt) is a microenterprise within the meaning of Commission Recommendation 2003/361/EC (fewer than 10 employees and an annual turnover or annual balance sheet total below EUR 2 million). For services, § 3 (3) BFSG provides an exemption from the obligations of the BFSG. We nonetheless aim for the best possible accessibility and publish this statement voluntarily. ## Conformance status On the basis of an internal self-assessment, we consider the website to be largely conformant with WCAG 2.1 Level AA. Some interactive content, such as performance charts and maps, has not yet been systematically tested with assistive technologies; we are working on improvements on an ongoing basis. ## Our current measures - Semantic HTML with a clear heading structure - Alternative text for informative images; decorative images marked as such - Sufficient colour contrast per WCAG 2.1 AA - Keyboard-operable navigation and forms - Respecting the prefers-reduced-motion system setting for animations ## Third-party content Third-party content embedded in the website, such as the status badge, links to AI services or social media links, is not within our direct area of responsibility. ## How this statement was prepared This statement was created in July 2026 on the basis of an internal self-assessment. It is reviewed regularly, and at the latest whenever the website or the web application changes materially. ## Feedback and contact Please let us know if you notice any barriers or need content in a more accessible format: fastmon labs UG (haftungsbeschränkt) Stresemannallee 4 30173 Hannover Germany Email: privacy@fastmon.eu We aim to respond to your feedback promptly. ## Enforcement procedure If our response to your feedback is not satisfactory, you can contact the market surveillance authority of your federal state. Information on this is provided by the German Federal Accessibility Agency (Bundesfachstelle Barrierefreiheit): www.bundesfachstelle-barrierefreiheit.de --- ## https://fastmon.eu/en/blog/ Blog # Web performance and privacy, in plain language. No jargon, no buzzwords. What the numbers really mean and how to make them better, from the people building fastmon. All Product Performance Privacy Product September 8, 2026 · 7 min read ## Ask your AI about your web performance: fastmon now has an MCP server Connect Claude, Claude Code or Cursor to fastmon and ask for your field data instead of clicking it together in the dashboard. Nineteen read-only tools, OAuth instead of keys, and an honest note about who actually receives your data. Kamil Adrian Czujowski Co-Founder Performance September 2, 2026 · 16 min read ## Real user monitoring tools in 2026: eight vendors, honestly compared Eight real user monitoring tools compared: prices, hosting and what lands on the visitor's device. List prices checked 2 September 2026, with an honest verdict. Kamil Adrian Czujowski Co-Founder Performance August 27, 2026 · 5 min read ## Your page takes 800 ms to the first byte. Doing what, exactly? TTFB is a single number for everything that happens before the first byte. How to split it into phases with one response header, why search and key-value stores deserve phases of their own, and how Early Hints make your TTFB look better than it is. Kamil Adrian Czujowski Co-Founder Performance August 6, 2026 · 4 min read ## Every deploy can wreck your performance. Would you notice? Regressions almost always ride in on a deploy. Why the average hides them, how a release marker from your CI/CD makes them visible, and what you actually compare at the p75. Kamil Adrian Czujowski Co-Founder Performance July 30, 2026 · 6 min read ## Browser cache, CDN cache, origin cache: what do they mean? When someone says: just turn on the cache. Which one? There are three, they sit behind one another, and between the first and the last one lies half a second of waiting for your visitors. Kamil Adrian Czujowski Co-Founder Performance July 15, 2026 · 4 min read ## LCP, FCP, TTFB: just buzzwords to you? Five acronyms, translated into plain language: what your visitors actually feel when these numbers are bad, and why Google takes them seriously. Kamil Adrian Czujowski Co-Founder Privacy July 12, 2026 · 4 min read ## Why we bet on Europe. And what that actually means. No Cloudflare, no AWS, no GCP: why we took the less convenient path, and what it concretely changes for your data. Kamil Adrian Czujowski Co-Founder Load more --- ## https://fastmon.eu/en/company/ Company Hannover, Germany # Honest monitoring, hosted in Europe. fastmon is a small, independent team in Germany building Real User Monitoring and analytics you can actually afford, with your data staying in the EU. No four-figure monthly bills, no US clouds, no dark patterns. - Based in Hannover - Hosted at Hetzner (DE) - 100% EU data path Our mission Every team should know what its visitors actually experience, without selling their data, exporting it, or paying enterprise prices for the privilege. Why fastmon ## Why we built fastmon. We have run real, high-traffic websites ourselves, and we needed to know what our visitors actually experienced. The tools that could tell us cost thousands of euros a month, and most of them shipped our data off to a US cloud. That felt backwards. Knowing how fast your site is for real people should not cost more than the infrastructure it runs on, and it should never mean handing your visitors' data to another jurisdiction. So we built fastmon: Real User Monitoring, synthetic checks and privacy-first analytics in one tool, hosted entirely in Germany, and priced so that a small shop can afford it. Independent, and built to stay that way. What we stand for ## Four things we will not compromise on. The principles behind every decision we make. ### Honest pricing From €29 a month instead of several thousand. Usage-based, transparent, and no surprise invoices. ### Your data stays in the EU Hosted exclusively in Germany, with no US provider anywhere in the data path. Sovereignty, not just residency. ### Independent by design No growth-at-all-costs playbook. We build fastmon to stay its own product for the long run. ### No dark patterns Cookieless* by default, claims we can back up, and no fine print working against you. Team ## The people behind fastmon. A small team that builds and runs the whole thing. ### Kamil Adrian Czujowski Co-Founder LinkedIn ### Lucas Röhrs Co-Founder LinkedIn ## Honest monitoring, built to stay independent. Read-only by default: no cookies*, no long-lived identifiers, hosted in Germany. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/compare/ Compare # Why teams switch to fastmon. The honest case against the tools fastmon replaces or complements. Real differences, no fake claims, and we name where the others still win. Head to head Synthetic ## vs Lighthouse Keep the lab, add the field: real-user Core Web Vitals next to your Lighthouse runs. Read the comparison Analytics ## vs Google Analytics 4 Privacy-first analytics from the EU, cookieless* by default, with performance built in. Read the comparison RUM ## vs Datadog Focused web-performance RUM, EU-hosted and cookieless*, at a fraction of the enterprise bill. Read the comparison Whatever you use today ## The four things that never change. However fastmon compares to your current tool, these hold either way. ### EU-hosted, no US jurisdiction Processed in Germany, no Cloudflare, AWS or GCP; no provider in the data path is subject to US law, so the US CLOUD Act cannot reach it. ### Cookieless by default* No cookies* in the default mode, the IP dropped at the edge, and no fingerprinting. ### One script, five areas RUM, synthetic monitoring, analytics, AI and privacy from a single tag. ### From €29 a month Enterprise capability without the enterprise bill, live in about five minutes. Honest by design ## Comparisons you can check. - Every competitor claim is verified against the vendor's own documentation and pricing. - We name where each tool still beats fastmon, right on its page. - fastmon's own numbers come straight from our docs and legal pages. ## Honestly compared, built in the EU. The web-performance job without a US cloud: read-only by default, no cookies*, no long-lived identifiers, from €29 a month. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/contact/ Contact # A short line, real answers. No ticket queue, no chatbot: your mail lands directly with the people who build fastmon. ## Support Questions about the product, setup, plans or your account. support@fastmon.eu ## Privacy Questions about privacy, the DPA and sub-processors. privacy@fastmon.eu ## Company details Company fastmon labs UG (haftungsbeschränkt) Address Stresemannallee 4, 30173 Hannover, Germany Registry Amtsgericht Hannover, HRB 230880 Managing directors Kamil Adrian Czujowski, Lucas Röhrs ## Social media Product updates and notes from the engine room are on LinkedIn. LinkedIn --- ## https://fastmon.eu/en/cookies/ Cookie banners and consent # Usually no banner. But not because of cookies. Plenty of vendors write: cookie-free, so no banner. The conclusion is often right, the reasoning almost never. What matters is not the cookie but whether anything already stored in the terminal device is accessed. In Minimal and Standard we store nothing on the device, and what we read was not there beforehand. In Full mode we write an identifier, and there you do need consent. Here is the whole derivation, including the opposing reading. The claim ## No cookie, no banner. Right answer, wrong reasoning. Cookie-free, therefore consent-free, therefore no banner. That chain appears on nearly every privacy-friendly analytics site. The conclusion holds in many cases, the route to it does not, and anyone relying on the wrong reasoning finds out only when someone asks. § 25(1) TDDDG, the German provision implementing Art. 5(3) ePrivacy, does not attach to cookies. It attaches to two acts: storing information in the terminal device, and accessing information already stored there. A cookie is only the best-known instance of the first. Setting no cookie therefore settles one half of the question, not both. The second half decides the banner: is anything accessed that is stored in the device? For Minimal and Standard our answer is no, because what gets read are status values the browser itself produces at the moment of the page view. For Full mode the answer is yes, because an identifier gets written. We set out both, including the stricter view that reaches a different conclusion. The controller for the integration is you, not us. A claim in a feature list will not help you in proceedings; a derivation you can follow will. What it turns on ## Four questions, not one. Whether you need a banner turns on four points. Cookies are only one of them, and the least important. ### Cookie or not is secondary § 25 speaks of information, not of cookies. What matters is whether anything is stored in the device or read from it, whatever the carrier. ### Stored, or produced at runtime A cookie is already there. A measurement comes into being during page load. Only the first is, on the wording, access to stored information. ### Fingerprinting or not Status queries tip into requiring consent as soon as they become a recognition signal. That is why we transmit classes rather than raw values. ### Which preset Minimal and Standard write nothing to the device. Full writes an identifier into sessionStorage, and there consent is required. Layer 1: § 25 TDDDG ## Storing or accessing, and which of them we do. § 25(1) TDDDG Die Speicherung von Informationen in der Endeinrichtung des Endnutzers oder der Zugriff auf Informationen, die bereits in der Endeinrichtung gespeichert sind, sind nur zulässig, wenn der Endnutzer auf der Grundlage von klaren und umfassenden Informationen eingewilligt hat. German Telecommunications Digital Services Data Protection Act. In English: storing information in the end user's terminal equipment, or accessing information already stored in it, is permitted only where the end user has consented on the basis of clear and comprehensive information. Two triggers, one word between them: or. Storing is enough, accessing is enough, they need not coincide. Whether the information is personal data is irrelevant for § 25. The provision protects the device, not the data. Storing: in Minimal and Standard we do not. No cookie, no localStorage, no sessionStorage. The write path is removed from the shipped bundle at build time, so it is not present in the browser rather than merely switched off. Accessing: here the decisive word sits in the statute, namely information that is „already stored in the terminal equipment“. What our script reads was nowhere beforehand. The timings come into being during page load, window.innerWidth is the current window state, navigator.connection a running estimate by the browser. These are queries to the runtime environment, not to a store. It gets borderline where such queries turn into a recognition signal, that is, fingerprinting. Which is why we transmit one of six viewport classes rather than the pixel value. That lowers the entropy far enough that recognition from this combination is practically ruled out. Full mode is a different matter: there an identifier is written into sessionStorage, and a write is uncontroversially covered. The exemptions in § 25(2) do not carry it: no. 1 covers only the mere transmission of a communication, and no. 2 requires the access to be strictly necessary for the provider to supply a service the user explicitly requested. A performance measurement is not that service. ### The opposing reading, in full Our classification is not the only defensible one. There is a stricter reading, and it is well sourced. Here it is, with what would follow from it, so you can weigh both instead of taking our word. DSK, guidance for providers of digital services Unlike data protection law, § 25(1) TDDDG establishes a consent requirement for the storing and/or reading of information on or from a terminal device irrespective of whether that information is personal data. This applies to us too. § 25 does not turn on personal data, so „we process no personal data“ is not an argument here. The only question is whether there is storing, or access to something stored. DSK, on reading via JavaScript It also counts as accessing information on end users' terminal equipment where, for example, properties of a device are actively read out by means of JavaScript code and transmitted to a server in order to create a fingerprint. The stricter reading extends this sentence to any reading via JavaScript. It sits in a fingerprinting context, though, and that is exactly where our line runs: classes rather than raw values, no recognition, no fingerprint. EDPB, Guidelines 2/2023, local processing This may be the case, for example, with an API provided by the web browser whose locally generated results can be retrieved remotely. This is the strongest point against us. The EDPB includes locally generated results of a browser API. Follow it and our performance measurement is covered too, and consent would be required. EDPB, Guidelines 2/2023, gaining access Such access clearly falls within the scope of Article 5(3) ePrivacy Directive, since the accessing entity explicitly instructs the terminal equipment to transmit the information. This sentence also supports the strict reading. Against it we hold the German statutory text, which requires information that is already stored. Which interpretation prevails has not been settled by a court. EDPB, Guidelines 2/2023, storage and access The storage of information and the access to information already stored need not both be present for Article 5(3) ePrivacy Directive to apply. Which is why „we set no cookies“ is not sufficient as reasoning. The second trigger has to be assessed on its own, and that is exactly the section above. Read the originals § 25 TDDDG, full text in German EDPB Guidelines 2/2023, version 2.0 DSK guidance for providers of digital services Our conclusion In Minimal and Standard mode, in our assessment no consent is required under § 25(1) TDDDG: nothing is stored in the device, and the status values that get read were not there beforehand. In Full mode it is required, because an identifier gets written. This assessment has been reviewed with our external data protection officer. A residual risk remains, because no court has ruled on this constellation. What happens on the device ## Line by line, nothing smoothed over. Three collection presets, and what each of them actually does on the visitor's device. The second-to-last row is the dividing line. | | Minimal | Standard | Full | Beacon script delivered to the browser sits in the browser cache, like any script on a page | Yes | Yes | Yes | Performance API read LCP, INP, CLS, TTFB, navigation and resource timing, produced during page load | Yes | Yes | Yes | Viewport class and connection class read | Yes | Yes | Yes | Error objects read type and count, stack frames from Standard up | Yes | Yes | Yes | Anything written to the device Full only, one tab-bound session ID in sessionStorage._fms | No | No | Yes | Cookie set | No | No | No | Long-lived or cross-site identifier | No | No | No | Consent under § 25 TDDDG required because of the write in Full, not because of cookies | No | No | Yes The dividing line is the row „Anything written to the device“. Above it sit values that come into being during page load and were not in the device before. Below it sits a write, and a write uncontroversially requires consent. Layer 2: GDPR ## Applicable, and because of the IP. § 25 TDDDG governs access to the device, the GDPR the processing that follows. The two are assessed separately, and the answers are allowed to diverge: no access under the TDDDG but the GDPR applicable is precisely our case. The payload values themselves we consider not relatable to a person: country instead of IP, classes instead of raw values, path without query string, no user ID, no long-lived recognition. The GDPR applies regardless, because of one item we never query. The IP address travels in the HTTP header of every request, and under the CJEU's Breyer ruling it is personal data. The legal basis is the legitimate-interest balancing test in Art. 6(1)(f) GDPR, not consent. On one side sit stability, performance measurement, basic statistics and debugging; on the other the visitor's protected interest. The risk to them is low: no cross-site tracking, no profiling, no fingerprinting. That balance would tip the moment it became an analysis of user behaviour in the sense of profiling. For that, the case law consistently requires consent, from Planet49 through the German Federal Court's cookie-consent ruling to the CJEU's Meta judgment. It carries here precisely because fastmon builds no profile. That balance only holds under conditions, and we meet them: IP and user agent are processed solely to receive the request and discarded in under a second, no reconstructible IP sits in the stored analytics data, and we pass the data to no one. ### Two deployments, two outcomes Large, generic sites A shop with six-figure visitor numbers, generic paths such as /category/shoes, many visitors per path and country. A single record fits thousands of people. Usually not relatable to a person Small or highly specific sites A B2B portal with a handful of visitors a day, speaking paths such as /customers/northwind-ltd/contract or /application/status. Country, device and path together can converge on one person. Possibly relatable, assess it yourself This classification is a case-by-case assessment and the controller's job, which means yours. We supply the factual basis and the documentation for it; we cannot make the call for you. In practice it decides your legal basis, your information duties and your retention. In both scenarios fastmon belongs in your privacy policy. IP address and edge ## The place where it stays borderline for us too. Under the case law of the Court of Justice of the European Union, an IP address is personal data. It is transmitted on every page view, which is technically unavoidable and unproblematic for delivering the page. It gets interesting once you use it to derive something. Which is exactly what our edge does, in more than one place: From the IP it resolves the country code and checks whether it belongs to a datacenter or a verified crawler. From the user agent it derives coarse classes: browser, major version, operating system, device type, plus a bot classification. It checks the browser's client hints for contradictions to spot spoofed requests. It condenses the referrer to medium and source, without search terms. And it computes the stitch. It then discards the IP, the raw user agent, the client hints and the referrer URL in under a second, without storing or logging them. Only the results reach the fastmon application. That is the point of the architecture: the application is never to see the raw data, and automated tests verify that it stays that way. And here is the honest caveat. Each of these derivations is an analysis, and it happens before the application sees anything. Passing on only the extract moves the personal reference out of the application. It does not undo the derivation itself: for a fraction of a second, personal data was processed. We rest that step on the same legitimate-interest balance: brief processing, immediate discarding, no reconstructible remainder in the stored data. Whether that survives a future court assessment is open. We think it more likely that requirements tighten over the medium term than loosen. Anyone selling you certainty here is selling you an opinion. ### One page view, step by step - 01 #### Browser requests the script The request carries the IP address, like every HTTP request. Technically inherent transmission, unproblematic for delivery. - 02 #### Beacon reads in the browser Performance API, viewport class, connection class, error objects. Status values of the runtime environment that were not in the device beforehand. - 03 #### Edge derives and discards Country code and datacenter check from the IP, device classes and bot classification from the user agent, medium and source from the referrer, stitch. After that the IP, user agent, client hints and referrer URL are gone, in under a second, with no log. This is the borderline step. - 04 #### Application sees only the extract Country, classes, metrics, path without query string. No raw IP, no user agent string, no persistent identifier. ### The stitch stays borderline To count unique visitors, the edge computes a short pseudonymous signal: HMAC-SHA256 over IP, user agent, the hash of your embed and the domain, under a salt that is regenerated every 24 hours and never leaves the edge's memory, no log, no disk, no API. Different per domain. What protects the signal is not the mathematics but the salt: the stored value alone yields no IP, but anyone holding the salt could try candidates and confirm a suspicion. Nobody holds that salt: it exists only inside the running edge process, the same process that sees and discards the IP on every request anyway. After rotation it is irretrievably gone, and from that point on nobody can make the link, us included. The stitch comes into being at the edge, not in the browser, so it is not a § 25 question but a GDPR one. We treat it as personal data, pseudonymisation rather than anonymisation, and rest it on the legitimate-interest basis. That reduces the risk, it does not remove it: a signal that joins page views across 24 hours is a form of recognition, and with highly specific paths a personal reference can arise. store_stitch=false switches the signal off, and the Minimal preset does not include it in the first place. The stitch is also why fastmon gets by without sessions. A real session ID would be more precise: it knows about inactivity, survives an IP change and separates visitors behind the same office IP. But it has to be stored on the device, and that is where the consent requirement begins. Percentiles need no identity at all, and for visitor counting the stitch is precise enough: shared IPs merge into one visitor, a changing IP counts twice, the absolute number carries a small blur while the trends stay stable. So we advise against sessions unless you genuinely need them. Only the Full preset writes a session ID, and there consent is part of the deal. Technical privacy documentation: edge, stitch and every setting What we do not claim That the question is settled for you. Our assessment covers our architecture, not your deployment. Which preset you run, how specific your paths are and how many visitors you have all feed into it. That assessment stays with you, and the legal position can change. If you gate it anyway ## What an opt-out costs you. Some operators put fastmon behind consent regardless, out of caution or because they run Full mode. Even then you are better off than with cookie-based tools: there every opt-out additionally costs the recognition, with us only sample size. With fastmon - If a visitor declines, nothing is measured for that visit, exactly as it should be - The sample gets smaller, the distribution stays intact. For percentiles such as the p75 that is the decisive point - No double-counted users, no orphaned sessions, because there is no long-lived recognition that could break in the first place - So your numbers get smaller, not skewed, whatever your opt-out rate happens to be With cookie-based tools - Every opt-out additionally costs the recognition the user counts are built on - Returning visitors turn into new visitors and unique counts drift upwards - Sessions break mid-funnel and reappear as new ones - The distortion grows with the opt-out rate and cannot be corrected after the fact Residual risk ## A game of cat and mouse, said out loud. The history of web tracking is a chain of technique and ruling. First people simply measured. Then courts required an opt-out in the privacy policy. Then a notice banner. Then „by continuing to browse you agree“ was struck down. Then came the consent banner we know today. We assume requirements will keep tightening. So we build such that a tightening does not catch us out: the beacon can be pushed entirely behind a consent gate, the presets turned down, and the data basis is narrow enough to still carry after a tightening. Residual risk remains regardless, with any tool. Anyone running modern IT accepts it in several places at once, usually without discussing it: standard contractual clauses for US services, transfer impact assessments whose basis can change, office suites no company is switching off tomorrow. The honest question is not whether you carry residual risk, but which, how large, and whether you carried it knowingly. Our contribution to that is traceability. No provider under US jurisdiction in the data path, so the transfer question never arises with us. Raw data that never reaches the application. And a page like this one, which prints the opposing reading in full. ### How the standard has shifted - Stage 1 Measurement simply happened, with no notice to the visitor - Stage 2 Opt-out in the privacy policy, required by court ruling - Stage 3 Notice banner along the lines of „by continuing you agree“ - Stage 4 That construction struck down, a real consent banner required - Stage 5 Dispute over what counts as access to the device. This is where we are - Stage 6 Open. Our assessment is one reading; the stricter one exists alongside it What you should do ## Six steps and it is documented. Not rocket science, but it has to be done and evidenced. Preferably in this order. - 01 ### Choose the preset deliberately Minimal and Standard stay write-free. Full writes an identifier and then needs consent. That is the real lever; everything else follows from it. - 02 ### Put fastmon in your privacy policy Vendor, purpose, legal basis (Art. 6(1)(f)), retention and recipients. In Minimal and Standard this is the step that replaces the banner. - 03 ### Gate Full mode behind consent Via your consent management platform or via grantConsent(), so the identifier is only written after opt-in. Category statistics, not „strictly necessary“. - 04 ### Assess relatability for your case How specific are your paths, how many visitors do you have per path and country? Document the result. This is the part nobody can do for you. - 05 ### Keep personal data out of collectable fields Not in URL paths, query strings, UTM parameters, tag values or error contexts. Customer numbers, names and email addresses do not belong in a URL that gets measured. - 06 ### Set retention to your own measure 90 days is the default, shorter is configurable. Longer only where you can justify why you need the data for that long. Interactive check ## Do you need a banner? Three questions. Three questions in the order a data protection officer would ask them: what happens on the device first, then what your web addresses reveal, then how many people are behind them. What is fastmon allowed to collect on your site? The collection mode is shown on the application in the dashboard. If you never changed it, it is Standard. Minimal Core performance only. No visitor signal, no error detail. Standard The default. Adds visitor counting, network calls and error detail. Full Everything, and it additionally places an identifier in the visitor's browser. Does any of your web addresses reveal who is involved? This is about the address itself, what sits in the browser bar. Does it contain names, customer, contract or case numbers? No, my addresses are generic For example /category/shoes or /blog/article. Nothing in them shows who opened the page. Yes, some of them spell it out For example /customers/northwind-ltd/contract or /application/status-4711. The address itself reveals who or what it is about. How many people open a single page? A rough estimate is enough. The question is whether one measurement could have come from many people or from just one. Many, at least a few hundred a month A single measurement could have come from a great many people. Few, sometimes only a handful A single measurement might be attributable to one particular person. The three possible outcomes No banner needed In our assessment you need no consent: nothing is stored on the device, the values read only come into being during the page view, and your data does not give rise to a personal reference. What takes the place of the banner is naming fastmon in your privacy policy. - Add fastmon to your privacy policy: vendor, purpose, legal basis Art. 6(1)(f), retention, recipients - Document the outcome of this assessment so you can justify it later - Keep personal data out of URL paths, query strings and UTM parameters Consent required The Full preset writes a tab-bound session ID into sessionStorage. A write to the device is uncontroversially covered by § 25(1) TDDDG, and the exemptions in subsection 2 do not carry a performance measurement. Either you collect consent, or you switch to Standard. - Add fastmon to your consent management platform, category statistics, not „strictly necessary“ - Load the beacon only after opt-in, or set session_consent to deferred and call grantConsent() once consent is given - Alternatively switch to the Standard preset, which removes the write entirely Borderline, assess it yourself Under § 25 TDDDG you need no consent in our assessment, because nothing is stored on the device. The GDPR question is open in your case, though: with speaking paths or few visitors the sum of attributes can converge on a single person. That assessment sits with you; we cannot make it for you. - Defuse speaking paths: get IDs and names out of the URL, or switch collect_query_keys off - Switch store_stitch off, and the stored row carries no visitor signal at all - If doubt remains: put fastmon behind consent and list it as statistics in your CMP - Document the assessment together with your data protection officer This outcome is our view based on what you told us, and it is not legal advice. Have it confirmed by your data protection officer or a lawyer before you go live. Responsibility for the integration remains with you as the operator of the website. Restart the check The evaluation runs entirely in your browser. We learn neither your answers nor your result. The asterisk ## What the asterisk in our footer means. Every page carries an asterisk after „no cookies“. That asterisk is the short version of everything above. Here is the long version, sentence by sentence. „In Minimal and Standard mode fastmon sets no cookie and stores nothing on the device“ means what exactly? That in these two modes no cookie is set and nothing is written, neither localStorage nor sessionStorage. The write path is not contained in the shipped script; it is removed at build time. That is verifiable, not merely promised. „What it reads are status values the browser generates at runtime“ means what exactly? That the values read were nowhere in the device before the page view. Timings come into being during page load, the window width is the current state, the connection class a running estimate. In our assessment that is not access to stored information within the meaning of § 25 TDDDG. The stricter opposing view is printed in full above. „Full mode writes an identifier“ means what exactly? That Full stores a tab-bound session ID in sessionStorage._fms, which expires when the tab closes. That is a write, and for it you need consent. Minimal and Standard do not do it. FAQ ## Cookie banners and consent, answered. The questions a data protection officer asks first, with the answers we give even when they are inconvenient. ### Do I need a cookie banner for fastmon? No, not in Minimal and Standard mode. Nothing is stored on the device, and the values read were not there beforehand. Naming fastmon in your privacy policy is enough. In Full mode you do need consent, because an identifier is written into sessionStorage. This classification has been reviewed with our external data protection officer; a residual risk remains, because no court has ruled on it. ### If I do use a banner: does fastmon have to be named in it? A specific product name is not mandatory. What is mandatory is that it be clear which data is processed for which purpose by whom, and how long it is kept. Those are the ordinary requirements for consent. In practice, naming the vendor is the simplest way to meet them, and it helps you with the information duties under Art. 13 and 14 GDPR at the same time. ### Why is „we set no cookies“ not sufficient as reasoning? Because § 25 TDDDG names two acts: storing in the device, and accessing what is already stored there. Per the EDPB the two need not both be present. Setting no cookie settles the first. The second has to be assessed on its own, and that assessment is exactly what most vendors skip when they argue from cookie-freeness. ### We process no personal data. Does that count for § 25? No. The German Data Protection Conference states expressly that § 25 applies irrespective of personal data; the provision protects the device, not the data. For § 25 all that matters is whether there is storing, or access to something stored. Personal data decides the second, separate question under the GDPR. ### What exactly does the beacon read from the browser? The Performance API for LCP, INP, CLS, TTFB and the timings, the window width as one of six classes, the connection class, the referrer, the page URL, plus error type and count. All of these come into being at the moment of the page view; none was in the device beforehand. We never call navigator.userAgent, and the IP and user agent reach us only as HTTP headers. ### The stricter view exists. Why do you not follow it? Because the German statutory text requires information already stored in the terminal equipment, and runtime values are not that. The EDPB's stricter reading includes locally generated results of a browser API; we print it in full above, because it is defensible. Should it prevail, our recommendation changes, and the beacon can be pushed entirely behind a consent gate. ### Is reading the window width not fingerprinting? That is exactly where the line runs, which is why we transmit no pixel value but one of six classes. Combined with country, browser family and device class the entropy stays low enough that recognition is practically ruled out. No canvas, no font enumeration, no sensors, no audio. ### And the stitch? It comes into being at the edge, not in the browser, so it is not a § 25 question but a GDPR one. We treat it as personal data and rest it on the legitimate-interest basis in Art. 6(1)(f). HMAC-SHA256, the salt rotates every 24 hours and never leaves the edge's memory, different per domain, not reversible. It stays borderline regardless: with highly specific paths a personal reference can arise. store_stitch=false switches it off. ### Why does the GDPR apply at all if the values are anonymous? Because of the IP address. It travels in the HTTP header of every request even though we never query it, and under the CJEU's Breyer ruling it is personal data. The legal basis is the legitimate-interest balance in Art. 6(1)(f), and it holds because the IP and user agent are processed only to receive the request and discarded in under a second. ### What happens to my numbers if I do put fastmon behind consent? They get smaller, not skewed. fastmon measures aggregated field performance from a sample, and a smaller sample stays meaningful as long as it is not systematically distorted. Because no long-lived recognition exists anyway, no sessions break and no unique counts drift. With cookie-based tools every opt-out additionally costs you the recognition. ### Do you need a data processing agreement? If personal data is processed in your deployment, yes, then we are a processor under Art. 28 GDPR. The agreement is concluded on registration and is publicly available. Because the IP in the header means personal data is involved in any case, we conclude it either way. ### Do I have to name fastmon in my privacy policy? Yes, and in Minimal and Standard that is the step which takes the place of the banner. It should carry vendor, purpose, legal basis under Art. 6(1)(f), retention and recipients. The information duties under Art. 13 and 14 GDPR apply as soon as personal data is processed, and via the IP in the header that is the case. ### How long may I retain the data? Delete once it is no longer needed for the purpose and no statutory retention duty stands in the way. How long that is, you have to justify, and it depends on your case. In fastmon 90 days is the default, shorter is configurable, up to 13 months on Enterprise plans. ### What if a court sees this differently later? We expect it to, and the history above shows why. That is why nothing about fastmon depends on today's reading holding: the beacon can be pushed entirely behind a consent gate, the presets turned down, and the data basis is narrow enough to still carry. What would change is our recommendation, not your setup. ### Is this legal advice? No. This page describes how fastmon is built and how we read the legal position, reviewed with our external data protection officer. The assessment for your deployment is yours to make, ideally with your own data protection officer. Not legal advice. This page reflects the state of our own assessment, reviewed with our external data protection officer, and describes how fastmon is built and documented. No court has ruled on this constellation; a residual risk remains. The legal position and supervisory practice change, and assessing your concrete deployment is your responsibility as controller. The binding documents are Privacy and Data Processing Agreement . ## 100% EU, hosted in Germany. No Cloudflare, no AWS, no GCP. Read-only by default: no cookies*, no long-lived identifiers. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/dpa/ Legal # Data Processing Agreement (DPA) Art. 28 GDPR · Last updated: 17 July 2026 Notice: This DPA applies automatically to all users of the fastmon platform and is concluded with binding effect upon acceptance of the Terms at registration. For individual Enterprise constellations with bilateral signature, an extended DPA version is available on request at privacy@fastmon.eu. ## § 1 Contracting parties, order of precedence (1) Customer, Controller: The user of the "fastmon" platform (entrepreneur within the meaning of Section 14 BGB) whose individual details are recorded in the user profile at contract conclusion. (2) Provider, Processor: fastmon labs UG (haftungsbeschränkt) Stresemannallee 4, 30173 Hannover, Germany Hannover Local Court, HRB 230880 Managing Directors: Kamil Adrian Czujowski, Lucas Röhrs Email: privacy@fastmon.eu (3) This DPA specifies the data protection obligations of the parties arising from the use of the Software-as-a-Service offering fastmon (Real User Monitoring). In the event of conflicts between this DPA and other agreements (in particular the Terms), the provisions of this DPA prevail. ## § 2 Subject, nature and purpose of processing (1) The Provider makes the SaaS service fastmon available to the Customer. The subject matter is the measurement of performance and availability of websites and web applications operated by the Customer from the perspective of actual end users (Real User Monitoring). Processed are Core Web Vitals (LCP, INP, CLS, TTFB, FCP), Navigation and Resource Timing, technical metadata on browser, operating system, device, viewport, country code (ISO-2) and error events. (2) The purpose of processing is to provide the dashboard, alerting and performance analysis to the Customer. (3) Processing of the data for the Provider's own purposes (advertising, profiling, transfer to third parties) does not take place. (4) The Customer warrants not to transmit personal or personally identifiable data of any kind into fields capable of being recorded by the Provider. This includes in particular URL paths, query strings, anchors, UTM and campaign parameters, freely configurable brand values, tag values and error contexts. Special categories under Art. 9 GDPR and data under Art. 10 GDPR are not processed. Any transmission contrary to this warranty takes place outside the agreed processing purpose and falls within the Customer's area of responsibility. ## § 3 Duration The duration of this DPA corresponds to the term of the main contract (fastmon usage agreement). ## § 4 Customer's right of instruction (1) The Provider processes personal data exclusively within the scope of the agreements made and according to documented instructions of the Customer. (2) Instructions are generally given through the use of the dashboard and API; instructions going beyond this are to be issued in text form to privacy@fastmon.eu. (3) If the Provider considers an instruction to be in breach of data protection law, it must inform the Customer immediately. ## § 5 Edge server architecture and Stitch identifier (1) The Provider operates an upstream edge server layer. The IP address and raw User-Agent of the end user are processed there exclusively transiently (less than 1 second in memory) to derive the country code (ISO 3166-1 alpha-2) and browser category, and are discarded immediately thereafter. (2) The application layer, database and logs do not at any time process or store raw IP addresses or raw User-Agent strings. This property is permanently safeguarded by automated tests. (3) The Stitch identifier is a server-side computed HMAC-SHA256 hash based on a rotating 24-hour salt, tenant-internal and per-site. Recognition beyond a session, across sites or across devices is technically impossible. The Stitch can be disabled per site ( store_stitch=false ). ## § 6 Provider's obligations (1) The Provider ensures that persons authorised to process the data are committed to confidentiality. (2) The Provider implements the technical and organisational measures described in § 8. (3) The Provider supports the Customer in complying with the obligations under Art. 32 to 36 GDPR within the scope of the information available to it. ## § 7 Sub-processors (1) The Customer approves the following sub-processors: - Hetzner Online GmbH, Gunzenhausen (DE), hosting, storage, backup (Falkenstein data center, DE) - sevdesk GmbH, Offenburg (DE), accounting and invoicing - Lettermint B.V., Zwolle (NL), transactional emails - Soverin B.V., Rotterdam (NL), business mail - BunnyWay d.o.o., Tržič (SI), authoritative DNS service - smoxy GmbH, Berlin (DE), ingress - Mistral AI SAS, Paris (FR), LLM inference (only when the AI chat function is opted in) - ScaleCommerce GmbH, Berlin (DE), hosting - All Quiet GmbH, Berlin (DE), on-call tool for fastmon Engineering (2) With Mollie B.V., Amsterdam (NL), there is no processing on behalf within the meaning of Art. 28 GDPR. Mollie acts as a regulated payment service provider under PSD2 in its own data protection responsibility. (3) A current list of sub-processors is available at fastmon.eu/en/subprocessors and on request from privacy@fastmon.eu. (4) If the Provider intends to engage further sub-processors or replace existing ones, it informs the Customer 30 days in advance in text form. The Customer has a right of objection for important data protection reasons. In case of a legitimate objection, the new sub-processor may not be used for the processing of the data of the objecting Customer until an amicable solution has been reached. If no solution is reached within 30 days, the Customer has a right of extraordinary termination of the main contract. ## § 8 Technical and Organisational Measures (TOM) The Provider implements in particular the following measures pursuant to Art. 32 GDPR: - EU-only infrastructure, no data transfer to US providers in the data path - TLS encryption of all external connections - Edge stripping of IP and User-Agent before the application layer - Data minimisation as architectural principle, no cookies and no persistent identifiers in the default mode - Tenant separation in the database via tenant IDs - Role-based access control, least-privilege principle - SSH access only via public key, 2FA for administrative consoles - Encrypted database backups, retention 7 days - External uptime monitoring and alerting Detailed TOM documentation available on request from privacy@fastmon.eu. ## § 9 Data subject rights (1) The Provider supports the Customer in responding to requests of data subjects under Art. 15 to 22 GDPR within the scope of the information available to it. (2) Due to the data-minimised architecture (edge stripping of IP, no persistent identifiers, 24-hour limit of the Stitch), direct attribution of telemetry data to a natural person is regularly not possible. The Provider points this out in individual cases (Art. 11 GDPR). (3) If a data subject contacts the Provider directly, the Provider forwards this request to the Customer without delay. ## § 10 Data breaches The Provider notifies the Customer of any breach of the protection of personal data pursuant to Art. 4 No. 12 GDPR immediately, at the latest within 24 hours of becoming aware. The notification contains at least the nature of the breach, affected data categories, approximate number of data subjects, consequences and measures taken. ## § 11 Deletion and return after end of contract (1) After termination of the main contract, the Provider deletes the personal data of the Customer within 30 days, including all backups within the regular backup retention. (2) The Customer can secure its data prior to end of contract via the export interfaces provided in the product. (3) Storage beyond the end of contract only takes place insofar as statutory retention obligations require it (in particular invoicing data, Section 257 HGB, Section 147 AO, 10 years). ## § 12 Audit rights (1) The Customer has the right to verify compliance with this DPA. This is primarily done by submission of the current TOM documentation, self-assessments and, if applicable, certificates of sub-processors (Hetzner ISO 27001, All Quiet ISO 27001). (2) On-site audits are possible with 30 days' prior notice, at most once per calendar year, during normal business hours. The costs are borne by the Customer, and by the Provider in case of a material violation found. ## § 13 Liability Liability is governed by Art. 82 GDPR and the provisions of the Terms. Liability caps in the Terms do not apply to fines under Art. 83 GDPR, insofar as their cause falls within the Provider's area of responsibility, and to intent and gross negligence. ## § 14 Government and law enforcement requests (1) If the Provider receives requests from authorities to disclose personal data of the Customer, it examines the lawfulness and discloses only the minimum legally required. (2) The Provider informs the Customer without delay, insofar as legally permitted. (3) Processing under the U.S. CLOUD Act, FISA 702 or comparable extraterritorial access regimes is currently not expected, as processing activities take place in the EU or EEA. ## § 15 Final provisions (1) German law applies, excluding the UN Sales Convention. (2) Place of jurisdiction is Hannover, unless mandatory statutory provisions provide otherwise. (3) Amendments to this DPA require text form. In case of conflicts between this DPA and the main contract, the provisions of this DPA prevail with respect to data protection matters. (4) Should individual provisions be invalid, the validity of the remaining provisions remains unaffected. fastmon labs UG (haftungsbeschränkt) · Stresemannallee 4, 30173 Hannover · Hannover Local Court HRB 230880 --- ## https://fastmon.eu/en/eu/ Digital sovereignty # 100% EU. No fine print. The entire fastmon data path runs in the EU, on infrastructure operated in Germany, with no US-jurisdiction provider anywhere in it. No cookies*, no fingerprinting, the IP gone before any code sees it. This is the difference between a tool from the EU and one with an EU region. What EU hosting really means ## From the EU, not just with an EU region. Most tools that call themselves privacy-friendly are US companies with a data center in Frankfurt. The servers sit in Europe, but the company answers to US law, and the US CLOUD Act reaches its data wherever it lives. An EU region is not the same as EU jurisdiction. fastmon is different by construction. fastmon labs UG is a German company registered in Hannover, and all customer and monitoring data is processed exclusively in the EU and stored in Germany (Hetzner, Falkenstein data center). Every provider in the data path, meaning every system that processes customer or monitoring data, is a German or EU company: no Cloudflare, no AWS, no GCP, no Vercel, no US-owned sub-processor. Because neither fastmon nor any sub-processor is subject to US law, the US CLOUD Act cannot reach that data. Sovereignty is only half of it. The tracker is privacy-first by design: it sets no cookies* in the default mode, uses no fingerprinting, and the visitor's IP and User-Agent are removed at the edge before any application code sees the request. What is left is field data you can defend to your data protection officer. Infrastructure ## No US provider in the data path. Where your data is processed decides who can compel access to it. fastmon keeps every step inside EU jurisdiction. ### Operated in Germany All customer and monitoring data is processed exclusively in the EU and stored in Germany (Hetzner, Falkenstein data center). Nothing leaves that path. ### No US-owned sub-processor No Cloudflare, no AWS, no GCP, no Vercel. Every provider in the data path is a German or EU company. ### The CLOUD Act cannot reach fastmon Because neither fastmon nor any sub-processor is subject to US law, the US CLOUD Act cannot reach it. ### EU region is not EU jurisdiction A US company with a Frankfurt region is still a US company. Sovereignty means no US law is in play, not just servers in Europe. Sub-processors ## Every provider, on the table. The full data path, from hosting to email to AI. Every one is a German or EU company. No US provider in the data path. | Provider | Purpose | Location | Hetzner Online GmbH | Hosting, storage, backup | Germany, Falkenstein | smoxy GmbH | Ingress | Germany, Berlin | sevdesk GmbH | Accounting and invoicing | Germany, Offenburg | All Quiet GmbH | On-call tooling for engineering | Germany, Berlin | ScaleCommerce GmbH | Hosting | Germany, Berlin | Lettermint B.V. | Transactional email | Netherlands, Zwolle | Soverin B.V. | Business email | Netherlands, Rotterdam | BunnyWay d.o.o. | Authoritative DNS | Slovenia, Tržič | Mistral AI SAS | AI inference, only if you opt in | France, Paris From the AVV, as of 17 July 2026. Five of the nine are in Germany, the rest in the EU. Internal business tools that never process customer or monitoring data are listed transparently on the providers page. See every provider in detail What we collect ## The whole payload, and what is not in it. fastmon collects field data, not identities. No setting turns on fingerprinting, a cross-site identifier or a per-person profile; the presets only change how much context is captured, never whether you can be recognized across sites or over time. What fastmon sees - Core Web Vitals and diagnostics from real page loads - Country only, 2-letter ISO, derived at the edge from the IP - Device, browser, OS, connection and viewport as buckets - Error type, count and stack frames (no message text by default) - A per-domain, 24-hour stitch signal for unique-visitor counts What it never does - No cookies* in the default mode - No canvas, font, Client Hints, battery, sensor or audio fingerprinting - No session replay, no reading of page content, no scroll or form capture - No cross-site identifiers, no third-party enrichment - No raw IP or User-Agent reaches the backend, ever Counting without cookies* ## Recognized for a visit, not tracked for life. fastmon counts unique visitors without a cookie* or a device ID. Instead the edge computes a short pseudonymous signal, the stitch, under a secret salt it throws away every 24 hours. - The salt is a 32-byte random value, held only in the active edge's RAM, rotated every 24 hours and never stored, distributed or logged - The domain is mixed into the hash, so the same visitor gets a different signal on every site: identifiers never cross domains - HMAC-SHA256 is one-way and cannot be inverted. And to tie a signal back to an IP, someone would have to brute-force every IP with the live salt, which is gone after a rotation (forward secrecy) - We treat the stitch as personal data and rest it on the legitimate-interest basis in GDPR Art. 6(1)(f), documented Cookies, TDDDG and consent Computed at the edge # rotating_salt: 32 bytes, edge RAM only, rotated every 24h # never stored, never logged stitch = HMAC-SHA256( rotating_salt, IP | User-Agent | collector_hash | domain ) # raw IP and User-Agent are discarded here, # before any application code sees the request Collection presets ## You choose how much is collected. Three presets, from performance-only to full session context. Standard is the default. In Minimal and Standard nothing is stored on the device; only Full places a tab-bound session ID, which expires when the tab closes. | | Minimal | Standard | Full | Web Vitals, device and connection class | Yes | Yes | Yes | Error type and count | Yes | Yes | Yes | Stitch visitor signal edge-derived, for unique counts | No | Yes | Yes | Fetch / XHR aggregates | No | Yes | Yes | Query key names | No | Yes | Yes | Full error stack frames | No | Yes | Yes | Error message text | No | No | Yes | Session id written to sessionStorage._fms | No | No | Yes Standard (the default) writes nothing to the visitor's device. Only the Full preset writes a single tab-scoped session id that dies with the tab. Consent and the TDDDG ## What we do, and what follows from it. Whether embedding an analytics tool needs consent under § 25 TDDDG turns on one question: is anything stored in the device, or is anything accessed that is already stored there? Cookies are only the best-known case, not the trigger. In the default mode nothing is written to the visitor's device, no cookie and no sessionStorage; the write path is removed from the shipped bundle at build time. What gets read are status values the browser itself produces during the page view: timings, viewport class, connection class. In our assessment that is not access to stored information within the meaning of § 25; a stricter reading sees it differently. Only the Full preset writes a session id, and for that you need consent, deferrable until your consent tool calls grantConsent(). The assessment for your own site, though, is yours to make, ideally with your data protection officer. § 25 TDDDG covers the device access; the GDPR covers the processing that follows, and both are assessed in parallel. Not legal advice. This mirrors how fastmon is built and documented; your deployment is your responsibility. The data sheet ## The facts, without the marketing. Everything on this page, condensed. All of it comes from the public documentation. Verified against docs.fastmon.eu. Retention and collection are configurable per site; the stitch is treated as personal data, with the legitimate-interest basis in Art. 6(1)(f) as its legal ground. Privacy data sheet Company fastmon labs UG Hannover, Germany Hosting Germany (Hetzner) No Cloudflare, AWS, GCP, Vercel IP address Removed at the edge Never reaches the application Geo Country only, ISO-2 Derived at the edge from the IP Cookies None by default* Opt-in consent mode only Fingerprinting None No canvas, font, sensor, audio Retention 90 days default Up to 13 months on Enterprise CLOUD Act No access No data-path provider under US law DPA Public at /en/dpa/ Lists every sub-processor Read the full privacy docs FAQ ## EU and privacy, answered. The questions a data protection officer asks first. ### Do I need a cookie banner for fastmon? No, not in Minimal and Standard mode. Nothing is stored on the device, and the values that get read were not there beforehand: they come into being at the moment of the page view. Naming fastmon in your privacy policy is enough. In Full mode you do need consent, because an identifier is written into sessionStorage. This classification has been reviewed with our external data protection officer; a residual risk remains, because no court has ruled on this constellation. The full derivation, with the statutory text and the opposing reading ### Where is the data stored? Exclusively in the EU, on infrastructure operated in Germany. No Cloudflare, no AWS, no GCP, no Vercel, no US-owned sub-processor anywhere in the data path. No provider in the data path is subject to US law, so the US CLOUD Act cannot reach it. ### How do you count visitors without cookies? The edge computes a short pseudonymous signal, the stitch, as an HMAC-SHA256 of the IP, User-Agent, a site-specific hash and the domain, under a salt that rotates every 24 hours and never leaves edge memory. It is a one-way HMAC, per-domain and bounded to about 24 hours; it cannot be inverted, and once the salt rotates it cannot be tied back to an IP at all. We treat it as personal data and rest it on the legitimate-interest basis in GDPR Art. 6(1)(f). ### What do you collect, and what do you refuse to collect? Field data: Core Web Vitals, error type and count, device and connection buckets, and country from the IP at the edge. No fingerprinting, no session replay, no reading of page content, no scroll or form capture, no cross-site identifiers, no third-party enrichment. No setting turns on fingerprinting or a cross-site identifier; the presets only change how much context is captured, never whether you can be recognized across sites or over time. ### Do you offer a DPA or AVV? Yes. The Data Processing Agreement is public at fastmon.eu/en/dpa/ and lists every sub-processor in the data path. Questions: privacy@fastmon.eu. ### How long is data retained? 90 days by default; on Enterprise configurable per site up to 13 months. Statistics are kept for 13 months. When retention runs out the rows are dropped, not archived. ### Can I sign up with Google or GitHub without data going to the US? Signing in with Google or GitHub is optional. It concerns your login only, never your monitoring data: that always stays on our infrastructure in Germany, no matter how you sign in. If you use social login, you authenticate directly with Google or GitHub, a request you make to their service; we do not route your measurement data there, and the monitoring data path stays US-free. If you would rather not touch a US provider at all, register with email and password; for signing in, your account also supports passkeys, which are device-bound, involve no third party and no password, making them the most private option. ## 100% EU, hosted in Germany. No Cloudflare, no AWS, no GCP. Read-only by default: no cookies*, no long-lived identifiers. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/features/ Features # Five areas. One view. One script, the same beacons, no extra tags. Here is every area in detail, with the numbers straight from the docs. Real User Monitoring ## The numbers from real visits. Every real page load reports the metrics Google ranks you by, measured on your visitors' own devices and networks and evaluated at the p75. Everything condenses into one Experience Score: 0 to 10, graded A+ to F, from seven weighted signals (LCP 25%, INP, FCP and error rate 15% each, page load, CLS and TTFB 10% each). More on Real User Monitoring Core Web Vitals Demo Experience Score 9.2 A LCP 1.2 s good ≤ 2.5 s INP 48 ms good ≤ 200 ms CLS 0.03 good ≤ 0.1 FCP 0.9 s good ≤ 1.8 s TTFB 190 ms good ≤ 800 ms Synthetic Monitoring Beta ## The lab, right next to the field. On top of the field data from your real visitors, fastmon runs scheduled lab tests. Two test types, controlled and reproducible. Lighthouse · every 24 h ### Full Lighthouse audit - Full run every 24 hours, desktop and mobile in one pass - Performance, Accessibility, Best Practices and SEO - Simulated device, ideal conditions, fully reproducible TTFB · every 5 min ### Lightweight server check - Server-response check about every 5 minutes - Split into DNS, TCP, SSL, server and transfer - Cache bypass on by default More on Synthetic Monitoring Web Analytics ## Analytics, without the second tool. Visitors, sources and campaigns sit right next to the load times that decide whether they convert. One less tool in your stack. More on Web Analytics Live · now Demo Live · last 5 min Unique Visitors 1,284 Pageviews 3,902 Campaigns Demo Source / Medium Visits - google / cpc gclid 412 - facebook / paid 233 - (direct) 301 - newsletter / email 188 fastmon AI New ## Ask your data. In plain language. 'Ask about this test' turns a Lighthouse test into a plain-language summary and drills into a single error, so you skip the query building. It stays on your own fastmon data. New, and evolving with every release. Ask in plain language Drill into errors No query building More on fastmon AI EU & Privacy ## Designed inside the GDPR. Not retrofitted to it. That is the difference between a monitoring tool from the EU and one with an EU region. Here is the data sheet: the honest version, footnote included. * In Minimal and Standard mode fastmon sets no cookie and stores nothing on the device; what it reads are status values the browser generates at runtime. Full mode writes an identifier, and there consent under § 25 TDDDG is required. Assessing this is the responsibility of the respective website operator embedding fastmon. Data sheet Cookies 0* strictly storage-free: no localStorage, no sessionStorage IP address removed at the edge before any application code ever sees it Location country only two-letter ISO code, nothing more Data path 100% EU no Cloudflare, no AWS, no GCP Retention 90 days default, configurable per website Fingerprinting none no canvas, no font enumeration More on EU & privacy Built to run in production ## Everything else that ships with it The plumbing that makes the five areas usable day to day. All on the same script, all in the same dashboard. ### One line, live in ~5 minutes A single script tag with defer, no build step. First visitors show up in the dashboard about a minute after deploy. ### Release tracking from CI/CD Tag releases with one API call from GitHub Actions, GitLab or Vercel. Markers land on every chart, and you compare the hours before and after. ### Alerts that route themselves Threshold or percentage-change rules on Web Vitals, error rate, pageviews and more, sent to email, Slack, Discord or a webhook. ### Server-Timing breakdown Split server time into edge, origin, backend, database, render, cache and external phases, each at p50, p75 and p95. ### Cache monitoring, three layers Browser, CDN and origin cache status side by side, plus the bfcache hit rate and resources by type. ### Explorer Ad-hoc analysis from p50 to p99, filter and group your metrics without writing SQL. API & Docs ## Your data, one API call away. Everything in the dashboard is a REST endpoint. Query any metric, wire fastmon into your own tools, or tag a release from CI/CD. Auto-generated OpenAPI schema, Bearer-token auth, offset and cursor pagination. - Analytics query API for every metric, aggregation and breakdown - Bearer-token auth (fm_...), scoped to owner or member - OpenAPI schema at /v1/openapi.json - Dedicated endpoints for errors, visitors, Server-Timing, releases and more Read the API reference api.fastmon.eu Example POST /v1/organizations/ {org} /analytics/query Authorization: Bearer fm_... "metrics" : [ "lcp" , "inp" , "cls" ], "aggregations" : [ "p75" ] 200 OK "data" : [{ "lcp" : { "p75" : 1240 }, "inp" : { "p75" : 45 } }], "meta" : { "total" : 1 , "has_more" : false } Compare ## How fastmon compares. The honest case against the tools fastmon replaces or complements. Real differences, no fake claims, and we name where the others still win. Synthetic ### vs Lighthouse Keep the lab, add the field: real-user Core Web Vitals next to your Lighthouse runs. Read the comparison Analytics ### vs Google Analytics 4 Privacy-first analytics from the EU, cookieless* by default, with performance built in. Read the comparison RUM ### vs Datadog Focused web-performance RUM, EU-hosted and cookieless*, at a fraction of the enterprise bill. Read the comparison All comparisons ## Everything in one tool, hosted in the EU. Monitoring, synthetics and analytics, read-only by default: no cookies*, no long-lived identifiers. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/ Glossary # Web performance, without the guesswork. Every metric, method and building block behind fastmon, defined in plain language. Core Web Vitals with their real thresholds, the difference between lab and field data, and the concepts that make monitoring privacy-first. Metrics 14 terms ## Web performance metrics What actually gets measured, and the thresholds that decide good from poor. CWV ### Core Web Vitals Google's set of three field metrics for loading (LCP), interactivity (INP) and visual stability (CLS) of a page. Core Web Vitals are the subset of web performance signals Google treats as essential for user experience and feeds into ranking. Each one captures a different moment: how fast the main content appears, how quickly the page responds to input, and how much the layout jumps around. A page is considered to pass only when all three are in the good range at the 75th percentile of real visits. Lab tools can estimate them, but the official assessment always uses field data from real users. Read the full entry Learn more LCP ### Largest Contentful Paint Good <= 2.5 s The time until the largest visible element in the viewport (image, video or text block) has rendered. LCP is the loading Core Web Vital. It answers the question a visitor cares about most: when does the page look ready? The clock starts when navigation begins and stops when the biggest above-the-fold element paints. Because the largest element is usually a hero image or headline, LCP is dominated by how fast the server responds and how quickly that one resource can be delivered and decoded. Good <= 2.5 s Needs work 2.5 to 4 s Poor > 4 s Field data (75th percentile) What moves it - Slow server response (high TTFB) delays everything downstream. - Large or unoptimised hero images, or images without a priority hint. - Render-blocking CSS and JavaScript in the document head. - Client-side rendering that paints the main content late. Read the full entry Learn more INP ### Interaction to Next Paint Good <= 200 ms How long the page takes to visually respond after a user interacts, measured across the whole visit. INP is the responsiveness Core Web Vital. It observes every click, tap and key press during a visit, measures the delay until the next frame is painted, and reports close to the worst one. A low INP means the interface feels instant. INP replaced First Input Delay in March 2024. Unlike FID, which only looked at the first interaction's input delay, INP covers the full interaction including event processing and rendering, so it reflects real sluggishness far better. Good <= 200 ms Needs work 200 to 500 ms Poor > 500 ms Field data (75th percentile) What moves it - Long JavaScript tasks that block the main thread during interaction. - Heavy event handlers doing work before the next paint. - Large DOM updates or layout thrashing triggered by an interaction. - Third-party scripts competing for the main thread. Read the full entry Learn more CLS ### Cumulative Layout Shift Good <= 0.1 A unitless score for how much visible content unexpectedly moves around while the page loads and runs. CLS is the visual stability Core Web Vital. Every time an element shifts without a user action, the browser scores it by how much of the viewport moved and how far. CLS sums the worst burst of those shifts during the visit. It is the metric behind the familiar frustration of tapping a button that jumps the instant a late banner or image loads. Unlike the time-based vitals it has no unit: lower is better, and 0 means nothing moved. Good <= 0.1 Needs work 0.1 to 0.25 Poor > 0.25 Field data (75th percentile) What moves it - Images and embeds without width and height (or an aspect ratio). - Ads, banners and iframes injected above existing content. - Web fonts that reflow text when they swap in. - Content inserted dynamically without reserved space. Read the full entry Learn more FCP ### First Contentful Paint Good <= 1.8 s The moment the browser renders the first piece of content: text, an image or a canvas. FCP marks the transition from a blank screen to the first visible sign that the page is loading. It is not a Core Web Vital itself, but it is a strong early indicator and a common diagnostic for a slow LCP. A fast FCP reassures visitors that something is happening. If FCP is slow, the cause is almost always upstream: server time, DNS, redirects or render-blocking resources. Good <= 1.8 s Needs work 1.8 to 3 s Poor > 3 s Field data (75th percentile) What moves it - High TTFB and slow initial server response. - Render-blocking stylesheets and synchronous scripts. - Slow font delivery that hides text until it arrives. Read the full entry TTFB ### Time to First Byte Good <= 0.8 s The time from the start of navigation until the browser receives the first byte of the response. TTFB captures everything that happens before rendering can even begin: DNS lookup, connection setup, TLS handshake, redirects, and the server producing the response. It is the foundation every other loading metric sits on. A high TTFB caps how fast FCP and LCP can ever be, which is why it is the first thing to check when a page feels slow. Server logic, database queries and cold caches are the usual culprits. Good <= 0.8 s Needs work 0.8 to 1.8 s Poor > 1.8 s Field data (75th percentile) What moves it - Slow backend processing or uncached database queries. - No CDN, so visitors far from the origin pay the round-trip. - Redirect chains before the final document loads. Read the full entry FID ### First Input Delay (retired) Good <= 100 ms The delay between a visitor's first interaction and the browser starting to process it. Replaced by INP. FID was the original responsiveness Core Web Vital. It only measured the input delay of the very first interaction, and only that delay, not the work or rendering that followed, so a page could score a good FID yet still feel sluggish. Google retired FID on 12 March 2024 in favour of INP, which measures the full interaction across the whole visit. FID is included here for context: you may still see it in older reports and tools. Good <= 100 ms Needs work 100 to 300 ms Poor > 300 ms Field data (75th percentile) Read the full entry TBT ### Total Blocking Time Good <= 200 ms The total time the main thread was blocked by long tasks between first paint and interactivity, measured in the lab. TBT is a lab metric and the closest lab proxy for INP. It sums the blocking portion (everything over 50 ms) of every long task after FCP, showing how much a page would ignore input while scripts run. Because it is measured in a controlled lab run, TBT is stable and great for catching regressions in CI before they reach real users as a poor INP. Good <= 200 ms Needs work 200 to 600 ms Poor > 600 ms Lab data (Lighthouse) What moves it - Large JavaScript bundles parsed and executed at load. - Expensive hydration in client-rendered frameworks. - Third-party tags running heavy work on the main thread. Read the full entry SI ### Speed Index Good <= 3.4 s A lab metric for how quickly the visible parts of a page fill in during load, based on video capture. Speed Index records the loading filmstrip and scores how fast pixels above the fold become visually complete. Two pages with the same LCP can have very different Speed Index if one fills in gradually and the other pops in all at once. It is a Lighthouse lab metric, useful for comparing perceived loading speed between builds, but it is not measured on real users. Good <= 3.4 s Needs work 3.4 to 5.8 s Poor > 5.8 s Lab data (Lighthouse) Read the full entry TTI ### Time to Interactive (legacy) A lab metric for when a page has rendered and can reliably respond to input quickly. TTI estimated the point at which the main thread had been quiet long enough for the page to handle interactions dependably. It was once a headline Lighthouse score. Lighthouse dropped TTI from its scoring in version 10 (2023) because TBT and INP describe responsiveness more reliably. It appears here for context with older audits. Read the full entry ### Page Load The classic load event: everything on the initial page, including images and subresources, has finished loading. Page Load (the window load event) is the oldest performance milestone. It is easy to understand and still useful as a coarse signal, but it says nothing about when the page looked or felt usable, which is why the Core Web Vitals exist. fastmon records it alongside the vitals so you keep the familiar number while seeing the metrics that actually track experience. Read the full entry ### Route Load The loading time of an in-app navigation in a single-page app, where no full page reload happens. In a single-page application, clicking a link swaps content client-side instead of loading a fresh document, so the classic load event never fires again. Route Load measures those soft navigations: how long a view change takes from click to painted content. Without it, SPAs look artificially fast because only the very first load is measured. fastmon detects soft navigations and times each route change so the numbers reflect what visitors actually wait for. Read the full entry ### Long Tasks & LoAF Any piece of JavaScript that occupies the main thread for more than 50 ms, blocking the page from responding. While a long task runs, the browser cannot handle clicks, scrolls or paints, which is exactly what a visitor perceives as jank. Long Animation Frames (LoAF) is the newer API that goes further, attributing a slow frame to the script and even the source line responsible. Long tasks are the raw material behind a poor INP or TBT. Finding and breaking them up, or moving work off the main thread, is the most direct way to make an interface feel fast. Read the full entry ### Experience Score A single 0 to 10 number fastmon derives from LCP, INP, CLS, FCP, TTFB, load time and error rate. Individual metrics are precise but hard to track at a glance across many pages. The Experience Score rolls them into one figure so a team can see the health of a page, a segment or a whole site at once, then drill down when it drops. It never replaces the underlying vitals: it points you at where to look, and the metric cards tell you why. Read the full entry Read the docs Methods 10 terms ## Monitoring methods How performance is measured, from real visitors to scheduled lab runs. RUM ### Real User Monitoring Measuring performance from the browsers of your actual visitors, on their real devices and networks. RUM collects metrics from every real session: the phones, laptops, browsers and connections your audience actually uses. That is field data, and it is the only way to know what people truly experience, including the slow long tail that lab tests miss. It is the foundation of Core Web Vitals assessment. fastmon's RUM is cookieless by default and strips IP addresses at the edge, so you get the field truth without building visitor profiles. Read the full entry Learn more ### Synthetic Monitoring Scheduled, repeatable tests that load a page in a controlled environment on a fixed interval. Synthetic monitoring runs a page through a lab (for fastmon, scheduled Lighthouse and TTFB checks) on a schedule, from the same device profile and network every time. Because the conditions are fixed, results are stable and comparable, which makes them ideal for catching regressions and testing pages before they have any traffic. It complements RUM rather than replacing it: synthetic tells you a page changed, RUM tells you whether real users felt it. Read the full entry Learn more ### Lab data vs field data Lab data comes from a controlled test; field data comes from real visitors. Both matter, for different reasons. Lab data is reproducible: same device, same network, same steps, so it is perfect for debugging and CI. But one machine cannot represent every visitor, so it can look rosy while real users struggle. Field data is messy and honest: it captures the full range of devices and connections in the wild. Core Web Vitals are officially assessed on field data. The healthiest workflow uses lab data to prevent regressions and field data to confirm the real-world result. Read the full entry ### Lighthouse Google's open-source tool that audits a page in a lab run and scores performance, accessibility, SEO and more. Lighthouse loads a page under simulated conditions and produces a 0 to 100 performance score from lab metrics like FCP, LCP, TBT, CLS and Speed Index, plus concrete recommendations. It powers the lab side of PageSpeed Insights. fastmon's synthetic checks run Lighthouse on a schedule so you get its diagnostics continuously, not just when someone happens to run an audit. Read the full entry CrUX ### Chrome UX Report Google's public dataset of real-world Core Web Vitals, aggregated from opted-in Chrome users. CrUX is the field data source behind Google Search's Core Web Vitals assessment and the field section of PageSpeed Insights. It reports the 75th percentile per metric, aggregated monthly across eligible Chrome traffic. It is invaluable but coarse: monthly, origin- or page-group level, Chrome only, and only for pages with enough traffic. Your own RUM fills those gaps with per-page, real-time, all-browser data. Read the full entry p75 ### Percentile (p75) The value below which a given share of visits fall. p75 means 75 percent were at least this fast. Averages hide pain: a handful of very slow sessions can be masked by many fast ones. Percentiles describe the distribution instead. The 75th percentile is the threshold Core Web Vitals use, so that three out of four visits are represented and the worst quarter cannot be averaged away. Watching p75 (and p90 or p95 for the tail) shows what most people experience and how bad it gets for the unlucky, which an average never reveals. Read the full entry ### Web Vitals Attribution The extra diagnostic data that explains why a metric was slow, not just how slow it was. Knowing LCP was 4 seconds is only half the story. Attribution breaks a metric into its phases (for LCP: time to first byte, resource load delay, load time, render delay) and names the responsible element or the CSS selector behind a layout shift or slow interaction. That turns a number into an action: instead of guessing, you see the exact image, script or element to fix. Read the full entry ### Web Analytics Traffic and behaviour measurement: page views, visitors, referrers and journeys, alongside performance. Analytics answers who visited, from where, and what they did. Paired with performance data it becomes far more useful: you can see whether a slow page costs conversions or which traffic source lands on your worst experiences. fastmon's analytics is privacy-first: no cookies in the default mode, no cross-site tracking, and IPs reduced to a country code at the edge. The default mode stores nothing on the device, so in our assessment no consent banner is needed either. Read the full entry Learn more ### Error Tracking Capturing JavaScript errors and failed requests from real sessions, grouped so you see the real problems. A page can score perfect vitals and still be broken for a segment of users because a script throws. Error tracking records those failures from the browser, with enough context (page, browser, sequence) to reproduce them. Similar errors are collapsed into one fingerprint, so a thousand occurrences of the same bug show up as a single ranked issue instead of noise. Read the full entry ### Alerting Notification rules that tell you when a metric breaches a threshold or degrades, before customers complain. Dashboards only help when someone is looking. Alerting watches the numbers for you and fires when a Core Web Vital, error rate or Experience Score crosses a line you set, or trends the wrong way. Good alerting is specific enough to be trusted: scoped to the pages and metrics that matter, so a page that turns critical reaches the right people instead of getting lost. Read the full entry Building blocks 8 terms ## fastmon building blocks The pieces that make up fastmon: from the beacon to the way visitors are counted. ### Beacon The small data packet the tracker sends to fastmon with a visit's measurements. When a page finishes measuring, the tracker packs the metrics, timings and any errors into a compact payload and sends it, typically via the Beacon API, so delivery does not block or slow the page. You can inspect exactly what a beacon contains with the fastmon Beacon Inspector browser extension, which is part of how fastmon keeps what it collects transparent. Read the full entry ### Tracker The lightweight script you embed once; it measures Core Web Vitals and errors directly in the browser. The tracker is the snippet that does the measuring. It hooks into standard browser APIs (the Performance API, PerformanceObserver, error events) and is aligned with the same web-vitals library Google uses, so the numbers are comparable to Chrome's. It is small and loads without blocking rendering, so adding monitoring does not itself hurt the performance you are trying to measure. Read the full entry ### Stitch fastmon's short-lived, edge-derived identifier that groups a visit without cookies or cross-site tracking. To count unique visitors and connect the pages of one visit, some identifier is needed. Stitch is derived at the edge and rotates on a 24-hour basis, so it can group a session but cannot follow anyone across days, sites or devices. It is how fastmon avoids the double-counting and orphaned sessions of pure cookieless approaches while still setting no cookies and building no long-lived profiles. Read the full entry ### Session One continuous visit: the sequence of page views and interactions a visitor makes before going idle. A session ties together the pages, timings and errors of a single visit so you can follow a journey rather than isolated hits. It is the unit behind metrics like pages per session and where in a flow people drop off. In fastmon a session is bounded by the short-lived Stitch identifier, so it reflects one visit and does not become a permanent profile. Read the full entry ### Pageview A single page load or, in a single-page app, a route change counted as its own view. The pageview is the atomic unit of analytics. Each one carries its metrics, timings and context, and many together make up a session and the traffic totals. fastmon counts soft navigations in single-page apps as pageviews too, so SPA traffic is not undercounted the way it is with tools that only see full document loads. Read the full entry ### Collection modes Presets (Light, Standard, Full) that decide how much detail the tracker collects. Not every site needs the same depth. Light keeps data to the essentials, Standard is the balanced default, and Full unlocks the richest diagnostics like detailed attribution and resource timing. The mode is a deliberate lever over the privacy and data trade-off, chosen by you rather than assumed, and it maps directly to what a visitor's device is asked for. Read the full entry ### Server-Timing An HTTP header your backend can send to break down where server time was spent, visible in RUM. TTFB tells you the server was slow, but not why. With the Server-Timing header your backend can report its own phases (database, cache, rendering) and the browser exposes them to the tracker. That connects a slow field TTFB to the exact backend step responsible, closing the gap between frontend symptom and backend cause. Read the full entry ### Cache-Status Whether a response came from a CDN edge, the origin server or the browser cache. The same URL can be fast or slow depending on where it was served from. Recording cache status per request shows your real hit rate and surfaces resources that keep missing the cache and hitting the origin. It turns caching from a hopeful configuration into something you can actually verify against real traffic. Read the full entry Privacy & EU 5 terms ## Privacy and EU Why fastmon measures without cookies and keeps every byte inside Germany. ### Cookieless Measuring without storing anything on the visitor's device: no cookies, no localStorage. Classic analytics writes a cookie to recognise returning visitors, which triggers consent requirements and can be blocked or cleared. fastmon is cookieless by default: in read-only mode it stores nothing on the device at all. Cookieless is not the same as consent-free. Reading browser performance APIs can still fall under consent rules, but by storing nothing fastmon removes an entire class of privacy and accuracy problems that cookie-based tools carry. Read the full entry Learn more ### Edge IP processing The visitor's IP address is reduced to a country code at the edge and discarded before any app code sees it. An IP address is personal data. Instead of logging it and anonymising later, fastmon derives only a coarse country code at the edge server and drops the raw IP immediately, so it never reaches storage or application logic. This is data minimisation by design: you still get geographic breakdowns, but there is no raw IP to leak, subpoena or misuse because it was never kept. Read the full entry Learn more GDPR ### GDPR The EU General Data Protection Regulation, the legal baseline for handling personal data in Europe. The GDPR governs how personal data (including IP addresses and identifiers) may be collected, processed and stored, and grants people rights over their data. Analytics tools have to justify what they collect and on what legal basis. fastmon is built inside the GDPR rather than retrofitted to it: minimal data, no raw IP retention, no cross-site profiles and EU-only processing, which keeps the compliance surface small by design. Read the full entry Learn more ### TDDDG (Section 25) The German law implementing the ePrivacy rule that reading from or writing to a device needs consent. TDDDG Section 25 (formerly TTDSG) is the German transposition of the ePrivacy Directive. It says storing information on, or accessing information from, a user's device generally requires consent, independent of whether that information is personal data. This is why even a cookieless tool can still need consent: reading the browser's performance APIs is access to the device. The website operator obtains that consent through their consent platform, exactly as with other tools, as described in fastmon's privacy policy. Read the full entry ### Data residency Where your data physically lives and under whose jurisdiction it falls. For fastmon: Germany, end to end. Data residency matters because location decides which laws apply. Data held by US providers can be reachable under regimes like the CLOUD Act even when the servers sit in Europe. fastmon is hosted 100 percent in Germany on Hetzner, with no US provider in the data path, so your monitoring data stays under EU jurisdiction from collection to storage. Read the full entry Learn more ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/legal-notice/ Legal # Legal Notice Last updated: June 2026 Information pursuant to § 5 DDG (German Digital Services Act) and § 18 MStV (German State Media Treaty). fastmon labs UG (haftungsbeschränkt) Stresemannallee 4 30173 Hannover Germany ## Authorised Managing Directors Kamil Adrian Czujowski Lucas Röhrs (each with sole power of representation) ## Commercial Register Hannover Local Court (Amtsgericht Hannover) HRB 230880 ## VAT Identification Number VAT identification number pursuant to § 27a UStG: DE463717862 ## Contact Email: support@fastmon.eu Data protection: privacy@fastmon.eu Web: fastmon.eu ## Responsible for Content Kamil Adrian Czujowski, address as above. ## EU Dispute Resolution The European Commission provides a platform for online dispute resolution (ODR): ec.europa.eu/consumers/odr . You can find our email address above. We are neither willing nor obliged to participate in dispute resolution proceedings before a consumer arbitration board. ## Liability for Content As a service provider, we are responsible for our own content on these pages in accordance with § 7 (1) DDG and general law. Under §§ 8 to 10 DDG, however, we are not obliged as a service provider to monitor transmitted or stored third-party information or to investigate circumstances that indicate unlawful activity. Obligations to remove or block the use of information under general law remain unaffected. Liability in this respect is only possible from the point in time at which we become aware of a specific infringement. If we become aware of any such infringements, we will remove the content in question immediately. ## Liability for Links Our offering contains links to external third-party websites over whose content we have no influence. We therefore cannot accept any liability for this third-party content. The respective provider or operator of the linked pages is always responsible for their content. The linked pages were checked for possible legal violations at the time of linking. No unlawful content was apparent at the time of linking. ## Copyright The content and works created by the site operators on these pages are subject to German copyright law. Reproduction, adaptation, distribution and any kind of exploitation outside the limits of copyright require the written consent of the respective author or creator. --- ## https://fastmon.eu/en/partners/ Partner program For agencies # Make performance measurable. And make it a business. Every site you look after needs monitoring. Put fastmon on it and take a share of the revenue, every month, for as long as the client stays. No setup fee, no exclusivity, on a platform hosted in Germany. Become a partner See the levels - Recurring revenue share - For the life of the account - No minimum revenue Who it is for ## Built for teams who answer for websites If someone calls you when a site gets slow, this program pays you for the tool you would have needed anyway. ### Web and shop agencies Shopware, TYPO3, WordPress, Next.js: you build the sites, fastmon shows what they do for real visitors. One account per client project. ### Hosting providers and managed services Monitoring as part of the hosting package. You see Core Web Vitals per client and can prove where a slowdown comes from before the phone rings. ### Performance consultants Before and after with real user data instead of one Lighthouse screenshot. The result of your work becomes visible, which makes it sellable. ### SEO and content teams Core Web Vitals are a ranking signal. With field data at the 75th percentile you argue with numbers in the client meeting, not with assumptions. Two tracks ## Refer it or run it yourself Every account counts towards your level, whichever track it runs in. The commission rate belongs to the refer track: in the manage track the price sits in your individual agreement instead. Track A ### Refer You bring us the client, we close and bill them, you get paid every month for as long as they stay. - Register the client by mail, then the attribution is unambiguous even if they sign up weeks later - We record you on the account, nothing to maintain afterwards - Monthly payout against your invoice - The client stays the contract partner, including support Track B ### Manage You are the contract partner and run your client projects in one or more organizations. Your clients can get full access to them, and the costs are agreed individually. - One invoice for all client projects - You set your own end customer price - One overview of all your clients' organizations - Clients can get full access to their projects - Individual terms instead of a fixed commission rate You can switch tracks at any time, and mix them per client. Levels ## From p75 to p99. Core Web Vitals are rated at the 75th percentile. We rate partners the same way: p75 is where you start, p99 is the top. The more active Standard accounts you run, the higher your rate, and it applies to the whole portfolio rather than only to the next client. From 1 Standard account ### p75 Partner 20% Commission The entry level, from your first client. - Partner kit: arguments, screenshots and slides for your pitch - Your own websites monitored free of charge - Partner badge for your website - A support channel that answers you directly From 10 Standard accounts ### p90 Partner 25% Commission For agencies that look after a set of client projects. - Listed in the partner directory on fastmon.eu - Priority support, for your clients too - A joint case study - Technical onboarding session for your team From 25 Standard accounts ### p95 Partner 30% Commission The highest fixed rate in the program. - Leads from our own sales in your region or niche - Co-marketing: article, webinar, event - A named contact at fastmon - Roadmap input and early access to features From 50 Standard accounts ### p99 Partner Custom depending on portfolio and client size Beyond 50 accounts a percentage table stops being useful. We agree the terms with you. - Terms agreed with you, based on your portfolio and the size of your clients - Enterprise deals closed together - Your logo on fastmon.eu - Joint product development The rate is not only for new clients. Move from p90 to p95 and from the next month on you earn more on every account you already have. ### Fast track Ten Standard accounts within your first 90 days and p90 applies from the day the tenth one goes active, not from the following month. ### Level protection If a client leaves, your level stays for three more months. One cancelled account does not cost you the rate. ### Monthly review We look at the number of active Standard accounts once a month. A promotion takes effect the following month, a drop only once the level protection has run out. Which plan earns what ## The ladder runs on Standard We would rather be straight about this than surprise you on the first statement. At €29 a month there is barely a margin to share, so Light earns less and only once it reaches volume. ### Standard from €99 per month Counts from the first account, at the rate of your level, and every Standard account counts towards the next level. 20% to 30% ### Light €29 per month Earns from your tenth active Light account and then on all of them, at a flat rate. Light accounts do not count towards the levels. 10% So a Light client is never a problem, it simply is not what the ladder is built on. If you mostly place small sites, tell us in the intro call and we look at it together. Calculator ## What does that add up to? Drag the slider to the number of client projects you would put on fastmon, then switch the plan. Client accounts 10 Plan per client Light, €29 Standard, €99 Level p90 25% Rate Revenue you bring €990 per month Your commission €248 per month €2,976 per year With 25 client accounts you would be p95 Partner: 30% on the whole portfolio. An example calculation on list prices, excluding VAT. What is binding is the partner agreement. What you sell with ## Six things that make the pitch easy The percentage is one half of this. The other half is a product you can put in front of a client without a disclaimer. ### One tool instead of three Real User Monitoring, scheduled Lighthouse audits and web analytics in one interface. One login, one invoice, one dashboard the client actually reads. ### Field data, not a lab score Core Web Vitals at the 75th percentile from real visitors, with the Lighthouse run beside it. That is how you prove an optimization instead of claiming it. ### The privacy argument, with the reasoning attached No US provider in the data path, hosted in Germany, nothing written to the device in the default mode. In our assessment that needs no consent under § 25 TDDDG, and the full derivation, residual risk included, is public on our cookies page. ### Prices your client understands €29 for small sites, €99 for a million pageviews. No enterprise quote standing between you and the signature. ### Installed in five minutes One script tag and you are measuring. No SDK, no tag manager project, and in the default mode, in our assessment, no consent layer to negotiate. ### 30 days to try it, no card Every client account starts with full access for 30 days without a credit card. You can show the numbers before anyone signs anything. Directory ## Our partners Agencies, hosting providers and consultancies that put fastmon in front of their clients. Among them the company whose platform fastmon itself runs on. ### ScaleCommerce Berlin p99 Partner E-commerce PaaS and managed hosting for Shopware, OXID, Magento and Spryker. Runs the platform fastmon itself is hosted on. View partner profile ### Your profile in the directory From p90 on you get a page of your own, with your services, your platforms and a link to your site. We take on new agencies, hosting providers and consultancies on an ongoing basis. Become a partner How it works ## Four steps to your first commission 01 ### Application A short mail with your company, your website and how many client projects you look after. 02 ### Intro call Thirty minutes with us: what you do, which track fits, which clients to start with. 03 ### Access Partner kit, a free account for your own sites, and you are recorded as a partner. You can start the same week. 04 ### First client From the first active account the commission runs, monthly and without an expiry date. FAQ ## Questions about the program What agencies ask us before they sign up. Anything missing, write to partner@fastmon.eu. ### What counts as an active client account? A paying fastmon account that you referred or manage, after the trial has ended and with no open invoice. Standard accounts count from the first one and move you up the levels. Your own free partner account never counts. ### Why does Light earn less? At €29 a month there is very little left to share once the service is paid for. So Light pays a flat 10% and only from your tenth active Light account. Standard is fully in from the first one. We would rather say that here than in the first statement. ### How long does the commission run? For as long as the client pays. We do not cut it off after 12 months and we do not halve it in year two. ### When and how do you pay out? Monthly against your invoice, from €50 accumulated. Anything below that stays in the balance and carries over, so nothing is lost. In the manage track there is no payout, the price is agreed individually instead. ### What happens when a client cancels? The commission for that client ends with their last paid month. Your level stays protected for three months. ### Can we mix both tracks? Yes, even per client. Some agencies refer their enterprise clients and manage the small ones themselves. ### Are there fees or minimum revenues? No joining fee, no minimum revenue, no notice period. If it does not work for you, you stop. ### Do we see our clients' data? In the manage track you run the projects yourself in one or more organizations, and your clients can get full access to them. In the refer track the account belongs to the client and you get access when they invite you. ### What does fastmon cost our clients? €29 for 200,000 pageviews a month, €99 for a million, with usage-based steps above that. Everything is on the plans page. ## Start with one client One active Standard account is enough for the commission to run. The rest is a short mail and one call. Become a partner See all plans --- ## https://fastmon.eu/en/plans/ Plans Early adopter # Simple, honest pricing. No hidden pricing. Two usage-based plans, priced per pageview. Light if you just want monitoring, Standard if you want everything. One prod and one dev application included, EU-hosted, and, at entry, lower list prices than RUMvision, DebugBear and SpeedCurve. Starter ## Light €29 /month 200,000 pageviews included, then €10 per extra 200k For small shops that just want monitoring, not debugging. Start for free - Core Web Vitals and real-user monitoring - Web analytics: traffic, sources, campaigns - Alerts by email, Slack, Discord or webhook - One prod and one dev application included, domain count irrelevant - Hosted in Germany, cookieless* by default - Monitoring focus: no deep error and network debugging - Optional sampling to lower the bill Recommended ## Standard €99 /month 1 million pageviews included, then €50 per extra 1M Everything fastmon does, for teams that debug and optimize. Start for free - Everything in Light, plus: - Full debugging: JS error grouping, network waterfalls, Server-Timing - Synthetic Monitoring (Lighthouse and TTFB) - fastmon AI: summaries and ask about a test - At least 60-day full retention, 13-month statistics - One prod and one dev application included, domain count irrelevant - Optional sampling to lower the bill Custom ## Enterprise Custom For high-traffic teams with custom pageview volume, long retention and a contract to match. The same EU-hosted platform, tuned to your scale. Learn more - Custom pageview volume and retention windows - Priority support with a named contact - Guided onboarding and dashboard setup - Debugging and optimization with fastmon experts - Signed DPA and security review Prices per month, excluding VAT. Early-adopter pricing while fastmon is in beta. Price calculator ## What will it cost you? Drag to your monthly pageviews and see both plans. Sampling can bring it down further. Monthly pageviews 1,000,000 Light €69 /month Monitoring only Standard €99 /month Everything, with debugging Not sure you need every pageview measured? Optional sampling lowers your billable volume. Ask us for a sampled quote. Enterprise ### Traffic at this scale? Let us tailor it. Above 10 million pageviews a month we build the plan around you: custom volume, the retention you need, and a price to match. Tell us your traffic and what you want to watch, and we will put a number in front of you. Learn more Versus the field ## The same job, a fraction of the price. Entry pricing of the RUM tools teams compare us with. fastmon is the lowest-priced option in this comparison. | | fastmon | RUMvision | DebugBear | SpeedCurve | Entry price | from €29/mo | from €150/mo | from $99/mo | from $90/mo | Pageviews at entry | 200k | 1.5M | 100k | configurable | Hosted in the EU | Yes | Yes | No | No | Long-term retention | 13-month statistics (raw data 90 days default) | from ~€700/mo | 24 months | from ~$576/mo Entry-tier list prices as of 27 August 2026; individual terms may differ, check each provider for current terms. DebugBear's cheapest plan with RUM is Startup at $99 on annual billing (100k pageviews), Team with 500k costs $249; SpeedCurve's entry bundles RUM and synthetic. RUMvision is the other EU-based option. Fair by default ## Pricing that stays on your side. The promises behind the price. No hidden tiers, no billing surprises, no lock-in. ### Early-adopter price, locked in The price you join at is the price you keep while fastmon is in beta. Early adopters do not get quietly repriced. ### No surprise invoices Usage-based and transparent. You only pay for the pageviews you actually send, and we flag it before you cross a tier, not after. ### We never cut off your monitoring Go over your included volume and your data keeps flowing. We reach out to sort it out, we do not silently drop pageviews or lock your dashboard. ### Sampling keeps you in control Turn on optional sampling any time to cap your billable volume, and stay on your plan instead of being pushed into a bigger one. Support ## Product support included. Expertise on tap. Every plan includes support for the product itself. If you need a human to dig into your data, that is a separate, hands-on service. - Product support on every plan, by email - Debugging support and performance optimization as consulting, with fastmon experts - Onboarding help for Enterprise FAQ ## Plans, answered. The questions people ask before they pick a plan. ### What counts as a pageview? Every page load your fastmon script reports. Single-page-app route changes count as soft navigations. You only pay for the pageviews you actually send. ### What if I do not know how many pageviews I have or what it will cost? No problem, you do not need to know upfront. Try fastmon for free: during that time you will see exactly how many pageviews add up and what your plan would cost, before you commit. ### How does sampling lower the price? Sampling measures a representative share of your traffic instead of every single pageview, which lowers your billable volume and your bill. It is optional; talk to us for a sampled quote. (Basic analytics counting stays exact and is not sampled.) ### How many domains are included? We do not count by domain, we count per application: one prod and one dev application are included, each with its subdomains like a blog. The number of domains is not relevant to us. Need several separate products? That is an Enterprise conversation. ### What is the difference between Light and Standard? Light is monitoring only: Core Web Vitals, analytics and alerts, for small shops that do not need to debug. Standard adds full debugging (error grouping, network waterfalls, Server-Timing), Synthetic Monitoring, fastmon AI, 60-day retention and 13-month statistics. ### Can I get help with debugging or optimization? Yes, as consulting with fastmon experts, separate from the product subscription. Product support is included on every plan. ### Why is fastmon cheaper than RUMvision, DebugBear or SpeedCurve? Early-adopter pricing and a focused product. RUMvision starts around €150, DebugBear's RUM tier around $249, SpeedCurve around $90. fastmon Light starts at €29, Standard at €99, both EU-hosted. ## The full platform, from €29 a month. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Hosted in Germany. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/privacy/ Legal # Privacy Policy Last updated: 17 July 2026 This privacy policy informs you in accordance with Articles 13 and 14 GDPR about the processing of personal data by fastmon labs UG (haftungsbeschränkt) in connection with visiting our websites and using our Software-as-a-Service offering "fastmon" (Real User Monitoring). ## 1. Controller fastmon labs UG (haftungsbeschränkt) Stresemannallee 4, 30173 Hannover, Germany Hannover Local Court, HRB 230880 Managing Directors: Kamil Adrian Czujowski, Lucas Röhrs Privacy contact: privacy@fastmon.eu ## 2. Data Protection Officer A Data Protection Officer is not required under Article 37 GDPR. The central contact for privacy enquiries is privacy@fastmon.eu. ## 3. Supervisory Authority The competent supervisory authority is the State Commissioner for Data Protection Lower Saxony (LfD Niedersachsen), Prinzenstraße 5, 30159 Hannover, Germany. ## 4. Processing when visiting our websites Each time you access one of our websites, our reverse proxy collects technical data (timestamp, requested resource, HTTP status, referrer category, derived country code). Source IP addresses are not stored in logs but stripped at the edge. Logs are retained for a maximum of 7 days and serve technical purposes only (security, error analysis). Legal basis: Article 6 (1) f GDPR (legitimate interest in technical operation). Our websites do not use tracking cookies or web-analytics tools that process personal data. ## 5. Real User Monitoring (fastmon service) When you visit a website that has the fastmon beacon script embedded, technical performance metrics are collected. The controller for this processing is the respective website operator with whom we have entered into a data processing agreement pursuant to Article 28 GDPR. ### 5.1 What is collected In the Standard collection mode (the default), only aggregated, data-minimised telemetry is collected: - Core Web Vitals (LCP, INP, CLS, TTFB, FCP) and other technical performance metrics - Browser family and major version, OS category, device class, viewport class - Country code (ISO 3166), derived from the IP address - Path of the visited page (query string and anchor are discarded) - Referrer category (e.g. "Google / search"), not the full referrer URL - UTM parameters (truncated to 64 characters), click-ID parameter name (not the value) ### 5.2 What is not collected - No cookies; in Light and Standard mode nothing is stored on the device - No persistent identifiers, no user IDs, no cross-site identifiers - No raw IP address (discarded at edge within less than 1 second) - No raw User-Agent string - No personal names, email addresses, form inputs, page content, click heatmaps, mouse movements, keystrokes, session replays ### 5.3 Edge Stripping and Stitch Identifier The IP address and raw User-Agent are processed exclusively at the edge server transiently (less than 1 second in memory) to derive country code and browser category. They are then irreversibly discarded. Storage in the application, database or logs does not occur at any time. For cookieless counting of unique visitors within a browser session, a server-side computed hash value (Stitch) is used. This is an HMAC-SHA256 based on a secret salt that rotates every 24 hours and exists only in the memory of the edge server. Linking of page views is limited to a maximum of 24 hours, after which the recognition chain ends. Cross-site or cross-device recognition is technically impossible. ### 5.4 Retention Default retention period for telemetry data is 90 days. On Enterprise plans, configurable per site up to 13 months. ### 5.5 ePrivacy / Consent In the Light and Standard collection modes, nothing is stored on the end user's device: no cookie, no localStorage, no sessionStorage. The corresponding code path is not contained in the shipped beacon. What is read are exclusively status values the browser itself produces in the course of the page view (performance interfaces, viewport class, connection class, error events). These values are not stored in the terminal equipment before the page view. In our view there is therefore neither storage of, nor access to, information already stored within the meaning of Section 25 (1) of the German Telecommunications-Digital Services Data Protection Act (TDDDG). A stricter interpretation, which also includes locally generated results of browser interfaces, is advanced; no court has settled the question. In the Full collection mode, a tab-bound session identifier is stored in the browser's sessionStorage. This write is covered by Section 25 (1) TDDDG and requires the end user's consent. It can be deferred until the website operator's consent management platform calls grantConsent(). Assessing the consent requirement for a specific integration is the responsibility of the operator of the respective website. The full derivation, with the statutory text and sources, is at Cookies, TDDDG and consent . ## 6. Dashboard usage (account data) When you register as a customer with fastmon, we process the following data as controller: - Name, email address, password hash, organisation affiliation, login timestamps - Invoicing data: company name, address, VAT ID, contact person, invoice amount, payment data Legal basis: Article 6 (1) b GDPR (performance of a contract), for invoicing data additionally Article 6 (1) c GDPR and Sections 257 HGB and 147 AO (10-year retention obligation). ## 7. Optional AI Chat function In the dashboard, an optional AI chat function can be activated that enables LLM-based analysis. When activated, user prompts and account or telemetry context data are transmitted to Mistral AI SAS (Paris, France). Processing takes place exclusively at EU endpoints. Inputs and outputs are not used for model training. The function is disabled by default. ## 8. Processors and Recipients We use the following processors and recipients. All are located in the EU or EEA. | Provider | Location | Purpose | Hetzner Online GmbH | DE | Hosting, storage, backup | sevdesk GmbH | DE | Accounting, invoicing | Mollie B.V. (independent controller) | NL | Payment processing (PSD2) | Lettermint B.V. | NL | Transactional emails | Soverin B.V. | NL | Business mail hosting | Mistral AI SAS | FR | LLM inference (opt-in only) | BunnyWay d.o.o. (bunny.net) | SI | Authoritative DNS service | smoxy GmbH | DE | Ingress | ScaleCommerce GmbH | DE | Hosting | All Quiet GmbH | DE | On-call tool (internal) For internal purposes unrelated to customer or visitor data (source code management, project management, development tools) we use additional providers, including US-based providers (GitHub, Linear, Anthropic). They do not receive personal data of website visitors, customers or their end users. A full overview of all providers is available at fastmon.eu/en/subprocessors . ## 9. Third-country transfers Within the processing operations described in this policy, no personal data is transferred to countries outside the EU or EEA. Third-country transfers occur only in compliance with Articles 44 et seq. GDPR; when a third-country provider is engaged, data subjects are informed in advance. ## 10. Your rights as data subject - Access to your processed data (Art. 15 GDPR) - Rectification of inaccurate data (Art. 16 GDPR) - Erasure of your data (Art. 17 GDPR) - Restriction of processing (Art. 18 GDPR) - Data portability (Art. 20 GDPR) - Objection to processing (Art. 21 GDPR) - Lodging a complaint with the supervisory authority (Art. 77 GDPR) Note on Art. 11 GDPR: Due to our data-minimised architecture (edge stripping of IP and User-Agent, no persistent identifiers, 24-hour limit on the Stitch), direct attribution of telemetry data to a natural person is regularly not possible. An access or erasure request relating to telemetry data therefore requires that you provide additional information enabling identification. Please direct enquiries to privacy@fastmon.eu . ## 11. Further documents - Data Processing Agreement (DPA) - List of sub-processors and Technical and Organisational Measures (TOM) available on request from privacy@fastmon.eu --- ## https://fastmon.eu/en/subprocessors/ Sub-processors # Every provider, out in the open. A sub-processor is a service provider that processes customer or monitoring data on behalf of fastmon (Art. 28 GDPR). This page lists both: every sub-processor in the customer data path and, because transparency should not stop at the data path, the internal business tools that never see customer or monitoring data. Last updated: 2 September 2026 ## The customer data path Every system that processes customer or monitoring data. A small number of carefully chosen sub-processors: every one a company in Germany or the EU, each bound by a data processing agreement. No provider in the customer data path is a US company; access under the US CLOUD Act is therefore not something to expect. ### Hosting and infrastructure | Provider | Purpose | Location | Hetzner Online GmbH | Hosting, storage, backup | Germany Germany, Falkenstein | Sc ScaleCommerce GmbH | Hosting | Germany Germany, Berlin | sm smoxy GmbH | Ingress | Germany Germany, Berlin | BunnyWay d.o.o. | Authoritative DNS service | Slovenia, Tržič ### Billing, accounting and payments | Provider | Purpose | Location | sd sevdesk GmbH | Accounting and invoicing | Germany Germany, Offenburg | Mo Mollie B.V. | Payment processing for online payments in Europe; regulated payment service provider (PSD2) acting as an independent controller, therefore not a sub-processor | Netherlands, Amsterdam ### Email | Provider | Purpose | Location | Lm Lettermint B.V. | Transactional emails | Netherlands, Zwolle | So Soverin B.V. | Business mail | Netherlands, Rotterdam ### Engineering operations | Provider | Purpose | Location | AQ All Quiet GmbH | On-call tool for fastmon Engineering | Germany Germany, Berlin ### AI (only if you opt in) | Provider | Purpose | Location | Mistral AI SAS | LLM inference, only when the AI chat function is opted in | France, Paris Five of the nine sub-processors are in Germany, the rest in the EU (Netherlands, Slovenia, France). Card payments run through Mollie B.V. (Amsterdam), which acts as a regulated payment service provider on its own account and is therefore not a sub-processor. ## Internal business tools We also use the following providers to run our internal business. No customer and no monitoring data is ever sent to them, they process none, and that is why they are not sub-processors under Art. 28 GDPR. We list them anyway, because transparency should not stop at the data path. | Provider | Purpose | Customer data | Location | GitHub, Inc. Version control | Source code hosting, version control and CI/CD pipelines | None sent | USA | Anthropic, PBC Development | AI-assisted development: coding and code reviews with Claude Code | None sent | USA | Infomaniak Network SA Communication | Internal team communication and collaboration (kSuite) | None sent | Switzerland, Geneva Our internal policy is simple: no customer or monitoring data in repositories, tickets, chats or development tools. The entire customer data path stays in Germany and the EU. ## International data transfers For the customer data path there are no third-country transfers: all customer and monitoring data is processed exclusively in Germany and the EU, and every sub-processor is based in the EU. For your data we therefore rely on neither standard contractual clauses nor adequacy decisions; access under the US CLOUD Act is not something to expect. Among the internal business tools, two providers are based in the USA and one in Switzerland. They process no customer or monitoring data; only internal data arises there, such as accounts of our own staff. For this internal data, the EU standard contractual clauses from the providers' data processing agreements apply (Art. 46 GDPR), GitHub is additionally certified under the EU-US Data Privacy Framework, and Switzerland is covered by an adequacy decision of the EU Commission (Art. 45 GDPR). ## Changes to this list Before we engage a new sub-processor or replace an existing one, we announce it at least 30 days in advance in text form and update this page. ## Objecting to sub-processors As a customer, you can object to an announced new sub-processor within 30 days for important data protection reasons (§ 7 DPA). If the objection is justified, we will not use the new provider for your data until a mutually agreeable solution is found; if none is reached within 30 days, you have an extraordinary right to terminate the main agreement. The binding version of the sub-processor list is part of the Data Processing Agreement . Questions about the data path? Write to privacy@fastmon.eu. --- ## https://fastmon.eu/en/terms/ Legal # Terms and Conditions Last updated: 29 June 2026 of fastmon labs UG (haftungsbeschränkt), Stresemannallee 4, 30173 Hannover, registered with the commercial register of the Hannover Local Court under HRB 230880, represented by the managing directors Kamil Adrian Czujowski and Lucas Röhrs ("Provider"), for the use of the Software-as-a-Service offering "fastmon". ## § 1 Scope, conclusion of contract (1) These terms apply to all contracts between the Provider and its customers regarding the use of the fastmon service. "Customer" in the sense of these terms is exclusively an entrepreneur within the meaning of Section 14 BGB, legal persons under public law or public-law special assets. Use by consumers within the meaning of Section 13 BGB is excluded. (2) Deviating or supplementary terms of the Customer do not become part of the contract unless the Provider expressly agrees to their validity in text form. (3) The contract is concluded by registration of the Customer in the fastmon dashboard and acceptance of these terms and the Data Processing Agreement (DPA). The Customer is expressly notified of these terms and the DPA at the time of registration, can review both in full prior to acceptance and accepts them by actively confirming their applicability (checkbox). The requirements for effective incorporation pursuant to Section 305 (2) BGB are thereby fulfilled. Upon conclusion of the contract, the Privacy Policy and DPA (including the TOM referenced therein) in the version valid at the time of registration become integral and inseparable parts of the contract. ## § 2 Description of services (1) The Provider makes the SaaS service fastmon available to the Customer for measuring the performance and availability of websites and web applications operated by the Customer (Real User Monitoring). (2) The scope of services results from the tariff chosen by the Customer and the product documentation at docs.fastmon.eu. The Provider reserves the right to adjust the scope of services for the improvement of the service, provided this is reasonable for the Customer and does not affect essential contractual obligations. (3) The Provider is entitled to use sub-processors and other service providers. The current list is available on request from privacy@fastmon.eu and is included in the applicable DPA . ## § 3 Customer obligations (1) The Customer undertakes to treat the access data for its account confidentially and to protect it against access by third parties. (2) The Customer warrants not to transmit personal or personally identifiable data of any kind to fields capable of being recorded by the Provider, in particular not in URL paths, query strings, UTM parameters, tag values and error contexts (cf. § 2 (4) DPA). (3) The Customer ensures that it has the necessary legal basis for the processing of the data and has informed its end users accordingly. (4) The Customer is responsible for the correct integration of the fastmon beacon and for the choice of collection mode (Light, Standard, Full) and the assessment of the consent requirement that follows from it. ## § 4 Remuneration, payment terms (1) The remuneration is based on the price list valid at the time of conclusion of the contract or the individually agreed tariff. (2) Unless otherwise agreed, billing is monthly or annually in advance. Invoices are due within 14 days of receipt without deduction. (3) Payment processing is handled via Mollie B.V. (Netherlands). The Provider reserves the right to add further payment service providers. (4) All prices are exclusive of statutory VAT. ## § 5 Availability, service levels (1) The Provider aims at an annual availability of the service of 99.5 percent. Planned maintenance windows and force majeure are excluded. (2) Status information is communicated via status.fastmon.eu. (3) On Enterprise plans, extended service levels can be agreed individually. ## § 6 Term and termination (1) The contract is concluded for an indefinite period and may be terminated by either party at the end of the respective billing period (monthly or annually) by ordinary notice. (2) The right to extraordinary termination for good cause remains unaffected. Good cause exists in particular in case of sustained breach of obligations under § 3 or default in payment. (3) Terminations require text form (email to support@fastmon.eu is sufficient). (4) After the end of the contract, customer data will be deleted in accordance with § 10 DPA. ## § 7 Data protection and processing on behalf (1) The Provider processes personal data exclusively in accordance with the applicable data protection provisions, in particular the GDPR and BDSG. (2) The Data Processing Agreement (DPA) pursuant to Art. 28 GDPR in the version valid at fastmon.eu/en/dpa is an integral and inseparable part of this main contract and is concluded simultaneously with the Customer's acceptance of these terms. The Customer confirms by registering that it has taken note of the DPA in the valid version, could reasonably take note of its content and agrees to its validity (Section 305 (2) BGB). In case of conflicts between these terms and the DPA, the DPA prevails with respect to data protection matters. (3) For Enterprise constellations with bilateral signature, an extended DPA version is available (request to privacy@fastmon.eu). ## § 8 Warranty and liability (1) The Provider is liable without limitation for intent and gross negligence and for damages from injury to life, body or health. (2) For slight negligence, the Provider is liable only for breach of essential contractual obligations (cardinal obligations). In such cases, liability is limited to the damage typically foreseeable in such contracts, but no more than the net fee paid by the Customer in the 12 months prior to the damage-causing event. (3) Liability under the Product Liability Act and under Art. 82 GDPR remains unaffected. The liability cap does not apply to fines under Art. 83 GDPR, insofar as their cause falls within the Provider's area of responsibility. (4) The Provider is not liable for personal data embedded by the Customer in recordable fields in breach of § 3 (2). ## § 9 Confidentiality The parties undertake to treat as confidential all confidential information of the other party obtained in connection with the contract and not to pass it on to third parties. The obligation survives the termination of the contract. ## § 10 Amendments to the terms (1) The Provider is entitled to amend these terms with 30 days' notice insofar as this is necessary for legal, regulatory or product-related reasons and no essential contractual obligations are changed to the detriment of the Customer. (2) If the Customer does not object to the amendment within the notice period, the amended terms are deemed accepted. In case of objection, both parties have the right to extraordinary termination with effect to the date of the amendment. ## § 11 Final provisions (1) German law applies, excluding the UN Sales Convention. (2) Place of jurisdiction is Hannover, insofar as the Customer is a merchant, legal person under public law or public-law special asset. (3) In case of conflicts between these terms and the DPA, the provisions of the DPA shall prevail with respect to data protection matters. (4) Should individual provisions of these terms be invalid, the validity of the remaining provisions remains unaffected. --- ## https://fastmon.eu/en/web-vitals-monitoring/ Web vitals monitoring # Measure Core Web Vitals: live, from your first visitor. You don't measure website speed in a lab, you measure it on real visitors. fastmon is web vitals monitoring from Germany: LCP, INP, CLS and TTFB from every real visit, deployable GDPR-compliant and cookieless* in the default mode. Live in about five minutes. Live on this page ## This is what fastmon looks like: your visit, measured live. No screenshot, no demo data: this page measures itself with the fastmon tracker. Below are the values of your visit to this page, measured live on your device, your network, your browser. This is exactly how you would see every visitor of your own website. Live: this page is measuring itself your visit TTFB FCP LCP CLS Same browser APIs the fastmon script uses. No cookies* involved. Nav type ··· Real values only: if a number is missing, your browser cannot measure that metric (Safari, for example, reports no LCP). fastmon measures exactly as honestly on your website. The metrics ## LCP, INP, CLS and TTFB, explained briefly. The three Core Web Vitals Google ranks you by, plus TTFB as the server diagnostic. fastmon scores them at the p75 against Google's thresholds: green means 75% of your visitors were at least this fast. LCP ### How fast does the main content appear? Largest Contentful Paint is the moment the biggest visible element (a hero image, video poster or headline) has rendered. fastmon breaks it into its four subparts, from TTFB to element render delay, so you see where the wait is. Good ≤ 2.5 s Needs work ≤ 4.0 s Poor > 4.0 s INP ### Does the page respond instantly to taps and clicks? Interaction to Next Paint is the worst-case delay between an interaction and the next frame. It replaced FID as a Core Web Vital in March 2024. Long Animation Frames (over 50 ms) point at the script that blocked the response. Good ≤ 200 ms Needs work ≤ 500 ms Poor > 500 ms CLS ### Does the layout jump around while loading? Cumulative Layout Shift scores how much visible content moves unexpectedly. fastmon reports the worst shift window per visit, so a late-loading banner that pushes your content down does not hide in the average. Good ≤ 0.1 Needs work ≤ 0.25 Poor > 0.25 TTFB ### How fast does your server respond? Time to First Byte is the time from the click to the first byte of the server response: DNS, connection, TLS and the work of your backend. Not a Core Web Vital, but a high TTFB slows everything after it, including your LCP. The first knob to turn when everything is slow. Good ≤ 0.8 s Needs work ≤ 1.8 s Poor > 1.8 s Model calculation ## What does a slow website cost you? The Deloitte/Google study 'Milliseconds Make Millions' (2020) measured across 37 brands and over 30 million sessions how a 0.1 s faster mobile load time correlates with conversion and revenue. Run the model with your own numbers. Your numbers Visitors per month Conversion rate in % Average order value in € What 0.1 s costs you €1,344 /month Model calculation, not a forecast With your numbers, a page that is 0.1 s faster would correspond to about €1,344 more revenue per month in this model. Revenue today (model) €16,000 Revenue with a 0.1 s faster page (model) €17,344 Difference per month €1,344 Difference per year €16,128 Model calculation based on the Deloitte/Google study 'Milliseconds Make Millions' (2020). No promise of results: your actual effect depends on your website, your industry and your implementation. fastmon measures where you lose time; the optimization is up to you. Transparency ### How we calculate Revenue = visitors x conversion rate x order value. Model factor: +8.4% conversion per 0.1 s faster mobile load time, the retail figure from the Deloitte/Google study 'Milliseconds Make Millions' (2020). So the difference above is revenue x 0.084. The same study also measured +9.2% average order value in retail and +10.1% conversion in travel; our model deliberately uses only the retail conversion factor. For context: per Google/SOASTA data (2017), the probability of a bounce increases 32% as load time grows from 1 s to 3 s. Sources: Deloitte/Google 'Milliseconds Make Millions' (2020), Google/SOASTA Research (2017). FAQ ## Web vitals monitoring, answered. The questions people ask before they measure their website speed. ### What are Core Web Vitals? Core Web Vitals are the three user-experience metrics Google measures for every website and factors into ranking: LCP (how fast the main content appears), INP (how fast the page reacts to input) and CLS (how much the layout jumps). Google scores them at the 75th percentile; good means LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1. fastmon measures all three from real visits, plus diagnostics like TTFB, FCP and page load time. ### How do I measure my website speed? There are two complementary ways. A lab test (Lighthouse, PageSpeed Insights) loads your page on a simulated device: reproducible, but it does not show what your visitors experience. Web vitals monitoring (Real User Monitoring) measures every real load time in your visitors' browsers, on their devices and networks, aggregated at the p75. fastmon makes this field data visible from your first visitor, without 28-day averages, and adds scheduled Lighthouse audits if you want them. ### Do I need a cookie banner for web vitals monitoring? No, not in Minimal and Standard mode. Nothing is stored on the device, and the values that get read were not there beforehand: they come into being at the moment of the page view. Naming fastmon in your privacy policy is enough. In Full mode you do need consent, because an identifier is written into sessionStorage. This classification has been reviewed with our external data protection officer; a residual risk remains, because no court has ruled on this constellation. The full derivation, with the statutory text and the opposing reading ### Does a faster website really make more revenue? There are solid field studies on this. The Deloitte/Google study 'Milliseconds Make Millions' (2020) measured across 37 brands and over 30 million sessions that a 0.1 s faster mobile load time went along with +8.4% conversion and +9.2% average order value in retail, and +10.1% conversion in travel. Per Google/SOASTA data (2017), the probability of a bounce increases 32% as load time grows from 1 s to 3 s. These are correlations from field studies, not a guarantee for your site: your effect depends on your website, your industry and your implementation. That is why our calculator works transparently with a disclosed model factor and promises you nothing. ### What does web vitals monitoring with fastmon cost? fastmon Light starts at €29 a month with 200,000 pageviews: Core Web Vitals, Real User Monitoring, web analytics and alerts. Standard from €99 adds full debugging, synthetic monitoring and fastmon AI. Both hosted in Germany, live in about five minutes, no credit card to start. ## Web vitals monitoring, from €29 a month. Live from your first visitor, read-only by default: no cookies*, no long-lived identifiers. Hosted in Germany. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/blog/browser-cdn-origin-cache/ Back to blog Performance # Browser cache, CDN cache, origin cache: what do they mean? When someone says: just turn on the cache. Which one? There are three, they sit behind one another, and between the first and the last one lies half a second of waiting for your visitors. Kamil Adrian Czujowski July 30, 2026 · 6 min read Honestly: nobody thinks about caches for fun. Not until the site is slow, someone in the meeting says “just turn on the cache” and the next question is already in the room: which one? Because there are three. They sit behind one another, and every further one costs time. A cache is always the same thing: a finished copy, so the same work does not have to be done twice. The only interesting part is where that copy sits and how far it is from your visitor. A visitor opens your page 1. Browser cache copy is already on the visitor's own device 0 ms not there, so keep going 2. CDN cache copy sits in a data centre near them ~20 ms not there, so keep going 3. Origin cache finished page sits on your own server ~150 ms not there, so keep going No cache left the page is built from scratch: database, prices, templates ~600 ms The first layer that holds the copy is the one that answers. Everything below it costs extra time. The numbers are typical orders of magnitude, not guarantees. ## The three layers, in plain language ### The browser cache: the copy at the visitor The fastest cache is the one where no request leaves at all. The browser still has the file on the device and takes it from there. No network, no waiting. The catch is obvious: on a first visit this cache is empty. For every new visitor, which means everyone your campaign is bringing in right now, it does not exist. The browser cache rewards regulars. It never sees new customers. ### The CDN cache: the copy nearby A CDN is a network of servers in many countries that serves your site from whichever location is closest to the visitor. What you save is not only work, it is distance: a visitor in Sydney gets their answer from Sydney instead of Frankfurt. The big lever is caching the page itself, not just images and scripts. Everybody does it for images, almost nobody does it for the page. And that is exactly where the waiting sits that your visitor spends in front of a blank screen. ### The origin cache: the finished page on your server If the request does reach you, the third layer decides how expensive it gets. The origin cache keeps the fully built page ready instead of assembling it every single time. This is where the gap is widest. With a copy: send it out. Without one: query the database, calculate prices, render templates, check availability. Hence the jump from 150 to 600 milliseconds in the diagram. To a visitor, by the way, these three layers are indistinguishable. All they notice is whether the page is there instantly or not. ## HIT and MISS: the two words that matter Caches always describe their outcome with the same words. Two of them are enough to start: - HIT : the copy was there and went straight out. The good case. - MISS : the copy was not there, so the request had to go one layer deeper. As soon as you look at a dashboard or a server log, a few in-between states show up. You do not have to memorise them, you just need to place them: EXPIRED means the copy was too old and got refreshed. STALE means an old copy went out on purpose to save time. REVALIDATED means the copy was checked and was still valid. BYPASS , PASS , DYNAMIC and NONE all mean the same thing in variations: for this request, the cache was not involved. One point matters here because it usually gets lost: these words apply per layer. A HIT at the CDN and a MISS in the origin cache are two separate statements. Only together do they tell you who actually answered. ## Why this is not just a technical detail The time to the first byte, called TTFB in reports, is the floor everything else stands on. While it runs, your visitor sees nothing. No image, no headline, no button. The browser cannot show what it has not received yet. Two consequences that reach beyond engineering: Google grades what real visitors experience. Rankings use Core Web Vitals from real Chrome visits, not the test run on your agency’s laptop. Which cache layer answered is therefore a ranking factor, even though it never appears on an invoice. Waiting costs you exactly where you can least afford it. You send paid traffic to landing pages. Those visitors arrive for the first time, so they have no browser cache, and they often land on URLs carrying campaign parameters. If a copy is missing anywhere, that exact visit pays the waiting time. And here is the trap modern hosting platforms set. Responses from the edge cache look fantastic, while a miss next to them can be ten times slower. In an average that difference disappears completely. Which is why the hit rate is the number that counts, not the mean. So a cache is not a switch you flip once. It is a rate, and rates move. ## What breaks a cache in daily life Three things explain most poor hit rates, and none of them usually comes from the engineering corner: - Campaign parameters. If every link carries a ?utm_source=... , many caches treat that as a different address and therefore a separate copy. In the worst case every campaign click gets a MISS. Well-configured caches ignore known tracking parameters when they look up a copy. But somebody has to tell them to. - Cookies. If a response sets or reads a cookie, many caches treat it as personal and do not cache it at all. A newly added tool, a consent banner, an A/B test: things like these can halve a good hit rate overnight without anyone touching “performance”. - Every release. After a deploy the cache starts out empty. The first visitors afterwards pay for rebuilding it. At ten deploys a week that is not an edge case, it is Tuesday. None of the three is visible in an average. They are visible when you know the hit rate per layer and when it dropped. ## What you can tell your developers Your servers know every one of these answers. They just tell nobody until someone asks them to. There is a standard header for it, and the browser hands it over on every visit: Server-Timing: cdn-cache;desc="HIT", fm-fpc;desc="MISS", db;dur=48 Translated: the CDN had the copy, the origin cache did not, and the database took 48 milliseconds. Four lines in the server config are enough. fastmon reads both layers separately, from every real visit, and puts the hit rate right next to load time. Pageviews without a value show up as “Unknown”, and that is a statement too: nobody currently knows what happens there. Note: Which header names fastmon recognises and what each status means is in our Server-Timing docs . That link is exactly what your developers need. ## What to take away Three layers, one order, one question: who answered? The browser cache only helps people coming back. The CDN decides the distance, provided you cache the page itself too. The origin cache decides how expensive a miss becomes. And the hit rate is not a setting you tick off. It is a number you keep an eye on. Real user monitoring shows it to you from every real visit instead of estimating it in a lab. About the author Kamil Adrian Czujowski Co-Founder At home in e-commerce since 2009. Knows online shops from both sides: from building bots for sneaker releases to protecting e-commerce platforms against exactly those attacks. His focus at fastmon is performance and reliability under load: short load times, high availability and a clean, privacy-first setup. LinkedIn --- ## https://fastmon.eu/en/blog/deploy-regressions/ Back to blog Performance # Every deploy can wreck your performance. Would you notice? Regressions almost always ride in on a deploy. Why the average hides them, how a release marker from your CI/CD makes them visible, and what you actually compare at the p75. Kamil Adrian Czujowski August 6, 2026 · 4 min read Honestly: almost nobody deploys and thinks about their LCP. You merge the branch, the pipeline goes green, the feature is live. Done. That this exact deploy pushed your load time from 2.1 to 3.4 seconds shows up in no error log. Nothing is “broken”. It just got slower. And that is the tricky thing about performance regressions: they throw no error. They slip in with a perfectly normal, successful deploy and stay until someone notices by accident. Usually weeks later, usually a customer. ## Why regressions almost always ride in on a deploy Your site does not get slower on its own overnight. It gets slower because something changed: a new library in the bundle, an image without dimensions, a third-party script, a font that now blocks, a query that pulls one more column. All of that arrives with a deploy. So the most honest question for any regression is not “what is slow?” but “since when?”. And “since when” is almost always “since which deploy”. Know the moment and you have your suspect. Miss it and you are searching in fog. ## Why you don’t see it in the average Here is the part that fools most people. You open your performance dashboard, look at the last 7 days, and the line is… unremarkable. No spike, no alarm. So all good? No. Two things hide the regression: The average smooths it away. If a deploy slows half your pages but leaves the other half untouched, the mean barely moves. That is why web performance looks at the 75th percentile, p75 for short, not the average. p75 means: 75% of your visitors were at least this fast. The average flatters. p75 shows you the experience of the people it actually hits. The long window dilutes it. A regression that went live two days ago drowns in five days of good data before it. Averaged over a week, the jump is a small bump. Over the 24 hours before and after, it is a wall. Together they make sure that the very number showing the damage is the one almost nobody looks at: p75, in a short window, around the deploy. ## The release marker: a moment, nothing more For anyone to say “around the deploy”, the system has to know when the deploy was. That is all a release is: a named moment on your site. Nothing more behind it. A version ( v2.4.1 , a Git SHA, a date, whatever) and a timestamp. No deploy database, no changelog, just the marker. The cleanest way is to set it automatically, at the end of your deploy job, after a successful deploy: - name: Tag fastmon release if: success() env: FASTMON_TOKEN: ${{ secrets.FASTMON_TOKEN }} FASTMON_SITE_ID: ${{ vars.FASTMON_SITE_ID }} run: curl -fsS https://api.fastmon.eu/v1/sites/$FASTMON_SITE_ID/releases \ -H "Authorization: Bearer $FASTMON_TOKEN" \ -H "Content-Type: application/json" \ -d "{ \"version\": \"${{ github.sha }}\" }" Four lines, set up once. From then on every successful deploy carries its own marker, with nobody having to remember when what went live. ## What you compare afterwards With the marker, “did this get worse?” becomes a single query. You pick the deploy in the release picker and the chart overlays before and after. Programmatically the lever is compare_to_release_id . And now the important part, the one thing to understand once: the “before” window is exactly as long as your “after” window and ends precisely at the release. Query the 24 hours after the deploy and the system compares them against the 24 hours right before. Same length, same time of day, same weekday mix. Only the deploy sits in between. Which leads to a simple rule: keep the window short. A 7-day query compares against the 7 days before and blurs the jump again. If you want to see a regression sharply, take 1 to 24 hours. ## The three traps Three things trip the comparison up in practice, and none of them is complicated: - The timestamp has to be right. Leave out released_at and the server sets “now”. Usually fine. But if your deploy job runs minutes before the actual go-live, say on a blue/green flip, date the marker to the moment the new version really gets traffic. Otherwise you cut at the wrong point. - Releases belong to a site. If a monorepo ships three sites, you need three release calls, even when the version string is identical. - A rollback is a release too. Tag it the same way, happily as rollback-v2.4.0 . Then the chart shows all three transitions: the broken release live, the regression, and the rollback that catches the line again. You cannot document a bad day more honestly than that. Note: The full flow, from API token through the release call in GitHub Actions, GitLab CI or Vercel to the comparison query, is in our docs on comparing releases . That link is exactly what your developers need. ## Two nets, not one The best time to catch a regression is before it goes live at all. That is what synthetic tests are for: a lab test under always-identical conditions that flags a jump before the deploy reaches real visitors. More about Synthetic Monitoring . But the lab does not know every device and every network. Whatever slips through, you catch in the field: on real visitors, at the p75, in the short window around the release marker. More about Real User Monitoring . Two nets, one after the other. One before the deploy, one after. ## What to take away Regressions throw no error, they ride in on a deploy, and the weekly average hides them reliably. They only surface when three things come together: a marker on the deploy, the p75 instead of the average, and a short window around the marker. The marker costs you four lines in CI. The query does the rest. And the next regression no longer gets a week’s head start. About the author Kamil Adrian Czujowski Co-Founder At home in e-commerce since 2009. Knows online shops from both sides: from building bots for sneaker releases to protecting e-commerce platforms against exactly those attacks. His focus at fastmon is performance and reliability under load: short load times, high availability and a clean, privacy-first setup. LinkedIn --- ## https://fastmon.eu/en/blog/mcp-server/ Back to blog Product # Ask your AI about your web performance: fastmon now has an MCP server Connect Claude, Claude Code or Cursor to fastmon and ask for your field data instead of clicking it together in the dashboard. Nineteen read-only tools, OAuth instead of keys, and an honest note about who actually receives your data. Kamil Adrian Czujowski September 8, 2026 · 7 min read Your AI writes your commit messages by now, reads your logs and explains unfamiliar code to you. Your field data was not part of that. For those numbers you still went to the dashboard, picked a range, filtered a country and typed the result out by hand. Since 2 September you can just ask instead. fastmon has an MCP server. You connect your own AI client to it, Claude, Claude Code or Cursor, and it fetches the data itself. The model stays yours. What that means for your data is spelled out further down, in full. ## What MCP is MCP stands for Model Context Protocol, an open standard that lets an AI client hook into external services. Instead of copying numbers out of a dashboard into a chat, the client looks them up itself. Claude calls these connections connectors, Cursor calls them MCP servers, other clients call them something else again. The protocol underneath is the same everywhere. For you it means this: enter one address, log in once through OAuth, then ask questions the way you would ask a colleague with dashboard access. ## What you can ask Nineteen tools are available, all of them read-only. What they return are the same aggregates and rankings that sit behind your dashboard. Three situations where we use it ourselves. ### The regression after a deploy A release went out on Friday afternoon, and on Monday something is slower. Instead of lining up two ranges in the dashboard, you have them compared. - Compare LCP and INP for the last seven days with the seven days before - What changed since the release on Friday? compare_periods and detect_changes do the work. The second one hunts for the anomalies itself, rather than waiting for you to guess the right dimension. ### The question from the meeting Someone wants to know why the site looks worse on mobile, and is not expecting a lecture on percentiles but an answer. - What is LCP p75 in Germany on mobile, broken down by page type? - Which third parties cost the most load time? get_breakdown gives you the breakdown, get_cwv_distribution the distribution behind it, get_third_party_impact the foreign scripts. It stops at fifty rows, which is plenty for a conversation and was never meant for an export. ### The error only Safari sees A JS error shows up, but it may only affect one browser version, and you want to know whether the work is worth it. - Which JS errors are new this week? - Show me details on this error, which browsers and which pages get_errors and get_error_detail . What comes back are error signatures and counts, not the sessions of individual visitors. ## What comes out of it The most useful answer we got while testing was not a number. The question was how LCP had developed, and the reply was that it was too early to say. Two daily buckets are noise, not a trend. So the client changed the question. Two days of data, 574 ms and 708 ms, is not a trend, and the client said so instead of drawing a line through two points. What it offered instead was the breakdown that actually helps: of the 628 ms until the largest paint, 494 ms are gone before the browser has a single byte. The browser spends about 134 ms turning the response into a picture. On a local machine with no network latency, that is the server doing all the work. For the sake of honesty: this is a local development environment, domain localhost , running Shopware, with almost no traffic. It is not a glamour shot. It does show the difference between a number and an answer, which is why it is here instead of something prettier. ## What the server cannot do All nineteen tools are read-only. Not one of them changes a setting, deletes anything or starts a synthetic run. If your client gets the idea to try, it finds nothing to try with. There is no raw data either. What comes back are aggregates and rankings, never individual beacon rows. Plus a few hard limits: | Limit | Value | Range per query | 90 days maximum | Rows per breakdown | 50 maximum | Requests per person | 120 per minute | Minute-level buckets | only up to a 6 hour range | Runtime per query | cut off after 30 seconds The rate limit applies per person, not per organisation, so one talkative client cannot block your colleagues. Hit it and you get a 429 with the wait time in seconds. Three of the nineteen tools cover Lighthouse runs and additionally need Synthetic Monitoring on your plan plus the synthetic:read scope. If either is missing, the server says so instead of returning an empty list. ## AI and privacy This is where it gets interesting, because the moment you connect your client, data goes somewhere that is not us. What leaves are the same field data your dashboard shows: page URLs, referrers, UTM parameters, country, device and browser, timestamps, error signatures. The recipient is the AI provider running your client. Not fastmon. We do not pick that provider and we are not a party to the relationship, which in plain words means responsibility for this transfer sits with your organisation. We write it out this bluntly because it is the point where MCP differs from every other feature we have built. What was possible on our side, we did: - Off by default. An owner has to switch MCP on in the organisation settings. That writes an audit log entry, so nobody has to guess later when the access was opened. - OAuth instead of keys. There is no key to copy. The endpoint rejects personal keys, organisation keys and session cookies, because a key carries no audience and therefore cannot say whether it was issued for this endpoint. - The connection is yours, not the organisation’s. Its rights come from your current role on every request. Get downgraded and it takes effect immediately. Leave the team and the connection is worthless. - Disconnecting takes one click. You cut it under Account and Access, and the access tokens expire within minutes. - No configuration access. Tokens, members, billing: there is no tool for any of it. Do not confuse any of this with the Ask assistant in the dashboard. That one runs under our own DPA, so it is a different recipient with a different consent. If you do not want data going to a third provider at all, use Ask and leave MCP off. ## How to connect your client An owner switches MCP on under Settings and MCP server, and the rest takes two minutes. Every client uses the same address, exactly like this, with no trailing slash: https://api.fastmon.eu/mcp ### Claude Code One line in the terminal: claude mcp add --transport http fastmon https://api.fastmon.eu/mcp Then open /mcp , pick fastmon and log in. ### Claude and Cursor In Claude under Settings and Connectors, in Cursor under MCP, enter the address in either case. Leave the OAuth fields empty. Both send you to fastmon, where you get to see who is actually asking: The note that we have not checked the app is deliberate. Anyone can register an app under any name. This screen is also where you pick the organisation. No tool takes an organisation as a parameter later on, the context is fixed by your consent. On the first tool call your client asks again, this time on its own side: Two consents on two levels: fastmon asks about the access, your client asks about every tool call. ## For agencies Partners connect individually to each customer organisation, and the customer is named on the consent screen. Rights resolve per request. When the partnership ends, the access ends in the same moment. Whether MCP is open at all stays the customer’s decision. ## The full list All nineteen tools with their parameters, the OAuth details for building your own client including the resource parameter per RFC 8707 and the well-known document per RFC 9728, plus setup for further clients: it is all in the MCP docs . And if you try it and your client cannot find something it should be able to find, tell us. Nineteen tools are a start, not a finished list. Start fastmon for free Or read the MCP docs first About the author Kamil Adrian Czujowski Co-Founder At home in e-commerce since 2009. Knows online shops from both sides: from building bots for sneaker releases to protecting e-commerce platforms against exactly those attacks. His focus at fastmon is performance and reliability under load: short load times, high availability and a clean, privacy-first setup. LinkedIn --- ## https://fastmon.eu/en/blog/real-user-monitoring-tools/ Back to blog Performance # Real user monitoring tools in 2026: eight vendors, honestly compared Eight real user monitoring tools compared: prices, hosting and what lands on the visitor's device. List prices checked 2 September 2026, with an honest verdict. Kamil Adrian Czujowski September 2, 2026 · 16 min read Honestly, right in the first sentence: we build one of the tools on this list. You are reading a comparison on a vendor’s blog, and that belongs at the top, not in the small print. So we do this differently from most lists of this kind. The criteria come before the first tool. Every price is a list price with a date on it. Where we could not source a fact, it says “not verified” instead of a guess. And every tool gets a line saying when it beats fastmon. Those are not courtesies: for several vendors on this list there are situations where we would reach for them ourselves. ## What real user monitoring measures, and what it does not Real user monitoring measures the experience of actual visitors while they use your site. A small script in the browser records how long it took until the largest visible element appeared, how quickly the page responded to the first click, and how much the content jumped while loading. Those values go to the vendor, who aggregates them across all visitors. The difference from a lab test is the whole reason RUM exists. A Lighthouse run measures one page under fixed conditions: one device, one network, one location. Your visitors are not a fixed condition. They sit on four year old Android phones in a congested mobile network, on an office machine with fibre, or on a train with a connection that comes and goes. RUM shows that distribution, which is why it is the data Google looks at too. What matters just as much is what RUM cannot do. It does not tell you reproducibly why something was slow, because every measurement happened under different conditions. It measures nothing before the first real visitor arrives, so it is no use as a pre-deploy test. And at low traffic the statistics get thin: below roughly a thousand pageviews a month the percentiles are no longer stable enough to decide anything. ## RUM or synthetic monitoring? This question comes up in every tool selection, and the honest answer is: both, where you can. | Real user monitoring | Synthetic monitoring | Data source | actual visitors | scheduled test runs | Conditions | variable, like reality | fixed and repeatable | Finds a problem | when visitors experience it | before visitors experience it | Answers | who it hits, how often, where | why exactly, reproducibly | Blind spot | rare pages with no traffic | anything that only happens live | Fit for alerting | medium, needs volume | high, stable baseline | Core Web Vitals | LCP, INP, CLS as field data | LCP and CLS, INP only approximated That last row often decides the choice. Interaction to Next Paint cannot be measured cleanly in a lab, because nobody clicks there. Lighthouse offers Total Blocking Time as a proxy instead. If you genuinely want to know your INP, there is no way around field data. ## What we compared on All eight tools measure real visitors. They differ on six points that genuinely hurt in daily use: Entry price and included volume. Not the list price on its own, but what it buys in pageviews or sessions. A cheap plan with 100,000 pageviews costs a mid-sized shop more than a dearer one with 1.5 million. Where the data sits and who can reach it. For a European company that is not a matter of taste, it is a question asked in every procurement process. What matters is not only the server location but the vendor’s jurisdiction: an EU region does not change which law the company answers to. What ends up on the device in the default mode. Cookie, localStorage or nothing. It decides what the consent question looks like, and it is where the tools differ most sharply. Whether field and lab live in the same tool. Buy them separately and you pay twice, then compare numbers from two systems with different definitions. How long the data stays. A year-over-year comparison needs thirteen months of history. With several vendors that costs a multiple of the entry price. What the tool was originally built for. An uptime service with a RUM feature behaves differently from a web performance tool. Both are legitimate, but it decides whether you find your way around the interface. ## The overview ### Price and volume | Tool | Entry | What that buys | Built for | fastmon | €29/mo | 200k pageviews | web performance, EU | Datadog RUM | $0.15/1,000 sessions | usage based | full-stack observability | New Relic | $0 up to 100 GB | 100 GB ingest | one platform for everything | Pingdom | €14.33/mo | 100k pageviews | uptime first | SpeedCurve | $90/mo | configurable | performance culture | DebugBear | $99/mo | 100k pageviews | Core Web Vitals, lab | RUMvision | €150/mo | 1.5M pageviews | RUM specialist, EU | Raygun | $80/mo | 100k sessions | errors and RUM ### Data path and device | Tool | Base and processing | On the device | fastmon | Germany, data path fully in the EU | nothing in the default mode | Datadog RUM | US company, EU region optional | cookie ( _dd_s ) | New Relic | US company, EU region at a surcharge | not verified | Pingdom | SolarWinds, headquartered in Austin, Texas; processing location not verified | not verified | SpeedCurve | US company, AWS us-east-1 | session cookie ( lux_uid ) | DebugBear | UK, Google Cloud, EU proxy as opt-in | no cookie by default | RUMvision | Netherlands, edge on AWS CloudFront | localStorage by default | Raygun | AWS, region not documented | not verified List prices, checked on 2 September 2026. DebugBear and Raygun at their annual rates; paying monthly costs more there. Hosting and device behaviour come from vendor documentation, checked on 14 July 2026. Where it says “not verified” we found no solid public source and therefore claim nothing. Terms change, so verify them with the vendor before you decide. ## The eight tools ### fastmon Real user monitoring, scheduled Lighthouse audits and web analytics in one interface, built and hosted in Germany. Light is €29 for 200,000 pageviews, Standard €99 for a million, usage based in steps above that. One production and one development application are included, and the number of domains does not matter. In the default mode nothing is stored on the device. The visitor identifier is short-lived and derived at the edge, where the IP address is reduced to a country code and never reaches application code. Debugging covers error grouping, network waterfalls and a breakdown of server time into nine phases via the Server-Timing header, including separate phases for search index and key-value store. Deploys can be tagged as a release, after which one query compares before and after at the 75th percentile. For shops, fastmon recognizes cart, checkout and completion from the URL patterns of the common systems, with no tracker change. Pick something else if you need session replay, expect logs and APM in the same tool, or want to measure native mobile apps. fastmon does none of that. Synthetic monitoring and analytics are also labelled beta. ### Datadog RUM The benchmark for teams that want frontend, backend, infrastructure and logs correlated in one place. When something surfaces in the frontend and the cause sits three layers down, Datadog is there where other tools stop. Pricing is split into separate SKUs, and working that out is the real task. RUM Measure is $0.15 per 1,000 sessions on an annual contract, remarkably cheap for aggregate metrics. The moment you want to inspect individual sessions, RUM Investigate joins at $3 per 1,000 filtered sessions, Session Replay at $2.50 and Product Analytics at $0.80. If aggregate metrics are all you need, the entry SKU is all you pay for; if you open individual sessions, you budget for several. Datadog is a US company, the EU region is an option rather than a default, and the browser SDK sets a cookie named _dd_s by default to hold a session together across pages. Pick Datadog if you are already there and want frontend data next to traces and logs. No specialized tool replaces that correlation, ours included. We have a dedicated fastmon versus Datadog comparison . ### New Relic The most generous free tier in the field: 100 GB of ingest per month costs nothing, then $0.40 per GB, or $0.60 with Data Plus. Browser monitoring is part of the platform rather than a separate SKU, so you pay for data volume, not for pageviews. The user prices are the part that surprises teams. A core user is $49 a month, a full platform user $349 a year and up depending on tier. With a larger team that quickly becomes the dominant line item, not the data. There is an EU region, at $0.05 per GB extra. Here too the vendor is a US company. Pick New Relic if you want a broad observability platform, can live with a consumption model, and want to use the free tier to try things out. ### Pingdom The best known name in uptime monitoring, with RUM as a second leg. Entry is €14.33 a month on annual payment for 100,000 pageviews, the cheapest on this list. Synthetic monitoring is billed separately at the same rate, so both together come to roughly €344 a year. The 30 day trial covers both. The product page describes a live map of visitors, breakdowns by browser, device and platform, load time with an Apdex score, session journeys and shareable reports. Core Web Vitals are part of the RUM product as well. The centre of gravity is clearly availability and classic load time, and that is exactly what Pingdom has been the known name for over twenty years. For European buyers the ownership matters. Pingdom was founded in Sweden in 2005 and belongs to SolarWinds today, headquartered in Austin, Texas. The pages we checked do not state where the RUM data is processed and stored. If you need processing to stay inside the EU, get that in writing before you buy. Pick Pingdom if uptime is your main topic and RUM the addition to it. If the processing location is decisive for you, settle it first. ### SpeedCurve The tool with the strongest culture around performance: dashboards you put on a wall, comparisons against competitors, lab and field side by side. If you want performance to become a topic other departments talk about, this is the best presentation of it. Entry is $90 a month, with sliders for RUM and synthetic volume, so there is no fixed included amount. Thirteen months of history starts at the Growth plan at $576, so the year-over-year comparison is a cost item of its own there. Hosting is in the AWS us-east-1 region. Ownership has moved: SpeedCurve belonged to Embrace and now trades as a Palo Alto Networks company, so it stays US-based. By default SpeedCurve sets a session cookie named lux_uid that expires thirty minutes after the last pageview. Pick SpeedCurve if you want to establish performance as a team topic and value good visualization. ### DebugBear The Core Web Vitals specialist with the deepest lab side. Experiments that let you simulate a change before you build it are a first-class feature, and for the question “what do we gain by removing this script?” there is no better tool on this list. Recently the Startup plan at $99 a month on annual billing already includes 100,000 RUM pageviews plus 4,000 synthetic tests. Team with 500,000 pageviews is $249, Corporate with two million $699. Fourteen day trial, no credit card. DebugBear is a UK company on Google Cloud. A proxy in Germany is available so IP addresses do not leave the EU, but it is opt-in rather than the default. Its RUM sets no cookies by default. Pick DebugBear if synthetic tests and lab debugging are your focus and the field is the supplement. With us it is the other way round. ### RUMvision The other European option on this list, from the Netherlands, and a pure RUM specialist. Entry is €150 a month for 1.5 million pageviews across two domains, with extra domains at €20. Measured by volume that is fair: if you use the 1.5 million, you pay less per pageview than with most others here. If you do not, you pay the highest entry price in the field. Thirteen months of retention only arrives with the Scale plan from €700. By default RUMvision uses localStorage and sessionStorage to tell new visitors from returning ones. That is not a cookie, but it is access to the device, and for the consent question that makes a difference. Both can be switched off, and the vendor says consent then falls away too. One point that the word EU tends to hide: collection runs through AWS CloudFront and AWS WAF. RUMvision documents the mechanism openly and cleanly, the IP is seen at the edge only long enough to derive the country code and is then discarded, with only the ISO code reaching the database. Still, if you pick a vendor by its data path, you should know that a US hyperscaler sits in that path, even though the company itself is Dutch. Pick RUMvision if you have high volume on few domains and want an EU vendor for whom RUM alone is enough. ### Raygun Error tracking, crash reporting and RUM from one vendor, with a strong eye on individual user sessions. If you care what a specific user experienced before the error hit, that is where Raygun is at its strongest. Real user monitoring starts at $80 a month billed annually for 100,000 sessions, $120 monthly, with extra sessions at $0.002 each. Fourteen day trial, no commitment. Raygun runs on AWS according to its own security page. Which region that is, and whether an EU option exists, is not stated there and we could not source it elsewhere. Pick Raygun if you want errors and performance at session level in one view and the server location does not matter to you. ## Core Web Vitals compared If Google is the reason you are buying, this is the row to read. All values refer to field data, that is, to actual visitors. | Tool | LCP, INP, CLS | Segmentation | Attribution | fastmon | yes, at the 75th percentile | page, page type, device, country, browser | yes, element and phase per pageview | Datadog RUM | yes | extensive | partial, via session details | New Relic | yes | extensive | partial | Pingdom | yes | browser, device, location | not verified | SpeedCurve | yes | extensive, incl. competitor benchmarks | yes | DebugBear | yes | extensive | yes, linked to lab data | RUMvision | yes | extensive | yes | Raygun | yes | session, device, location | partial We classified segmentation and attribution from the vendors’ public product and documentation pages, as of 2 September 2026. “Partial” means an attribution exists but not as a dedicated view per metric. Where it says “not verified” we found no solid source. Attribution is the part that saves the most time. Knowing that LCP sits at 3.4 seconds helps little. Knowing that it is the hero image on the category page, and that the time sits in load delay rather than in rendering, is the difference between guessing and working. ## And if it has to be free There are two free routes that carry you surprisingly far. The Chrome UX Report gives you field data from real Chrome users for any sufficiently visited domain, with nothing to install. And PageSpeed Insights shows that field data next to a Lighthouse run, so field and lab on one screen. You hit the limit quickly. CrUX only knows Chrome users, aggregates over 28 days, and will not show you one page of your shop at the moment it was slow. There is no error data, no network waterfall, and no way to compare yesterday’s deploy with the day before. For “where do we stand?” it is enough. For “what happened yesterday?” it is not. More in our comparison with Lighthouse . ## Which tool for which situation If you are in one of these situations, the answer is fairly clear: - European shop or agency, privacy comes up in every meeting: fastmon or RUMvision. Both companies are based in the EU. They differ in price, in included volume, in what lands on the device (nothing, with us, in the default mode), and in the data path: RUMvision collects through AWS CloudFront, while with us every provider in the customer data path is an EU company. - You already run Datadog or New Relic: stay there, unless the bill or the privacy question forces you out. A second tool next to an observability platform rarely pays off. - Uptime is the main topic, performance the bonus: Pingdom, cheap and with a name your management already knows. - Load time is your core job and you work a lot in the lab: DebugBear or SpeedCurve. - Errors and individual user sessions come first: Raygun. - You want field, lab and analytics in one tool without an enterprise contract: that is what we built fastmon for. ## What to watch out for when choosing Three mistakes come up again and again, and all three cost money or nerves later. Buying on list price instead of price per pageview. Work out your actual monthly traffic against the included volume. A $10 plan with 100,000 pageviews is more expensive than a €150 plan with 1.5 million as soon as you have two million. Forgetting retention. Almost every vendor sells the short history cheaply and the long one dearly. If you want to know in January how last December went, you need thirteen months, and with several vendors that is exactly the jump into the next tier. Checking the data path only during procurement. The question of where data sits and who can legally reach it comes up in every larger organization. Asking it once the tool is already embedded leads to migrations nobody planned for. ## What we do differently Three things we are happy to be held to, all three checkable. The cheapest EU-hosted entry in this comparison. €29 for 200,000 pageviews against €150 at RUMvision, the only other EU vendor on this list. Cheaper overall is Pingdom at €14.33, and New Relic has a free tier. Neither is an EU vendor, and that is the point of the claim: among the tools with a European data path, we are the cheapest way in. Nothing on the device. In the default mode fastmon writes neither a cookie nor localStorage. In our assessment that needs no consent under § 25 TDDDG, and the full derivation including the residual risk is public on our cookies page . We know of no other tool on this list that derives its own legal position publicly in that detail. The data path stays in the EU. Built and hosted in Germany, and every provider in the customer data path is a company from Germany or the EU, listed in our sub-processor list . No Cloudflare, no AWS, no GCP. What we cannot do is in the fastmon section above, and none of it changes that for some teams one of the other seven is the right choice. ## Try it instead of comparing it In the end no table decides this, the question is whether you find what you are looking for in the interface. Every fastmon account starts with 30 days of full access, no credit card, and the script is one tag in the head. Five minutes later you are looking at your first real visitors. Something wrong here? Everything stated about other vendors is a list price or a public product claim, checked on 2 September 2026. Prices and features change, sometimes within the same week. If you spot something that is no longer accurate, or never was, write to support@fastmon.eu . We will correct it and note the date of the change. That invitation goes to the vendors themselves as well. Start fastmon for free Or look at the plans first About the author Kamil Adrian Czujowski Co-Founder At home in e-commerce since 2009. Knows online shops from both sides: from building bots for sneaker releases to protecting e-commerce platforms against exactly those attacks. His focus at fastmon is performance and reliability under load: short load times, high availability and a clean, privacy-first setup. LinkedIn --- ## https://fastmon.eu/en/blog/ttfb-server-timing/ Back to blog Performance # Your page takes 800 ms to the first byte. Doing what, exactly? TTFB is a single number for everything that happens before the first byte. How to split it into phases with one response header, why search and key-value stores deserve phases of their own, and how Early Hints make your TTFB look better than it is. Kamil Adrian Czujowski August 27, 2026 · 5 min read Honestly: TTFB is the most thankless number on the dashboard. It sits there, says 800 ms, and that is where the information ends. Was it the database? A template doing too much? The payment provider whose API is having a bad day? The cache that did not hit? The number knows. It just does not say. And the answer is usually one response header away. ## TTFB is a sum, not a diagnosis Time to First Byte measures the span from the click to the first byte of the response. Everything is in there: DNS, connection, TLS, the trip to the edge, the trip from the edge to the origin, and then all the work your application does. One value for half a dozen stations. As long as it is small, that is fine. Once it grows, every optimization becomes a bet. You rewrite the database query, deploy, wait two days for enough data, look. Nothing moved. So the template. Deploy, wait, look. Still nothing. After the third round it turns out to be the search index nobody thought about. That is not a skill problem, it is a visibility problem. You are optimizing a sum without knowing its parts. ## The header is three lines in your backend Server-Timing is a standard response header your backend uses to attach where the time went to every response. No SDK, no extra request, no instrumentation in the browser. You are already measuring somewhere in your code, you just write the values into a header: $response->headers->set('Server-Timing', sprintf( 'db;dur=%.1f, render;dur=%.1f, cache;dur=%.1f', $dbMs, $renderMs, $cacheMs That is Symfony, which is also the Shopware world. Flask, Express and the rest take the same three lines, they are in the docs. The browser reads the header anyway, and our beacon picks it up from the document response on every pageview. From then on the breakdown is part of your field data, measured on real visitors instead of one test run. ## Nine phases, and what sits behind them To turn other people’s metric names into something comparable, fastmon normalizes them into nine phases: - Edge ( edge_dur ) and Origin ( origin_dur ): the route. Time at the edge, and time between edge and origin server. - Backend ( backend_dur ): the application as a whole. This is also where WordPress lands with its wp-total . - Database ( db_dur ) and Rendering ( render_dur ): the two classics, relational queries and building the page. - Cache ( cache_dur ), External calls ( external_dur ), Search ( search_dur ) and Key-value store ( kv_dur ): the four that get summed, because a single request tends to hit several of them. The usual names are already known: elasticsearch , opensearch and solr land in search, redis and valkey in the key-value store, http , fetch and api in external calls. If you want it unambiguous, send the phases under their fm- names, which take precedence over everything else. You see the result under Analytics, Server-Timing, in the response breakdown waterfall and as a column in the explorer, each as p50, p75 and p95. Percentiles, not averages, for the same reason as everywhere else: the average flatters, the p75 shows you the visitors who actually suffer. ## What you read off it The moment those three lines pay for themselves looks roughly like this: backend 60 ms, database 25 ms, rendering 30 ms, search 240 ms. The discussion about query optimization is over before it started. The database is not slow, the search index is. Or: everything under 50 ms, external calls at 300 ms. Then your TTFB is not about your code, it is about a service somebody hung into the page build synchronously two months ago. Or the uncomfortable one: cache phase high, cache hit rate good. Then the cache is not the problem, it is a solution that takes too long, usually because it is reached over the network instead of a local socket. None of the three is visible in a single number. All three jump out at you in ten seconds once there are four. ## Two new phases, and a step in the chart Search and key-value stores have been phases of their own since 27 August. Before that both sat in cache_dur , which was still sort of true for Redis and had not been true for Elasticsearch in a long time. Throwing them together meant you could see that a store was slowing you down, but not which one. That has an honest side effect you should know about before you notice it: because Redis moved out of the cache phase into the key-value store, cache_dur gets smaller from that deploy on. In the chart that is a step down. It is not an improvement, it is a reshuffle. We did not touch the values already stored, which is why the step is there and stays visible. ## Early Hints: when your TTFB starts lying And then there is the case where your TTFB improves without anything getting faster. With 103 Early Hints your server, usually the edge in front of it, sends a provisional response carrying preload and preconnect hints while your backend is still working. The browser starts fetching files early. For your visitors that is a real gain. For your measurement it is a trap: the first byte that arrives is the 103, not your actual response. Since Chrome 133, responseStart counts that provisional response, and because almost every tool derives its TTFB from it, your number drops the moment you switch Early Hints on. Your server takes exactly as long as before. So the fastmon tracker additionally reads the timestamp of the final response headers and puts it next to it as ttfb_final . Two values, one clear answer: - Both equal: there was no provisional response, your TTFB is your TTFB. - ttfb_final larger: the difference is exactly the head start the edge gave your visitors. The TTFB page shows it at your chosen percentile, the response breakdown as a line of its own from the first byte to the final headers. - Empty: the browser does not report it, or it was a soft navigation. Which gives you the rule of thumb people otherwise miscalculate: the edge and backend phases have to fit into ttfb_final , not into ttfb . Measure against the smaller of the two and you end up puzzled by phases that supposedly last longer than the whole response. Note: Which metric names map to which phase, how to add your own, and the limits for values and descriptions are all in our Server-Timing docs . That is the page for your developers. ## What to take away TTFB tells you it was slow. Server-Timing tells you where. The difference between the two is three lines in your backend, and after that a discussion held with numbers instead of guesses. Start with db , render and cache , that covers most cases. If a search index or a key-value store is involved, add those two, they have earned it. And if you run Early Hints, look at ttfb_final before celebrating a suddenly excellent TTFB. All of it measured on real visitors, not in a lab. More on Real User Monitoring . About the author Kamil Adrian Czujowski Co-Founder At home in e-commerce since 2009. Knows online shops from both sides: from building bots for sneaker releases to protecting e-commerce platforms against exactly those attacks. His focus at fastmon is performance and reliability under load: short load times, high availability and a clean, privacy-first setup. LinkedIn --- ## https://fastmon.eu/en/blog/warum-europa/ Back to blog Privacy # Why we bet on Europe. And what that actually means. No Cloudflare, no AWS, no GCP: why we took the less convenient path, and what it concretely changes for your data. Kamil Adrian Czujowski July 12, 2026 · 4 min read Honestly: the convenient path would have looked different. An AWS account, Cloudflare in front, a Vercel deploy, done. That is how most teams build today, and we understand every one of them. The tooling is mature, the docs are good, everything moves fast. We decided against it anyway. There is not a single US provider anywhere in fastmon’s data path. No Cloudflare, no AWS, no GCP, no Vercel. Why we put ourselves through this, and what it concretely changes for your data: that is what this post is about. ## “EU hosting” is printed on everything now Most tools that call themselves privacy-friendly are US companies with a data center in Frankfurt. The servers sit in Europe. The company still answers to US law, and the US CLOUD Act reaches its data wherever it lives. An EU region is simply not the same as EU jurisdiction. That is the difference between a tool from the EU and one with an EU region. And that is exactly where we did not want to end up. ## What actually sits behind ours fastmon labs UG is a German company from Hannover. All customer and monitoring data is processed exclusively in the EU and stored in Germany: Hetzner, Falkenstein data center. And the rest? European too, all the way through. A few examples from our provider list: - Hosting, storage and backup: Hetzner, Germany - Ingress: a company from Berlin - DNS: a provider from Slovenia - Transactional and business email: two providers from the Netherlands - AI inference: Mistral AI from Paris, and only if you actively opt in Nine sub-processors in total, five of them based in Germany, the rest in the EU. The full list is not something you negotiate out of a sales call, it sits publicly in our DPA. And full transparency, because the question will come up eventually: for our internal toolkit we do use US tools. Our code lives on GitHub, tickets run through Linear, and Claude Code from Anthropic helps us build. The difference: no customer and no monitoring data flows through any of them, our internal policy forbids exactly that, and that is why these tools are not sub-processors. We list them openly on our provider page anyway. The data path, meaning everything that touches your data and your visitors’ data, stays in Germany and the EU. ## The CLOUD Act, without the drama The US CLOUD Act obliges US companies to hand over data, no matter where their servers stand. That is why the Frankfurt region does not help. At fastmon, no provider in the data path is subject to US law; access under it is therefore not something to expect. We deliberately claim no more than that. Law is not a switch you flip once, and words like “impossible” have no place in a data path. But the starting position is fundamentally different when no party involved answers to a US order. ## What actually reaches your data Jurisdiction is one half. The other half is what gets collected in the first place. There we rely on architecture instead of promises: - Your visitors’ IP is reduced to a country code at the edge, just the country, ISO-2, and discarded immediately. No raw IP and no User-Agent ever reaches the backend. - In the default mode, fastmon sets no cookies* and stores nothing on the device. - No fingerprinting, no cross-site identifiers, no third-party enrichment. The asterisk behind “cookies” is deliberate, by the way. Cookie-free does not automatically mean consent-free. More on that in a moment. ## The part nobody can take off your plate Now the uncomfortable part that many vendors like to leave out. Whether embedding an analytics tool requires consent under § 25 TDDDG, Germany’s implementation of the ePrivacy rules, is disputed. The strict reading, which Germany and the EDPB lean towards, treats analytics and performance measurement as not strictly necessary. We assume exactly that strict reading and build and document conservatively. In plain terms: in Light and Standard mode, in our assessment, you do not need a consent banner, because nothing is stored on the device and the values read were not there beforehand. In Full mode you do, because an identifier gets written. Responsibility for the integration stays with you either way. The assessment for your own site is yours to make, ideally together with your data protection officer. A tool that gives you a blanket all-clear here is exactly the kind of tool you should question. Note: This is not legal advice. It describes how fastmon is built and documented; the assessment for your specific setup is yours. ## Why we put ourselves through this Because the product would not be credible otherwise. A monitoring tool that promises privacy and then ships the data through US clouds would be exactly the fine print we criticize above. The path is less convenient, we will admit that openly. Fewer ready-made building blocks, more running things ourselves, and with every new provider the first question is: are they based in the EU? But honestly: the European providers we work with are not a compromise. They are just not the default. Maybe that is exactly what should change. Everything here is laid out in more detail, with every number and every provider, on our EU & Privacy page. About the author Kamil Adrian Czujowski Co-Founder At home in e-commerce since 2009. Knows online shops from both sides: from building bots for sneaker releases to protecting e-commerce platforms against exactly those attacks. His focus at fastmon is performance and reliability under load: short load times, high availability and a clean, privacy-first setup. LinkedIn --- ## https://fastmon.eu/en/blog/web-vitals-buzzwords/ Back to blog Performance # LCP, FCP, TTFB: just buzzwords to you? Five acronyms, translated into plain language: what your visitors actually feel when these numbers are bad, and why Google takes them seriously. Kamil Adrian Czujowski July 15, 2026 · 4 min read Honestly: nobody wakes up in the morning thinking about their LCP. Your visitors certainly don’t. They think: Why can’t I see anything yet? Why doesn’t this button react? Why did the text jump away the exact moment I tried to tap it? That is precisely what these acronyms measure. Each one answers a question a visitor actually asks. There is nothing more to it. Let’s walk through them, in plain language. ## Five acronyms, five questions ### TTFB: is anything happening at all? Time to First Byte. The time from the request to the first byte your server sends back. Until then, the browser does: nothing. A bad TTFB drags everything else down, because the browser cannot render what it has not received. As a rule of thumb: up to 800 ms counts as good. ### FCP: when do I finally see something? First Contentful Paint. The moment the browser paints content for the first time. A piece of text, a logo, anything. Before that, the page is simply blank. FCP is your page’s first sign of life. Good means: up to 1.8 s. ### LCP: when do I see the thing I came for? Largest Contentful Paint. The moment the biggest visible element has finished rendering: the hero image, the video poster, the big headline. From this point on, the page feels “there”. Google’s thresholds: up to 2.5 s is good, above 4.0 s is poor. A lot of everyday reality sits in between. ### INP: why is this button janky? Interaction to Next Paint. The worst-case delay between a tap or click and the next visible frame. When visitors click twice because “nothing happened”: that is INP. Up to 200 ms is good, above 500 ms is poor. INP replaced FID as a Core Web Vital in March 2024. ### CLS: why does everything jump around? Cumulative Layout Shift. It scores how much visible content moves unexpectedly. The classic: a banner loads late, the text slides down, you hit the wrong link. CLS is not a time, it is a score: up to 0.1 is good, above 0.25 is poor. Note: Strictly speaking, only three of these are Core Web Vitals: LCP, INP and CLS. FCP and TTFB are diagnostic metrics. They explain why the big three look the way they do. ## Lighthouse says 95. People still complain. Both can be true at the same time, and that confuses everyone at first. Lighthouse is a lab test: a simulated device, one location, ideal conditions, fully reproducible. That is exactly what it is good at. Because the conditions never change, it catches regressions before they go live . But the test knows nothing about the three-year-old Android on a cellular connection that is opening your page right now. Field data measures exactly that: every real page view, on real devices, on real networks. That is what Real User Monitoring, RUM for short, means. Noisier than the lab, yes. But real. And because field data scatters, you don’t look at the average. You look at the 75th percentile, p75 for short. p75 means: 75% of your visitors were at least this fast. The average flatters you. p75 shows you the experience of the people who suffer. One more detail: INP is a field-only metric. A lab test does not click like a human, so INP comes from the field, not from the lab. ## Why Google takes this seriously Google ranks by the real Core Web Vitals of Chrome users, collected in the Chrome UX Report (CrUX). Not by your Lighthouse score. Your lab can say 95 and your field can say something entirely different, and for your ranking, the field wins. The logic is simple: Google wants to link to results that feel good, on the devices people actually use. You can call that strict. Unfair it is not. ## What to do with all this Don’t start with the score, start with the questions. Do your visitors see something quickly? Does the page react to the first click? Does the layout stay put? To answer those, you need numbers from real visitors, judged at the p75 instead of the average. That is exactly what fastmon does: the Core Web Vitals from every real visit, at the p75 against Google’s thresholds. If you want to see what that looks like: More about Real User Monitoring . From now on, these are not buzzwords anymore. Promise. About the author Kamil Adrian Czujowski Co-Founder At home in e-commerce since 2009. Knows online shops from both sides: from building bots for sneaker releases to protecting e-commerce platforms against exactly those attacks. His focus at fastmon is performance and reliability under load: short load times, high availability and a clean, privacy-first setup. LinkedIn --- ## https://fastmon.eu/en/compare/datadog/ fastmon vs Datadog RUM # Real User Monitoring, without the enterprise bill. Datadog RUM is part of a full observability suite, priced and built for enterprises. fastmon is focused web-performance RUM: lighter, EU-hosted, and a fraction of the cost. Datadog is a serious full-stack observability platform: APM, logs, infrastructure and RUM. If you need all of that in one place, it does far more than fastmon, and we will not pretend otherwise. But for web performance specifically, Datadog RUM is heavy, uses cookies, comes from a US company under the CLOUD Act, and gets expensive fast at real traffic. fastmon does the web-performance job: Core Web Vitals, errors and network timing from real users, cookieless* by default, hosted in Germany, from €29 a month. Focused web RUM ## At a fraction of the cost. For web performance specifically, the differences are stark. | | fastmon | Datadog RUM | Core Web Vitals from real users | Yes | Yes | JavaScript errors and network timing | Yes | Yes | Alerts and release tracking | Yes | Yes | Cookieless* in the default mode | Yes | No | Hosted in the EU, no US jurisdiction | Yes | No | Lightweight script | ~40 KB | ~60 KB gzipped | Setup | One script tag | SDK and config | Session replay | No, by design | Yes | Full-stack observability (APM, logs, infra) | No | Yes | Raw data retention | 90 days (default), up to 13 months (Enterprise) | events 15 to 30 days (metrics longer) | Price at about 1M sessions Datadog bills per session, fastmon per pageview; 1M sessions are typically 2 to 4M pageviews | ≈ €169 to €200/mo (at ~3M pageviews) | from ~$150/mo (RUM Measure, annual); Investigate $3 per 1k sessions Datadog restructured RUM pricing in 2026: RUM Measure from $0.15 per 1k sessions (annual), RUM Investigate $3 per 1k filtered sessions, Session Replay extra. Prices vary by contract. Datadog does far more than web RUM. As of 14 July 2026: list prices / typical configuration; individual terms may differ. Why teams pick fastmon for web RUM ## Lighter, EU-hosted, affordable. When web performance is what you actually need to watch. ### A fraction of the cost From €29 a month. Datadog has per-session, modular list pricing; debugging-grade features sit in the higher-priced Investigate tier. ### EU-hosted and cookieless* In Germany, no US provider in the data path, no cookies* in the default mode. Datadog is a US company under the CLOUD Act, even in its EU region. ### Live in five minutes One script tag, around 40 KB, no agent and no build step. Focused on web performance, nothing to configure. Fair play ## Where Datadog is the right call. If you need APM, log management, infrastructure monitoring and RUM in one platform, Datadog is built for exactly that and does far more than fastmon. fastmon is the focused, EU-hosted, affordable choice when web performance is the thing you need to watch. FAQ ## fastmon and Datadog. The questions people ask before they switch. ### Is fastmon a Datadog replacement? For web-performance RUM, yes, and at a fraction of the price. For full observability, meaning APM, logs and infrastructure, no: Datadog is a much broader platform. fastmon deliberately does one thing well. ### How much cheaper is fastmon? fastmon starts at €29 a month. Datadog has per-session, modular list pricing; debugging-grade features sit in the higher-priced Investigate tier, and costs depend on contract and modules. For web performance specifically, fastmon covers the essentials for far less. ## Honestly compared, built in the EU. The web-performance job without a US cloud: read-only by default, no cookies*, no long-lived identifiers, from €29 a month. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/compare/ga4/ fastmon vs Google Analytics 4 # Analytics without the cookie baggage. GA4 counts visits with cookies and sends the data to Google. fastmon gives you privacy-first web analytics from the EU, plus the Core Web Vitals GA4 does not measure out of the box. GA4 is powerful and free, and for deep marketing analytics it does a lot. But it sets cookies, samples your data in explorations, and processes it as a US company. In the EU that usually means a consent banner and a Schrems-shaped headache. fastmon is analytics built privacy-first: no cookies* in the default mode, the IP dropped at the edge, hosted in Germany, no US provider in the data path. And because it runs on the same beacons as your Web Vitals, traffic and performance sit in one tool. Privacy first ## And performance included. The differences that matter for an EU team that also cares about speed. | | fastmon | Google Analytics 4 | No cookies* in the default mode | Yes | No | Hosted in the EU, no US jurisdiction | Yes | No | IP processing without a US company | Yes | No | Unsampled data | Yes | Partial | Core Web Vitals in the same tool traffic and performance together | Yes | Partial | Error grouping and network timing (RUM) | Yes | No | Campaign attribution (UTM, click-ID label) | Yes | Yes | Data used to improve ad products | Never | Configurable | Raw data retention | 90 days (default), up to 13 months (Enterprise) | 2 or 14 months | Marketing funnels and audiences | No | Yes | Price | from €29/mo | Free GA4 behavior depends on configuration; the comparison reflects standard (free) GA4 defaults. GA4 360 raises retention (up to 50 months) and sampling limits. fastmon Analytics is in beta. As of 14 July 2026: list prices / typical configuration; individual terms may differ. Why teams move off GA4 ## Privacy, sovereignty, and speed. The reasons EU teams give for switching their analytics to fastmon. ### No cookie baggage Cookieless* and storage-free in the default mode, so you avoid GA4's cookies entirely. In our assessment that removes the banner too; Full mode still needs one. ### Your data stays in the EU Processed and stored in Germany, no US provider in the data path, so the US CLOUD Act cannot reach it. ### Performance in the same view Traffic and Core Web Vitals on the same beacons, so you see which slow pages are quietly costing you conversions. Fair play ## Where GA4 still wins. GA4 is free, integrates tightly with Google Ads, and offers funnels, audiences and event modeling that fastmon does not. If your world revolves around Google Ads and advanced marketing analytics, GA4 is hard to beat. fastmon is for teams who want privacy-first traffic and performance in one EU-hosted tool. FAQ ## fastmon and GA4. The questions people ask before they switch. ### Is fastmon a full GA4 replacement? For most sites, yes: visitors, sources, pages, locations, devices and campaigns, next to your performance data. It deliberately does not do funnels as a report, conversion goals, custom events or A/B testing, and it is in beta. ### Do I still need a cookie banner? fastmon sets no cookies* in the default mode and writes nothing to the device, so you avoid GA4's cookies. In our assessment Minimal and Standard need no consent either, because the values read were not in the device beforehand; Full mode does. With GA4 the banner is mandatory, because cookies get set. The full derivation, with the statutory text and the opposing reading ## Honestly compared, built in the EU. The web-performance job without a US cloud: read-only by default, no cookies*, no long-lived identifiers, from €29 a month. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/compare/lighthouse/ fastmon vs Lighthouse # Keep the lab. Add the field. Lighthouse tells you how fast one simulated device loaded your page. fastmon shows you how fast it was for your real visitors, and still runs Lighthouse for you, on a schedule. Lighthouse is a great, free lab tool. It loads your page once on a simulated device under ideal conditions and scores it. That is perfect for catching regressions before you ship, and fastmon runs exactly that for you as Synthetic Monitoring. But a lab score is not what your visitors feel. A three-year-old phone on mobile data is not an idealized desktop. fastmon adds Real User Monitoring: the Core Web Vitals your real visitors actually get, aggregated at the p75, right next to the lab run. You keep the lab and gain the field. Lab and field ## Side by side, in one tool. fastmon runs Lighthouse for you and adds the real-user data a lab test can never see. | | fastmon | Lighthouse | Lab audits (Lighthouse) | Yes | Yes | Real-user field data (RUM) | Yes | No | Measures your visitors' real devices | Yes | No | Core Web Vitals at the p75 from real visitors | Yes | No | INP (a field-only metric) | Yes | No | JavaScript errors from production | Yes | No | Server-Timing and network from real visits | Yes | Single load only | Segments by country, device and page | Yes | No | Scheduled, continuous monitoring | Yes | Manual or CI | Alerts and release tracking | Yes | No | Dashboard with history | Yes | One-off report | Price | from €29/mo | Free Lighthouse is free and open-source, and fastmon uses it for its Synthetic Monitoring. This comparison is about lab-only versus lab-plus-field. As of 14 July 2026: list prices / typical configuration; individual terms may differ. What the field adds ## The three things a lab cannot show you. Everything below only exists once real visitors load your page. ### The experience, not a simulation Real devices, real networks, aggregated at the p75, so you see what visitors actually get, not one idealized run. ### INP and real errors Interaction to Next Paint and JavaScript errors only exist in the field. Lighthouse cannot measure them at all. ### Continuous, with alerts fastmon watches every visit and alerts on regressions, instead of a score you have to remember to run by hand. Fair play ## Where Lighthouse alone is enough. If you only need a quick lab score in CI and never look at real-user data, Lighthouse on its own is free and excellent. fastmon is for teams who also want to know, continuously, what their real visitors experience. FAQ ## fastmon and Lighthouse. The questions people ask before they switch. ### Does fastmon replace Lighthouse? No, it includes it. fastmon runs scheduled Lighthouse audits for desktop and mobile as Synthetic Monitoring, and adds Real User Monitoring on top. You get the lab and the field in one tool. ### Why is field data better than a Lighthouse score? It is not better, it is different, and you want both. Lighthouse is a clean, reproducible lab signal. Field data is the messy truth of real devices and networks at the p75, including INP and errors a lab cannot see. ## Honestly compared, built in the EU. The web-performance job without a US cloud: read-only by default, no cookies*, no long-lived identifiers, from €29 a month. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/contact/sales/ Sales # Let's talk Enterprise. Custom pageview volume, long retention and a contract to match, on the same EU-hosted platform. Tell us your traffic and what you want to watch, and we'll put a number in front of you. - EU-hosted - Signed DPA - GDPR compliant - Hosted in Germany ## What Enterprise includes - Custom pageview volume and retention windows - Priority support with a named contact - Guided onboarding and dashboard setup - Debugging and optimization with fastmon experts - Signed DPA and security review ## Talk to sales No form, no chatbot. Your message lands directly with the founding team. Email our sales team Answered directly by the founders Kamil & Lucas Helpful in your first message: your monthly pageviews, what you want to monitor, and any compliance needs. See all plans General enquiry ## How it works 01 ### Your enquiry Send us a short note with your traffic and what you want to watch. 02 ### Needs assessment We assess volume, retention and compliance requirements together with you. 03 ### Personal offer You receive a tailored plan and a personal offer, sized to your scale. --- ## https://fastmon.eu/en/features/ai/ fastmon AI New # fastmon AI. Your data, in plain language. fastmon AI works on the monitoring data you already have. It turns a Lighthouse report into a short written summary and lets you ask follow-up questions about a specific test, or drill into a single error. It is not a general chatbot, and it only reads your own monitoring data. What is fastmon AI? ## Not a chatbot. An assistant for your data. fastmon AI is not a general-purpose assistant that answers anything. It sits on the monitoring data you already collect and does a few things well: it explains a synthetic test in plain language, and it helps you make sense of an error. Nothing more, and that is deliberate. A Lighthouse report is dense. One click turns it into a short written summary, in English or German, so you get the gist without reading every audit. Want to go deeper? Ask about this test opens an assistant with the run in context, and you ask follow-up questions about the specific audits that matter. In the dashboard, the 'Ask about this test' error drill-down does the same for a single error: a summary and a time-series, so you see what broke and when, without building a query by hand. Every AI feature is optional and gated by your organization's AI setting, so you decide whether to use it at all. What it does ## Three things, done well. No magic box. Three concrete features that sit on top of your Lighthouse and error data. ### One-click summary Turns a Lighthouse report into a short written summary, in English or German. Generated once, then stored and reused, so reading it again is free. ### Ask about this test Opens the fastmon AI assistant with the run in context, so you can ask follow-up questions about the specific audits that matter to you. ### 'Ask about this test' error drill-down In the dashboard, drill into a single error: the assistant returns a summary and a time-series, so you see what broke and how it trended. Honestly ## What it does, and what it does not. We would rather be narrow and honest than promise a magic box. Here is exactly where fastmon AI helps, and where it does not. What fastmon AI does - Summarize a Lighthouse report in plain English or German - Answer follow-up questions about a specific synthetic test - Drill into a single error with a summary and a time-series - Stay optional, gated by your organization's AI setting What it is not - Not a general-purpose chatbot: it stays on your fastmon data - Not an ask-anything box: every answer is scoped to a test or an error - Not a new data source: it explains data fastmon already collects - Not unlimited: generating summaries is capped at 30 per organization per hour New and still evolving. Availability is controlled per organization. FAQ ## fastmon AI, answered. The questions people ask about the AI features. ### Is fastmon AI a general-purpose chatbot? No. It only works on your fastmon monitoring data. Every answer is scoped to a specific synthetic test or a specific error; there is no ask-anything mode. ### What does the one-click summary do? It turns a Lighthouse report from a synthetic test into a short written summary, in English or German. The summary is generated once, then stored and reused, so reading it again is free. Generating new summaries is limited to 30 per organization per hour. ### What is the 'Ask about this test' error drill-down? In the dashboard you can drill into a single error, and the assistant returns a summary and a time-series, so you see what broke and how it trended, without writing a query by hand. ### Do I have to use the AI features? No. Every AI feature is optional and gated by your organization's AI setting. If it is switched off, the rest of fastmon works exactly as before. ### Which AI model do you use? We focus on what the assistant does rather than which model powers it, since that may change over time. What stays fixed is the scope: plain-language summaries and follow-up questions on your own test and error data, and it stays optional per organization. ## AI that keeps your data in Europe. Summaries and answers about your tests, read-only by default: no cookies*, no long-lived identifiers. In the EU. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/features/analytics/ Web Analytics Beta # Web Analytics. Traffic and performance, one tool. fastmon Analytics is the exploration layer on the same beacons that measure your Web Vitals. Who is on the site, where they came from, which pages get viewed, which errors fire. No cookies*, country only, hosted in the EU. What is fastmon Analytics? ## The same data, a different question. Analytics is the exploration layer on top of everything your beacons already collect. The Web Vitals dashboard asks how fast the site is; Analytics asks what is happening on it. Same data, different question, one script tag. So your traffic and your performance live in one place. You do not bolt a second tool onto the page and you do not reconcile two dashboards at the end of the month. Who visited, and how fast it was for them, sit side by side. And it counts the way the rest of fastmon works: no cookies* in the default mode, the country derived from the IP at the edge, the IP itself gone before any code sees it. Analytics is in beta, so layout and metrics may still change, but the privacy model does not. Live and headline metrics ## Who is on the site, and how many. Three headline metrics, Unique Visitors, Pageviews and Views per Visit, each with its trend against the previous period. Plus the visitors in the last five minutes, expandable to a per-minute chart. Break any of it down by source, page, location or device. See it in the docs Live · now Demo Live · last 5 min Unique Visitors 1,284 Pageviews 3,902 Sources Demo Source / Medium Visits - google / cpc gclid 412 - facebook / paid 233 - (direct) 301 - newsletter / email 188 Breakdowns ## Four ways to read your traffic. Every metric drills down through four breakdown panels, each with its own sub-tabs. ### Sources Channel vs UTM source: where traffic comes from, from direct visits to individual paid campaigns. ### Pages Which pages get viewed, with a most-viewed, best and worst toggle so slow pages surface next to popular ones. ### Locations By country, 2-letter ISO, derived at the edge from the IP. No city, no region, no raw IP stored. ### Devices Browser vs OS, device type, connection and viewport, all as buckets rather than exact fingerprints. Campaign attribution ## Full UTM coverage, the click value stays out. fastmon reads the campaign tags on your own outbound URLs: the full UTM set, plus which ad platform sent the click. The click-ID value itself is intentionally discarded, so paid traffic ties back to the campaign, never to the individual. - utm_source, utm_medium, utm_campaign, utm_term and utm_content, each capped at 64 characters - The click-ID label (for example gclid) is detected; the click-ID value itself is dropped - Break traffic down by source, medium and campaign - No cross-site tracking and no per-person profiles anywhere in it Read the Analytics docs From your campaign URL # read from your own outbound campaign URL utm_source = "google" utm_medium = "cpc" utm_campaign = "spring_sale" click_id_param = "gclid" # the label only, capped 64 chars # the click-ID value (Cj0KCQ...) is discarded fastmon vs GA4 ## Why teams switch from GA4. A privacy-first analytics tool from the EU, sitting right next to the performance data GA4 never had. | | fastmon | Google Analytics 4 | No cookies* in the default mode | Yes | No | Hosted in the EU, no US jurisdiction | Yes | No | Core Web Vitals in the same tool traffic and performance together | Yes | Partial | Unsampled data | Yes | Partial | Raw data retention | 90 days default, up to 13 months (Enterprise) | 14 months (standard) GA4 behavior depends on configuration; the comparison reflects typical defaults. fastmon Analytics is in beta. As of 14 July 2026: list prices / typical configuration; individual terms may differ. FAQ ## Web Analytics, answered. The questions people ask before they switch. ### Is fastmon Analytics a replacement for Google Analytics? For most sites, yes: it covers visitors, sources, pages, locations, devices and campaigns, next to your performance data. What it deliberately does not do is funnels as a report, conversion goals, custom events, A/B testing or session replay. It is also in beta, so layout and metrics may still change. ### Do you count visitors without cookies? Yes. fastmon sets no cookies* in the default mode. Unique visitors are counted from a short pseudonymous signal computed at the edge (an HMAC with a salt that rotates every 24 hours and never leaves edge memory), scoped per domain and bounded to about 24 hours. More detail on the EU and privacy page. ### Which metrics do I get? Three headline metrics, Unique Visitors, Pageviews and Views per Visit, each with its trend; current visitors in the last five minutes; visitor-level metrics like visit duration, pages per visit and error count; and error rate over time. Breakdowns cover Sources, Pages, Locations and Devices. ### Do you track gclid and fbclid? fastmon captures the UTM tags on your outbound URLs and detects which ad platform sent a click (the click-ID label, for example gclid). The click-ID value itself is discarded, so you get campaign attribution without storing a per-person identifier. fbclid is not a value we retain. ### Can I see performance and traffic together? Yes, that is the point. Analytics and Web Vitals run on the same beacons and the same query API. The Explorer even ships presets that mix traffic and performance, from Core Web Vitals to errors and backend timing. ### Where is the data stored? Exclusively in the EU, on infrastructure operated in Germany, with no US-owned sub-processor in the data path. No cookies*, country only, and a 90-day default retention that you can configure per site. More on the EU and privacy page. ## Analytics without cookies*, without long-term profiles. Traffic and campaigns without tracking: read-only by default, no cookies*, no long-lived identifiers. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/features/rum/ Real User Monitoring # Real User Monitoring. Real users, real numbers. fastmon measures web performance right in your visitors' browsers: real devices, real networks, the Core Web Vitals Google ranks you by. No lab, no guesswork, no 28-day averages. What is RUM? ## The performance your visitors actually get. Real User Monitoring (RUM) measures how your website performs in the browsers of your real visitors, on their own devices and networks, as they experience it. A small script reads the browser's native Performance APIs on every page load and reports the timings back. This is field data, the opposite of a lab test on one fast machine in an office. That difference is the point. A synthetic tool tells you how fast one simulated device loaded your page under ideal conditions. RUM tells you how fast it was for the visitor on a three-year-old Android on mobile data. It is the truth, noisy and slower, aggregated at the 75th percentile so you see the experience of the users who suffer, not a flattering average. It is also not web analytics. Analytics counts visits and sources. RUM measures the performance of each visit: the Core Web Vitals Google ranks you by, JavaScript errors, and where the time actually goes. fastmon gives you all of it from one script, without cookies*, hosted entirely in the EU. Why RUM ## See what a lab test never shows you. Three things field data does that synthetic checks and analytics cannot. ### See what real users experience Every real page load reports its Core Web Vitals, so you see the performance your visitors actually get, segmented by device, network and country, not a single average. ### Fix the right thing p75 percentiles, LCP subparts, request waterfalls and error fingerprints point you at the pages and causes that matter, instead of chasing a lab score. ### Get alerted before users complain Threshold and regression rules on the vitals, routed to email, Slack, Discord or a webhook, with release markers so you know which deploy caused it. Core Web Vitals ## The three metrics Google ranks you by. fastmon reports LCP, INP and CLS from real visits, aggregated at the p75 against Google's own thresholds. Green means 75% of your visitors were at least this fast. LCP ### How fast does the main content appear? Largest Contentful Paint is the moment the biggest visible element (a hero image, video poster or headline) has rendered. fastmon breaks it into its four subparts, from TTFB to element render delay, so you see where the wait is. Good ≤ 2.5 s Needs work ≤ 4.0 s Poor > 4.0 s INP ### Does the page respond instantly to taps and clicks? Interaction to Next Paint is the worst-case delay between an interaction and the next frame. It replaced FID as a Core Web Vital in March 2024. Long Animation Frames (over 50 ms) point at the script that blocked the response. Good ≤ 200 ms Needs work ≤ 500 ms Poor > 500 ms CLS ### Does the layout jump around while loading? Cumulative Layout Shift scores how much visible content moves unexpectedly. fastmon reports the worst shift window per visit, so a late-loading banner that pushes your content down does not hide in the average. Good ≤ 0.1 Needs work ≤ 0.25 Poor > 0.25 ### One number for the meeting: the Experience Score. fastmon condenses the vitals plus error rate and load time into a single Experience Score from 0 to 10, graded A+ to F. Seven weighted signals: LCP 25%, INP, FCP and error rate 15% each, page load time, CLS and TTFB 10% each. Each is mapped to a sub-score by linear interpolation against its good and bad threshold. Network timing · p75 982 ms GET / app.4f2.js main.a1c.css api/cart 0 0.5 s 1 s DNS TCP TTFB Transfer TypeError Error rate 0.4% Cannot read properties of undefined (reading 'map') 3 visitors affected · first seen 2 h ago · checkout.js:42 Errors & network ## Where the time goes, and what breaks. Slow is one problem, broken is another. fastmon reports both from the same real visits, down to the backend phase and the exact error fingerprint. - JavaScript errors grouped by fingerprint (type, message, stack shape), with occurrence count, affected visitors and first and last seen - Error rate over time: the share of pageviews with at least one error, excluding errors from ad-blocked trackers and teardown noise - Navigation and resource timing, plus fetch and XHR calls at the p75 and p95 with a request waterfall - Server-Timing breakdown into seven phases across the request path (edge, origin, backend, database, render, cache, external) - Cache monitoring across browser, CDN and origin layers, including the bfcache hit rate Read the Analytics docs Geo · demo by country Germany 90 % · 1,3M Segments ## Slice it by country, device and page. An average hides the visitors who suffer. fastmon lets you break every metric down until you find the segment that is actually slow. - Geography by country, derived from the IP at the edge (the raw IP never reaches the backend) - Device type, browser, OS, viewport and connection type - Per-page and per-template, so you see which routes are slow - Visitor Explorer: individual visits with duration, device and per-page Web Vitals and errors - Single-page apps: client-side route changes are tracked as soft navigations More on Web Analytics Built for production ## Alerts, releases and an API. RUM is only useful if it fits your workflow. fastmon plugs into the tools you already run. ### Alerts that route themselves Rules on LCP, INP, CLS, FCP, TTFB, error rate, pageviews or visitors, absolute or percentage-change, sent to email, Slack, Discord or a webhook. ### Release tracking Tag a deploy with one API call from GitHub Actions, GitLab or Vercel. fastmon compares the vitals before and after at the p75. ### REST API with OpenAPI Query every metric through the Analytics API, with Bearer-token auth, offset and cursor pagination and an OpenAPI schema. Privacy ## Designed inside the GDPR. Not retrofitted to it. That is the difference between a monitoring tool from the EU and one with an EU region. Here is the data sheet: the honest version, footnote included. * In Minimal and Standard mode fastmon sets no cookie and stores nothing on the device; what it reads are status values the browser generates at runtime. Full mode writes an identifier, and there consent under § 25 TDDDG is required. Assessing this is the responsibility of the respective website operator embedding fastmon. Data sheet Cookies 0* strictly storage-free: no localStorage, no sessionStorage IP address removed at the edge before any application code ever sees it Location country only two-letter ISO code, nothing more Data path 100% EU no Cloudflare, no AWS, no GCP Retention 90 days default, configurable per website Fingerprinting none no canvas, no font enumeration More on EU & privacy Where it fits ## RUM, Synthetic and Analytics. Three different jobs. fastmon does all three from one script, but they answer different questions. Real User Monitoring This page The performance real visitors get, from the field, at the p75. Answers: how fast is my site, really, and for whom? Synthetic Monitoring Complementary Scheduled lab tests on a simulated device under ideal conditions. Reproducible, great for catching regressions before a deploy. Web Analytics Same tool Who visits, from where, through which campaign. Measures traffic, not performance. In fastmon it sits right next to the vitals. Setup ## Live in about five minutes. One script tag in the head, no build step, no configuration. Works with any stack, from static HTML to Next.js, WordPress and Shopware. index.html 1 < script defer src = "https://fastmon.site/s/{source_hash}.js" > 01 ### Add the tag Vanilla JS, ~40 KB compressed, loads with defer. 02 ### Verify with a 204 The collector answers 204 No Content. One look at the network tab. 03 ### Watch data arrive Your first visitors show up in the dashboard about a minute later. Installation guide in the docs FAQ ## Real User Monitoring, answered. The questions people ask before they add the tag. ### What is the difference between RUM and synthetic monitoring? RUM is passive: it measures real visits in real browsers, so it captures the actual experience across every device and network, aggregated at the p75. Synthetic monitoring is active: it runs scheduled tests on a simulated device under ideal, reproducible conditions. They complement each other, and fastmon does both from the same script. ### Is RUM just another analytics tool? No. Analytics counts visits, sources and campaigns. RUM measures the performance of each visit: Core Web Vitals, JavaScript errors and network timing. fastmon shows both side by side, but the RUM data is about speed and stability, not traffic. ### Which metrics does fastmon measure? The three Core Web Vitals (LCP, INP, CLS) at the p75 against Google's thresholds, plus the diagnostics FCP, TTFB and page load time, JavaScript errors, and network timing including Server-Timing phases. Everything condenses into one Experience Score from 0 to 10. ### Do I need a cookie banner for RUM? No, not in Minimal and Standard mode. Nothing is stored on the device, and the values that get read were not there beforehand: they come into being at the moment of the page view. Naming fastmon in your privacy policy is enough. In Full mode you do need consent, because an identifier is written into sessionStorage. This classification has been reviewed with our external data protection officer; a residual risk remains, because no court has ruled on this constellation. The full derivation, with the statutory text and the opposing reading ### Where is the data stored? Entirely in the EU, on infrastructure run in Germany. No Cloudflare, no AWS, no GCP, no US sub-processor anywhere in the data path. Data is retained for 90 days by default, configurable per website. ### How fast is the setup and will it slow my site down? About five minutes: one script tag with defer, no build step. The script is vanilla JS, around 40 KB compressed, and reads the browser's native Performance APIs. Data goes out through navigator.sendBeacon on a deliberately lean wire format, batched across the page lifecycle. ## See what your visitors actually experience. Core Web Vitals from real devices, read-only by default: no cookies*, no long-lived identifiers. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/features/synthetic/ Synthetic Monitoring # Synthetic Monitoring. The lab beside the field. Scheduled Lighthouse audits on a simulated device, plus lightweight TTFB checks, under ideal and reproducible conditions, right next to the field data from your real visitors. Catch regressions before they ship. What is Synthetic Monitoring? ## A controlled run, on a schedule. Synthetic Monitoring runs your page through a test lab on a fixed schedule: a simulated device, one location, ideal conditions, fully reproducible. Because the conditions never change, a synthetic run is the clean signal that tells you a regression shipped, before your real users feel it. It is the counterpart to Real User Monitoring, not a replacement. RUM is the truth from the field, noisy but real. Synthetic is the controlled baseline, reproducible but blind to real conditions. fastmon runs both from the same setup, so you read the lab and reality side by side. Synthetic Monitoring is currently in beta. The measuring itself happens outside fastmon: every run is executed by Commerce-Score, the performance analyzer of ScaleCommerce GmbH, the company behind fastmon. That is why it is opt-in, and why only the page URLs you monitor ever leave the platform. Powered by ### Commerce-Score Every synthetic run in fastmon is measured by Commerce-Score, the open-source performance analyzer built by ScaleCommerce GmbH. It scores 20+ metrics per page on mobile and desktop, from Core Web Vitals and TTFB to third-party weight and the Lighthouse categories. fastmon schedules the runs, keeps the results and puts them next to the field data from your real visitors. - Off by default: the organization owner switches external measurements on. - Only the page URLs you monitor are sent, never visitor data. - Open source, built by ScaleCommerce GmbH in Germany, the company behind fastmon. Visit commerce-score.io Two test types Beta ## Lighthouse and TTFB, on a schedule. Every monitored page runs two kinds of test, automatically. Lighthouse · every 24 h ### Full Lighthouse audit - One full run every 24 hours, desktop and mobile in a single pass - Four categories: Performance, Accessibility, Best Practices, SEO - Lab metrics: LCP, FCP, CLS, TBT, Speed Index, TTFB - Cache bypass is on by default, so you measure the uncached worst case TTFB · every 5 min ### Lightweight server check - A server-response check about every 5 minutes - Split into DNS, TCP, SSL, server and transfer phases - Catches backend slowdowns between full audits - Runs on the same schedule, no extra setup Read the Synthetic docs The audit ## Four categories, one run. Each Lighthouse audit scores your page on the same four categories Google uses, on both desktop and mobile. ### Performance The lab metrics behind the score: LCP, FCP, CLS, TBT and Speed Index on a controlled device. ### Accessibility Automated checks for contrast, labels, roles and the structure assistive tech relies on. ### Best Practices Modern-web checks: HTTPS, correct image sizing, console errors and safe defaults. ### SEO The technical basics search engines expect: meta tags, crawlability and valid markup. Plans ## How many pages you can watch. Manual pages you add yourself, plus auto pages picked from your top RUM traffic. One-shot ad-hoc tests are always unlimited. | Plan | Manual pages | Auto pages | Beta | 5 | 5 | Light | 2 | 3 | Standard | 5 | 10 | Enterprise | 25 | 50 One-shot tests run on demand without a schedule and are deliberately unlimited. Limits during the beta; plan mapping may still change. Lab and field ## Two views, one truth. Neither view is the whole picture. The lab is reproducible but blind to real conditions; the field is real but noisy. fastmon shows both, so a regression in the lab and its impact in the field line up. Lab · Synthetic - Simulated device, one location, ideal conditions - Reproducible, perfect for catching regressions - Runs on a schedule, before and after a deploy Field · RUM - All real visitors, real networks, real devices - Aggregated at the p75, the truth about the experience - Includes INP, which the lab cannot measure More on Real User Monitoring FAQ ## Synthetic Monitoring, answered. The questions before you schedule your first test. ### How often does a test run? A full Lighthouse audit runs once every 24 hours, measuring desktop and mobile in a single pass. A lighter TTFB check runs about every 5 minutes to catch backend slowdowns in between. You can also fire a one-shot test on demand. ### How does it differ from Real User Monitoring? Synthetic is a controlled lab test on a simulated device under ideal conditions, reproducible and great for catching regressions. RUM measures your real visitors in the field at the p75. They complement each other, and fastmon runs both. Note that INP is a field-only metric, so it comes from RUM, not the lab. ### Which Lighthouse categories are measured? All four: Performance, Accessibility, Best Practices and SEO, on both desktop and mobile in the same run. Cache bypass is on by default so you always measure the uncached worst case. ### How many pages can I monitor? It depends on your plan. Light watches 2 manual plus 3 auto pages, Standard 5 plus 10, up to Enterprise at 25 plus 50. Auto pages are picked from your top RUM traffic. One-shot ad-hoc tests are always unlimited. ### Who actually runs the synthetic tests? Commerce-Score, the open-source performance analyzer of ScaleCommerce GmbH, the company behind fastmon. Because it is an external service it acts as a sub-processor, which is why Synthetic Monitoring stays off until the organization owner enables external measurements. From then on only the page URLs you monitor are sent there; visitor data never leaves fastmon. You can try the analyzer yourself at commerce-score.io. ## Catch regressions before they ship. Scheduled Lighthouse audits, read-only by default: no cookies*, no long-lived identifiers. Hosted in Germany. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/alerting/ Methods # Alerting Notification rules that tell you when a metric breaches a threshold or degrades, before customers complain. Dashboards only help when someone is looking. Alerting watches the numbers for you and fires when a Core Web Vital, error rate or Experience Score crosses a line you set, or trends the wrong way. Good alerting is specific enough to be trusted: scoped to the pages and metrics that matter, so a page that turns critical reaches the right people instead of getting lost. Related terms - RUM Real User Monitoring Measuring performance from the browsers of your actual visitors, on their real devices and networks. - Synthetic Monitoring Scheduled, repeatable tests that load a page in a controlled environment on a fixed interval. - Lab data vs field data Lab data comes from a controlled test; field data comes from real visitors. Both matter, for different reasons. - Lighthouse Google's open-source tool that audits a page in a lab run and scores performance, accessibility, SEO and more. - CrUX Chrome UX Report Google's public dataset of real-world Core Web Vitals, aggregated from opted-in Chrome users. - p75 Percentile (p75) The value below which a given share of visits fall. p75 means 75 percent were at least this fast. - Web Vitals Attribution The extra diagnostic data that explains why a metric was slow, not just how slow it was. - Web Analytics Traffic and behaviour measurement: page views, visitors, referrers and journeys, alongside performance. - Error Tracking Capturing JavaScript errors and failed requests from real sessions, grouped so you see the real problems. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/beacon/ Building blocks # Beacon The small data packet the tracker sends to fastmon with a visit's measurements. When a page finishes measuring, the tracker packs the metrics, timings and any errors into a compact payload and sends it, typically via the Beacon API, so delivery does not block or slow the page. You can inspect exactly what a beacon contains with the fastmon Beacon Inspector browser extension, which is part of how fastmon keeps what it collects transparent. Related terms - Tracker The lightweight script you embed once; it measures Core Web Vitals and errors directly in the browser. - Stitch fastmon's short-lived, edge-derived identifier that groups a visit without cookies or cross-site tracking. - Session One continuous visit: the sequence of page views and interactions a visitor makes before going idle. - Pageview A single page load or, in a single-page app, a route change counted as its own view. - Collection modes Presets (Light, Standard, Full) that decide how much detail the tracker collects. - Server-Timing An HTTP header your backend can send to break down where server time was spent, visible in RUM. - Cache-Status Whether a response came from a CDN edge, the origin server or the browser cache. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/cache-status/ Building blocks # Cache-Status Whether a response came from a CDN edge, the origin server or the browser cache. The same URL can be fast or slow depending on where it was served from. Recording cache status per request shows your real hit rate and surfaces resources that keep missing the cache and hitting the origin. It turns caching from a hopeful configuration into something you can actually verify against real traffic. Related terms - Beacon The small data packet the tracker sends to fastmon with a visit's measurements. - Tracker The lightweight script you embed once; it measures Core Web Vitals and errors directly in the browser. - Stitch fastmon's short-lived, edge-derived identifier that groups a visit without cookies or cross-site tracking. - Session One continuous visit: the sequence of page views and interactions a visitor makes before going idle. - Pageview A single page load or, in a single-page app, a route change counted as its own view. - Collection modes Presets (Light, Standard, Full) that decide how much detail the tracker collects. - Server-Timing An HTTP header your backend can send to break down where server time was spent, visible in RUM. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/cls/ Metrics CLS # Cumulative Layout Shift A unitless score for how much visible content unexpectedly moves around while the page loads and runs. Good <= 0.1 Needs work 0.1 to 0.25 Poor > 0.25 Field data (75th percentile) CLS is the visual stability Core Web Vital. Every time an element shifts without a user action, the browser scores it by how much of the viewport moved and how far. CLS sums the worst burst of those shifts during the visit. It is the metric behind the familiar frustration of tapping a button that jumps the instant a late banner or image loads. Unlike the time-based vitals it has no unit: lower is better, and 0 means nothing moved. What moves it - Images and embeds without width and height (or an aspect ratio). - Ads, banners and iframes injected above existing content. - Web fonts that reflow text when they swap in. - Content inserted dynamically without reserved space. Learn more Related terms - CWV Core Web Vitals Google's set of three field metrics for loading (LCP), interactivity (INP) and visual stability (CLS) of a page. - LCP Largest Contentful Paint The time until the largest visible element in the viewport (image, video or text block) has rendered. - INP Interaction to Next Paint How long the page takes to visually respond after a user interacts, measured across the whole visit. - FCP First Contentful Paint The moment the browser renders the first piece of content: text, an image or a canvas. - TTFB Time to First Byte The time from the start of navigation until the browser receives the first byte of the response. - FID First Input Delay (retired) The delay between a visitor's first interaction and the browser starting to process it. Replaced by INP. - TBT Total Blocking Time The total time the main thread was blocked by long tasks between first paint and interactivity, measured in the lab. - SI Speed Index A lab metric for how quickly the visible parts of a page fill in during load, based on video capture. - TTI Time to Interactive (legacy) A lab metric for when a page has rendered and can reliably respond to input quickly. - Page Load The classic load event: everything on the initial page, including images and subresources, has finished loading. - Route Load The loading time of an in-app navigation in a single-page app, where no full page reload happens. - Long Tasks & LoAF Any piece of JavaScript that occupies the main thread for more than 50 ms, blocking the page from responding. - Experience Score A single 0 to 10 number fastmon derives from LCP, INP, CLS, FCP, TTFB, load time and error rate. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/collection-modes/ Building blocks # Collection modes Presets (Light, Standard, Full) that decide how much detail the tracker collects. Not every site needs the same depth. Light keeps data to the essentials, Standard is the balanced default, and Full unlocks the richest diagnostics like detailed attribution and resource timing. The mode is a deliberate lever over the privacy and data trade-off, chosen by you rather than assumed, and it maps directly to what a visitor's device is asked for. Related terms - Beacon The small data packet the tracker sends to fastmon with a visit's measurements. - Tracker The lightweight script you embed once; it measures Core Web Vitals and errors directly in the browser. - Stitch fastmon's short-lived, edge-derived identifier that groups a visit without cookies or cross-site tracking. - Session One continuous visit: the sequence of page views and interactions a visitor makes before going idle. - Pageview A single page load or, in a single-page app, a route change counted as its own view. - Server-Timing An HTTP header your backend can send to break down where server time was spent, visible in RUM. - Cache-Status Whether a response came from a CDN edge, the origin server or the browser cache. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/cookieless/ Privacy & EU # Cookieless Measuring without storing anything on the visitor's device: no cookies, no localStorage. Classic analytics writes a cookie to recognise returning visitors, which triggers consent requirements and can be blocked or cleared. fastmon is cookieless by default: in read-only mode it stores nothing on the device at all. Cookieless is not the same as consent-free. Reading browser performance APIs can still fall under consent rules, but by storing nothing fastmon removes an entire class of privacy and accuracy problems that cookie-based tools carry. Learn more Related terms - Edge IP processing The visitor's IP address is reduced to a country code at the edge and discarded before any app code sees it. - GDPR GDPR The EU General Data Protection Regulation, the legal baseline for handling personal data in Europe. - TDDDG (Section 25) The German law implementing the ePrivacy rule that reading from or writing to a device needs consent. - Data residency Where your data physically lives and under whose jurisdiction it falls. For fastmon: Germany, end to end. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/core-web-vitals/ Metrics CWV # Core Web Vitals Google's set of three field metrics for loading (LCP), interactivity (INP) and visual stability (CLS) of a page. Core Web Vitals are the subset of web performance signals Google treats as essential for user experience and feeds into ranking. Each one captures a different moment: how fast the main content appears, how quickly the page responds to input, and how much the layout jumps around. A page is considered to pass only when all three are in the good range at the 75th percentile of real visits. Lab tools can estimate them, but the official assessment always uses field data from real users. Learn more Related terms - LCP Largest Contentful Paint The time until the largest visible element in the viewport (image, video or text block) has rendered. - INP Interaction to Next Paint How long the page takes to visually respond after a user interacts, measured across the whole visit. - CLS Cumulative Layout Shift A unitless score for how much visible content unexpectedly moves around while the page loads and runs. - FCP First Contentful Paint The moment the browser renders the first piece of content: text, an image or a canvas. - TTFB Time to First Byte The time from the start of navigation until the browser receives the first byte of the response. - FID First Input Delay (retired) The delay between a visitor's first interaction and the browser starting to process it. Replaced by INP. - TBT Total Blocking Time The total time the main thread was blocked by long tasks between first paint and interactivity, measured in the lab. - SI Speed Index A lab metric for how quickly the visible parts of a page fill in during load, based on video capture. - TTI Time to Interactive (legacy) A lab metric for when a page has rendered and can reliably respond to input quickly. - Page Load The classic load event: everything on the initial page, including images and subresources, has finished loading. - Route Load The loading time of an in-app navigation in a single-page app, where no full page reload happens. - Long Tasks & LoAF Any piece of JavaScript that occupies the main thread for more than 50 ms, blocking the page from responding. - Experience Score A single 0 to 10 number fastmon derives from LCP, INP, CLS, FCP, TTFB, load time and error rate. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/crux/ Methods CrUX # Chrome UX Report Google's public dataset of real-world Core Web Vitals, aggregated from opted-in Chrome users. CrUX is the field data source behind Google Search's Core Web Vitals assessment and the field section of PageSpeed Insights. It reports the 75th percentile per metric, aggregated monthly across eligible Chrome traffic. It is invaluable but coarse: monthly, origin- or page-group level, Chrome only, and only for pages with enough traffic. Your own RUM fills those gaps with per-page, real-time, all-browser data. Related terms - RUM Real User Monitoring Measuring performance from the browsers of your actual visitors, on their real devices and networks. - Synthetic Monitoring Scheduled, repeatable tests that load a page in a controlled environment on a fixed interval. - Lab data vs field data Lab data comes from a controlled test; field data comes from real visitors. Both matter, for different reasons. - Lighthouse Google's open-source tool that audits a page in a lab run and scores performance, accessibility, SEO and more. - p75 Percentile (p75) The value below which a given share of visits fall. p75 means 75 percent were at least this fast. - Web Vitals Attribution The extra diagnostic data that explains why a metric was slow, not just how slow it was. - Web Analytics Traffic and behaviour measurement: page views, visitors, referrers and journeys, alongside performance. - Error Tracking Capturing JavaScript errors and failed requests from real sessions, grouped so you see the real problems. - Alerting Notification rules that tell you when a metric breaches a threshold or degrades, before customers complain. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/data-residency/ Privacy & EU # Data residency Where your data physically lives and under whose jurisdiction it falls. For fastmon: Germany, end to end. Data residency matters because location decides which laws apply. Data held by US providers can be reachable under regimes like the CLOUD Act even when the servers sit in Europe. fastmon is hosted 100 percent in Germany on Hetzner, with no US provider in the data path, so your monitoring data stays under EU jurisdiction from collection to storage. Learn more Related terms - Cookieless Measuring without storing anything on the visitor's device: no cookies, no localStorage. - Edge IP processing The visitor's IP address is reduced to a country code at the edge and discarded before any app code sees it. - GDPR GDPR The EU General Data Protection Regulation, the legal baseline for handling personal data in Europe. - TDDDG (Section 25) The German law implementing the ePrivacy rule that reading from or writing to a device needs consent. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/edge-ip/ Privacy & EU # Edge IP processing The visitor's IP address is reduced to a country code at the edge and discarded before any app code sees it. An IP address is personal data. Instead of logging it and anonymising later, fastmon derives only a coarse country code at the edge server and drops the raw IP immediately, so it never reaches storage or application logic. This is data minimisation by design: you still get geographic breakdowns, but there is no raw IP to leak, subpoena or misuse because it was never kept. Learn more Related terms - Cookieless Measuring without storing anything on the visitor's device: no cookies, no localStorage. - GDPR GDPR The EU General Data Protection Regulation, the legal baseline for handling personal data in Europe. - TDDDG (Section 25) The German law implementing the ePrivacy rule that reading from or writing to a device needs consent. - Data residency Where your data physically lives and under whose jurisdiction it falls. For fastmon: Germany, end to end. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/error-tracking/ Methods # Error Tracking Capturing JavaScript errors and failed requests from real sessions, grouped so you see the real problems. A page can score perfect vitals and still be broken for a segment of users because a script throws. Error tracking records those failures from the browser, with enough context (page, browser, sequence) to reproduce them. Similar errors are collapsed into one fingerprint, so a thousand occurrences of the same bug show up as a single ranked issue instead of noise. Related terms - RUM Real User Monitoring Measuring performance from the browsers of your actual visitors, on their real devices and networks. - Synthetic Monitoring Scheduled, repeatable tests that load a page in a controlled environment on a fixed interval. - Lab data vs field data Lab data comes from a controlled test; field data comes from real visitors. Both matter, for different reasons. - Lighthouse Google's open-source tool that audits a page in a lab run and scores performance, accessibility, SEO and more. - CrUX Chrome UX Report Google's public dataset of real-world Core Web Vitals, aggregated from opted-in Chrome users. - p75 Percentile (p75) The value below which a given share of visits fall. p75 means 75 percent were at least this fast. - Web Vitals Attribution The extra diagnostic data that explains why a metric was slow, not just how slow it was. - Web Analytics Traffic and behaviour measurement: page views, visitors, referrers and journeys, alongside performance. - Alerting Notification rules that tell you when a metric breaches a threshold or degrades, before customers complain. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/experience-score/ Metrics # Experience Score A single 0 to 10 number fastmon derives from LCP, INP, CLS, FCP, TTFB, load time and error rate. Individual metrics are precise but hard to track at a glance across many pages. The Experience Score rolls them into one figure so a team can see the health of a page, a segment or a whole site at once, then drill down when it drops. It never replaces the underlying vitals: it points you at where to look, and the metric cards tell you why. Read the docs Related terms - CWV Core Web Vitals Google's set of three field metrics for loading (LCP), interactivity (INP) and visual stability (CLS) of a page. - LCP Largest Contentful Paint The time until the largest visible element in the viewport (image, video or text block) has rendered. - INP Interaction to Next Paint How long the page takes to visually respond after a user interacts, measured across the whole visit. - CLS Cumulative Layout Shift A unitless score for how much visible content unexpectedly moves around while the page loads and runs. - FCP First Contentful Paint The moment the browser renders the first piece of content: text, an image or a canvas. - TTFB Time to First Byte The time from the start of navigation until the browser receives the first byte of the response. - FID First Input Delay (retired) The delay between a visitor's first interaction and the browser starting to process it. Replaced by INP. - TBT Total Blocking Time The total time the main thread was blocked by long tasks between first paint and interactivity, measured in the lab. - SI Speed Index A lab metric for how quickly the visible parts of a page fill in during load, based on video capture. - TTI Time to Interactive (legacy) A lab metric for when a page has rendered and can reliably respond to input quickly. - Page Load The classic load event: everything on the initial page, including images and subresources, has finished loading. - Route Load The loading time of an in-app navigation in a single-page app, where no full page reload happens. - Long Tasks & LoAF Any piece of JavaScript that occupies the main thread for more than 50 ms, blocking the page from responding. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/fcp/ Metrics FCP # First Contentful Paint The moment the browser renders the first piece of content: text, an image or a canvas. Good <= 1.8 s Needs work 1.8 to 3 s Poor > 3 s Field data (75th percentile) FCP marks the transition from a blank screen to the first visible sign that the page is loading. It is not a Core Web Vital itself, but it is a strong early indicator and a common diagnostic for a slow LCP. A fast FCP reassures visitors that something is happening. If FCP is slow, the cause is almost always upstream: server time, DNS, redirects or render-blocking resources. What moves it - High TTFB and slow initial server response. - Render-blocking stylesheets and synchronous scripts. - Slow font delivery that hides text until it arrives. Related terms - CWV Core Web Vitals Google's set of three field metrics for loading (LCP), interactivity (INP) and visual stability (CLS) of a page. - LCP Largest Contentful Paint The time until the largest visible element in the viewport (image, video or text block) has rendered. - INP Interaction to Next Paint How long the page takes to visually respond after a user interacts, measured across the whole visit. - CLS Cumulative Layout Shift A unitless score for how much visible content unexpectedly moves around while the page loads and runs. - TTFB Time to First Byte The time from the start of navigation until the browser receives the first byte of the response. - FID First Input Delay (retired) The delay between a visitor's first interaction and the browser starting to process it. Replaced by INP. - TBT Total Blocking Time The total time the main thread was blocked by long tasks between first paint and interactivity, measured in the lab. - SI Speed Index A lab metric for how quickly the visible parts of a page fill in during load, based on video capture. - TTI Time to Interactive (legacy) A lab metric for when a page has rendered and can reliably respond to input quickly. - Page Load The classic load event: everything on the initial page, including images and subresources, has finished loading. - Route Load The loading time of an in-app navigation in a single-page app, where no full page reload happens. - Long Tasks & LoAF Any piece of JavaScript that occupies the main thread for more than 50 ms, blocking the page from responding. - Experience Score A single 0 to 10 number fastmon derives from LCP, INP, CLS, FCP, TTFB, load time and error rate. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/fid/ Metrics FID # First Input Delay (retired) The delay between a visitor's first interaction and the browser starting to process it. Replaced by INP. Good <= 100 ms Needs work 100 to 300 ms Poor > 300 ms Field data (75th percentile) FID was the original responsiveness Core Web Vital. It only measured the input delay of the very first interaction, and only that delay, not the work or rendering that followed, so a page could score a good FID yet still feel sluggish. Google retired FID on 12 March 2024 in favour of INP, which measures the full interaction across the whole visit. FID is included here for context: you may still see it in older reports and tools. Related terms - CWV Core Web Vitals Google's set of three field metrics for loading (LCP), interactivity (INP) and visual stability (CLS) of a page. - LCP Largest Contentful Paint The time until the largest visible element in the viewport (image, video or text block) has rendered. - INP Interaction to Next Paint How long the page takes to visually respond after a user interacts, measured across the whole visit. - CLS Cumulative Layout Shift A unitless score for how much visible content unexpectedly moves around while the page loads and runs. - FCP First Contentful Paint The moment the browser renders the first piece of content: text, an image or a canvas. - TTFB Time to First Byte The time from the start of navigation until the browser receives the first byte of the response. - TBT Total Blocking Time The total time the main thread was blocked by long tasks between first paint and interactivity, measured in the lab. - SI Speed Index A lab metric for how quickly the visible parts of a page fill in during load, based on video capture. - TTI Time to Interactive (legacy) A lab metric for when a page has rendered and can reliably respond to input quickly. - Page Load The classic load event: everything on the initial page, including images and subresources, has finished loading. - Route Load The loading time of an in-app navigation in a single-page app, where no full page reload happens. - Long Tasks & LoAF Any piece of JavaScript that occupies the main thread for more than 50 ms, blocking the page from responding. - Experience Score A single 0 to 10 number fastmon derives from LCP, INP, CLS, FCP, TTFB, load time and error rate. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/gdpr/ Privacy & EU GDPR # GDPR The EU General Data Protection Regulation, the legal baseline for handling personal data in Europe. The GDPR governs how personal data (including IP addresses and identifiers) may be collected, processed and stored, and grants people rights over their data. Analytics tools have to justify what they collect and on what legal basis. fastmon is built inside the GDPR rather than retrofitted to it: minimal data, no raw IP retention, no cross-site profiles and EU-only processing, which keeps the compliance surface small by design. Learn more Related terms - Cookieless Measuring without storing anything on the visitor's device: no cookies, no localStorage. - Edge IP processing The visitor's IP address is reduced to a country code at the edge and discarded before any app code sees it. - TDDDG (Section 25) The German law implementing the ePrivacy rule that reading from or writing to a device needs consent. - Data residency Where your data physically lives and under whose jurisdiction it falls. For fastmon: Germany, end to end. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/inp/ Metrics INP # Interaction to Next Paint How long the page takes to visually respond after a user interacts, measured across the whole visit. Good <= 200 ms Needs work 200 to 500 ms Poor > 500 ms Field data (75th percentile) INP is the responsiveness Core Web Vital. It observes every click, tap and key press during a visit, measures the delay until the next frame is painted, and reports close to the worst one. A low INP means the interface feels instant. INP replaced First Input Delay in March 2024. Unlike FID, which only looked at the first interaction's input delay, INP covers the full interaction including event processing and rendering, so it reflects real sluggishness far better. What moves it - Long JavaScript tasks that block the main thread during interaction. - Heavy event handlers doing work before the next paint. - Large DOM updates or layout thrashing triggered by an interaction. - Third-party scripts competing for the main thread. Learn more Related terms - CWV Core Web Vitals Google's set of three field metrics for loading (LCP), interactivity (INP) and visual stability (CLS) of a page. - LCP Largest Contentful Paint The time until the largest visible element in the viewport (image, video or text block) has rendered. - CLS Cumulative Layout Shift A unitless score for how much visible content unexpectedly moves around while the page loads and runs. - FCP First Contentful Paint The moment the browser renders the first piece of content: text, an image or a canvas. - TTFB Time to First Byte The time from the start of navigation until the browser receives the first byte of the response. - FID First Input Delay (retired) The delay between a visitor's first interaction and the browser starting to process it. Replaced by INP. - TBT Total Blocking Time The total time the main thread was blocked by long tasks between first paint and interactivity, measured in the lab. - SI Speed Index A lab metric for how quickly the visible parts of a page fill in during load, based on video capture. - TTI Time to Interactive (legacy) A lab metric for when a page has rendered and can reliably respond to input quickly. - Page Load The classic load event: everything on the initial page, including images and subresources, has finished loading. - Route Load The loading time of an in-app navigation in a single-page app, where no full page reload happens. - Long Tasks & LoAF Any piece of JavaScript that occupies the main thread for more than 50 ms, blocking the page from responding. - Experience Score A single 0 to 10 number fastmon derives from LCP, INP, CLS, FCP, TTFB, load time and error rate. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/lab-vs-field/ Methods # Lab data vs field data Lab data comes from a controlled test; field data comes from real visitors. Both matter, for different reasons. Lab data is reproducible: same device, same network, same steps, so it is perfect for debugging and CI. But one machine cannot represent every visitor, so it can look rosy while real users struggle. Field data is messy and honest: it captures the full range of devices and connections in the wild. Core Web Vitals are officially assessed on field data. The healthiest workflow uses lab data to prevent regressions and field data to confirm the real-world result. Related terms - RUM Real User Monitoring Measuring performance from the browsers of your actual visitors, on their real devices and networks. - Synthetic Monitoring Scheduled, repeatable tests that load a page in a controlled environment on a fixed interval. - Lighthouse Google's open-source tool that audits a page in a lab run and scores performance, accessibility, SEO and more. - CrUX Chrome UX Report Google's public dataset of real-world Core Web Vitals, aggregated from opted-in Chrome users. - p75 Percentile (p75) The value below which a given share of visits fall. p75 means 75 percent were at least this fast. - Web Vitals Attribution The extra diagnostic data that explains why a metric was slow, not just how slow it was. - Web Analytics Traffic and behaviour measurement: page views, visitors, referrers and journeys, alongside performance. - Error Tracking Capturing JavaScript errors and failed requests from real sessions, grouped so you see the real problems. - Alerting Notification rules that tell you when a metric breaches a threshold or degrades, before customers complain. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/lcp/ Metrics LCP # Largest Contentful Paint The time until the largest visible element in the viewport (image, video or text block) has rendered. Good <= 2.5 s Needs work 2.5 to 4 s Poor > 4 s Field data (75th percentile) LCP is the loading Core Web Vital. It answers the question a visitor cares about most: when does the page look ready? The clock starts when navigation begins and stops when the biggest above-the-fold element paints. Because the largest element is usually a hero image or headline, LCP is dominated by how fast the server responds and how quickly that one resource can be delivered and decoded. What moves it - Slow server response (high TTFB) delays everything downstream. - Large or unoptimised hero images, or images without a priority hint. - Render-blocking CSS and JavaScript in the document head. - Client-side rendering that paints the main content late. Learn more Related terms - CWV Core Web Vitals Google's set of three field metrics for loading (LCP), interactivity (INP) and visual stability (CLS) of a page. - INP Interaction to Next Paint How long the page takes to visually respond after a user interacts, measured across the whole visit. - CLS Cumulative Layout Shift A unitless score for how much visible content unexpectedly moves around while the page loads and runs. - FCP First Contentful Paint The moment the browser renders the first piece of content: text, an image or a canvas. - TTFB Time to First Byte The time from the start of navigation until the browser receives the first byte of the response. - FID First Input Delay (retired) The delay between a visitor's first interaction and the browser starting to process it. Replaced by INP. - TBT Total Blocking Time The total time the main thread was blocked by long tasks between first paint and interactivity, measured in the lab. - SI Speed Index A lab metric for how quickly the visible parts of a page fill in during load, based on video capture. - TTI Time to Interactive (legacy) A lab metric for when a page has rendered and can reliably respond to input quickly. - Page Load The classic load event: everything on the initial page, including images and subresources, has finished loading. - Route Load The loading time of an in-app navigation in a single-page app, where no full page reload happens. - Long Tasks & LoAF Any piece of JavaScript that occupies the main thread for more than 50 ms, blocking the page from responding. - Experience Score A single 0 to 10 number fastmon derives from LCP, INP, CLS, FCP, TTFB, load time and error rate. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/lighthouse/ Methods # Lighthouse Google's open-source tool that audits a page in a lab run and scores performance, accessibility, SEO and more. Lighthouse loads a page under simulated conditions and produces a 0 to 100 performance score from lab metrics like FCP, LCP, TBT, CLS and Speed Index, plus concrete recommendations. It powers the lab side of PageSpeed Insights. fastmon's synthetic checks run Lighthouse on a schedule so you get its diagnostics continuously, not just when someone happens to run an audit. Related terms - RUM Real User Monitoring Measuring performance from the browsers of your actual visitors, on their real devices and networks. - Synthetic Monitoring Scheduled, repeatable tests that load a page in a controlled environment on a fixed interval. - Lab data vs field data Lab data comes from a controlled test; field data comes from real visitors. Both matter, for different reasons. - CrUX Chrome UX Report Google's public dataset of real-world Core Web Vitals, aggregated from opted-in Chrome users. - p75 Percentile (p75) The value below which a given share of visits fall. p75 means 75 percent were at least this fast. - Web Vitals Attribution The extra diagnostic data that explains why a metric was slow, not just how slow it was. - Web Analytics Traffic and behaviour measurement: page views, visitors, referrers and journeys, alongside performance. - Error Tracking Capturing JavaScript errors and failed requests from real sessions, grouped so you see the real problems. - Alerting Notification rules that tell you when a metric breaches a threshold or degrades, before customers complain. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/long-tasks/ Metrics # Long Tasks & LoAF Any piece of JavaScript that occupies the main thread for more than 50 ms, blocking the page from responding. While a long task runs, the browser cannot handle clicks, scrolls or paints, which is exactly what a visitor perceives as jank. Long Animation Frames (LoAF) is the newer API that goes further, attributing a slow frame to the script and even the source line responsible. Long tasks are the raw material behind a poor INP or TBT. Finding and breaking them up, or moving work off the main thread, is the most direct way to make an interface feel fast. Related terms - CWV Core Web Vitals Google's set of three field metrics for loading (LCP), interactivity (INP) and visual stability (CLS) of a page. - LCP Largest Contentful Paint The time until the largest visible element in the viewport (image, video or text block) has rendered. - INP Interaction to Next Paint How long the page takes to visually respond after a user interacts, measured across the whole visit. - CLS Cumulative Layout Shift A unitless score for how much visible content unexpectedly moves around while the page loads and runs. - FCP First Contentful Paint The moment the browser renders the first piece of content: text, an image or a canvas. - TTFB Time to First Byte The time from the start of navigation until the browser receives the first byte of the response. - FID First Input Delay (retired) The delay between a visitor's first interaction and the browser starting to process it. Replaced by INP. - TBT Total Blocking Time The total time the main thread was blocked by long tasks between first paint and interactivity, measured in the lab. - SI Speed Index A lab metric for how quickly the visible parts of a page fill in during load, based on video capture. - TTI Time to Interactive (legacy) A lab metric for when a page has rendered and can reliably respond to input quickly. - Page Load The classic load event: everything on the initial page, including images and subresources, has finished loading. - Route Load The loading time of an in-app navigation in a single-page app, where no full page reload happens. - Experience Score A single 0 to 10 number fastmon derives from LCP, INP, CLS, FCP, TTFB, load time and error rate. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/page-load/ Metrics # Page Load The classic load event: everything on the initial page, including images and subresources, has finished loading. Page Load (the window load event) is the oldest performance milestone. It is easy to understand and still useful as a coarse signal, but it says nothing about when the page looked or felt usable, which is why the Core Web Vitals exist. fastmon records it alongside the vitals so you keep the familiar number while seeing the metrics that actually track experience. Related terms - CWV Core Web Vitals Google's set of three field metrics for loading (LCP), interactivity (INP) and visual stability (CLS) of a page. - LCP Largest Contentful Paint The time until the largest visible element in the viewport (image, video or text block) has rendered. - INP Interaction to Next Paint How long the page takes to visually respond after a user interacts, measured across the whole visit. - CLS Cumulative Layout Shift A unitless score for how much visible content unexpectedly moves around while the page loads and runs. - FCP First Contentful Paint The moment the browser renders the first piece of content: text, an image or a canvas. - TTFB Time to First Byte The time from the start of navigation until the browser receives the first byte of the response. - FID First Input Delay (retired) The delay between a visitor's first interaction and the browser starting to process it. Replaced by INP. - TBT Total Blocking Time The total time the main thread was blocked by long tasks between first paint and interactivity, measured in the lab. - SI Speed Index A lab metric for how quickly the visible parts of a page fill in during load, based on video capture. - TTI Time to Interactive (legacy) A lab metric for when a page has rendered and can reliably respond to input quickly. - Route Load The loading time of an in-app navigation in a single-page app, where no full page reload happens. - Long Tasks & LoAF Any piece of JavaScript that occupies the main thread for more than 50 ms, blocking the page from responding. - Experience Score A single 0 to 10 number fastmon derives from LCP, INP, CLS, FCP, TTFB, load time and error rate. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/pageview/ Building blocks # Pageview A single page load or, in a single-page app, a route change counted as its own view. The pageview is the atomic unit of analytics. Each one carries its metrics, timings and context, and many together make up a session and the traffic totals. fastmon counts soft navigations in single-page apps as pageviews too, so SPA traffic is not undercounted the way it is with tools that only see full document loads. Related terms - Beacon The small data packet the tracker sends to fastmon with a visit's measurements. - Tracker The lightweight script you embed once; it measures Core Web Vitals and errors directly in the browser. - Stitch fastmon's short-lived, edge-derived identifier that groups a visit without cookies or cross-site tracking. - Session One continuous visit: the sequence of page views and interactions a visitor makes before going idle. - Collection modes Presets (Light, Standard, Full) that decide how much detail the tracker collects. - Server-Timing An HTTP header your backend can send to break down where server time was spent, visible in RUM. - Cache-Status Whether a response came from a CDN edge, the origin server or the browser cache. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/percentile-p75/ Methods p75 # Percentile (p75) The value below which a given share of visits fall. p75 means 75 percent were at least this fast. Averages hide pain: a handful of very slow sessions can be masked by many fast ones. Percentiles describe the distribution instead. The 75th percentile is the threshold Core Web Vitals use, so that three out of four visits are represented and the worst quarter cannot be averaged away. Watching p75 (and p90 or p95 for the tail) shows what most people experience and how bad it gets for the unlucky, which an average never reveals. Related terms - RUM Real User Monitoring Measuring performance from the browsers of your actual visitors, on their real devices and networks. - Synthetic Monitoring Scheduled, repeatable tests that load a page in a controlled environment on a fixed interval. - Lab data vs field data Lab data comes from a controlled test; field data comes from real visitors. Both matter, for different reasons. - Lighthouse Google's open-source tool that audits a page in a lab run and scores performance, accessibility, SEO and more. - CrUX Chrome UX Report Google's public dataset of real-world Core Web Vitals, aggregated from opted-in Chrome users. - Web Vitals Attribution The extra diagnostic data that explains why a metric was slow, not just how slow it was. - Web Analytics Traffic and behaviour measurement: page views, visitors, referrers and journeys, alongside performance. - Error Tracking Capturing JavaScript errors and failed requests from real sessions, grouped so you see the real problems. - Alerting Notification rules that tell you when a metric breaches a threshold or degrades, before customers complain. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/route-load/ Metrics # Route Load The loading time of an in-app navigation in a single-page app, where no full page reload happens. In a single-page application, clicking a link swaps content client-side instead of loading a fresh document, so the classic load event never fires again. Route Load measures those soft navigations: how long a view change takes from click to painted content. Without it, SPAs look artificially fast because only the very first load is measured. fastmon detects soft navigations and times each route change so the numbers reflect what visitors actually wait for. Related terms - CWV Core Web Vitals Google's set of three field metrics for loading (LCP), interactivity (INP) and visual stability (CLS) of a page. - LCP Largest Contentful Paint The time until the largest visible element in the viewport (image, video or text block) has rendered. - INP Interaction to Next Paint How long the page takes to visually respond after a user interacts, measured across the whole visit. - CLS Cumulative Layout Shift A unitless score for how much visible content unexpectedly moves around while the page loads and runs. - FCP First Contentful Paint The moment the browser renders the first piece of content: text, an image or a canvas. - TTFB Time to First Byte The time from the start of navigation until the browser receives the first byte of the response. - FID First Input Delay (retired) The delay between a visitor's first interaction and the browser starting to process it. Replaced by INP. - TBT Total Blocking Time The total time the main thread was blocked by long tasks between first paint and interactivity, measured in the lab. - SI Speed Index A lab metric for how quickly the visible parts of a page fill in during load, based on video capture. - TTI Time to Interactive (legacy) A lab metric for when a page has rendered and can reliably respond to input quickly. - Page Load The classic load event: everything on the initial page, including images and subresources, has finished loading. - Long Tasks & LoAF Any piece of JavaScript that occupies the main thread for more than 50 ms, blocking the page from responding. - Experience Score A single 0 to 10 number fastmon derives from LCP, INP, CLS, FCP, TTFB, load time and error rate. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/rum/ Methods RUM # Real User Monitoring Measuring performance from the browsers of your actual visitors, on their real devices and networks. RUM collects metrics from every real session: the phones, laptops, browsers and connections your audience actually uses. That is field data, and it is the only way to know what people truly experience, including the slow long tail that lab tests miss. It is the foundation of Core Web Vitals assessment. fastmon's RUM is cookieless by default and strips IP addresses at the edge, so you get the field truth without building visitor profiles. Learn more Related terms - Synthetic Monitoring Scheduled, repeatable tests that load a page in a controlled environment on a fixed interval. - Lab data vs field data Lab data comes from a controlled test; field data comes from real visitors. Both matter, for different reasons. - Lighthouse Google's open-source tool that audits a page in a lab run and scores performance, accessibility, SEO and more. - CrUX Chrome UX Report Google's public dataset of real-world Core Web Vitals, aggregated from opted-in Chrome users. - p75 Percentile (p75) The value below which a given share of visits fall. p75 means 75 percent were at least this fast. - Web Vitals Attribution The extra diagnostic data that explains why a metric was slow, not just how slow it was. - Web Analytics Traffic and behaviour measurement: page views, visitors, referrers and journeys, alongside performance. - Error Tracking Capturing JavaScript errors and failed requests from real sessions, grouped so you see the real problems. - Alerting Notification rules that tell you when a metric breaches a threshold or degrades, before customers complain. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/server-timing/ Building blocks # Server-Timing An HTTP header your backend can send to break down where server time was spent, visible in RUM. TTFB tells you the server was slow, but not why. With the Server-Timing header your backend can report its own phases (database, cache, rendering) and the browser exposes them to the tracker. That connects a slow field TTFB to the exact backend step responsible, closing the gap between frontend symptom and backend cause. Related terms - Beacon The small data packet the tracker sends to fastmon with a visit's measurements. - Tracker The lightweight script you embed once; it measures Core Web Vitals and errors directly in the browser. - Stitch fastmon's short-lived, edge-derived identifier that groups a visit without cookies or cross-site tracking. - Session One continuous visit: the sequence of page views and interactions a visitor makes before going idle. - Pageview A single page load or, in a single-page app, a route change counted as its own view. - Collection modes Presets (Light, Standard, Full) that decide how much detail the tracker collects. - Cache-Status Whether a response came from a CDN edge, the origin server or the browser cache. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/session/ Building blocks # Session One continuous visit: the sequence of page views and interactions a visitor makes before going idle. A session ties together the pages, timings and errors of a single visit so you can follow a journey rather than isolated hits. It is the unit behind metrics like pages per session and where in a flow people drop off. In fastmon a session is bounded by the short-lived Stitch identifier, so it reflects one visit and does not become a permanent profile. Related terms - Beacon The small data packet the tracker sends to fastmon with a visit's measurements. - Tracker The lightweight script you embed once; it measures Core Web Vitals and errors directly in the browser. - Stitch fastmon's short-lived, edge-derived identifier that groups a visit without cookies or cross-site tracking. - Pageview A single page load or, in a single-page app, a route change counted as its own view. - Collection modes Presets (Light, Standard, Full) that decide how much detail the tracker collects. - Server-Timing An HTTP header your backend can send to break down where server time was spent, visible in RUM. - Cache-Status Whether a response came from a CDN edge, the origin server or the browser cache. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/speed-index/ Metrics SI # Speed Index A lab metric for how quickly the visible parts of a page fill in during load, based on video capture. Good <= 3.4 s Needs work 3.4 to 5.8 s Poor > 5.8 s Lab data (Lighthouse) Speed Index records the loading filmstrip and scores how fast pixels above the fold become visually complete. Two pages with the same LCP can have very different Speed Index if one fills in gradually and the other pops in all at once. It is a Lighthouse lab metric, useful for comparing perceived loading speed between builds, but it is not measured on real users. Related terms - CWV Core Web Vitals Google's set of three field metrics for loading (LCP), interactivity (INP) and visual stability (CLS) of a page. - LCP Largest Contentful Paint The time until the largest visible element in the viewport (image, video or text block) has rendered. - INP Interaction to Next Paint How long the page takes to visually respond after a user interacts, measured across the whole visit. - CLS Cumulative Layout Shift A unitless score for how much visible content unexpectedly moves around while the page loads and runs. - FCP First Contentful Paint The moment the browser renders the first piece of content: text, an image or a canvas. - TTFB Time to First Byte The time from the start of navigation until the browser receives the first byte of the response. - FID First Input Delay (retired) The delay between a visitor's first interaction and the browser starting to process it. Replaced by INP. - TBT Total Blocking Time The total time the main thread was blocked by long tasks between first paint and interactivity, measured in the lab. - TTI Time to Interactive (legacy) A lab metric for when a page has rendered and can reliably respond to input quickly. - Page Load The classic load event: everything on the initial page, including images and subresources, has finished loading. - Route Load The loading time of an in-app navigation in a single-page app, where no full page reload happens. - Long Tasks & LoAF Any piece of JavaScript that occupies the main thread for more than 50 ms, blocking the page from responding. - Experience Score A single 0 to 10 number fastmon derives from LCP, INP, CLS, FCP, TTFB, load time and error rate. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/stitch/ Building blocks # Stitch fastmon's short-lived, edge-derived identifier that groups a visit without cookies or cross-site tracking. To count unique visitors and connect the pages of one visit, some identifier is needed. Stitch is derived at the edge and rotates on a 24-hour basis, so it can group a session but cannot follow anyone across days, sites or devices. It is how fastmon avoids the double-counting and orphaned sessions of pure cookieless approaches while still setting no cookies and building no long-lived profiles. Related terms - Beacon The small data packet the tracker sends to fastmon with a visit's measurements. - Tracker The lightweight script you embed once; it measures Core Web Vitals and errors directly in the browser. - Session One continuous visit: the sequence of page views and interactions a visitor makes before going idle. - Pageview A single page load or, in a single-page app, a route change counted as its own view. - Collection modes Presets (Light, Standard, Full) that decide how much detail the tracker collects. - Server-Timing An HTTP header your backend can send to break down where server time was spent, visible in RUM. - Cache-Status Whether a response came from a CDN edge, the origin server or the browser cache. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/synthetic/ Methods # Synthetic Monitoring Scheduled, repeatable tests that load a page in a controlled environment on a fixed interval. Synthetic monitoring runs a page through a lab (for fastmon, scheduled Lighthouse and TTFB checks) on a schedule, from the same device profile and network every time. Because the conditions are fixed, results are stable and comparable, which makes them ideal for catching regressions and testing pages before they have any traffic. It complements RUM rather than replacing it: synthetic tells you a page changed, RUM tells you whether real users felt it. Learn more Related terms - RUM Real User Monitoring Measuring performance from the browsers of your actual visitors, on their real devices and networks. - Lab data vs field data Lab data comes from a controlled test; field data comes from real visitors. Both matter, for different reasons. - Lighthouse Google's open-source tool that audits a page in a lab run and scores performance, accessibility, SEO and more. - CrUX Chrome UX Report Google's public dataset of real-world Core Web Vitals, aggregated from opted-in Chrome users. - p75 Percentile (p75) The value below which a given share of visits fall. p75 means 75 percent were at least this fast. - Web Vitals Attribution The extra diagnostic data that explains why a metric was slow, not just how slow it was. - Web Analytics Traffic and behaviour measurement: page views, visitors, referrers and journeys, alongside performance. - Error Tracking Capturing JavaScript errors and failed requests from real sessions, grouped so you see the real problems. - Alerting Notification rules that tell you when a metric breaches a threshold or degrades, before customers complain. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/tbt/ Metrics TBT # Total Blocking Time The total time the main thread was blocked by long tasks between first paint and interactivity, measured in the lab. Good <= 200 ms Needs work 200 to 600 ms Poor > 600 ms Lab data (Lighthouse) TBT is a lab metric and the closest lab proxy for INP. It sums the blocking portion (everything over 50 ms) of every long task after FCP, showing how much a page would ignore input while scripts run. Because it is measured in a controlled lab run, TBT is stable and great for catching regressions in CI before they reach real users as a poor INP. What moves it - Large JavaScript bundles parsed and executed at load. - Expensive hydration in client-rendered frameworks. - Third-party tags running heavy work on the main thread. Related terms - CWV Core Web Vitals Google's set of three field metrics for loading (LCP), interactivity (INP) and visual stability (CLS) of a page. - LCP Largest Contentful Paint The time until the largest visible element in the viewport (image, video or text block) has rendered. - INP Interaction to Next Paint How long the page takes to visually respond after a user interacts, measured across the whole visit. - CLS Cumulative Layout Shift A unitless score for how much visible content unexpectedly moves around while the page loads and runs. - FCP First Contentful Paint The moment the browser renders the first piece of content: text, an image or a canvas. - TTFB Time to First Byte The time from the start of navigation until the browser receives the first byte of the response. - FID First Input Delay (retired) The delay between a visitor's first interaction and the browser starting to process it. Replaced by INP. - SI Speed Index A lab metric for how quickly the visible parts of a page fill in during load, based on video capture. - TTI Time to Interactive (legacy) A lab metric for when a page has rendered and can reliably respond to input quickly. - Page Load The classic load event: everything on the initial page, including images and subresources, has finished loading. - Route Load The loading time of an in-app navigation in a single-page app, where no full page reload happens. - Long Tasks & LoAF Any piece of JavaScript that occupies the main thread for more than 50 ms, blocking the page from responding. - Experience Score A single 0 to 10 number fastmon derives from LCP, INP, CLS, FCP, TTFB, load time and error rate. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/tdddg/ Privacy & EU # TDDDG (Section 25) The German law implementing the ePrivacy rule that reading from or writing to a device needs consent. TDDDG Section 25 (formerly TTDSG) is the German transposition of the ePrivacy Directive. It says storing information on, or accessing information from, a user's device generally requires consent, independent of whether that information is personal data. This is why even a cookieless tool can still need consent: reading the browser's performance APIs is access to the device. The website operator obtains that consent through their consent platform, exactly as with other tools, as described in fastmon's privacy policy. Related terms - Cookieless Measuring without storing anything on the visitor's device: no cookies, no localStorage. - Edge IP processing The visitor's IP address is reduced to a country code at the edge and discarded before any app code sees it. - GDPR GDPR The EU General Data Protection Regulation, the legal baseline for handling personal data in Europe. - Data residency Where your data physically lives and under whose jurisdiction it falls. For fastmon: Germany, end to end. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/tracker/ Building blocks # Tracker The lightweight script you embed once; it measures Core Web Vitals and errors directly in the browser. The tracker is the snippet that does the measuring. It hooks into standard browser APIs (the Performance API, PerformanceObserver, error events) and is aligned with the same web-vitals library Google uses, so the numbers are comparable to Chrome's. It is small and loads without blocking rendering, so adding monitoring does not itself hurt the performance you are trying to measure. Related terms - Beacon The small data packet the tracker sends to fastmon with a visit's measurements. - Stitch fastmon's short-lived, edge-derived identifier that groups a visit without cookies or cross-site tracking. - Session One continuous visit: the sequence of page views and interactions a visitor makes before going idle. - Pageview A single page load or, in a single-page app, a route change counted as its own view. - Collection modes Presets (Light, Standard, Full) that decide how much detail the tracker collects. - Server-Timing An HTTP header your backend can send to break down where server time was spent, visible in RUM. - Cache-Status Whether a response came from a CDN edge, the origin server or the browser cache. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/ttfb/ Metrics TTFB # Time to First Byte The time from the start of navigation until the browser receives the first byte of the response. Good <= 0.8 s Needs work 0.8 to 1.8 s Poor > 1.8 s Field data (75th percentile) TTFB captures everything that happens before rendering can even begin: DNS lookup, connection setup, TLS handshake, redirects, and the server producing the response. It is the foundation every other loading metric sits on. A high TTFB caps how fast FCP and LCP can ever be, which is why it is the first thing to check when a page feels slow. Server logic, database queries and cold caches are the usual culprits. What moves it - Slow backend processing or uncached database queries. - No CDN, so visitors far from the origin pay the round-trip. - Redirect chains before the final document loads. Related terms - CWV Core Web Vitals Google's set of three field metrics for loading (LCP), interactivity (INP) and visual stability (CLS) of a page. - LCP Largest Contentful Paint The time until the largest visible element in the viewport (image, video or text block) has rendered. - INP Interaction to Next Paint How long the page takes to visually respond after a user interacts, measured across the whole visit. - CLS Cumulative Layout Shift A unitless score for how much visible content unexpectedly moves around while the page loads and runs. - FCP First Contentful Paint The moment the browser renders the first piece of content: text, an image or a canvas. - FID First Input Delay (retired) The delay between a visitor's first interaction and the browser starting to process it. Replaced by INP. - TBT Total Blocking Time The total time the main thread was blocked by long tasks between first paint and interactivity, measured in the lab. - SI Speed Index A lab metric for how quickly the visible parts of a page fill in during load, based on video capture. - TTI Time to Interactive (legacy) A lab metric for when a page has rendered and can reliably respond to input quickly. - Page Load The classic load event: everything on the initial page, including images and subresources, has finished loading. - Route Load The loading time of an in-app navigation in a single-page app, where no full page reload happens. - Long Tasks & LoAF Any piece of JavaScript that occupies the main thread for more than 50 ms, blocking the page from responding. - Experience Score A single 0 to 10 number fastmon derives from LCP, INP, CLS, FCP, TTFB, load time and error rate. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/tti/ Metrics TTI # Time to Interactive (legacy) A lab metric for when a page has rendered and can reliably respond to input quickly. TTI estimated the point at which the main thread had been quiet long enough for the page to handle interactions dependably. It was once a headline Lighthouse score. Lighthouse dropped TTI from its scoring in version 10 (2023) because TBT and INP describe responsiveness more reliably. It appears here for context with older audits. Related terms - CWV Core Web Vitals Google's set of three field metrics for loading (LCP), interactivity (INP) and visual stability (CLS) of a page. - LCP Largest Contentful Paint The time until the largest visible element in the viewport (image, video or text block) has rendered. - INP Interaction to Next Paint How long the page takes to visually respond after a user interacts, measured across the whole visit. - CLS Cumulative Layout Shift A unitless score for how much visible content unexpectedly moves around while the page loads and runs. - FCP First Contentful Paint The moment the browser renders the first piece of content: text, an image or a canvas. - TTFB Time to First Byte The time from the start of navigation until the browser receives the first byte of the response. - FID First Input Delay (retired) The delay between a visitor's first interaction and the browser starting to process it. Replaced by INP. - TBT Total Blocking Time The total time the main thread was blocked by long tasks between first paint and interactivity, measured in the lab. - SI Speed Index A lab metric for how quickly the visible parts of a page fill in during load, based on video capture. - Page Load The classic load event: everything on the initial page, including images and subresources, has finished loading. - Route Load The loading time of an in-app navigation in a single-page app, where no full page reload happens. - Long Tasks & LoAF Any piece of JavaScript that occupies the main thread for more than 50 ms, blocking the page from responding. - Experience Score A single 0 to 10 number fastmon derives from LCP, INP, CLS, FCP, TTFB, load time and error rate. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/web-analytics/ Methods # Web Analytics Traffic and behaviour measurement: page views, visitors, referrers and journeys, alongside performance. Analytics answers who visited, from where, and what they did. Paired with performance data it becomes far more useful: you can see whether a slow page costs conversions or which traffic source lands on your worst experiences. fastmon's analytics is privacy-first: no cookies in the default mode, no cross-site tracking, and IPs reduced to a country code at the edge. The default mode stores nothing on the device, so in our assessment no consent banner is needed either. Learn more Related terms - RUM Real User Monitoring Measuring performance from the browsers of your actual visitors, on their real devices and networks. - Synthetic Monitoring Scheduled, repeatable tests that load a page in a controlled environment on a fixed interval. - Lab data vs field data Lab data comes from a controlled test; field data comes from real visitors. Both matter, for different reasons. - Lighthouse Google's open-source tool that audits a page in a lab run and scores performance, accessibility, SEO and more. - CrUX Chrome UX Report Google's public dataset of real-world Core Web Vitals, aggregated from opted-in Chrome users. - p75 Percentile (p75) The value below which a given share of visits fall. p75 means 75 percent were at least this fast. - Web Vitals Attribution The extra diagnostic data that explains why a metric was slow, not just how slow it was. - Error Tracking Capturing JavaScript errors and failed requests from real sessions, grouped so you see the real problems. - Alerting Notification rules that tell you when a metric breaches a threshold or degrades, before customers complain. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/glossary/web-vitals-attribution/ Methods # Web Vitals Attribution The extra diagnostic data that explains why a metric was slow, not just how slow it was. Knowing LCP was 4 seconds is only half the story. Attribution breaks a metric into its phases (for LCP: time to first byte, resource load delay, load time, render delay) and names the responsible element or the CSS selector behind a layout shift or slow interaction. That turns a number into an action: instead of guessing, you see the exact image, script or element to fix. Related terms - RUM Real User Monitoring Measuring performance from the browsers of your actual visitors, on their real devices and networks. - Synthetic Monitoring Scheduled, repeatable tests that load a page in a controlled environment on a fixed interval. - Lab data vs field data Lab data comes from a controlled test; field data comes from real visitors. Both matter, for different reasons. - Lighthouse Google's open-source tool that audits a page in a lab run and scores performance, accessibility, SEO and more. - CrUX Chrome UX Report Google's public dataset of real-world Core Web Vitals, aggregated from opted-in Chrome users. - p75 Percentile (p75) The value below which a given share of visits fall. p75 means 75 percent were at least this fast. - Web Analytics Traffic and behaviour measurement: page views, visitors, referrers and journeys, alongside performance. - Error Tracking Capturing JavaScript errors and failed requests from real sessions, grouped so you see the real problems. - Alerting Notification rules that tell you when a metric breaches a threshold or degrades, before customers complain. All terms ## Monitoring that belongs in the EU. Read-only by default: no cookies*, no long-lived identifiers, no US provider in the data path. Live in about five minutes. Light €29 /month 200,000 pageviews included. Start for free View plans Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans --- ## https://fastmon.eu/en/partners/apply/ Become a partner # Two paragraphs, then we talk. No application portal, no sales funnel. Tell us who you are and how many client projects you look after, and we take it from there in a short call. - No joining fee - No minimum revenue - Leave at any time ## What to put in the first mail - Your company and your website - How many client projects you look after - Which track fits you: refer or manage yourself - What you work with: Shopware, WordPress, TYPO3, your own stack - Optional: two client projects you would start with ## Write to us No form, no chatbot. Your message lands directly with the founding team. Email our partner team Answered directly by the founders Kamil & Lucas Prefer to talk? Put two time slots in the mail and we send a link. Back to the program See all plans ## How it works 01 ### Your application The mail lands with the founding team, not in a sales inbox. You get a personal answer. 02 ### Intro call Half an hour on video, no slide deck: your clients, your stack, which track fits you. 03 ### Access and starter kit You are recorded as a partner and get the partner kit plus a free account for your own sites. Requirements ## We take you on if - you build, run or look after websites or shops for clients - you use fastmon yourself, at least on your own site - you support your clients technically rather than only placing a link We do not accept coupon or cashback sites. Self purchases and bidding on our brand in search ads are excluded. Terms ## The conditions in short - 20% from the first active Standard account, 25% from ten, 30% from 25. From 50 the terms are negotiated with you. - Light (€29) pays a flat 10%, from your tenth active Light account, and does not count towards the levels. - In the manage track the accounts still count towards your level, and instead of a commission we agree the price with you. - The commission runs for as long as the client pays. No 12 month limit. - Register a client by mail before they sign up, then the attribution is unambiguous. - Payout monthly against your invoice, from €50 accumulated, net plus VAT or reverse charge within the EU. - Levels are reviewed monthly, with three months of level protection after a cancellation, and ten accounts within the first 90 days put you on p90 right away. - You can leave at any time, with no notice period. What is binding is the partner agreement you receive before you start. This page is the summary. ## Anything this page does not answer? Put it straight into the mail. It lands with the founding team, not in a sales pipeline. Email our partner team --- ## https://fastmon.eu/en/partners/scalecommerce/ Partner profile p99 Partner # ScaleCommerce Performance hosting from Berlin. E-commerce PaaS and managed hosting for Shopware, OXID, Magento and Spryker. fastmon itself runs on the ScaleCommerce platform. Visit scale.sc Based in Berlin, Germany Role Hosting partner Focus E-commerce PaaS, managed hosting Platforms Shopware, OXID, Magento, Spryker Who they are ## Hosting that is judged by performance ScaleCommerce runs online shops and web applications as a platform service: git based deployments, CI/CD, caching, bot protection, backups and security updates included. The stack covers Shopware, OXID, Magento and Spryker as well as custom applications on Node.js or Next.js. What makes them a fit for us is the yardstick they use. ScaleCommerce does not sell uptime alone, they sell shop performance, and they optimize towards load time and conversion. That is the same number fastmon puts on the screen, measured on real visitors instead of a lab run. The relationship reaches into our own infrastructure: fastmon runs on the ScaleCommerce platform, and the data sits on servers in Germany. Both of them, ScaleCommerce and the data center operator Hetzner, are named in our sub-processor list, where anyone can check it. See our sub-processor list Services ## What they run for clients ### Managed e-commerce hosting Platform as a service for shops: git based deployments, CI/CD, Redis, automatic backups and security updates, operations included. ### Shop performance Optimization aimed at load time and conversion, not only at availability. Bottlenecks are worked on in the application, not just in the infrastructure. ### Traffic peaks Distributed infrastructure so campaigns, sale days and TV spots do not become the reason growth stops. ### Best practice bundle More than 20 preconfigured building blocks, from bot protection to edge functions, instead of a project that starts from zero every time. Why it fits ## What the combination gives you ### One yardstick on both sides ScaleCommerce makes shops fast, fastmon shows what of that reaches the real visitor. You discuss results with your client instead of measurement methods. ### fastmon runs there We run on what we recommend: fastmon itself sits on the ScaleCommerce platform, with the data in Germany. If you look after clients there, the shop and its monitoring live in the same place. ### A data path that stays in the EU No US provider in between, for you and for your clients' visitors. One less question in every procurement process. p99 Partner ### The top level of the program p99 is the highest of the four partner levels. It comes with individually agreed terms, enterprise deals we close together and shared product work. How the levels work ## Become a partner yourself The program is open to every agency, hosting provider and consultancy that looks after websites. Same ladder, same conditions. Become a partner To the partner program --- ## https://fastmon.eu/de/ Dein Lighthouse-Score sagt 95. # Wie schnell ist deine Seite, wirklich? Deine Besucher wissen es längst. fastmon zeigt es dir: echte Ladezeiten von echten Geräten in echten Netzen, mit den Zahlen, nach denen Google dich rankt. Kostenlos starten Alle Features Keine Kreditkarte ~5 Minuten Setup Hosting in Deutschland Standardmäßig read-only* Live: diese Seite misst sich gerade selbst dein Besuch TTFB FCP LCP CLS Dieselben Browser-APIs wie das fastmon-Skript. Ohne Cookies*. Navigationstyp ··· Neu im Thema? ## LCP, FCP, TTFB: alles nur Buzzwords für dich? Kein Problem. Im Blog erklären wir jede Metrik in normaler Sprache: was sie misst, warum Google sie liebt und wie du sie verbesserst. Der fastmon Blog Metriken in normaler Sprache Zum Blog Das Produkt ## Eine Plattform. Sechzehn Instrumente. Fünf Bereiche, ein Script, dieselben Beacons. Das komplette Register mit allen sechzehn Instrumenten findest du weiter unten. - Real User Monitoring Core Web Vitals p75 · 7d LCP (p75) 0.44 s Besuchererlebnis 90% gut Gut 90% VB 4% Schlecht 6% INP 56 ms CLS 0.00 TTFB 0.18 s FCP 0.28 s Page Load 0.9 s Fehlerrate 0.00 % Core Web Vitals, Fehler und Netzwerk-Timing aus jedem echten Besuch, bewertet am p75 gegen die Google-Schwellen. Mehr zu Real User Monitoring - Synthetic Monitoring Lighthouse Desktop · alle 24h 82 Performance 96 Barrierefreiheit 100 Best Practices 92 SEO Metriken First Contentful Paint 0.9 s Largest Contentful Paint 1.8 s Total Blocking Time 120 ms Cumulative Layout Shift 0.01 Potenziale Render-blocking Ressourcen entfernen 50 ms sparen Ungenutztes JavaScript reduzieren 250 ms sparen Bild-Auslieferung verbessern 51 kB sparen Geplante Lighthouse-Audits für Desktop und Mobile alle 24 Stunden, TTFB-Checks alle 5 Minuten. Lab und Feld nebeneinander. Mehr zu Synthetic Monitoring - Web-Analytics Aktuelle Besucher 385 in den letzten 5 Minuten Top-Quellen Direkt 1.2M Google 198.6K Instagram 17.0K YouTube 10.1K Live-Besucher der letzten fünf Minuten, Quellen, Kampagnen, UTM und Ad-Click-IDs. Ein Tool weniger im Stack. Mehr zu Analytics - fastmon AI fastmon AI Beta Wie hat sich LCP in den letzten 7 Tagen entwickelt? lcp_p75 (ms) · 7d 2.800 2.100 1.400 700 0 13. 14. 15. 16. 17. 18. 19. 20. LCP p75 lag meist im gut -Bereich (136 bis 382 ms), mit einem Ausreißer am 19.07. ( 2.681 ms ). Ursache lohnt einen Blick. Stell Fragen zu einem Test oder Fehler in normaler Sprache und bekomm eine fundierte Antwort. Kein Query-Bauen, kein Dashboard-Suchen. Mehr zu fastmon AI - EU & Datenschutz Datenpfad 100 % EU 01 Besucher Browser-Beacon IP + User-Agent 02 Edge (Falkenstein) IP verworfen, < 1 s → Ländercode (DE) 03 Backend EU Hetzner, Deutschland keine rohe IP Kein Cloudflare Kein AWS Kein GCP Kein US-Anbieter IP-Adresse und User-Agent werden am Edge entfernt, bevor irgendein Application-Code sie sieht. Kein Cloudflare, kein AWS, kein GCP: der komplette Datenpfad bleibt in der EU. Mehr zu EU & Datenschutz Core Web Vitals p75 · 7d LCP (p75) 0.44 s Besuchererlebnis 90% gut Gut 90% VB 4% Schlecht 6% INP 56 ms CLS 0.00 TTFB 0.18 s FCP 0.28 s Page Load 0.9 s Fehlerrate 0.00 % Lighthouse Desktop · alle 24h 82 Performance 96 Barrierefreiheit 100 Best Practices 92 SEO Metriken First Contentful Paint 0.9 s Largest Contentful Paint 1.8 s Total Blocking Time 120 ms Cumulative Layout Shift 0.01 Potenziale Render-blocking Ressourcen entfernen 50 ms sparen Ungenutztes JavaScript reduzieren 250 ms sparen Bild-Auslieferung verbessern 51 kB sparen Aktuelle Besucher 385 in den letzten 5 Minuten Top-Quellen Direkt 1.2M Google 198.6K Instagram 17.0K YouTube 10.1K fastmon AI Beta Wie hat sich LCP in den letzten 7 Tagen entwickelt? lcp_p75 (ms) · 7d 2.800 2.100 1.400 700 0 13. 14. 15. 16. 17. 18. 19. 20. LCP p75 lag meist im gut -Bereich (136 bis 382 ms), mit einem Ausreißer am 19.07. ( 2.681 ms ). Ursache lohnt einen Blick. Datenpfad 100 % EU 01 Besucher Browser-Beacon IP + User-Agent 02 Edge (Falkenstein) IP verworfen, < 1 s → Ländercode (DE) 03 Backend EU Hetzner, Deutschland keine rohe IP Kein Cloudflare Kein AWS Kein GCP Kein US-Anbieter Für Entwickler ## Live, bevor dein Kaffee durch ist Ein Script-Tag, kein Build-Step, keine Konfiguration. index.html 1 < script defer src = "…/f26b….js" > 2 → 204 No Content ✓ 01 ~5 Minuten Tag einbauen Vanilla JS, ~40 KB komprimiert, lädt mit defer. Läuft mit jedem Stack. Network Name Status f26b593f08…js 204 c/collect 204 204 No Content ✓ 02 Nach deinem Deploy In DevTools prüfen Der Collector antwortet mit 204 No Content. Ein Blick in den Network-Tab genügt. Live gerade eben 1 erster Besucher Direktzugriff · Deutschland LCP 0.4 s 03 +60 Sekunden Daten ankommen sehen Rund eine Minute später erscheinen die ersten Besucher im Dashboard. Funktioniert mit jedem Stack - WordPress - Shopify - Shopware - Lovable - TYPO3 - Webflow - Next.js - React und überall sonst, wo du ein Script-Tag einbauen kannst. Installations-Guide in den Docs Das Register ## Alles, was fastmon misst - 01 Core Web Vitals LCP, INP, CLS von echten Nutzern: die Metriken, nach denen Google rankt. - 02 Web-Analytics Live-Besucher, Seiten, Quellen, Kampagnen und UTM-Attribution inklusive. - 03 Error Tracking JavaScript-Fehler mit Typ, Häufigkeit und Herkunft. Aus Produktion. - 04 Netzwerk-Waterfall DNS, TCP, TLS, Server, Transfer: wo die Zeit wirklich bleibt. - 05 Sessions & Visitor Explorer Einzelne Besuche mit Performance pro Seite, Dauer und Geräte-Kontext. - 06 Geo & Geräte Traffic und Web Vitals nach Land, Browser, Gerät, Verbindung. - 07 Performance-Alerts Schwellen- und Regressions-Regeln an E-Mail, Slack, Discord oder Webhook. - 08 Release-Tracking Deploys markiert in Charts: Regressionen bekommen eine Uhrzeit. - 09 Explorer Ad-hoc-Analyse, p50 bis p99, filtern und gruppieren ohne SQL. - 10 Frag zu einem Test Neu Fragen zu einem Test oder Fehler in normaler Sprache, du bekommst eine fundierte Antwort. - 11 Synthetic Monitoring Beta Lighthouse alle 24 h und TTFB-Checks alle 5 Minuten, neben deinen Felddaten. - 12 Server-Timing Backend-Phasen wie Datenbank, Cache und Render in jedem echten Request. - 13 Cache-Monitoring Browser-, CDN- und Origin-Ebene, bfcache-Hit-Rates, Ressourcen nach Typ. - 14 API- & Fetch-Monitoring Jeder Fetch- und XHR-Call: langsame Requests, Fehler und Tail-Latenz. - 15 REST API Voller Zugriff mit Token-Auth und OpenAPI-Schema. - 16 Teams & Rollen Multi-Org, Owner- und Member-Rollen, Partner-Clients für Agenturen. Alle Features im Detail Warum es sich rechnet ## Performance ist Umsatz. In einem Tool Langsame Seiten verlieren Kunden, bevor dein Conversion-Tracking sie überhaupt bemerkt. fastmon misst die Core Web Vitals deiner echten Besucher und macht sichtbar, was jede Zehntelsekunde Ladezeit am Umsatz hängt. - Google rankt nach echten Core Web Vitals (CrUX), nicht nach Laborwerten - p75 statt Durchschnitt: du siehst die Besucher, die wirklich leiden - Was dich jede Zehntelsekunde kostet, rechnest du mit deinen eigenen Zahlen durch Was dich Langsamkeit kostet Für wen ## Gebaut fürs ganze Team Vier Rollen, ein Dashboard: alle sehen die Zahlen, die sie wirklich brauchen. Analytics ### Marketing - Kampagnen, Quellen und UTM-Attribution - Ladezeiten direkt neben Conversions - Live-Besucher der letzten fünf Minuten - Ad-Click-IDs wie gclid inklusive Mehr zu Analytics API & Docs ### Entwickler - JavaScript-Fehler mit Typ und Herkunft - Netzwerk-Waterfall und Server-Timing - REST API mit OpenAPI-Schema - Release-Marker per curl aus der CI/CD Zu den Docs EU & Datenschutz ### CTOs - Komplette Infrastruktur in der EU - Kein US-Anbieter im Datenpfad - IP am Edge entfernt, nur Ländercode - AVV inklusive, 90 Tage Aufbewahrung EU & Datenschutz Pläne ### Gründer & Geschäftsführung - Experience Score: eine Note von A+ bis F - Ein Tool statt drei im Stack - Transparente Preise ab 29 € im Monat - Team-Zugänge mit Owner- und Member-Rollen Preise ansehen Datenschutz ## Innerhalb der DSGVO entworfen. Nicht nachträglich angepasst. Das ist der Unterschied zwischen einem Monitoring-Tool aus der EU und einem mit EU-Region. Hier ist das Datenblatt: die ehrliche Version, mit Fußnote. * In den Modi Minimal und Standard setzt fastmon kein Cookie und speichert nichts auf dem Endgerät; gelesen werden nur Statuswerte, die der Browser zur Laufzeit selbst erzeugt. Im Modus Full wird eine Kennung geschrieben, dort ist eine Einwilligung nach § 25 TDDDG erforderlich. Die Prüfung obliegt dem jeweiligen Website-Betreiber, der fastmon einbindet. Datenblatt Cookies 0* strikt speicherfrei: kein localStorage, kein sessionStorage IP-Adresse am Edge entfernt bevor irgendein Application-Code sie sieht Standort nur Land zweistelliger ISO-Code, mehr nicht Datenpfad 100 % EU kein Cloudflare, kein AWS, kein GCP Aufbewahrung 90 Tage Default, pro Website einstellbar Fingerprinting keins kein Canvas, keine Font-Enumeration Die Einordnung ## Lighthouse, GA4 oder Datadog? Synthetische Tools messen nicht, was Nutzer fühlen. Analytics-Tools messen Traffic, keine Performance. Enterprise-RUM wie Datadog kann weit mehr und lädt ein ~60-KB-Script; die Listenpreise sind pro Session und modular. fastmon sitzt dazwischen, standardmäßig cookiefrei* und in der EU gehostet. | Fähigkeit | fastmon Performance-RUM | Lighthouse Synthetische Tests | GA4 Traffic-Analytics | Plausible Web-Analytics | Datadog RUM Enterprise-RUM | Real User Monitoring (Felddaten) | ✓ Ja | Nein | Nein | Nein | ✓ Ja | Core Web Vitals (LCP, INP, CLS) | ✓ Ja | Synthetisch | Nein | Nein | ✓ Ja | Netzwerk- & Resource-Timing | ✓ Ja | Synthetisch | Nein | Nein | ✓ Ja | JavaScript-Error-Tracking | ✓ Ja | Nein | Nein | Nein | ✓ Ja | Geo- & Geräte-Breakdowns | ✓ Ja | Nein | ✓ Ja | ✓ Ja | ✓ Ja | Funktioniert ohne Cookies* | ✓ Ja | N/A | Nein | ✓ Ja | Nein | EU-gehostet | ✓ Ja | N/A | Nein | ✓ Ja | Optional | Einstiegspreis | ab 29 €/Monat | kostenlos | kostenlos | ab 9 $/Monat | nutzungsbasiert pro Session Stand: 14. Juli 2026; Listenpreise bzw. dokumentierte Standard-Konfiguration, individuelle Konditionen können abweichen. *: siehe Fußnote am Seitenende. FAQ ## Häufige Fragen Die ehrlichen Antworten, inklusive der Cookie-Banner-Frage, um die sich alle anderen drücken. Alles Weitere steht in den Docs. Zur Dokumentation ### Brauche ich einen Cookie-Banner für fastmon? Nein, in den Modi Minimal und Standard nicht. Es wird nichts auf dem Endgerät gespeichert, und die Werte, die gelesen werden, lagen vorher nicht dort: sie entstehen erst beim Seitenaufruf. Es genügt, fastmon in deiner Datenschutzerklärung zu nennen. Im Modus Full brauchst du eine Einwilligung, weil dort eine Kennung in den sessionStorage geschrieben wird. Diese Einordnung ist mit unserem externen Datenschutzbeauftragten geprüft; ein Restrisiko bleibt, weil zu dieser Konstellation kein Urteil vorliegt. Die ganze Herleitung, mit Normtext und Gegenauffassung ### Speichert fastmon IP-Adressen? Nein. Die IP wird am Edge entfernt, bevor irgendein Application-Code sie zu Gesicht bekommt. Übrig bleibt ein zweistelliger Ländercode. Auch der User-Agent-Header wird am Edge entfernt. Kein Canvas-Fingerprinting, keine Font-Enumeration, keine Kennung, die eine Domain-Grenze überlebt. Die komplette Privacy-Seite ### Wo liegen meine Daten? Die komplette Infrastruktur läuft in der EU, ohne Anbieter mit US-Jurisdiktion im Datenpfad: kein Cloudflare, kein AWS, kein GCP. Daten werden per Default 90 Tage aufbewahrt, pro Website einstellbar. Ein AVV ist verfügbar. Datenhaltung in den Docs ### Wie schnell bin ich live? Ein Script-Tag, rund fünf Minuten vom Signup bis zu den ersten Datenpunkten. Deine ersten Besucher erscheinen etwa eine Minute nach dem Deployment im Dashboard. In Sekunden verifizierbar: Der Collector antwortet im Network-Tab mit 204 No Content. Installations-Guide ### Macht das Skript meine Seite langsamer? Das Skript ist Vanilla JS, rund 40 KB komprimiert, lädt mit defer und liest die nativen Performance-APIs des Browsers, statt selbst Arbeit zu verrichten. Die Daten gehen über navigator.sendBeacon in Batches raus, verteilt über den Seiten-Lifecycle, in einem bewusst schlanken Wire-Format. So funktioniert die Pipeline ### Was genau misst fastmon? Die fünf Web Vitals (LCP, INP, CLS, FCP, TTFB), bewertet am p75 gegen die Google-Schwellen, dazu JavaScript-Fehler, Page Load Time und Netzwerk-Timing. Verdichtet wird alles im Experience Score: 0 bis 10, Noten A+ bis F, aus sieben gewichteten Indikatoren. Metriken & Schwellen ### Sehe ich, ob ein Deploy etwas verschlechtert hat? Ja. Tagge Releases aus deiner CI/CD-Pipeline, ein einzelner curl im Deploy-Schritt, und fastmon markiert sie in jedem Chart. Vergleiche die 24 Stunden nach einem Release mit den 24 Stunden davor, im Dashboard oder per API. CI/CD-Release-Guide ### Brauche ich Lighthouse dann noch? Behalt es für die Entwicklung, und lass fastmon es in Produktion für dich laufen: Synthetic Monitoring fährt geplante Lighthouse-Audits (Desktop und Mobile) und TTFB-Checks im 5-Minuten-Takt neben deinen Felddaten. Lab gegen Realität, in einer Ansicht. Synthetic-Monitoring-Docs Pläne ## Volle Plattform, ab 29 € im Monat. Zwei nutzungsbasierte Pläne, keine Feature-Matrix pro Instrument. Light fürs Monitoring, Standard für alles, beide in Deutschland gehostet. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Alle Pläne ansehen - 200.000 Pageviews im Monat, dann 10 € je weitere 200k - Core Web Vitals und Real User Monitoring - Web-Analytics: Traffic, Quellen, Kampagnen - Eine Prod- und eine Dev-Applikation inklusive, Anzahl der Domains egal - Hosting in Deutschland, 100 % EU-Datenpfad Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen Was ist neu ## Changelog Alle ansehen ### Early Hints und Store-Phasen Der Vorsprung durch 103 Early Hints wird messbar, Suche und Key-Value-Store zählen als eigene Backend-Phasen. 27. August 2026 ### Checkout im Explorer Funnel-Stufe und Warenkorb-Aktionen als Dimension und Metrik: gruppieren, filtern und bis zum einzelnen Seitenaufruf aufklappen. 26. August 2026 ### Checkout-Funnel Warenkorb, Checkout und Abschluss erkennt fastmon an den URL-Mustern der gängigen Shopsysteme, ohne Änderung am Tracker. 26. August 2026 ### Response Breakdown Ein Wasserfall am gewählten Perzentil: DNS, Verbindung, Wartezeit und Transfer, danach die LCP-Phasen. 25. August 2026 Alle ansehen --- ## https://fastmon.eu/de/agb/ Rechtliches # Allgemeine Geschäftsbedingungen Stand: 29. Juni 2026 der fastmon labs UG (haftungsbeschränkt), Stresemannallee 4, 30173 Hannover, eingetragen im Handelsregister des Amtsgerichts Hannover unter HRB 230880, vertreten durch die Geschäftsführer Kamil Adrian Czujowski und Lucas Röhrs („Anbieter"), für die Nutzung des Software-as-a-Service-Dienstes „fastmon". ## § 1 Geltungsbereich, Vertragsschluss (1) Diese AGB gelten für sämtliche Verträge zwischen dem Anbieter und seinen Kunden über die Nutzung des fastmon-Dienstes. Kunde im Sinne dieser AGB ist ausschließlich Unternehmer gemäß § 14 BGB, juristische Personen des öffentlichen Rechts oder öffentlich-rechtliche Sondervermögen. Eine Nutzung durch Verbraucher gemäß § 13 BGB ist ausgeschlossen. (2) Abweichende oder ergänzende Allgemeine Geschäftsbedingungen des Kunden werden nicht Vertragsbestandteil, es sei denn, der Anbieter stimmt ihrer Geltung ausdrücklich in Textform zu. (3) Der Vertrag kommt durch Registrierung des Kunden im fastmon-Dashboard und Akzeptanz dieser AGB sowie des Auftragsverarbeitungsvertrages (AVV) zustande. Der Kunde wird bei der Registrierung ausdrücklich auf diese AGB und den AVV hingewiesen, kann beide vor Akzeptanz in vollem Umfang einsehen und akzeptiert sie durch aktives Bestätigen der Geltung (Häkchenfeld). Damit sind die Voraussetzungen einer wirksamen Einbeziehung gemäß § 305 Abs. 2 BGB erfüllt. Mit Abschluss des Vertrages werden die zum Zeitpunkt der Registrierung gültige Datenschutzerklärung sowie der AVV (samt darin in Bezug genommener TOM) integraler und untrennbarer Vertragsbestandteil. ## § 2 Leistungsbeschreibung (1) Der Anbieter stellt dem Kunden den SaaS-Dienst fastmon zur Messung der Performance und Verfügbarkeit der vom Kunden betriebenen Webseiten und Webanwendungen zur Verfügung (Real User Monitoring). (2) Der Leistungsumfang ergibt sich aus dem vom Kunden gewählten Tarif sowie der Produkt-Dokumentation unter docs.fastmon.eu. Der Anbieter behält sich vor, den Leistungsumfang zur Verbesserung des Dienstes anzupassen, soweit dies für den Kunden zumutbar ist und keine wesentlichen Vertragspflichten beeinträchtigt. (3) Der Anbieter ist berechtigt, Unterauftragsverarbeiter und sonstige Dienstleister einzusetzen. Die jeweils aktuelle Liste ist auf Anforderung bei privacy@fastmon.eu erhältlich und im jeweils gültigen AVV aufgeführt. ## § 3 Pflichten des Kunden (1) Der Kunde verpflichtet sich, die Zugangsdaten zu seinem Konto vertraulich zu behandeln und gegen Zugriffe Dritter zu schützen. (2) Der Kunde sichert zu, keine personenbezogenen oder personenbeziehbaren Daten gleich welcher Art in vom Anbieter erfassbare Felder zu übermitteln, insbesondere nicht in URL-Pfade, Query-Strings, UTM-Parameter, Tag-Werte und Fehler-Kontexte (vgl. § 2 Abs. 4 AVV). (3) Der Kunde stellt sicher, dass er über die jeweils erforderliche Rechtsgrundlage für die Verarbeitung der Daten verfügt und seine Endnutzer entsprechend informiert hat. (4) Der Kunde ist verantwortlich für die korrekte Einbindung des fastmon-Beacons sowie für die Wahl des Erfassungs-Modus (Light, Standard, Full) und die daraus folgende Prüfung der Einwilligungspflicht. ## § 4 Vergütung, Zahlungsbedingungen (1) Die Vergütung richtet sich nach dem zum Zeitpunkt des Vertragsschlusses geltenden Preisverzeichnis bzw. dem individuell vereinbarten Tarif. (2) Sofern nicht anders vereinbart, erfolgt die Abrechnung monatlich bzw. jährlich im Voraus. Rechnungen sind innerhalb von 14 Tagen ab Zugang ohne Abzug fällig. (3) Die Zahlungsabwicklung erfolgt über Mollie B.V. (Niederlande). Der Anbieter behält sich vor, weitere Zahlungsdienstleister hinzuzufügen. (4) Alle Preise verstehen sich zuzüglich der gesetzlichen Umsatzsteuer. ## § 5 Verfügbarkeit, Service Level (1) Der Anbieter strebt eine jährliche Verfügbarkeit des Dienstes von 99,5 Prozent an. Geplante Wartungsfenster und höhere Gewalt sind ausgenommen. (2) Statusinformationen werden über status.fastmon.eu kommuniziert. (3) Auf Enterprise-Plänen können erweiterte Service-Level individuell vereinbart werden. ## § 6 Laufzeit und Kündigung (1) Der Vertrag wird auf unbestimmte Zeit geschlossen und kann von beiden Parteien zum Ende der jeweiligen Abrechnungsperiode (monatlich oder jährlich) ordentlich gekündigt werden. (2) Das Recht zur außerordentlichen Kündigung aus wichtigem Grund bleibt unberührt. Ein wichtiger Grund liegt insbesondere vor bei nachhaltigem Verstoß gegen Pflichten aus § 3 oder Zahlungsverzug. (3) Kündigungen bedürfen der Textform (E-Mail an support@fastmon.eu ausreichend). (4) Nach Vertragsende werden Kundendaten gemäß § 10 AVV gelöscht. ## § 7 Datenschutz und Auftragsverarbeitung (1) Der Anbieter verarbeitet personenbezogene Daten ausschließlich entsprechend den geltenden datenschutzrechtlichen Bestimmungen, insbesondere der DSGVO und dem BDSG. (2) Der Auftragsverarbeitungsvertrag (AVV) gemäß Art. 28 DSGVO in der unter fastmon.eu/avv jeweils gültigen Fassung ist integraler und untrennbarer Bestandteil dieses Hauptvertrages und wird mit Akzeptanz dieser AGB durch den Kunden zugleich abgeschlossen. Der Kunde bestätigt mit der Registrierung, dass er den AVV in der gültigen Fassung zur Kenntnis genommen, in zumutbarer Weise Kenntnis vom Inhalt nehmen konnte und mit dessen Geltung einverstanden ist (§ 305 Abs. 2 BGB). Bei Konflikten zwischen den Bestimmungen dieser AGB und des AVV gehen die Regelungen des AVV vor, soweit datenschutzrechtliche Themen betroffen sind. (3) Für Enterprise-Konstellationen mit beidseitiger Unterschrift ist eine erweiterte AVV-Fassung verfügbar (Anfrage an privacy@fastmon.eu). ## § 8 Gewährleistung und Haftung (1) Der Anbieter haftet uneingeschränkt für Vorsatz und grobe Fahrlässigkeit sowie für Schäden aus der Verletzung des Lebens, des Körpers oder der Gesundheit. (2) Für leichte Fahrlässigkeit haftet der Anbieter nur bei Verletzung wesentlicher Vertragspflichten (Kardinalpflichten). In diesen Fällen ist die Haftung auf den vertragstypischen, vorhersehbaren Schaden begrenzt, höchstens jedoch auf das vom Kunden in den letzten 12 Monaten vor dem schadensauslösenden Ereignis gezahlte Nettoentgelt. (3) Die Haftung nach dem Produkthaftungsgesetz sowie nach Art. 82 DSGVO bleibt unberührt. Die Haftungsobergrenze findet keine Anwendung auf Bußgelder nach Art. 83 DSGVO, soweit deren Ursache in den Verantwortungsbereich des Anbieters fällt. (4) Der Anbieter haftet nicht für vom Kunden in erfassbaren Feldern eingebettete personenbezogene Daten unter Verstoß gegen § 3 Abs. 2. ## § 9 Geheimhaltung Die Parteien verpflichten sich, sämtliche im Zusammenhang mit dem Vertrag erlangten vertraulichen Informationen der jeweils anderen Partei vertraulich zu behandeln und nicht an Dritte weiterzugeben. Die Pflicht überdauert die Beendigung des Vertrages. ## § 10 Änderungen der AGB (1) Der Anbieter ist berechtigt, diese AGB unter Wahrung einer Ankündigungsfrist von 30 Tagen anzupassen, soweit dies aus rechtlichen, regulatorischen oder produktbezogenen Gründen erforderlich ist und keine wesentlichen Vertragspflichten zum Nachteil des Kunden geändert werden. (2) Widerspricht der Kunde der Änderung innerhalb der Ankündigungsfrist nicht, gelten die geänderten AGB als angenommen. Im Widerspruchsfall steht beiden Parteien ein außerordentliches Kündigungsrecht zum Wirksamwerden der Änderung zu. ## § 11 Schlussbestimmungen (1) Es gilt deutsches Recht unter Ausschluss des UN-Kaufrechts. (2) Gerichtsstand ist Hannover, soweit der Kunde Kaufmann, juristische Person des öffentlichen Rechts oder öffentlich-rechtliches Sondervermögen ist. (3) Bei Widersprüchen zwischen diesen AGB und dem AVV gehen die Regelungen des AVV vor, soweit datenschutzrechtliche Themen betroffen sind. (4) Sollten einzelne Bestimmungen dieser AGB unwirksam sein, bleibt die Gültigkeit der übrigen Bestimmungen unberührt. --- ## https://fastmon.eu/de/avv/ Rechtliches # Auftragsverarbeitungsvertrag (AVV) Art. 28 DSGVO · Stand: 17. Juli 2026 Hinweis: Dieser AVV gilt automatisch für alle Nutzer der Plattform fastmon und wird durch Akzeptanz der AGB bei der Registrierung verbindlich abgeschlossen. Für individuelle Enterprise-Konstellationen mit beidseitiger Unterschrift ist eine erweiterte Fassung des AVV verfügbar, anzufordern über privacy@fastmon.eu. ## § 1 Vertragsparteien und Rangfolge (1) Auftraggeber, Verantwortlicher: Der Nutzer der Plattform „fastmon" (Unternehmer gemäß § 14 BGB), dessen individuelle Angaben bei Vertragsschluss im Nutzerprofil erfasst werden. (2) Auftragnehmer, Auftragsverarbeiter: fastmon labs UG (haftungsbeschränkt) Stresemannallee 4, 30173 Hannover Amtsgericht Hannover, HRB 230880 Geschäftsführer: Kamil Adrian Czujowski, Lucas Röhrs E-Mail: privacy@fastmon.eu (3) Dieser Vertrag konkretisiert die datenschutzrechtlichen Verpflichtungen der Parteien, die sich aus der Nutzung des Software-as-a-Service-Dienstes fastmon (Real User Monitoring) ergeben. Im Falle von Widersprüchen zwischen diesem AVV und anderen Vereinbarungen (insbesondere AGB) gehen die Bestimmungen dieses AVV vor. ## § 2 Gegenstand, Art und Zweck der Verarbeitung (1) Der Auftragnehmer stellt dem Auftraggeber den SaaS-Dienst fastmon zur Verfügung. Gegenstand ist die Messung der Performance und Verfügbarkeit der vom Auftraggeber betriebenen Webseiten und Webanwendungen aus Sicht der tatsächlichen Endnutzer (Real User Monitoring). Verarbeitet werden Core Web Vitals (LCP, INP, CLS, TTFB, FCP), Navigation- und Resource-Timing, technische Metadaten zu Browser, Betriebssystem, Gerät, Viewport, Country-Code (ISO-2) sowie Fehlerereignisse. (2) Zweck der Verarbeitung ist die Bereitstellung des Dashboards, der Alarmierung und der Performance-Auswertung für den Auftraggeber. (3) Eine Verarbeitung der Daten zu eigenen Zwecken des Auftragnehmers (Werbung, Profilierung, Weitergabe an Dritte) findet nicht statt. (4) Der Auftraggeber sichert zu, keine personenbezogenen oder personenbeziehbaren Daten gleich welcher Art in vom Auftragnehmer erfassbare Felder zu übermitteln. Dies umfasst insbesondere URL-Pfade, Query-Strings, Anker, UTM- und Kampagnen-Parameter, frei konfigurierbare Markenwerte, Tag-Werte und Fehler-Kontexte. Besondere Kategorien nach Art. 9 DSGVO und Daten nach Art. 10 DSGVO werden nicht verarbeitet. Eine entgegen dieser Zusicherung erfolgende Übermittlung erfolgt außerhalb des Verarbeitungszwecks und fällt in den Verantwortungsbereich des Auftraggebers. ## § 3 Dauer Die Dauer dieses Vertrages entspricht der Laufzeit des Hauptvertrages (Nutzungsvertrag fastmon). ## § 4 Weisungsrecht des Auftraggebers (1) Der Auftragnehmer verarbeitet personenbezogene Daten ausschließlich im Rahmen der getroffenen Vereinbarungen und nach dokumentierten Weisungen des Auftraggebers. (2) Weisungen erfolgen in der Regel durch die Nutzung des Dashboards und der API; darüber hinausgehende Weisungen sind in Textform an privacy@fastmon.eu zu richten. (3) Hält der Auftragnehmer eine Weisung für datenschutzrechtswidrig, hat er den Auftraggeber unverzüglich zu informieren. ## § 5 Edge-Server-Architektur und Stitch-Identifier (1) Der Auftragnehmer betreibt eine vorgelagerte Edge-Server-Schicht. Die IP-Adresse und der rohe User-Agent des Endnutzers werden dort ausschließlich transient (weniger als 1 Sekunde im Arbeitsspeicher) zur Ableitung von Country-Code (ISO 3166-1 alpha-2) und Browser-Kategorie verarbeitet und unmittelbar danach vernichtet. (2) Die Anwendungsschicht, Datenbank und Logs verarbeiten und speichern zu keinem Zeitpunkt rohe IP-Adressen oder rohe User-Agent-Strings. Diese Eigenschaft ist durch automatisierte Tests dauerhaft abgesichert. (3) Der Stitch-Identifier ist ein serverseitig berechneter HMAC-SHA256-Hash auf Basis eines rotierenden 24-Stunden-Salts, mandantenintern und pro-Site. Eine Wiedererkennung über Sitzungen hinaus, über Sites hinweg oder über Geräte hinweg ist technisch ausgeschlossen. Der Stitch ist pro Site abschaltbar ( store_stitch=false ). ## § 6 Pflichten des Auftragnehmers (1) Der Auftragnehmer gewährleistet, dass die zur Verarbeitung berechtigten Personen zur Vertraulichkeit verpflichtet sind. (2) Der Auftragnehmer setzt die in § 8 beschriebenen technischen und organisatorischen Maßnahmen um. (3) Der Auftragnehmer unterstützt den Auftraggeber bei der Einhaltung der Pflichten gemäß Art. 32 bis 36 DSGVO im Rahmen der ihm zur Verfügung stehenden Informationen. ## § 7 Unterauftragsverarbeiter (1) Der Auftraggeber genehmigt die folgenden Unterauftragsverarbeiter: - Hetzner Online GmbH, Gunzenhausen (DE), Hosting, Storage, Backup (Rechenzentrum Falkenstein, DE) - sevdesk GmbH, Offenburg (DE), Buchhaltung und Rechnungserstellung - Lettermint B.V., Zwolle (NL), transaktionale E-Mails - Soverin B.V., Rotterdam (NL), Geschäftsmail - BunnyWay d.o.o., Tržič (SI), autoritativer DNS-Dienst - smoxy GmbH, Berlin (DE), Ingress - Mistral AI SAS, Paris (FR), LLM-Inferenz (nur bei Opt-in der AI-Chat-Funktion) - ScaleCommerce GmbH, Berlin (DE), Hosting - All Quiet GmbH, Berlin (DE), On-Call-Tool für fastmon-Engineering (2) Mit Mollie B.V., Amsterdam (NL) besteht keine Auftragsverarbeitung im Sinne von Art. 28 DSGVO. Mollie handelt als regulierter Zahlungsdienstleister gemäß PSD2 in eigener datenschutzrechtlicher Verantwortlichkeit. (3) Eine aktuelle Liste der Unterauftragsverarbeiter ist unter fastmon.eu/de/subprozessoren einsehbar und auf Anforderung bei privacy@fastmon.eu erhältlich. (4) Beabsichtigt der Auftragnehmer, weitere Unterauftragsverarbeiter hinzuzuziehen oder zu ersetzen, informiert er den Auftraggeber 30 Tage vorab in Textform. Dem Auftraggeber steht ein Widerspruchsrecht aus wichtigem datenschutzrechtlichem Grund zu. Bei berechtigtem Widerspruch darf der neue Unterauftragsverarbeiter nicht für die Verarbeitung der Daten des widersprechenden Auftraggebers eingesetzt werden, bis eine einvernehmliche Lösung erreicht wurde. Kommt innerhalb von 30 Tagen keine Lösung zustande, steht dem Auftraggeber ein außerordentliches Kündigungsrecht des Hauptvertrages zu. ## § 8 Technische und organisatorische Maßnahmen (TOM) Der Auftragnehmer setzt gemäß Art. 32 DSGVO insbesondere folgende Maßnahmen um: - EU-only-Infrastruktur, keine Datenübermittlung an US-Provider im Datenpfad - TLS-Verschlüsselung sämtlicher externer Verbindungen - Edge-Stripping IP und User-Agent vor der Anwendungsschicht - Datensparsamkeit als Architektur-Prinzip, keine Cookies und keine persistenten Identifier im Default-Modus - Mandantentrennung in der Datenbank über Tenant-IDs - Rollenbasierte Zugriffskontrolle, Least-Privilege-Prinzip - SSH-Zugang nur per Public-Key, 2FA für administrative Konsolen - Verschlüsselte Datenbank-Backups, Retention 7 Tage - Externes Uptime-Monitoring und Alarmierung Detaillierte TOM-Dokumentation auf Anforderung an privacy@fastmon.eu. ## § 9 Betroffenenrechte (1) Der Auftragnehmer unterstützt den Auftraggeber bei der Beantwortung von Anträgen Betroffener nach Art. 15 bis 22 DSGVO im Rahmen der ihm zur Verfügung stehenden Informationen. (2) Aufgrund der datensparsamen Architektur (Edge-Stripping IP, keine persistenten Identifier, 24-Stunden-Begrenzung des Stitch) ist eine direkte Zuordnung von Telemetriedaten zu einer natürlichen Person regelmäßig nicht möglich. Der Auftragnehmer weist hierauf im Einzelfall hin (Art. 11 DSGVO). (3) Wendet sich eine betroffene Person direkt an den Auftragnehmer, leitet er diese Anfrage unverzüglich an den Auftraggeber weiter. ## § 10 Datenschutzverletzungen Der Auftragnehmer meldet dem Auftraggeber jede Verletzung des Schutzes personenbezogener Daten gemäß Art. 4 Nr. 12 DSGVO unverzüglich, spätestens innerhalb von 24 Stunden ab Kenntnis. Die Meldung enthält mindestens Art der Verletzung, betroffene Datenkategorien, ungefähre Anzahl Betroffener, Folgen und ergriffene Maßnahmen. ## § 11 Löschung und Rückgabe nach Vertragsende (1) Nach Beendigung des Hauptvertrages löscht der Auftragnehmer die personenbezogenen Daten des Auftraggebers innerhalb von 30 Tagen, einschließlich aller Backups innerhalb der regulären Backup-Retention. (2) Der Auftraggeber kann seine Daten vor Vertragsende über die im Produkt bereitgestellten Export-Schnittstellen sichern. (3) Eine Speicherung über das Vertragsende hinaus erfolgt nur, soweit gesetzliche Aufbewahrungspflichten dies erfordern (insbesondere Rechnungsdaten, § 257 HGB, § 147 AO, 10 Jahre). ## § 12 Kontrollrechte (1) Der Auftraggeber hat das Recht, die Einhaltung dieser Vereinbarung zu kontrollieren. Vorrangig erfolgt dies durch Vorlage der aktuellen TOM-Dokumentation, Selbstauskünfte und ggf. Zertifikate der Unterauftragsverarbeiter (Hetzner ISO 27001, All Quiet ISO 27001). (2) Vor-Ort-Prüfungen sind mit 30 Tagen Vorankündigung möglich, maximal einmal pro Kalenderjahr, während der üblichen Geschäftszeiten. Die Kosten trägt der Auftraggeber, bei festgestelltem wesentlichem Verstoß der Auftragnehmer. ## § 13 Haftung Die Haftung richtet sich nach Art. 82 DSGVO sowie den Regelungen der AGB. Haftungsobergrenzen aus den AGB finden keine Anwendung auf Bußgelder nach Art. 83 DSGVO, soweit deren Ursache in den Verantwortungsbereich des Auftragnehmers fällt, sowie auf Vorsatz und grobe Fahrlässigkeit. ## § 14 Behörden- und Strafverfolgungsanfragen (1) Erhält der Auftragnehmer Anfragen von Behörden auf Herausgabe personenbezogener Daten des Auftraggebers, prüft er die Rechtmäßigkeit und gibt nur dasjenige Minimum heraus, das gesetzlich erforderlich ist. (2) Der Auftragnehmer informiert den Auftraggeber unverzüglich, soweit dies rechtlich zulässig ist. (3) Eine Verarbeitung unter dem U.S. CLOUD Act, FISA 702 oder vergleichbaren extraterritorialen Zugriffsregimen ist nach derzeitiger Bewertung nicht zu erwarten, da die Verarbeitungstätigkeiten in der EU bzw. im EWR stattfinden. ## § 15 Schlussbestimmungen (1) Es gilt deutsches Recht unter Ausschluss des UN-Kaufrechts. (2) Gerichtsstand ist Hannover, soweit nicht zwingende gesetzliche Regelungen Abweichendes vorsehen. (3) Änderungen dieses AVV bedürfen der Textform. Bei Widersprüchen zwischen diesem AVV und dem Hauptvertrag gehen die Regelungen dieses AVV vor, soweit datenschutzrechtliche Themen betroffen sind. (4) Sollten einzelne Bestimmungen unwirksam sein, bleibt die Gültigkeit der übrigen Regelungen unberührt. fastmon labs UG (haftungsbeschränkt) · Stresemannallee 4, 30173 Hannover · Amtsgericht Hannover HRB 230880 --- ## https://fastmon.eu/de/barrierefreiheit/ Rechtliches # Erklärung zur Barrierefreiheit Zuletzt aktualisiert: Juli 2026 Die fastmon labs UG (haftungsbeschränkt) ist bestrebt, die Website fastmon.eu und die Web-Anwendung von fastmon im Einklang mit dem Barrierefreiheitsstärkungsgesetz (BFSG) sowie den Web Content Accessibility Guidelines (WCAG) 2.1 Level AA zugänglich zu gestalten. ## Geltungsbereich Diese Erklärung bezieht sich auf die Website https://fastmon.eu/ und ergänzend auf die fastmon-Web-Anwendung (das Dashboard unter app.fastmon.eu). ## Status nach Unternehmensgröße Die fastmon labs UG (haftungsbeschränkt) ist ein Kleinstunternehmen im Sinne der Empfehlung 2003/361/EG der Europäischen Kommission (weniger als 10 Beschäftigte und ein Jahresumsatz bzw. eine Jahresbilanzsumme unter 2 Mio. EUR). Für Dienstleistungen gilt nach § 3 Abs. 3 BFSG eine Ausnahme von den Pflichten des BFSG. Wir streben dennoch die bestmögliche Barrierefreiheit an und veröffentlichen diese Erklärung freiwillig. ## Stand der Vereinbarkeit Auf Basis einer internen Selbstbewertung halten wir die Website für weitgehend vereinbar mit WCAG 2.1 Level AA. Einzelne interaktive Inhalte, etwa Performance-Diagramme und Karten, wurden noch nicht systematisch mit assistiven Technologien getestet; hier arbeiten wir laufend an Verbesserungen. ## Unsere aktuellen Maßnahmen - Semantisches HTML mit klarer Überschriftenstruktur - Alternativtexte für informative Bilder, dekorative Bilder als solche ausgezeichnet - Ausreichende Farbkontraste nach WCAG 2.1 AA - Tastaturbedienbare Navigation und Formulare - Berücksichtigung der Systemeinstellung prefers-reduced-motion für Animationen ## Inhalte Dritter In die Website eingebettete Inhalte Dritter, etwa der Status-Badge, Verweise auf KI-Dienste oder Social-Media-Links, liegen nicht in unserem unmittelbaren Verantwortungsbereich. ## Erstellung dieser Erklärung Diese Erklärung wurde im Juli 2026 auf Basis einer internen Selbstbewertung erstellt. Sie wird regelmäßig, spätestens bei wesentlichen Änderungen der Website oder der Web-Anwendung, überprüft. ## Feedback und Kontaktangaben Bitte teilen Sie uns mit, wenn Ihnen Barrieren auffallen oder Sie Inhalte in einem zugänglicheren Format benötigen: fastmon labs UG (haftungsbeschränkt) Stresemannallee 4 30173 Hannover Deutschland E-Mail: privacy@fastmon.eu Wir bemühen uns, auf Ihr Feedback zeitnah zu reagieren. ## Durchsetzungsverfahren Sollte unsere Reaktion auf Ihr Feedback nicht zufriedenstellend sein, können Sie sich an die zuständige Marktüberwachungsbehörde Ihres Bundeslandes wenden. Informationen hierzu stellt die Bundesfachstelle Barrierefreiheit bereit: www.bundesfachstelle-barrierefreiheit.de --- ## https://fastmon.eu/de/blog/ Blog # Web-Performance und Datenschutz, in Klartext. Kein Fachchinesisch, keine Buzzwords. Was die Zahlen wirklich bedeuten und wie du sie besser machst, von den Leuten, die fastmon bauen. Alle Produkt Performance Datenschutz Produkt 8. September 2026 · 7 Min. Lesezeit ## Frag deine KI nach deiner Web-Performance: fastmon hat jetzt einen MCP-Server Verbinde Claude, Claude Code oder Cursor mit fastmon und frag nach deinen Felddaten, statt sie im Dashboard zusammenzuklicken. Neunzehn lesende Werkzeuge, OAuth statt Schlüssel, und eine ehrliche Notiz dazu, wer dabei deine Daten bekommt. Kamil Adrian Czujowski Co-Founder Performance 2. September 2026 · 16 Min. Lesezeit ## Real User Monitoring Tools 2026: acht Anbieter, ehrlich verglichen Acht Real-User-Monitoring-Tools im Vergleich: Preise, Hosting und was auf dem Endgerät landet. Listenpreise vom 2. September 2026, mit ehrlicher Empfehlung. Kamil Adrian Czujowski Co-Founder Performance 27. August 2026 · 5 Min. Lesezeit ## Deine Seite braucht 800 ms bis zum ersten Byte. Wofür eigentlich? TTFB ist eine einzige Zahl für alles, was vor dem ersten Byte passiert. Wie du sie mit einem Response-Header in Phasen zerlegst, warum Suche und Key-Value-Store eigene Phasen verdient haben und wieso Early Hints dein TTFB schöner aussehen lassen, als es ist. Kamil Adrian Czujowski Co-Founder Performance 6. August 2026 · 4 Min. Lesezeit ## Jeder Deploy kann deine Performance kaputt machen. Merkst du es? Regressionen hängen fast immer an einem Deploy. Warum der Durchschnitt sie versteckt, wie ein Release-Marker aus der CI/CD sie sichtbar macht und was du am p75 wirklich vergleichst. Kamil Adrian Czujowski Co-Founder Performance 30. Juli 2026 · 6 Min. Lesezeit ## Browser-Cache, CDN-Cache, Origin-Cache: was bedeutet das? Wenn jemand sagt: schalt doch den Cache ein. Welchen denn? Es gibt drei, sie liegen hintereinander, und zwischen der ersten und der letzten Schicht liegt eine halbe Sekunde Wartezeit für deine Besucher. Kamil Adrian Czujowski Co-Founder Performance 15. Juli 2026 · 4 Min. Lesezeit ## LCP, FCP, TTFB: alles nur Buzzwords für dich? Fünf Abkürzungen, übersetzt in normale Sprache: was deine Besucher wirklich spüren, wenn diese Zahlen schlecht sind, und warum Google sie ernst nimmt. Kamil Adrian Czujowski Co-Founder Datenschutz 12. Juli 2026 · 4 Min. Lesezeit ## Warum wir auf Europa setzen. Und was das wirklich bedeutet. Kein Cloudflare, kein AWS, kein GCP: warum wir den unbequemeren Weg gegangen sind und was davon konkret bei deinen Daten ankommt. Kamil Adrian Czujowski Co-Founder Mehr laden --- ## https://fastmon.eu/de/cookies/ Cookie-Banner und Einwilligung # Meistens kein Banner. Aber nicht wegen der Cookies. Viele Anbieter schreiben: cookiefrei, also kein Banner. Das Ergebnis stimmt oft, die Begründung fast nie. Entscheidend ist nicht das Cookie, sondern ob auf Informationen zugegriffen wird, die im Endgerät bereits gespeichert sind. In Minimal und Standard speichern wir nichts auf dem Endgerät, und was wir lesen, lag vorher nicht dort. Im Modus Full schreiben wir eine Kennung, und dort brauchst du eine Einwilligung. Hier steht die ganze Herleitung, samt der Gegenauffassung. Die Behauptung ## Kein Cookie, kein Banner. Richtig geraten, falsch begründet. Cookiefrei, also einwilligungsfrei, also kein Banner. Diese Kette steht bei fast jedem datenschutzfreundlichen Analyse-Tool. Das Ergebnis stimmt in vielen Fällen, der Weg dorthin nicht, und wer sich auf die falsche Begründung stützt, merkt das erst, wenn jemand nachfragt. § 25 Abs. 1 TDDDG knüpft nicht an Cookies an, sondern an zwei Vorgänge: das Speichern von Informationen im Endgerät und den Zugriff auf Informationen, die dort bereits gespeichert sind. Ein Cookie ist nur der bekannteste Fall des ersten. Kein Cookie zu setzen erledigt damit die eine Hälfte der Frage, nicht beide. Die zweite Hälfte entscheidet über den Banner: wird auf etwas zugegriffen, das im Endgerät gespeichert ist? Für Minimal und Standard lautet unsere Antwort nein, weil dort nur Statuswerte gelesen werden, die der Browser im Moment des Seitenaufrufs selbst erzeugt. Für den Modus Full lautet sie ja, weil dort eine Kennung geschrieben wird. Wir stellen beides dar, auch die strengere Auffassung, die zu einem anderen Ergebnis kommt. Verantwortlich für die Einbindung bist du, nicht wir. Eine Behauptung in einer Feature-Liste hilft dir in einem Verfahren nicht, eine nachvollziehbare Herleitung schon. Worauf es ankommt ## Vier Fragen, nicht eine. Ob du einen Banner brauchst, hängt an vier Punkten. Cookies sind nur einer davon, und der unwichtigste. ### Cookie oder nicht ist zweitrangig § 25 spricht von Informationen, nicht von Cookies. Entscheidend ist, ob etwas im Endgerät gespeichert oder von dort gelesen wird, unabhängig vom Träger. ### Gespeichert oder zur Laufzeit erzeugt Ein Cookie liegt vorher da. Ein Messwert entsteht erst beim Seitenaufbau. Nur der erste Fall ist nach dem Wortlaut ein Zugriff auf gespeicherte Informationen. ### Fingerprinting oder nicht Statusabfragen kippen in die Einwilligungspflicht, sobald daraus ein Wiedererkennungsmerkmal wird. Deshalb übermitteln wir Klassen statt Rohwerte. ### Welches Preset Minimal und Standard schreiben nichts auf das Gerät. Full schreibt eine Kennung in den sessionStorage, und dort ist die Einwilligung erforderlich. Ebene 1: § 25 TDDDG ## Speichern oder Zugriff, und was davon wir tun. § 25 Abs. 1 TDDDG Die Speicherung von Informationen in der Endeinrichtung des Endnutzers oder der Zugriff auf Informationen, die bereits in der Endeinrichtung gespeichert sind, sind nur zulässig, wenn der Endnutzer auf der Grundlage von klaren und umfassenden Informationen eingewilligt hat. Gesetz über den Datenschutz und den Schutz der Privatsphäre in der Telekommunikation und bei digitalen Diensten Zwei Tatbestände, ein Wort dazwischen: oder. Speichern reicht, Zugriff reicht, beides muss nicht zusammenkommen. Ob die Informationen personenbezogen sind, spielt für § 25 keine Rolle. Die Norm schützt das Endgerät, nicht die Daten. Speichern: in Minimal und Standard tun wir es nicht. Kein Cookie, kein localStorage, kein sessionStorage. Der Schreibpfad wird beim Build aus dem ausgelieferten Bundle entfernt, ist also im Browser nicht vorhanden und nicht bloß abgeschaltet. Zugriff: hier steht das entscheidende Wort im Gesetz, nämlich Informationen, die „bereits in der Endeinrichtung gespeichert sind“. Was unser Skript liest, lag vorher nirgends. Die Timings entstehen während des Seitenaufbaus, window.innerWidth ist der aktuelle Fensterzustand, navigator.connection eine laufende Schätzung des Browsers. Das sind Abfragen an die Laufzeitumgebung, nicht an einen Speicher. Grenzwertig wird es, wenn aus solchen Abfragen ein Wiedererkennungsmerkmal wird, also Fingerprinting. Deshalb übermitteln wir vom Viewport nur eine von sechs Klassen statt des Pixelwerts. Die Entropie sinkt dadurch so weit, dass eine Wiedererkennung aus dieser Kombination praktisch ausgeschlossen ist. Im Modus Full liegt der Fall anders: dort wird eine Kennung in den sessionStorage geschrieben, und ein Schreibvorgang ist unstreitig erfasst. Die Ausnahmen in § 25 Abs. 2 tragen dafür nicht: Nr. 1 erfasst nur die reine Übertragung einer Nachricht, und Nr. 2 verlangt, dass der Zugriff unbedingt erforderlich ist, damit der Anbieter einen vom Nutzer ausdrücklich gewünschten Dienst bereitstellen kann. Eine Performance-Messung ist dieser Dienst nicht. ### Die Gegenauffassung, im Wortlaut Unsere Einordnung ist nicht die einzige vertretbare. Es gibt eine strengere Lesart, und sie ist gut belegt. Hier ist sie, mit dem, was daraus folgen würde, damit du beides gegeneinander halten kannst statt uns zu glauben. DSK, Orientierungshilfe für Anbieter digitaler Dienste Im Unterschied zu den datenschutzrechtlichen Vorschriften begründet § 25 Abs. 1 TDDDG ein Einwilligungserfordernis für das Speichern und/oder Auslesen von Informationen auf bzw. aus einem Endgerät unabhängig von einem Personenbezug der Informationen. Das gilt auch für uns. § 25 hängt nicht am Personenbezug, „wir verarbeiten keine personenbezogenen Daten“ ist hier kein Argument. Die Frage ist allein, ob ein Speichern oder ein Zugriff auf Gespeichertes vorliegt. DSK, zum Auslesen per JavaScript Auch ist es als Zugriff von Informationen auf Endeinrichtungen der Endnutzer:innen zu werten, wenn aktiv beispielsweise mittels JavaScript-Code Eigenschaften eines Endgerätes ausgelesen und für die Erstellung eines Fingerprints an einen Server übermittelt werden. Die strengere Lesart zieht diesen Satz auf jedes Auslesen per JavaScript. Er steht allerdings im Kontext Fingerprinting, und genau dort liegt unsere Abgrenzung: Klassen statt Rohwerte, keine Wiedererkennung, kein Fingerprint. EDSA, Leitlinien 2/2023, lokale Verarbeitung Dies kann beispielsweise bei einer vom Webbrowser bereitgestellten API der Fall sein, bei der lokal generierte Ergebnisse aus der Ferne abgerufen werden können. Das ist der stärkste Punkt gegen uns. Der EDSA bezieht auch lokal erzeugte Ergebnisse einer Browser-API ein. Folgt man ihm, wäre auch unsere Performance-Messung erfasst und eine Einwilligung nötig. EDSA, Leitlinien 2/2023, Zugriff Ein solcher Zugriff fällt eindeutig in den Anwendungsbereich von Artikel 5 Absatz 3 ePrivacy RL, da die zugreifende Stelle das Endgerät ausdrücklich anweist, die Informationen zu übermitteln. Auch dieser Satz stützt die strenge Lesart. Wir halten ihm den deutschen Normtext entgegen, der Informationen verlangt, die bereits gespeichert sind. Welche Auslegung sich durchsetzt, ist gerichtlich nicht geklärt. EDSA, Leitlinien 2/2023, Speichern und Zugriff Die Speicherung von Informationen und der Zugriff auf bereits gespeicherte Informationen müssen nicht beide vorliegen, damit Artikel 5 Absatz 3 ePrivacy RL Anwendung findet. Deshalb genügt „wir setzen keine Cookies“ nicht als Begründung. Der zweite Tatbestand muss eigenständig geprüft werden, und genau das ist der Abschnitt oben. Selbst nachlesen § 25 TDDDG im Volltext EDSA-Leitlinien 2/2023, Version 2.0 DSK-Orientierungshilfe für Anbieter digitaler Dienste Unser Ergebnis In den Modi Minimal und Standard ist nach unserer Einschätzung keine Einwilligung nach § 25 TDDDG erforderlich: es wird nichts im Endgerät gespeichert, und die gelesenen Statuswerte lagen vorher nicht dort. Im Modus Full ist sie erforderlich, weil dort eine Kennung geschrieben wird. Diese Einschätzung ist mit unserem externen Datenschutzbeauftragten geprüft. Ein Restrisiko bleibt, weil zu dieser Konstellation kein Urteil vorliegt. Was auf dem Gerät passiert ## Zeile für Zeile, ohne Beschönigung. Drei Erfassungs-Presets, und was jedes davon auf dem Endgerät des Besuchers tatsächlich tut. Die vorletzte Zeile ist die Trennlinie. | | Minimal | Standard | Full | Beacon-Skript im Browser ausgeliefert liegt im Browser-Cache, wie jedes Skript einer Seite | Ja | Ja | Ja | Performance-API gelesen LCP, INP, CLS, TTFB, Navigation- und Resource-Timing, beim Seitenaufbau erzeugt | Ja | Ja | Ja | Viewport-Klasse und Verbindungsklasse gelesen | Ja | Ja | Ja | Fehlerobjekte gelesen Typ und Anzahl, Stack-Frames ab Standard | Ja | Ja | Ja | Etwas auf das Gerät geschrieben nur Full, eine tab-gebundene Session-ID in sessionStorage._fms | Nein | Nein | Ja | Cookie gesetzt | Nein | Nein | Nein | Langlebige oder seitenübergreifende ID | Nein | Nein | Nein | Einwilligung nach § 25 TDDDG erforderlich wegen des Schreibvorgangs in Full, nicht wegen Cookies | Nein | Nein | Ja Die Trennlinie ist die Zeile „Etwas auf das Gerät geschrieben“. Darüber stehen Werte, die beim Seitenaufbau entstehen und vorher nicht im Gerät lagen. Darunter steht ein Schreibvorgang, und der ist unstreitig einwilligungspflichtig. Ebene 2: DSGVO ## Anwendbar, und zwar wegen der IP. § 25 TDDDG regelt den Zugriff auf das Gerät, die DSGVO die Verarbeitung danach. Beide werden getrennt geprüft, und die Antworten dürfen auseinanderfallen: kein Zugriff nach TDDDG, aber DSGVO anwendbar, ist genau unser Fall. Die Payload-Werte selbst halten wir für nicht personenbeziehbar: nur das Land statt der IP, Klassen statt Rohwerten, Pfad ohne Query-String, keine User-ID, keine langlebige Wiedererkennung. Anwendbar ist die DSGVO trotzdem, und zwar wegen eines Datums, das wir gar nicht abfragen. Die IP-Adresse wird bei jeder Anfrage im HTTP-Header mitgesendet, und sie ist nach dem EuGH-Urteil Breyer ein personenbezogenes Datum. Rechtsgrundlage ist die Interessenabwägung nach Art. 6 Abs. 1 lit. f DSGVO, nicht die Einwilligung. Auf der einen Seite stehen Stabilität, Performance-Messung, Basisstatistik und Fehlersuche, auf der anderen das Schutzinteresse des Besuchers. Das Risiko für ihn ist gering: kein Cross-Site-Tracking, keine Profilbildung, kein Fingerprinting. Diese Abwägung würde kippen, sobald es um eine Analyse des Nutzerverhaltens im Sinne einer Profilbildung geht. Dafür verlangt die Rechtsprechung durchgängig eine Einwilligung, von Planet49 über die BGH-Entscheidung zur Cookie-Einwilligung bis zum EuGH-Urteil zu Meta. Sie trägt hier gerade deshalb, weil fastmon kein Profil baut. Diese Abwägung trägt nur unter Bedingungen, und die halten wir ein: IP und User-Agent werden ausschließlich zur Entgegennahme der Anfrage verarbeitet und in unter einer Sekunde verworfen, in den gespeicherten Analysedaten steht keine wiederherstellbare IP, und wir geben die Daten nicht an Dritte weiter. ### Zwei Einsatzszenarien, zwei Ergebnisse Große, allgemeine Seiten Ein Shop mit sechsstelligen Besucherzahlen, generische Pfade wie /kategorie/schuhe, viele Besucher pro Pfad und Land. Ein einzelner Datensatz passt auf tausende Personen. Personenbeziehbarkeit in der Regel nicht gegeben Kleine oder sehr spezifische Seiten Ein B2B-Portal mit wenigen Besuchern am Tag, sprechende Pfade wie /kunden/nordwind-gmbh/vertrag oder /bewerbung/status. Land, Gerät und Pfad zusammen können auf eine Person zulaufen. Personenbeziehbarkeit möglich, eigene Prüfung nötig Diese Einordnung ist eine Einzelfallbetrachtung und Aufgabe des Verantwortlichen, also deine. Wir liefern die Datenlage und die Dokumentation dafür, die Bewertung können wir dir nicht abnehmen. Praktisch entscheidet sie über Rechtsgrundlage, Informationspflichten und Löschfristen. In beiden Szenarien gehört fastmon in deine Datenschutzerklärung. IP-Adresse und Edge ## Die Stelle, an der es auch bei uns grenzwertig bleibt. Die IP-Adresse ist nach der Rechtsprechung des Europäischen Gerichtshofs ein personenbezogenes Datum. Übertragen wird sie bei jedem Seitenaufruf, das ist technisch unvermeidbar und für die Auslieferung der Seite auch unproblematisch. Interessant wird es, wenn man sie benutzt, um daraus etwas abzuleiten. Genau das tut unser Edge, an mehreren Stellen: Aus der IP löst er den Ländercode auf und prüft, ob sie zu einem Rechenzentrum oder einem verifizierten Crawler gehört. Aus dem User-Agent leitet er grobe Klassen ab: Browser, Hauptversion, Betriebssystem, Gerätetyp, dazu eine Bot-Einstufung. Die Client Hints des Browsers prüft er auf Widersprüche, um gespoofte Zugriffe zu erkennen. Den Referrer verdichtet er auf Medium und Quelle, ohne Suchbegriffe. Und er berechnet den Stitch. Danach verwirft er IP, rohen User-Agent, Client Hints und Referrer-URL, in weniger als einer Sekunde, ohne sie zu speichern oder zu loggen. In die fastmon-Anwendung gelangen nur die Ergebnisse. Das ist der Zweck der Architektur: die Anwendung soll die Rohdaten nie sehen, und automatisierte Tests prüfen, dass das so bleibt. Und hier liegt der ehrliche Vorbehalt. Jede dieser Ableitungen ist eine Auswertung, und sie findet statt, bevor die Anwendung etwas sieht. Dass wir nur das Extrakt weitergeben, verlagert den Personenbezug aus der Anwendung heraus. Es macht die Ableitung selbst nicht ungeschehen: für den Bruchteil einer Sekunde wurden personenbezogene Daten verarbeitet. Wir stützen diesen Schritt auf dieselbe Interessenabwägung: kurze Verarbeitung, sofortiges Verwerfen, kein wiederherstellbarer Rest in den gespeicherten Daten. Ob das einer künftigen gerichtlichen Wertung standhält, ist offen. Wir halten es für wahrscheinlicher, dass die Anforderungen mittelfristig steigen als sinken. Wer dir hier Gewissheit verkauft, verkauft dir eine Meinung. ### Ein Seitenaufruf, Schritt für Schritt - 01 #### Browser fordert das Skript an Der Request enthält die IP-Adresse, wie jeder HTTP-Request. Technisch bedingte Übertragung, für die Auslieferung unproblematisch. - 02 #### Beacon liest im Browser Performance-API, Viewport-Klasse, Verbindungsklasse, Fehlerobjekte. Statuswerte der Laufzeitumgebung, die vorher nicht im Gerät lagen. - 03 #### Edge leitet ab und verwirft Ländercode und Rechenzentrums-Check aus der IP, Geräteklassen und Bot-Einstufung aus dem User-Agent, Medium und Quelle aus dem Referrer, Stitch. Danach sind IP, User-Agent, Client Hints und Referrer-URL weg, in unter einer Sekunde, ohne Log. Das ist der grenzwertige Schritt. - 04 #### Anwendung sieht nur das Extrakt Land, Klassen, Metriken, Pfad ohne Query-String. Keine rohe IP, kein User-Agent-String, kein persistenter Identifikator. ### Der Stitch bleibt grenzwertig Für die Zählung eindeutiger Besucher berechnet der Edge ein kurzes pseudonymes Signal: HMAC-SHA256 aus IP, User-Agent, dem Hash deiner Einbindung und der Domain, unter einem Salt, der alle 24 Stunden neu erzeugt wird und den Arbeitsspeicher des Edge nie verlässt, kein Log, keine Festplatte, keine API. Pro Domain unterschiedlich. Was das Signal schützt, ist dabei nicht die Mathematik, sondern der Salt: Aus dem gespeicherten Wert allein lässt sich keine IP gewinnen, wer aber den Salt hätte, könnte Kandidaten durchprobieren und einen Verdacht bestätigen. Diesen Salt hat niemand: er existiert nur im laufenden Edge-Prozess, demselben, der die IP bei jedem Request ohnehin sieht und verwirft. Nach der Rotation ist er unwiederbringlich weg, und ab da kann niemand mehr zuordnen, auch wir nicht. Der Stitch entsteht am Edge und nicht im Browser, ist also keine Frage des § 25, sondern der DSGVO. Wir behandeln ihn als personenbezogenes Datum, Pseudonymisierung statt Anonymisierung, und stützen ihn auf die Interessenabwägung. Das reduziert das Risiko, es beseitigt es nicht: ein Signal, das Seitenaufrufe über 24 Stunden zusammenführt, ist eine Wiedererkennung, und mit sehr spezifischen Pfaden kann daraus ein Personenbezug entstehen. store_stitch=false schaltet das Signal ab, und das Minimal-Preset enthält es ohnehin nicht. Der Stitch ist auch der Grund, warum fastmon ohne Sessions auskommt. Eine echte Session-ID wäre genauer: sie kennt Inaktivität, übersteht einen IP-Wechsel und trennt Besucher hinter derselben Firmen-IP. Dafür muss sie auf dem Gerät gespeichert werden, und damit beginnt die Einwilligungspflicht. Für Perzentile braucht es gar keine Identität, und für die Besucherzählung ist der Stitch genau genug: geteilte IPs verschmelzen zu einem Besucher, wechselnde IPs zählen doppelt, die absolute Zahl trägt eine kleine Unschärfe, die Trends bleiben stabil. Deshalb raten wir von Sessions ab, solange du sie nicht wirklich brauchst. Erst das Full-Preset schreibt eine Session-ID, und dort gehört die Einwilligung dazu. Technische Datenschutz-Doku: Edge, Stitch und jede Einstellung Was wir nicht behaupten Dass die Frage damit für dich erledigt ist. Unsere Einschätzung deckt unsere Architektur ab, nicht deinen Einsatz. Welches Preset du fährst, wie spezifisch deine Pfade sind und wie viele Besucher du hast, entscheidet mit. Diese Bewertung bleibt bei dir, und die Rechtslage kann sich ändern. Wenn du trotzdem gaten willst ## Was ein Opt-out dich kostet. Manche Betreiber legen fastmon trotzdem hinter die Einwilligung, aus Vorsicht oder weil sie den Modus Full nutzen. Auch dann bist du besser dran als mit cookie-basierten Tools: dort kostet jedes Opt-out zusätzlich die Wiedererkennung, bei uns nur Stichprobe. Bei fastmon - Lehnt ein Besucher ab, wird für diesen Besuch nichts gemessen, genau wie es sein muss - Die Stichprobe wird kleiner, die Verteilung bleibt intakt. Für Perzentile wie den p75 ist das der entscheidende Punkt - Keine doppelt gezählten Nutzer, keine verwaisten Sessions, weil es ohnehin keine langlebige Wiedererkennung gibt, die zerbrechen könnte - Deine Zahlen werden kleiner, nicht schief, unabhängig von der Höhe der Opt-out-Rate Bei cookie-basierten Tools - Jedes Opt-out kostet zusätzlich die Wiedererkennung, auf der die Nutzerzahlen aufbauen - Wiederkehrende Besucher werden zu neuen Besuchern, die Unique-Zahlen laufen nach oben weg - Sessions brechen mitten im Funnel ab und tauchen als neue Sessions wieder auf - Die Verzerrung wächst mit der Opt-out-Rate und ist nachträglich nicht korrigierbar Restrisiko ## Ein Katz-und-Maus-Spiel, offen ausgesprochen. Die Geschichte des Web-Trackings ist eine Kette aus Technik und Urteil. Erst wurde einfach gemessen. Dann verlangten Gerichte einen Opt-out in der Datenschutzerklärung. Dann einen Hinweis-Banner. Dann kippte „wer weitersurft, stimmt zu“. Dann kam der Consent-Banner, den wir heute kennen. Wir gehen davon aus, dass die Anforderungen weiter steigen. Deshalb bauen wir so, dass eine Verschärfung uns nicht kalt erwischt: das Beacon lässt sich vollständig hinter eine Einwilligung schieben, die Presets nach unten schalten, und die Datenbasis ist schmal genug, dass sie auch nach einer Verschärfung noch trägt. Restrisiko bleibt trotzdem, und zwar bei jedem Tool. Wer moderne IT einsetzt, akzeptiert es an vielen Stellen gleichzeitig, meist ohne darüber zu sprechen: Standardvertragsklauseln für US-Dienste, Transfer-Folgenabschätzungen, deren Grundlage sich ändern kann, Office-Pakete, die kein Unternehmen morgen abschaltet. Die ehrliche Frage ist nicht, ob du Restrisiko trägst, sondern welches, wie groß es ist, und ob du es bewusst getragen hast. Unser Beitrag dazu ist Nachvollziehbarkeit. Kein Anbieter mit US-Jurisdiktion im Datenpfad, damit die Transfer-Frage bei uns gar nicht erst entsteht. Rohdaten, die die Anwendung nie erreichen. Und eine Seite wie diese, auf der die Gegenauffassung im Wortlaut steht. ### Wie sich der Maßstab verschoben hat - Stufe 1 Gemessen wurde einfach, ohne Information an den Besucher - Stufe 2 Opt-out in der Datenschutzerklärung, per Urteil verlangt - Stufe 3 Hinweis-Banner nach dem Motto „wer weitersurft, stimmt zu“ - Stufe 4 Diese Konstruktion gekippt, echter Consent-Banner nötig - Stufe 5 Streit darüber, was als Zugriff auf das Endgerät gilt. Hier stehen wir - Stufe 6 Offen. Unsere Einschätzung ist die eine Lesart, die strengere existiert daneben Was du tun solltest ## Sechs Schritte, dann ist es dokumentiert. Keine Raketentechnik, aber es muss gemacht und nachweisbar sein. Am besten in dieser Reihenfolge. - 01 ### Preset bewusst wählen Minimal und Standard bleiben schreibfrei. Full schreibt eine Kennung und braucht dann eine Einwilligung. Das ist der eigentliche Hebel, alles andere folgt daraus. - 02 ### fastmon in deine Datenschutzerklärung Anbieter, Zweck, Rechtsgrundlage (Art. 6 Abs. 1 lit. f), Aufbewahrung und Empfänger. In Minimal und Standard ist das der Schritt, der den Banner ersetzt. - 03 ### Bei Full hinter die Einwilligung legen Über deine Consent-Management-Plattform oder über grantConsent(), damit die Kennung erst nach Opt-in geschrieben wird. Kategorie Statistik, nicht „technisch notwendig“. - 04 ### Personenbeziehbarkeit für deinen Fall bewerten Wie spezifisch sind deine Pfade, wie viele Besucher hast du pro Pfad und Land? Das Ergebnis dokumentieren. Das ist der Teil, den dir niemand abnimmt. - 05 ### Keine personenbezogenen Daten in erfassbare Felder Nicht in URL-Pfade, Query-Strings, UTM-Parameter, Tag-Werte und Fehler-Kontexte. Kundennummern, Namen und E-Mail-Adressen gehören nicht in eine URL, die gemessen wird. - 06 ### Aufbewahrung auf dein Maß setzen 90 Tage sind der Default, kürzer ist einstellbar. Länger nur, wenn du begründen kannst, warum du die Daten so lange brauchst. Interaktiver Check ## Brauchst du einen Banner? Drei Fragen. Drei Fragen in der Reihenfolge, in der auch eine Datenschutzbeauftragte prüft: erst was auf dem Gerät passiert, dann was in deinen Web-Adressen steht, dann wie viele Menschen dahinterstehen. Was darf fastmon bei dir erfassen? Der Erfassungs-Modus steht im Dashboard bei der Application. Wenn du nichts umgestellt hast, ist es Standard. Minimal Nur die Kern-Performance. Kein Besuchersignal, keine Fehlerdetails. Standard Die Voreinstellung. Zusätzlich Besucherzählung, Netzwerkaufrufe und Fehlerdetails. Full Alles, und zusätzlich wird eine Kennung im Browser des Besuchers abgelegt. Verrät eine deiner Web-Adressen, um wen es geht? Gemeint ist die Adresse selbst, also was in der Browser-Zeile steht. Enthält sie Namen, Kunden-, Vertrags- oder Vorgangsnummern? Nein, meine Adressen sind allgemein Zum Beispiel /kategorie/schuhe oder /blog/artikel. Daran ist nicht zu erkennen, wer die Seite aufgerufen hat. Ja, bei manchen steht es drin Zum Beispiel /kunden/nordwind-gmbh/vertrag oder /bewerbung/status-4711. Aus der Adresse geht hervor, um wen oder was es geht. Wie viele Menschen rufen eine einzelne Seite auf? Eine grobe Schätzung genügt. Es geht um die Frage, ob ein einzelner Messwert auf viele Menschen passt oder nur auf einen. Viele, mindestens einige hundert im Monat Ein einzelner Messwert könnte von sehr vielen Menschen stammen. Wenige, manchmal nur eine Handvoll Ein einzelner Messwert könnte einer bestimmten Person zuzuordnen sein. Die drei möglichen Ergebnisse Kein Banner nötig Nach unserer Einschätzung brauchst du keine Einwilligung: es wird nichts auf dem Endgerät gespeichert, die gelesenen Werte entstehen erst beim Seitenaufruf, und deine Datenlage lässt keinen Personenbezug entstehen. An die Stelle des Banners tritt die Nennung in deiner Datenschutzerklärung. - fastmon in die Datenschutzerklärung: Anbieter, Zweck, Rechtsgrundlage Art. 6 Abs. 1 lit. f, Aufbewahrung, Empfänger - Das Ergebnis dieser Prüfung dokumentieren, damit du es später begründen kannst - Personenbezogene Daten aus URL-Pfaden, Query-Strings und UTM-Parametern heraushalten Einwilligung nötig Das Full-Preset schreibt eine tab-gebundene Session-ID in den sessionStorage. Ein Schreibvorgang auf dem Endgerät ist unstreitig von § 25 Abs. 1 TDDDG erfasst, und die Ausnahmen des Abs. 2 greifen für eine Performance-Messung nicht. Entweder du holst die Einwilligung ein, oder du wechselst auf Standard. - fastmon in deiner Consent-Management-Plattform anlegen, Kategorie Statistik, nicht „technisch notwendig“ - Das Beacon erst nach Opt-in laden, oder session_consent auf deferred setzen und nach Zustimmung grantConsent() aufrufen - Alternativ auf das Standard-Preset wechseln, dann entfällt der Schreibvorgang ganz Grenzwertig, eigene Prüfung nötig Nach § 25 TDDDG brauchst du nach unserer Einschätzung keine Einwilligung, weil nichts auf dem Endgerät gespeichert wird. Die DSGVO-Frage ist bei dir aber offen: mit sprechenden Pfaden oder wenigen Besuchern kann die Summe der Merkmale auf eine einzelne Person zulaufen. Diese Bewertung liegt bei dir, wir können sie dir nicht abnehmen. - Sprechende Pfade entschärfen: IDs und Namen raus aus der URL, oder collect_query_keys ausschalten - store_stitch abschalten, dann trägt die gespeicherte Zeile kein Besuchersignal mehr - Wenn Unsicherheit bleibt: fastmon hinter die Einwilligung legen und in der CMP als Statistik führen - Die Bewertung mit deiner Datenschutzbeauftragten dokumentieren Dieses Ergebnis ist unsere Auffassung auf Basis deiner Angaben und keine Rechtsberatung. Lass es vor dem Livegang von deiner Datenschutzbeauftragten oder einer Juristin bestätigen. Verantwortlich für die Einbindung bleibst du als Betreiber der Website. Check neu starten Die Auswertung läuft vollständig in deinem Browser. Wir erfahren weder deine Antworten noch dein Ergebnis. Das Sternchen ## Was das Sternchen in unserem Footer bedeutet. Auf jeder Seite steht hinter „keine Cookies“ ein Sternchen. Das ist die Kurzfassung von allem, was oben steht. Hier ist die Langfassung, Satz für Satz. „In den Modi Minimal und Standard setzt fastmon kein Cookie und speichert nichts auf dem Endgerät“ heißt genau was? Dass in diesen beiden Modi kein Cookie gesetzt und nichts geschrieben wird, weder localStorage noch sessionStorage. Der Schreibpfad ist im ausgelieferten Skript nicht enthalten, er wird beim Build entfernt. Das ist prüfbar, nicht nur zugesagt. „Gelesen werden nur Statuswerte, die der Browser zur Laufzeit selbst erzeugt“ heißt genau was? Dass die gelesenen Werte vor dem Seitenaufruf nirgends im Gerät lagen. Timings entstehen beim Seitenaufbau, die Fensterbreite ist der aktuelle Zustand, die Verbindungsklasse eine laufende Schätzung. Nach unserer Einschätzung ist das kein Zugriff auf gespeicherte Informationen im Sinne des § 25 TDDDG. Die strengere Gegenauffassung steht oben im Wortlaut. „Im Modus Full wird eine Kennung geschrieben“ heißt genau was? Dass Full eine tab-gebundene Session-ID in sessionStorage._fms ablegt, die beim Schließen des Tabs verfällt. Das ist ein Schreibvorgang, und dafür brauchst du eine Einwilligung. Minimal und Standard tun das nicht. FAQ ## Cookie-Banner und Einwilligung, beantwortet. Die Fragen, die eine Datenschutzbeauftragte zuerst stellt, mit den Antworten, die wir auch dann geben, wenn sie unbequem sind. ### Brauche ich für fastmon einen Cookie-Banner? Nein, in den Modi Minimal und Standard nicht. Es wird nichts auf dem Endgerät gespeichert, und die gelesenen Werte lagen vorher nicht dort. Es genügt, fastmon in deiner Datenschutzerklärung zu nennen. Im Modus Full brauchst du eine Einwilligung, weil dort eine Kennung in den sessionStorage geschrieben wird. Diese Einordnung ist mit unserem externen Datenschutzbeauftragten geprüft, ein Restrisiko bleibt, weil kein Urteil dazu vorliegt. ### Wenn ich einen Banner nutze: muss fastmon namentlich drinstehen? Ein bestimmter Produktname ist nicht zwingend. Zwingend ist, dass klar hervorgeht, welche Daten zu welchem Zweck durch wen verarbeitet werden und wie lange sie aufbewahrt werden. Das sind die normalen Anforderungen an eine Einwilligung. In der Praxis ist die namentliche Nennung der einfachste Weg, sie zu erfüllen, und sie hilft dir zugleich bei den Informationspflichten aus Art. 13 und 14 DSGVO. ### Warum reicht „wir setzen keine Cookies“ nicht als Begründung? Weil § 25 TDDDG zwei Vorgänge nennt: Speichern im Endgerät und Zugriff auf dort bereits Gespeichertes. Laut EDSA müssen nicht beide vorliegen. Kein Cookie zu setzen erledigt den ersten. Der zweite muss eigenständig geprüft werden, und genau diese Prüfung machen die meisten Anbieter nicht, wenn sie mit Cookiefreiheit argumentieren. ### Wir verarbeiten doch keine personenbezogenen Daten. Zählt das für § 25? Nein. Die Datenschutzkonferenz hält ausdrücklich fest, dass § 25 unabhängig von einem Personenbezug greift, die Norm schützt das Endgerät und nicht die Daten. Für § 25 kommt es nur darauf an, ob gespeichert oder auf Gespeichertes zugegriffen wird. Der Personenbezug entscheidet die zweite, davon getrennte Frage nach der DSGVO. ### Was genau liest das Beacon aus dem Browser? Die Performance-API für LCP, INP, CLS, TTFB und die Timings, die Fensterbreite als eine von sechs Klassen, die Verbindungsklasse, den Referrer, die Seiten-URL sowie Fehlertyp und -anzahl. Alle diese Werte entstehen im Moment des Seitenaufrufs, keiner lag vorher im Gerät. navigator.userAgent rufen wir nicht auf, IP und User-Agent erreichen uns nur als HTTP-Header. ### Es gibt doch die strengere Auffassung. Warum folgt ihr ihr nicht? Weil der deutsche Normtext Informationen verlangt, die bereits in der Endeinrichtung gespeichert sind, und das trifft auf Laufzeitwerte nicht zu. Die strengere Lesart des EDSA bezieht lokal erzeugte Ergebnisse einer Browser-API mit ein; wir stellen sie oben im Wortlaut dar, weil sie vertretbar ist. Sollte sie sich durchsetzen, ändert sich unsere Empfehlung, und das Beacon lässt sich vollständig hinter eine Einwilligung schieben. ### Ist das Auslesen der Fensterbreite nicht Fingerprinting? Genau dort verläuft die Grenze, und deshalb übermitteln wir keinen Pixelwert, sondern eine von sechs Klassen. In Kombination mit Land, Browser-Familie und Geräteklasse bleibt die Entropie so niedrig, dass eine Wiedererkennung praktisch ausgeschlossen ist. Kein Canvas, keine Font-Enumeration, keine Sensoren, kein Audio. ### Und der Stitch? Der entsteht am Edge und nicht im Browser, ist also keine § 25-Frage, sondern eine der DSGVO. Wir behandeln ihn als personenbezogenes Datum und stützen ihn auf die Interessenabwägung nach Art. 6 Abs. 1 lit. f. HMAC-SHA256, Salt rotiert alle 24 Stunden und verlässt den Arbeitsspeicher des Edge nie, pro Domain unterschiedlich, nicht umkehrbar. Grenzwertig bleibt er trotzdem, mit sehr spezifischen Pfaden kann ein Personenbezug entstehen. store_stitch=false schaltet ihn ab. ### Warum ist die DSGVO überhaupt anwendbar, wenn die Werte anonym sind? Wegen der IP-Adresse. Die wird bei jeder Anfrage im HTTP-Header mitgesendet, auch wenn wir sie nicht abfragen, und sie ist nach dem EuGH-Urteil Breyer ein personenbezogenes Datum. Rechtsgrundlage ist die Interessenabwägung nach Art. 6 Abs. 1 lit. f, und sie trägt, weil IP und User-Agent nur zur Entgegennahme verarbeitet und in unter einer Sekunde verworfen werden. ### Was passiert mit meinen Zahlen, wenn ich fastmon doch hinter die Einwilligung lege? Sie werden kleiner, nicht schief. fastmon misst aggregierte Feld-Performance per Stichprobe, und eine kleinere Stichprobe bleibt aussagekräftig, solange sie nicht systematisch verzerrt ist. Weil ohnehin keine langlebige Wiedererkennung existiert, brechen keine Sessions und laufen keine Unique-Zahlen weg. Bei cookie-basierten Tools kostet dich jedes Opt-out zusätzlich die Wiedererkennung. ### Braucht ihr einen Auftragsverarbeitungsvertrag? Wenn in deinem Einsatz personenbezogene Daten verarbeitet werden, ja, dann sind wir Auftragsverarbeiter nach Art. 28 DSGVO. Der AVV wird mit der Registrierung geschlossen und liegt öffentlich vor. Weil über die IP im Header ohnehin personenbezogene Daten im Spiel sind, schließen wir ihn in jedem Fall. ### Muss ich fastmon in meiner Datenschutzerklärung nennen? Ja, das ist der Schritt, der in Minimal und Standard an die Stelle des Banners tritt. Hinein gehören Anbieter, Zweck, Rechtsgrundlage nach Art. 6 Abs. 1 lit. f, Aufbewahrung und Empfänger. Die Informationspflichten aus Art. 13 und 14 DSGVO gelten, sobald personenbezogene Daten verarbeitet werden, und über die IP im Header ist das der Fall. ### Wie lange darf ich die Daten aufbewahren? Löschen, sobald sie für den Zweck nicht mehr gebraucht werden und keine gesetzliche Aufbewahrungspflicht entgegensteht. Wie lang das ist, musst du begründen, und es hängt von deinem Fall ab. In fastmon sind 90 Tage der Default, kürzer ist einstellbar, bis 13 Monate auf Enterprise-Plänen. ### Was, wenn ein Gericht das später anders sieht? Damit rechnen wir, und die Historie oben zeigt, warum. Deshalb hängt bei fastmon nichts an der Annahme, dass die heutige Auslegung hält: das Beacon lässt sich vollständig hinter eine Einwilligung schieben, die Presets nach unten schalten, und die Datenbasis ist schmal genug, dass sie auch dann noch trägt. Was sich ändern würde, ist unsere Empfehlung, nicht dein Setup. ### Ist das hier Rechtsberatung? Nein. Diese Seite beschreibt, wie fastmon gebaut ist und wie wir die Rechtslage lesen, geprüft mit unserem externen Datenschutzbeauftragten. Die Beurteilung für deinen Einsatz triffst du, idealerweise mit deiner eigenen Datenschutzbeauftragten. Keine Rechtsberatung. Diese Seite gibt den Stand unserer eigenen Prüfung wieder, geprüft mit unserem externen Datenschutzbeauftragten, und beschreibt, wie fastmon gebaut und dokumentiert ist. Zu dieser Konstellation liegt keine gerichtliche Entscheidung vor; ein Restrisiko bleibt. Rechtslage und Aufsichtspraxis ändern sich, und die Beurteilung für deinen konkreten Einsatz obliegt dir als Verantwortlichem. Verbindlich sind Datenschutz und AVV . ## 100 % EU, gehostet in Deutschland. Kein Cloudflare, kein AWS, kein GCP. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/datenschutz/ Rechtliches # Datenschutzerklärung Stand: 17. Juli 2026 Diese Datenschutzerklärung informiert Sie gemäß Art. 13 und 14 DSGVO über die Verarbeitung personenbezogener Daten durch die fastmon labs UG (haftungsbeschränkt) im Zusammenhang mit dem Besuch unserer Webseiten und der Nutzung unseres Software-as-a-Service-Dienstes „fastmon" (Real User Monitoring). ## 1. Verantwortlicher fastmon labs UG (haftungsbeschränkt) Stresemannallee 4, 30173 Hannover, Deutschland Amtsgericht Hannover, HRB 230880 Geschäftsführer: Kamil Adrian Czujowski, Lucas Röhrs E-Mail Datenschutz: privacy@fastmon.eu ## 2. Datenschutzbeauftragter Ein Datenschutzbeauftragter ist gemäß Art. 37 DSGVO nicht erforderlich. Zentraler Kontakt für Datenschutzanfragen ist privacy@fastmon.eu. ## 3. Aufsichtsbehörde Zuständige Aufsichtsbehörde ist der Landesbeauftragte für den Datenschutz Niedersachsen (LfD Niedersachsen), Prinzenstraße 5, 30159 Hannover. ## 4. Verarbeitung beim Besuch unserer Webseiten (fastmon.eu, docs.fastmon.eu, app.fastmon.eu) Bei jedem Aufruf einer unserer Webseiten erhebt unser Reverse-Proxy technische Daten (Zeitstempel, abgerufene Ressource, HTTP-Status, Referrer-Quelle, abgeleiteter Country-Code). Quell-IP-Adressen werden nicht in Logs gespeichert , sondern bereits am Edge entfernt. Logs werden maximal 7 Tage aufbewahrt und dienen ausschließlich technischen Zwecken (Sicherheit, Fehleranalyse). Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse am technischen Betrieb). Auf unseren Webseiten werden keine Tracking-Cookies und keine Web-Analytics-Tools eingesetzt, die personenbezogene Daten verarbeiten. ## 5. Real User Monitoring (fastmon-Dienst) Wenn Sie eine Website besuchen, in die das fastmon-Beacon-Script eingebunden ist, werden technische Performance-Metriken erhoben. Verantwortlicher für diese Verarbeitung ist der jeweilige Betreiber der Website, mit dem wir einen Auftragsverarbeitungsvertrag gemäß Art. 28 DSGVO abgeschlossen haben. ### 5.1 Was wird erhoben Im Erfassungs-Modus Standard (Voreinstellung) werden ausschließlich aggregierte, datensparsame Telemetrie-Daten erhoben: - Core Web Vitals (LCP, INP, CLS, TTFB, FCP) und weitere technische Performance-Metriken - Browser-Familie und Major-Version (z.B. „Chrome 124"), Betriebssystem-Kategorie, Geräte-Klasse, Viewport-Klasse - Country-Code (ISO 3166, z.B. „DE"), abgeleitet aus der IP-Adresse - Pfad der besuchten Seite (Query-String und Anker werden verworfen) - Referrer-Kategorie (z.B. „Google / search"), nicht die vollständige Referrer-URL - UTM-Parameter (gekürzt auf 64 Zeichen), Klick-ID-Parameter-Name (nicht der Wert) ### 5.2 Was nicht erhoben wird - Keine Cookies; in den Modi Light und Standard wird nichts auf dem Endgerät gespeichert - Keine persistenten Identifier, keine User-IDs, keine Cross-Site-Identifier - Keine rohe IP-Adresse (am Edge in weniger als 1 Sekunde verworfen) - Kein roher User-Agent-String - Keine Personennamen, E-Mail-Adressen, Formulareingaben, Seiteninhalt, Klick-Heatmaps, Maus-Bewegungen, Keystrokes, Session-Replays ### 5.3 Edge-Stripping und Stitch-Identifier Die IP-Adresse und der rohe User-Agent werden ausschließlich am Edge-Server transient verarbeitet (weniger als 1 Sekunde im Arbeitsspeicher) zur Ableitung von Country-Code und Browser-Kategorie. Anschließend werden sie unwiderruflich verworfen. Eine Speicherung in der Anwendung, Datenbank oder in Logs findet zu keinem Zeitpunkt statt. Zur cookielosen Zählung eindeutiger Besucher innerhalb einer Browser-Sitzung wird ein serverseitig berechneter Hash-Wert verwendet (Stitch). Dieser ist ein HMAC-SHA256 auf Basis eines geheimen Salts, der alle 24 Stunden rotiert wird und ausschließlich im Arbeitsspeicher des Edge-Servers existiert. Eine Zusammenführung von Seitenaufrufen ist auf maximal 24 Stunden begrenzt; danach bricht die Wiedererkennungskette ab. Eine site- oder geräteübergreifende Wiedererkennung ist technisch ausgeschlossen. ### 5.4 Aufbewahrung Default-Aufbewahrungsdauer der Telemetriedaten beträgt 90 Tage. Auf Enterprise-Plänen pro Site bis 13 Monate konfigurierbar. ### 5.5 TDDDG / Einwilligung In den Erfassungs-Modi Light und Standard wird nichts auf dem Endgerät des Endnutzers gespeichert: kein Cookie, kein localStorage, kein sessionStorage. Der entsprechende Programmpfad ist im ausgelieferten Beacon nicht enthalten. Gelesen werden ausschließlich Statuswerte, die der Browser im Zuge des Seitenaufrufs selbst erzeugt (Performance-Schnittstellen, Viewport-Klasse, Verbindungsklasse, Fehlerereignisse). Diese Werte sind vor dem Seitenaufruf nicht in der Endeinrichtung gespeichert. Nach unserer Auffassung liegt damit weder eine Speicherung noch ein Zugriff auf bereits gespeicherte Informationen im Sinne des § 25 Abs. 1 TDDDG vor. Eine strengere Auslegung, die auch lokal erzeugte Ergebnisse von Browser-Schnittstellen einbezieht, wird vertreten; eine gerichtliche Klärung liegt nicht vor. Im Erfassungs-Modus Full wird eine tab-gebundene Session-Kennung im sessionStorage des Browsers gespeichert. Dieser Schreibvorgang ist von § 25 Abs. 1 TDDDG erfasst und setzt eine Einwilligung des Endnutzers voraus. Er kann aufgeschoben werden, bis die Consent-Management-Plattform des Website-Betreibers grantConsent() aufruft. Die Beurteilung der Einwilligungspflicht für die konkrete Einbindung obliegt dem Betreiber der jeweiligen Website. Die vollständige Herleitung mit Normtext und Quellen finden Sie unter Cookies, TDDDG und Einwilligung . ## 6. Dashboard-Nutzung (Konto-Daten) Wenn Sie sich als Kunde bei fastmon registrieren, verarbeiten wir folgende Daten als Verantwortlicher: - Name, E-Mail-Adresse, Passwort-Hash, Organisations-Zugehörigkeit, Login-Zeitpunkte - Rechnungsdaten: Firmenname, Anschrift, USt-ID, Ansprechpartner, Rechnungsbetrag, Zahlungsdaten Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung), für Rechnungsdaten zusätzlich Art. 6 Abs. 1 lit. c DSGVO und § 257 HGB sowie § 147 AO (10 Jahre Aufbewahrungspflicht). ## 7. Optionale AI-Chat-Funktion Im Dashboard kann optional eine AI-Chat-Funktion aktiviert werden, die LLM-gestützte Auswertungen ermöglicht. Bei Aktivierung werden Nutzer-Prompts und Konto- bzw. Telemetrie-Kontextdaten an Mistral AI SAS (Paris, Frankreich) übermittelt. Die Verarbeitung erfolgt ausschließlich an EU-Endpunkten. Inputs und Outputs werden nicht zum Modell-Training verwendet. Die Funktion ist standardmäßig deaktiviert. ## 8. Auftragsverarbeiter und Empfänger Wir setzen folgende Auftragsverarbeiter und Empfänger ein. Sämtliche sind in der EU bzw. im EWR ansässig. | Anbieter | Sitz | Zweck | Hetzner Online GmbH | DE | Hosting, Storage, Backup | sevdesk GmbH | DE | Buchhaltung, Rechnungserstellung | Mollie B.V. (eigenständiger Verantwortlicher) | NL | Zahlungsabwicklung (PSD2) | Lettermint B.V. | NL | Transaktionale E-Mails | Soverin B.V. | NL | Geschäftsmail-Hosting | Mistral AI SAS | FR | LLM-Inferenz (nur bei Opt-in) | BunnyWay d.o.o. (bunny.net) | SI | Autoritativer DNS-Dienst | smoxy GmbH | DE | Ingress | ScaleCommerce GmbH | DE | Hosting | All Quiet GmbH | DE | On-Call-Tool (intern) Für interne Zwecke ohne Bezug zu Kunden- oder Besucherdaten (Quellcode-Verwaltung, Projektmanagement, Entwicklungswerkzeuge) setzen wir weitere Anbieter ein, darunter Anbieter mit Sitz in den USA (GitHub, Linear, Anthropic). Diese erhalten keine personenbezogenen Daten von Websitebesuchern, Kunden oder deren Endnutzern. Eine Übersicht aller Anbieter finden Sie unter fastmon.eu/de/subprozessoren . ## 9. Drittlandsübermittlung Im Rahmen der in dieser Erklärung beschriebenen Verarbeitungen findet keine Übermittlung personenbezogener Daten in Länder außerhalb der EU bzw. des EWR statt. Eine Drittlandsübermittlung erfolgt nur unter Einhaltung der Art. 44 ff. DSGVO; bei Einsatz eines Anbieters aus einem Drittland werden Betroffene vorab informiert. ## 10. Ihre Rechte als Betroffene Sie haben gegenüber uns die folgenden Rechte: - Auskunft über Ihre verarbeiteten Daten (Art. 15 DSGVO) - Berichtigung unrichtiger Daten (Art. 16 DSGVO) - Löschung Ihrer Daten (Art. 17 DSGVO) - Einschränkung der Verarbeitung (Art. 18 DSGVO) - Datenübertragbarkeit (Art. 20 DSGVO) - Widerspruch gegen die Verarbeitung (Art. 21 DSGVO) - Beschwerde bei der Aufsichtsbehörde (Art. 77 DSGVO) Hinweis zu Art. 11 DSGVO: Aufgrund unserer datensparsamen Architektur (Edge-Stripping IP und User-Agent, keine persistenten Identifier, 24-Stunden-Begrenzung des Stitch) ist eine direkte Zuordnung von Telemetriedaten zu einer natürlichen Person regelmäßig nicht möglich. Eine Auskunfts- oder Löschanfrage in Bezug auf Telemetriedaten setzt daher voraus, dass Sie zusätzliche Informationen zur Verfügung stellen, die eine Identifizierung ermöglichen. Anfragen richten Sie bitte an privacy@fastmon.eu . ## 11. Weitere Dokumente - Auftragsverarbeitungsvertrag (AVV) - Liste der Unterauftragsverarbeiter sowie der Technischen und organisatorischen Maßnahmen (TOM) auf Anforderung an privacy@fastmon.eu --- ## https://fastmon.eu/de/eu/ Digitale Souveränität # 100 % EU. Kein Kleingedrucktes. Der komplette Datenpfad von fastmon läuft in der EU, auf in Deutschland betriebener Infrastruktur, ohne einen einzigen Anbieter mit US-Jurisdiktion. Keine Cookies*, kein Fingerprinting, die IP weg, bevor irgendein Code sie sieht. Das ist der Unterschied zwischen einem Tool aus der EU und einem mit EU-Region. Was EU-Hosting wirklich heißt ## Aus der EU, nicht nur mit EU-Region. Die meisten Tools, die sich datenschutzfreundlich nennen, sind US-Unternehmen mit einem Rechenzentrum in Frankfurt. Die Server stehen in Europa, aber das Unternehmen untersteht US-Recht, und der US CLOUD Act greift auf dessen Daten zu, wo immer sie liegen. Eine EU-Region ist nicht dasselbe wie EU-Jurisdiktion. fastmon ist von Grund auf anders gebaut. Die fastmon labs UG ist ein deutsches Unternehmen aus Hannover, und alle Kunden- und Monitoring-Daten werden ausschließlich in der EU verarbeitet und in Deutschland gespeichert (Hetzner, Rechenzentrum Falkenstein). Jeder Anbieter im Datenpfad, also in jedem System, das Kunden- oder Monitoring-Daten verarbeitet, ist ein deutsches oder EU-Unternehmen: kein Cloudflare, kein AWS, kein GCP, kein Vercel, kein US-eigener Subauftragsverarbeiter. Weil weder fastmon noch ein Subauftragsverarbeiter unter US-Recht fällt, hat der US CLOUD Act keinen Zugriff auf diese Daten. Souveränität ist nur die Hälfte. Der Tracker ist Privacy-first by Design: er setzt im Standard-Modus keine Cookies*, nutzt kein Fingerprinting, und IP sowie User-Agent des Besuchers werden am Edge entfernt, bevor irgendein Application-Code die Anfrage sieht. Was bleibt, sind Felddaten, die du vor deiner Datenschutzbeauftragten vertreten kannst. Infrastruktur ## Kein US-Anbieter im Datenpfad. Wo deine Daten verarbeitet werden, entscheidet, wer Zugriff erzwingen kann. fastmon hält jeden Schritt in der EU-Jurisdiktion. ### Betrieben in Deutschland Alle Kunden- und Monitoring-Daten werden ausschließlich in der EU verarbeitet und in Deutschland gespeichert (Hetzner, Rechenzentrum Falkenstein). Nichts verlässt diesen Pfad. ### Kein US-eigener Subauftragsverarbeiter Kein Cloudflare, kein AWS, kein GCP, kein Vercel. Jeder Anbieter im Datenpfad ist ein deutsches oder EU-Unternehmen. ### Der CLOUD Act greift nicht Weil weder fastmon noch ein Subauftragsverarbeiter unter US-Recht fällt, hat der US CLOUD Act keinen Zugriff. ### EU-Region ist nicht EU-Recht Ein US-Konzern mit Frankfurt-Region bleibt ein US-Konzern. Souveränität heißt: kein US-Recht im Spiel, nicht nur Server in Europa. Subauftragsverarbeiter ## Jeder Anbieter, offen auf dem Tisch. Der komplette Datenpfad, von Hosting über E-Mail bis KI. Jeder ist ein deutsches oder EU-Unternehmen. Kein US-Anbieter im Datenpfad. | Anbieter | Zweck | Standort | Hetzner Online GmbH | Hosting, Storage, Backup | Deutschland, Falkenstein | smoxy GmbH | Ingress | Deutschland, Berlin | sevdesk GmbH | Buchhaltung und Rechnungen | Deutschland, Offenburg | All Quiet GmbH | On-Call-Tooling fürs Engineering | Deutschland, Berlin | ScaleCommerce GmbH | Hosting | Deutschland, Berlin | Lettermint B.V. | Transaktionale E-Mails | Niederlande, Zwolle | Soverin B.V. | Geschäftsmail | Niederlande, Rotterdam | BunnyWay d.o.o. | Autoritativer DNS | Slowenien, Tržič | Mistral AI SAS | KI-Inferenz, nur bei Opt-in | Frankreich, Paris Aus dem AVV, Stand 17. Juli 2026. Fünf von neun sitzen in Deutschland, der Rest in der EU. Interne Business-Tools, die keine Kunden- oder Monitoring-Daten verarbeiten, listen wir transparent auf der Anbieter-Seite. Alle Anbieter im Detail Was wir erfassen ## Die ganze Payload, und was nicht drin ist. fastmon erfasst Felddaten, keine Identitäten. Keine Einstellung schaltet Fingerprinting, eine seitenübergreifende ID oder ein Personen-Profil frei; die Presets ändern nur, wie viel Kontext erfasst wird, nie ob dich jemand über Seiten oder über die Zeit wiedererkennt. Was fastmon sieht - Core Web Vitals und Diagnose-Werte aus echten Seitenaufrufen - Nur das Land, ISO-2, am Edge aus der IP abgeleitet - Gerät, Browser, OS, Verbindung und Viewport als Buckets - Fehlertyp, -anzahl und Stack-Frames (kein Meldungstext im Standard) - Ein Stitch-Signal pro Domain, über 24 Stunden, für die Unique-Visitor-Zählung Was es nie tut - Keine Cookies* im Standard-Modus - Kein Canvas-, Font-, Client-Hints-, Batterie-, Sensor- oder Audio-Fingerprinting - Kein Session Replay, kein Auslesen von Seiteninhalten, keine Scroll- oder Formular-Erfassung - Keine seitenübergreifenden IDs, keine Anreicherung durch Dritte - Keine rohe IP und kein User-Agent erreicht je das Backend Zählen ohne Cookies* ## Für einen Besuch erkannt, nicht fürs Leben verfolgt. fastmon zählt eindeutige Besucher ohne Cookie* und ohne Geräte-ID. Stattdessen berechnet der Edge ein kurzes pseudonymes Signal, den Stitch, unter einem geheimen Salt, den er alle 24 Stunden wegwirft. - Der Salt ist ein 32-Byte-Zufallswert, nur im RAM des aktiven Edge, alle 24 Stunden rotiert, nie gespeichert, verteilt oder geloggt - Die Domain fließt in den Hash ein, damit derselbe Besucher auf jeder Seite ein anderes Signal bekommt: IDs überschreiten nie Domain-Grenzen - HMAC-SHA256 ist eine Einwegfunktion, nicht umkehrbar. Und um das Signal doch einer IP zuzuordnen, müsste jemand alle IPs mit dem aktiven Salt durchprobieren, der nach der Rotation weg ist (Forward Secrecy) - Wir behandeln den Stitch als personenbezogenes Datum und stützen ihn auf die Interessenabwägung nach DSGVO Art. 6 Abs. 1 lit. f, dokumentiert Cookies, TDDDG und Einwilligung Am Edge berechnet # rotating_salt: 32 Byte, nur Edge-RAM, alle 24h rotiert # nie gespeichert, nie geloggt stitch = HMAC-SHA256( rotating_salt, IP | User-Agent | collector_hash | domain ) # rohe IP und User-Agent werden hier verworfen, # bevor irgendein Application-Code die Anfrage sieht Erfassungs-Presets ## Du wählst, wie viel erfasst wird. Drei Presets, von reiner Performance bis zum vollen Session-Kontext. Standard ist der Default. In Minimal und Standard wird nichts auf dem Gerät gespeichert; erst Full legt eine tab-gebundene Session-ID ab, die beim Schließen des Tabs verfällt. | | Minimal | Standard | Full | Web Vitals, Gerät und Verbindungsklasse | Ja | Ja | Ja | Fehlertyp und -anzahl | Ja | Ja | Ja | Stitch-Besuchersignal am Edge abgeleitet, für die Unique-Visitor-Zählung | Nein | Ja | Ja | Fetch-/XHR-Aggregate | Nein | Ja | Ja | Query-Key-Namen | Nein | Ja | Ja | Volle Error-Stack-Frames | Nein | Ja | Ja | Error-Meldungstext | Nein | Nein | Ja | Session-ID in sessionStorage._fms geschrieben | Nein | Nein | Ja Standard (der Default) schreibt nichts auf das Endgerät des Besuchers. Nur das Full-Preset schreibt eine einzige tab-gebundene Session-ID, die mit dem Tab stirbt. Einwilligung und das TDDDG ## Was wir tun, und was daraus folgt. Ob die Einbindung eines Analyse-Tools eine Einwilligung nach § 25 TDDDG braucht, hängt an einer Frage: wird etwas im Endgerät gespeichert, oder wird auf etwas zugegriffen, das dort bereits gespeichert ist? Cookies sind dabei nur der bekannteste Fall, nicht der Tatbestand. Im Standard-Modus wird nichts auf das Endgerät geschrieben, kein Cookie und kein sessionStorage; der Schreibpfad wird beim Build aus dem ausgelieferten Bundle entfernt. Gelesen werden Statuswerte, die der Browser beim Seitenaufruf selbst erzeugt: Timings, Viewport-Klasse, Verbindungsklasse. Nach unserer Einschätzung ist das kein Zugriff auf gespeicherte Informationen im Sinne des § 25, eine strengere Lesart sieht das anders. Erst das Full-Preset schreibt eine Session-ID, und dafür brauchst du eine Einwilligung, aufschiebbar bis dein Consent-Tool grantConsent() aufruft. Die Einschätzung für deine eigene Seite triffst aber du, idealerweise mit deiner Datenschutzbeauftragten. § 25 TDDDG betrifft den Geräte-Zugriff, die DSGVO die anschließende Verarbeitung, und beide werden parallel geprüft. Keine Rechtsberatung. Dies spiegelt, wie fastmon gebaut und dokumentiert ist; dein Einsatz liegt in deiner Verantwortung. Das Datenblatt ## Die Fakten, ohne Marketing. Alles auf dieser Seite, verdichtet. Alle Angaben stammen aus der öffentlichen Dokumentation. Geprüft gegen docs.fastmon.eu. Retention und Erfassung sind pro Site einstellbar; der Stitch wird als personenbezogenes Datum behandelt, Rechtsgrundlage ist die Interessenabwägung nach Art. 6 Abs. 1 lit. f. Datenblatt Datenschutz Unternehmen fastmon labs UG Hannover, Deutschland Hosting Deutschland (Hetzner) Kein Cloudflare, AWS, GCP, Vercel IP-Adresse Am Edge entfernt Erreicht die Anwendung nie Geo Nur Land, ISO-2 Am Edge aus der IP abgeleitet Cookies Standardmäßig keine* Nur im Opt-in-Consent-Modus Fingerprinting Keins Kein Canvas, Font, Sensor, Audio Retention 90 Tage Default Bis 13 Monate (Enterprise) CLOUD Act Kein Zugriff Kein Datenpfad-Anbieter unter US-Recht AVV Öffentlich unter /de/avv/ Listet jeden Subauftragsverarbeiter Zur kompletten Datenschutz-Doku FAQ ## EU und Datenschutz, beantwortet. Die Fragen, die eine Datenschutzbeauftragte zuerst stellt. ### Brauche ich für fastmon einen Cookie-Banner? Nein, in den Modi Minimal und Standard nicht. Es wird nichts auf dem Endgerät gespeichert, und die Werte, die gelesen werden, lagen vorher nicht dort: sie entstehen erst beim Seitenaufruf. Es genügt, fastmon in deiner Datenschutzerklärung zu nennen. Im Modus Full brauchst du eine Einwilligung, weil dort eine Kennung in den sessionStorage geschrieben wird. Diese Einordnung ist mit unserem externen Datenschutzbeauftragten geprüft; ein Restrisiko bleibt, weil zu dieser Konstellation kein Urteil vorliegt. Die ganze Herleitung, mit Normtext und Gegenauffassung ### Wo werden die Daten gespeichert? Ausschließlich in der EU, auf in Deutschland betriebener Infrastruktur. Kein Cloudflare, kein AWS, kein GCP, kein Vercel, kein US-eigener Subauftragsverarbeiter im Datenpfad. Kein Anbieter im Datenpfad unterliegt US-Recht; der US CLOUD Act hat damit keinen Zugriff. ### Wie zählt ihr Besucher ohne Cookies? Der Edge berechnet ein kurzes pseudonymes Signal, den Stitch, als HMAC-SHA256 aus IP, User-Agent, einem seitenspezifischen Hash und der Domain, unter einem Salt, der alle 24 Stunden rotiert und den Edge-Speicher nie verlässt. Es ist ein Einweg-HMAC, pro Domain und auf rund 24 Stunden begrenzt; umkehren lässt es sich nicht, und nach der Rotation ist es keiner IP mehr zuzuordnen. Wir behandeln es als personenbezogenes Datum und stützen es auf die Interessenabwägung nach DSGVO Art. 6 Abs. 1 lit. f. ### Was erfasst ihr, und was erfasst ihr bewusst nicht? Felddaten: Core Web Vitals, Fehlertyp und -anzahl, Gerät- und Verbindungs-Buckets und das Land aus der IP am Edge. Kein Fingerprinting, kein Session Replay, kein Auslesen von Seiteninhalten, keine Scroll- oder Formular-Erfassung, keine seitenübergreifenden IDs, keine Anreicherung durch Dritte. Keine Einstellung schaltet Fingerprinting oder eine seitenübergreifende ID frei; die Presets ändern nur, wie viel Kontext erfasst wird, nie ob dich jemand über Seiten oder über die Zeit wiedererkennt. ### Bekomme ich einen AVV oder DPA? Ja. Der Auftragsverarbeitungsvertrag ist öffentlich unter fastmon.eu/de/avv/ einsehbar und listet jeden Subauftragsverarbeiter im Datenpfad. Fragen: privacy@fastmon.eu. ### Wie lange werden die Daten aufbewahrt? Standardmäßig 90 Tage; auf Enterprise pro Website bis 13 Monate konfigurierbar. Statistiken bleiben 13 Monate. Wenn die Retention abläuft, werden die Zeilen verworfen, nicht archiviert. ### Kann ich mich mit Google oder GitHub anmelden, ohne dass Daten in die USA gehen? Die Anmeldung mit Google oder GitHub ist optional. Sie betrifft ausschließlich deinen Login, nie deine Monitoring-Daten: die bleiben immer auf unserer Infrastruktur in Deutschland, egal wie du dich anmeldest. Nutzt du Social-Login, authentifizierst du dich direkt bei Google bzw. GitHub, das ist eine Anfrage von dir an deren Dienst; wir übertragen deine Messdaten nicht dorthin, und der Datenpfad des Monitorings bleibt US-frei. Wer gar keinen US-Anbieter berühren möchte, registriert sich mit E-Mail und Passwort; fürs Anmelden unterstützt dein Konto zusätzlich Passkeys, gerätegebunden, ohne Dritten und ohne Passwort und damit am datensparsamsten. ## 100 % EU, gehostet in Deutschland. Kein Cloudflare, kein AWS, kein GCP. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/funktionen/ Features # Fünf Bereiche. Ein Blick. Ein Script, dieselben Beacons, keine Extra-Tags. Hier ist jeder Bereich im Detail, mit den Zahlen direkt aus den Docs. Real User Monitoring ## Die Zahlen aus echten Besuchen. Jeder echte Seitenaufruf meldet die Metriken, nach denen Google dich rankt, gemessen auf den Geräten und in den Netzen deiner Besucher, bewertet am p75. Alles verdichtet sich zu einem Experience Score: 0 bis 10, Note A+ bis F, aus sieben gewichteten Signalen (LCP 25 %, INP, FCP und Fehlerrate je 15 %, Page Load, CLS und TTFB je 10 %). Mehr zu Real User Monitoring Core Web Vitals Demo Experience Score 9,2 A LCP 1,2 s gut ≤ 2,5 s INP 48 ms gut ≤ 200 ms CLS 0,03 gut ≤ 0,1 FCP 0,9 s gut ≤ 1,8 s TTFB 190 ms gut ≤ 800 ms Synthetic Monitoring Beta ## Das Labor, direkt neben dem Feld. Zusätzlich zu den Felddaten deiner echten Besucher fährt fastmon geplante Labortests. Zwei Testarten, kontrolliert und reproduzierbar. Lighthouse · alle 24 h ### Voller Lighthouse-Audit - Volle Messung alle 24 Stunden, Desktop und Mobile in einem Run - Performance, Accessibility, Best Practices und SEO - Simuliertes Gerät, ideale Bedingungen, voll reproduzierbar TTFB · alle 5 Min ### Leichter Server-Check - Server-Response-Check etwa alle 5 Minuten - Zerlegt in DNS, TCP, SSL, Server, Transfer - Cache-Bypass standardmäßig aktiv Mehr zu Synthetic Monitoring Web-Analytics ## Analytics, ohne das zweite Tool. Besucher, Quellen und Kampagnen liegen direkt neben den Ladezeiten, die über die Conversion entscheiden. Ein Tool weniger im Stack. Mehr zu Web-Analytics Live · jetzt Demo Live · letzte 5 Min Unique Visitors 1.284 Pageviews 3.902 Kampagnen Demo Quelle / Medium Besuche - google / cpc gclid 412 - facebook / paid 233 - (direct) 301 - newsletter / email 188 fastmon AI Neu ## Frag deine Daten. In normaler Sprache. „Frag zu diesem Test“ macht aus einem Lighthouse-Test eine Klartext-Zusammenfassung und drillt in einen einzelnen Fehler, damit du dir das Query-Bauen sparst. Es bleibt auf deinen eigenen fastmon-Daten. Neu, und wächst mit jedem Release. Frag in normaler Sprache Drill in Fehler Kein Query-Bauen Mehr zu fastmon AI EU & Datenschutz ## Innerhalb der DSGVO entworfen. Nicht nachträglich angepasst. Das ist der Unterschied zwischen einem Monitoring-Tool aus der EU und einem mit EU-Region. Hier ist das Datenblatt: die ehrliche Version, mit Fußnote. * In den Modi Minimal und Standard setzt fastmon kein Cookie und speichert nichts auf dem Endgerät; gelesen werden nur Statuswerte, die der Browser zur Laufzeit selbst erzeugt. Im Modus Full wird eine Kennung geschrieben, dort ist eine Einwilligung nach § 25 TDDDG erforderlich. Die Prüfung obliegt dem jeweiligen Website-Betreiber, der fastmon einbindet. Datenblatt Cookies 0* strikt speicherfrei: kein localStorage, kein sessionStorage IP-Adresse am Edge entfernt bevor irgendein Application-Code sie sieht Standort nur Land zweistelliger ISO-Code, mehr nicht Datenpfad 100 % EU kein Cloudflare, kein AWS, kein GCP Aufbewahrung 90 Tage Default, pro Website einstellbar Fingerprinting keins kein Canvas, keine Font-Enumeration Mehr zu EU & Datenschutz Gebaut für Produktion ## Alles andere, was mitkommt Die Mechanik, die die fünf Bereiche im Alltag nutzbar macht. Alles über dasselbe Script, alles im selben Dashboard. ### Eine Zeile, live in ~5 Minuten Ein einzelnes Script-Tag mit defer, kein Build-Step. Die ersten Besucher erscheinen rund eine Minute nach dem Deploy im Dashboard. ### Release-Tracking aus der CI/CD Tagge Releases mit einem API-Call aus GitHub Actions, GitLab oder Vercel. Marker landen in jedem Chart, und du vergleichst die Stunden davor und danach. ### Alerts, die sich selbst routen Schwellen- oder Prozent-Regeln auf Web Vitals, Fehlerrate, Pageviews und mehr, an E-Mail, Slack, Discord oder einen Webhook. ### Server-Timing-Breakdown Zerlege die Serverzeit in Edge, Origin, Backend, Datenbank, Render, Cache und External, jeweils am p50, p75 und p95. ### Cache-Monitoring, drei Ebenen Browser-, CDN- und Origin-Cache-Status nebeneinander, dazu die bfcache-Hit-Rate und Ressourcen nach Typ. ### Explorer Ad-hoc-Analyse von p50 bis p99, filtere und gruppiere deine Metriken ohne SQL. API & Docs ## Deine Daten, einen API-Call entfernt. Alles im Dashboard ist ein REST-Endpunkt. Frag jede Metrik ab, klink fastmon in deine eigenen Tools ein oder tagge ein Release aus der CI/CD. Auto-generiertes OpenAPI-Schema, Bearer-Token-Auth, Offset- und Cursor-Pagination. - Analytics-Query-API für jede Metrik, Aggregation und Aufschlüsselung - Bearer-Token-Auth (fm_...), auf Owner oder Member gescoped - OpenAPI-Schema unter /v1/openapi.json - Eigene Endpunkte für Fehler, Visitors, Server-Timing, Releases und mehr Zur API-Referenz api.fastmon.eu Beispiel POST /v1/organizations/ {org} /analytics/query Authorization: Bearer fm_... "metrics" : [ "lcp" , "inp" , "cls" ], "aggregations" : [ "p75" ] 200 OK "data" : [{ "lcp" : { "p75" : 1240 }, "inp" : { "p75" : 45 } }], "meta" : { "total" : 1 , "has_more" : false } Vergleich ## Wie fastmon abschneidet. Der ehrliche Fall gegen die Tools, die fastmon ersetzt oder ergänzt. Echte Unterschiede, keine Fake-Aussagen, und wir sagen, wo die anderen weiter gewinnen. Synthetic ### vs Lighthouse Labor behalten, Feld ergänzen: Echtnutzer-Core-Web-Vitals neben deinen Lighthouse-Läufen. Zum Vergleich Analytics ### vs Google Analytics 4 Datenschutzfreundliche Analytics aus der EU, standardmäßig cookiefrei*, mit Performance inklusive. Zum Vergleich RUM ### vs Datadog Fokussiertes Web-Performance-RUM, EU-gehostet und cookiefrei*, zum Bruchteil der Enterprise-Rechnung. Zum Vergleich Alle Vergleiche ## Alles in einem Tool, in der EU gehostet. Monitoring, Synthetics und Analytics, read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/ Glossar # Web-Performance, ohne Raterei. Jede Metrik, Methode und jeder Baustein hinter fastmon, in klarer Sprache erklärt. Core Web Vitals mit ihren echten Schwellenwerten, der Unterschied zwischen Labor- und Felddaten und die Konzepte, die Monitoring datenschutzfreundlich machen. Metriken 14 Begriffe ## Web-Performance-Metriken Was tatsächlich gemessen wird und die Schwellenwerte, die gut von schlecht trennen. CWV ### Core Web Vitals Googles Satz aus drei Feld-Metriken für Ladezeit (LCP), Interaktivität (INP) und visuelle Stabilität (CLS) einer Seite. Core Web Vitals sind die Teilmenge der Performance-Signale, die Google als essenziell für die Nutzererfahrung wertet und ins Ranking einfließen lässt. Jede Metrik erfasst einen anderen Moment: wie schnell der Hauptinhalt erscheint, wie schnell die Seite auf Eingaben reagiert und wie stark das Layout springt. Als bestanden gilt eine Seite nur, wenn alle drei im 75. Perzentil echter Besuche im grünen Bereich liegen. Labor-Tools können sie schätzen, die offizielle Bewertung nutzt aber immer Felddaten echter Nutzer. Zum ganzen Eintrag Mehr erfahren LCP ### Largest Contentful Paint Gut <= 2.5 s Die Zeit, bis das größte sichtbare Element im Viewport (Bild, Video oder Textblock) gerendert ist. LCP ist das Lade-Core-Web-Vital. Es beantwortet die Frage, die Besucher am meisten interessiert: Wann sieht die Seite fertig aus? Die Uhr startet mit der Navigation und stoppt, sobald das größte Element oberhalb der Falz gezeichnet ist. Weil das größte Element meist ein Hero-Bild oder eine Überschrift ist, wird LCP davon bestimmt, wie schnell der Server antwortet und wie schnell diese eine Ressource geliefert und dekodiert werden kann. Gut <= 2.5 s Ausbaufähig 2.5 to 4 s Schlecht > 4 s Felddaten (75. Perzentil) Was es beeinflusst - Langsame Serverantwort (hoher TTFB) verzögert alles Nachfolgende. - Große oder unoptimierte Hero-Bilder, oder Bilder ohne Priority-Hint. - Render-blockierendes CSS und JavaScript im Dokumentenkopf. - Client-seitiges Rendering, das den Hauptinhalt spät zeichnet. Zum ganzen Eintrag Mehr erfahren INP ### Interaction to Next Paint Gut <= 200 ms Wie lange die Seite braucht, um nach einer Nutzerinteraktion sichtbar zu reagieren, gemessen über den gesamten Besuch. INP ist das Reaktions-Core-Web-Vital. Es beobachtet jeden Klick, Tap und Tastendruck während eines Besuchs, misst die Verzögerung bis zum nächsten gezeichneten Frame und meldet nahezu den schlechtesten Wert. Ein niedriger INP bedeutet, die Oberfläche fühlt sich sofort an. INP hat First Input Delay im März 2024 abgelöst. Anders als FID, das nur die Eingabeverzögerung der ersten Interaktion betrachtete, deckt INP die komplette Interaktion inklusive Event-Verarbeitung und Rendering ab und bildet echte Trägheit deutlich besser ab. Gut <= 200 ms Ausbaufähig 200 to 500 ms Schlecht > 500 ms Felddaten (75. Perzentil) Was es beeinflusst - Lange JavaScript-Tasks, die den Main-Thread während der Interaktion blockieren. - Schwere Event-Handler, die vor dem nächsten Paint viel Arbeit erledigen. - Große DOM-Updates oder Layout-Thrashing durch eine Interaktion. - Third-Party-Skripte, die um den Main-Thread konkurrieren. Zum ganzen Eintrag Mehr erfahren CLS ### Cumulative Layout Shift Gut <= 0.1 Ein einheitenloser Wert dafür, wie stark sich sichtbarer Inhalt unerwartet verschiebt, während die Seite lädt und läuft. CLS ist das Core-Web-Vital für visuelle Stabilität. Jedes Mal, wenn sich ein Element ohne Nutzeraktion verschiebt, bewertet der Browser, wie viel des Viewports sich wie weit bewegt hat. CLS summiert den schlimmsten Schub dieser Verschiebungen während des Besuchs. Es ist die Metrik hinter dem bekannten Ärger, wenn ein Button im Moment des Antippens wegspringt, weil ein spätes Banner oder Bild lädt. Anders als die zeitbasierten Vitals hat es keine Einheit: kleiner ist besser, und 0 heißt, nichts hat sich bewegt. Gut <= 0.1 Ausbaufähig 0.1 to 0.25 Schlecht > 0.25 Felddaten (75. Perzentil) Was es beeinflusst - Bilder und Embeds ohne Breite und Höhe (oder Seitenverhältnis). - Werbung, Banner und iframes, die über bestehenden Inhalt eingefügt werden. - Web-Fonts, die Text umbrechen, wenn sie geladen sind. - Dynamisch eingefügter Inhalt ohne reservierten Platz. Zum ganzen Eintrag Mehr erfahren FCP ### First Contentful Paint Gut <= 1.8 s Der Moment, in dem der Browser den ersten Inhalt rendert: Text, ein Bild oder ein Canvas. FCP markiert den Übergang vom leeren Bildschirm zum ersten sichtbaren Zeichen, dass die Seite lädt. Es ist selbst kein Core Web Vital, aber ein starker Frühindikator und ein häufiges Diagnosemittel für einen langsamen LCP. Ein schneller FCP signalisiert Besuchern, dass etwas passiert. Ist FCP langsam, liegt die Ursache fast immer davor: Serverzeit, DNS, Weiterleitungen oder render-blockierende Ressourcen. Gut <= 1.8 s Ausbaufähig 1.8 to 3 s Schlecht > 3 s Felddaten (75. Perzentil) Was es beeinflusst - Hoher TTFB und langsame erste Serverantwort. - Render-blockierende Stylesheets und synchrone Skripte. - Langsame Font-Auslieferung, die Text bis zur Ankunft verbirgt. Zum ganzen Eintrag TTFB ### Time to First Byte Gut <= 0.8 s Die Zeit vom Start der Navigation bis der Browser das erste Byte der Antwort empfängt. TTFB erfasst alles, was passiert, bevor das Rendern überhaupt beginnen kann: DNS-Auflösung, Verbindungsaufbau, TLS-Handshake, Weiterleitungen und die Erzeugung der Antwort durch den Server. Es ist das Fundament, auf dem jede andere Lade-Metrik aufsetzt. Ein hoher TTFB begrenzt, wie schnell FCP und LCP je sein können, weshalb es das Erste ist, was man bei einer langsamen Seite prüft. Server-Logik, Datenbankabfragen und kalte Caches sind die üblichen Verdächtigen. Gut <= 0.8 s Ausbaufähig 0.8 to 1.8 s Schlecht > 1.8 s Felddaten (75. Perzentil) Was es beeinflusst - Langsame Backend-Verarbeitung oder ungecachte Datenbankabfragen. - Kein CDN, sodass entfernte Besucher die Rundreise bezahlen. - Weiterleitungsketten vor dem finalen Dokument. Zum ganzen Eintrag FID ### First Input Delay (abgelöst) Gut <= 100 ms Die Verzögerung zwischen der ersten Interaktion eines Besuchers und dem Beginn ihrer Verarbeitung durch den Browser. Durch INP ersetzt. FID war das ursprüngliche Reaktions-Core-Web-Vital. Es mass nur die Eingabeverzögerung der allerersten Interaktion, und nur diese Verzögerung, nicht die folgende Arbeit oder das Rendering, sodass eine Seite einen guten FID erreichen und sich trotzdem träge anfühlen konnte. Google hat FID am 12. März 2024 zugunsten von INP abgelöst, das die komplette Interaktion über den gesamten Besuch misst. FID steht hier zur Einordnung: In älteren Reports und Tools kann es noch auftauchen. Gut <= 100 ms Ausbaufähig 100 to 300 ms Schlecht > 300 ms Felddaten (75. Perzentil) Zum ganzen Eintrag TBT ### Total Blocking Time Gut <= 200 ms Die Gesamtzeit, in der der Main-Thread zwischen erstem Paint und Interaktivität von langen Tasks blockiert war, im Labor gemessen. TBT ist eine Labor-Metrik und der nächste Labor-Stellvertreter für INP. Es summiert den blockierenden Anteil (alles über 50 ms) jeder langen Task nach dem FCP und zeigt, wie lange eine Seite Eingaben ignorieren würde, während Skripte laufen. Weil es in einem kontrollierten Labordurchlauf gemessen wird, ist TBT stabil und ideal, um Regressionen in der CI zu fangen, bevor sie echte Nutzer als schlechten INP treffen. Gut <= 200 ms Ausbaufähig 200 to 600 ms Schlecht > 600 ms Labordaten (Lighthouse) Was es beeinflusst - Große JavaScript-Bundles, die beim Laden geparst und ausgeführt werden. - Teure Hydration in client-gerenderten Frameworks. - Third-Party-Tags, die schwere Arbeit auf dem Main-Thread erledigen. Zum ganzen Eintrag SI ### Speed Index Gut <= 3.4 s Eine Labor-Metrik dafür, wie schnell sich die sichtbaren Teile einer Seite während des Ladens füllen, basierend auf Videoaufnahme. Speed Index nimmt den Lade-Filmstreifen auf und bewertet, wie schnell die Pixel oberhalb der Falz visuell vollständig werden. Zwei Seiten mit gleichem LCP können sehr unterschiedliche Speed-Index-Werte haben, wenn eine sich nach und nach füllt und die andere auf einen Schlag erscheint. Es ist eine Lighthouse-Labor-Metrik, nützlich um die gefühlte Ladegeschwindigkeit zwischen Builds zu vergleichen, wird aber nicht an echten Nutzern gemessen. Gut <= 3.4 s Ausbaufähig 3.4 to 5.8 s Schlecht > 5.8 s Labordaten (Lighthouse) Zum ganzen Eintrag TTI ### Time to Interactive (veraltet) Eine Labor-Metrik dafür, wann eine Seite gerendert ist und zuverlässig schnell auf Eingaben reagieren kann. TTI schätzte den Punkt, ab dem der Main-Thread lange genug ruhig war, damit die Seite Interaktionen verlässlich verarbeiten konnte. Es war einst eine zentrale Lighthouse-Kennzahl. Lighthouse hat TTI in Version 10 (2023) aus der Bewertung entfernt, weil TBT und INP die Reaktionsfähigkeit zuverlässiger beschreiben. Es steht hier zur Einordnung älterer Audits. Zum ganzen Eintrag ### Page Load Das klassische Load-Event: alles auf der Erstseite, inklusive Bilder und Subressourcen, ist fertig geladen. Page Load (das window-Load-Event) ist der älteste Performance-Meilenstein. Er ist leicht verständlich und als grobes Signal weiterhin nützlich, sagt aber nichts darüber, wann die Seite nutzbar aussah oder sich so anfühlte, weshalb es die Core Web Vitals gibt. fastmon erfasst ihn neben den Vitals, sodass die vertraute Zahl bleibt, während die Metriken sichtbar werden, die Erfahrung wirklich abbilden. Zum ganzen Eintrag ### Route Load Die Ladezeit einer In-App-Navigation in einer Single-Page-App, bei der kein voller Seiten-Reload passiert. In einer Single-Page-Application tauscht ein Klick den Inhalt client-seitig aus, statt ein frisches Dokument zu laden, sodass das klassische Load-Event nie wieder feuert. Route Load misst diese Soft-Navigationen: wie lange ein Ansichtswechsel vom Klick bis zum gezeichneten Inhalt dauert. Ohne das wirken SPAs künstlich schnell, weil nur der allererste Ladevorgang gemessen wird. fastmon erkennt Soft-Navigationen und misst jeden Route-Wechsel, sodass die Zahlen abbilden, worauf Besucher wirklich warten. Zum ganzen Eintrag ### Long Tasks & LoAF Jedes Stück JavaScript, das den Main-Thread länger als 50 ms belegt und die Seite am Reagieren hindert. Während eine lange Task läuft, kann der Browser keine Klicks, Scrolls oder Paints verarbeiten, was Besucher genau als Ruckeln wahrnehmen. Long Animation Frames (LoAF) ist die neuere API, die weiter geht und einen langsamen Frame dem verantwortlichen Skript und sogar der Quellzeile zuordnet. Long Tasks sind das Rohmaterial hinter einem schlechten INP oder TBT. Sie zu finden und aufzubrechen, oder Arbeit vom Main-Thread zu verlagern, ist der direkteste Weg zu einer schnell wirkenden Oberfläche. Zum ganzen Eintrag ### Experience Score Eine einzelne Zahl von 0 bis 10, die fastmon aus LCP, INP, CLS, FCP, TTFB, Ladezeit und Fehlerrate bildet. Einzelne Metriken sind präzise, aber über viele Seiten hinweg schwer auf einen Blick zu verfolgen. Der Experience Score fasst sie zu einer Zahl zusammen, sodass ein Team die Gesundheit einer Seite, eines Segments oder einer ganzen Site auf einmal sieht und bei einem Einbruch gezielt tiefer geht. Er ersetzt nie die zugrunde liegenden Vitals: Er zeigt, wo man hinschauen sollte, und die Metrik-Karten sagen, warum. Zum ganzen Eintrag Zur Dokumentation Methoden 10 Begriffe ## Monitoring-Methoden Wie Performance gemessen wird, von echten Besuchern bis zu geplanten Labortests. RUM ### Real User Monitoring Performance aus den Browsern deiner echten Besucher messen, auf ihren realen Geräten und Netzwerken. RUM sammelt Metriken aus jeder echten Sitzung: den Smartphones, Laptops, Browsern und Verbindungen, die dein Publikum tatsächlich nutzt. Das sind Felddaten, und nur so weiß man, was Menschen wirklich erleben, inklusive des langsamen Long Tail, den Labortests verpassen. Es ist die Grundlage der Core-Web-Vitals-Bewertung. Das RUM von fastmon ist standardmäßig cookiefrei und entfernt IP-Adressen am Edge, sodass die Feld-Wahrheit ohne Besucherprofile entsteht. Zum ganzen Eintrag Mehr erfahren ### Synthetic Monitoring Geplante, wiederholbare Tests, die eine Seite in kontrollierter Umgebung in festem Intervall laden. Synthetic Monitoring schickt eine Seite nach Zeitplan durch ein Labor (bei fastmon geplante Lighthouse- und TTFB-Checks), jedes Mal vom gleichen Geräteprofil und Netzwerk. Weil die Bedingungen fix sind, sind Ergebnisse stabil und vergleichbar, ideal um Regressionen zu fangen und Seiten zu testen, bevor sie Traffic haben. Es ergänzt RUM, statt es zu ersetzen: Synthetic sagt, dass sich eine Seite verändert hat, RUM sagt, ob echte Nutzer es gespürt haben. Zum ganzen Eintrag Mehr erfahren ### Labordaten vs Felddaten Labordaten stammen aus einem kontrollierten Test, Felddaten von echten Besuchern. Beides zählt, aus verschiedenen Gründen. Labordaten sind reproduzierbar: gleiches Gerät, gleiches Netzwerk, gleiche Schritte, perfekt für Debugging und CI. Aber eine Maschine kann nicht jeden Besucher abbilden, daher kann es rosig aussehen, während echte Nutzer kämpfen. Felddaten sind unordentlich und ehrlich: Sie erfassen die volle Bandbreite an Geräten und Verbindungen. Core Web Vitals werden offiziell auf Felddaten bewertet. Der gesündeste Workflow nutzt Labordaten gegen Regressionen und Felddaten, um das reale Ergebnis zu bestätigen. Zum ganzen Eintrag ### Lighthouse Googles Open-Source-Tool, das eine Seite in einem Labordurchlauf prüft und Performance, Barrierefreiheit, SEO und mehr bewertet. Lighthouse lädt eine Seite unter simulierten Bedingungen und erzeugt aus Labor-Metriken wie FCP, LCP, TBT, CLS und Speed Index einen Performance-Score von 0 bis 100, plus konkrete Empfehlungen. Es treibt die Laborseite von PageSpeed Insights an. Die synthetischen Checks von fastmon führen Lighthouse nach Zeitplan aus, sodass die Diagnostik kontinuierlich vorliegt und nicht nur, wenn zufällig jemand ein Audit startet. Zum ganzen Eintrag CrUX ### Chrome UX Report Googles öffentlicher Datensatz realer Core Web Vitals, aggregiert aus zustimmenden Chrome-Nutzern. CrUX ist die Felddatenquelle hinter der Core-Web-Vitals-Bewertung der Google-Suche und dem Feldbereich von PageSpeed Insights. Es meldet das 75. Perzentil je Metrik, monatlich aggregiert über berechtigten Chrome-Traffic. Es ist wertvoll, aber grob: monatlich, auf Origin- oder Seitengruppen-Ebene, nur Chrome, und nur für Seiten mit genug Traffic. Das eigene RUM füllt diese Lücken mit Daten pro Seite, in Echtzeit und über alle Browser. Zum ganzen Eintrag p75 ### Perzentil (p75) Der Wert, unter den ein bestimmter Anteil der Besuche fällt. p75 heißt, 75 Prozent waren mindestens so schnell. Durchschnitte verbergen Schmerz: Eine Handvoll sehr langsamer Sitzungen kann von vielen schnellen überdeckt werden. Perzentile beschreiben stattdessen die Verteilung. Das 75. Perzentil ist die Schwelle der Core Web Vitals, damit drei von vier Besuchen repräsentiert sind und das schlechteste Viertel nicht wegdurchschnittet wird. p75 zu beobachten (und p90 oder p95 für den Long Tail) zeigt, was die meisten Menschen erleben und wie schlimm es für die Unglücklichen wird, was ein Durchschnitt nie verrät. Zum ganzen Eintrag ### Web Vitals Attribution Die zusätzlichen Diagnosedaten, die erklären, warum eine Metrik langsam war, nicht nur wie langsam. Zu wissen, dass LCP 4 Sekunden war, ist nur die halbe Geschichte. Attribution zerlegt eine Metrik in ihre Phasen (bei LCP: Time to First Byte, Ressourcen-Ladeverzögerung, Ladezeit, Render-Verzögerung) und benennt das verantwortliche Element oder den CSS-Selektor hinter einer Layoutverschiebung oder langsamen Interaktion. Das macht aus einer Zahl eine Handlung: statt zu raten, siehst du genau das Bild, Skript oder Element, das behoben werden muss. Zum ganzen Eintrag ### Web-Analytics Messung von Traffic und Verhalten: Seitenaufrufe, Besucher, Referrer und Journeys, gemeinsam mit Performance. Analytics beantwortet, wer besucht hat, woher und was getan wurde. Mit Performance-Daten kombiniert wird es weit nützlicher: Man sieht, ob eine langsame Seite Conversions kostet oder welche Traffic-Quelle auf den schlechtesten Erfahrungen landet. Die Analytics von fastmon ist datenschutzfreundlich: keine Cookies im Standardmodus, kein Cross-Site-Tracking und IPs am Edge auf einen Country-Code reduziert. Im Standardmodus wird nichts auf dem Endgerät gespeichert, sodass nach unserer Einschätzung auch kein Consent-Banner nötig ist. Zum ganzen Eintrag Mehr erfahren ### Error Tracking Erfassen von JavaScript-Fehlern und fehlgeschlagenen Requests aus echten Sitzungen, gruppiert, sodass die echten Probleme sichtbar werden. Eine Seite kann perfekte Vitals erreichen und für ein Nutzersegment trotzdem kaputt sein, weil ein Skript wirft. Error Tracking erfasst diese Fehler aus dem Browser, mit genug Kontext (Seite, Browser, Ablauf), um sie zu reproduzieren. Ähnliche Fehler werden zu einem Fingerprint zusammengefasst, sodass tausend Vorkommen desselben Bugs als ein einzelnes, priorisiertes Problem erscheinen statt als Rauschen. Zum ganzen Eintrag ### Alarmierung Benachrichtigungsregeln, die melden, wenn eine Metrik einen Schwellenwert reißt oder sich verschlechtert, bevor Kunden sich beschweren. Dashboards helfen nur, wenn jemand hinschaut. Alarmierung beobachtet die Zahlen für dich und feuert, wenn ein Core Web Vital, eine Fehlerrate oder ein Experience Score eine von dir gesetzte Linie überschreitet oder in die falsche Richtung tendiert. Gute Alarmierung ist spezifisch genug, um ihr zu vertrauen: begrenzt auf die Seiten und Metriken, die zählen, sodass eine kritisch werdende Seite die richtigen Leute erreicht, statt unterzugehen. Zum ganzen Eintrag Bausteine 8 Begriffe ## fastmon-Bausteine Die Teile, aus denen fastmon besteht: vom Beacon bis zur Art, wie Besucher gezählt werden. ### Beacon Das kleine Datenpaket, das der Tracker mit den Messwerten eines Besuchs an fastmon sendet. Wenn eine Seite mit dem Messen fertig ist, packt der Tracker Metriken, Timings und etwaige Fehler in eine kompakte Nutzlast und sendet sie, typischerweise über die Beacon-API, sodass die Zustellung die Seite nicht blockiert oder verlangsamt. Was ein Beacon genau enthält, lässt sich mit der fastmon Beacon-Inspector-Browsererweiterung prüfen, Teil davon, wie fastmon transparent hält, was es erfasst. Zum ganzen Eintrag ### Tracker Das leichtgewichtige Skript, das du einmal einbindest; es misst Core Web Vitals und Fehler direkt im Browser. Der Tracker ist das Snippet, das die Messung macht. Er hängt sich in Standard-Browser-APIs ein (Performance-API, PerformanceObserver, Error-Events) und ist auf dieselbe web-vitals-Library abgestimmt, die Google nutzt, sodass die Zahlen mit denen von Chrome vergleichbar sind. Er ist klein und lädt ohne das Rendering zu blockieren, sodass das Hinzufügen von Monitoring nicht selbst die Performance beschädigt, die du messen willst. Zum ganzen Eintrag ### Stitch fastmons kurzlebiger, am Edge abgeleiteter Identifier, der einen Besuch ohne Cookies oder Cross-Site-Tracking gruppiert. Um eindeutige Besucher zu zählen und die Seiten eines Besuchs zu verbinden, braucht es einen Identifier. Stitch wird am Edge abgeleitet und rotiert im 24-Stunden-Takt, sodass er eine Sitzung gruppieren, aber niemandem über Tage, Sites oder Geräte folgen kann. So vermeidet fastmon das Doppelzählen und die verwaisten Sitzungen rein cookiefreier Ansätze und setzt trotzdem keine Cookies und baut keine langlebigen Profile. Zum ganzen Eintrag ### Session Ein zusammenhängender Besuch: die Abfolge von Seitenaufrufen und Interaktionen, bevor ein Besucher inaktiv wird. Eine Session verbindet die Seiten, Timings und Fehler eines einzelnen Besuchs, sodass du einer Journey folgen kannst statt isolierten Treffern. Sie ist die Einheit hinter Metriken wie Seiten pro Session und der Frage, wo in einem Flow Menschen abspringen. In fastmon ist eine Session durch den kurzlebigen Stitch-Identifier begrenzt, sodass sie einen Besuch abbildet und kein dauerhaftes Profil wird. Zum ganzen Eintrag ### Pageview Ein einzelner Seitenaufruf oder, in einer Single-Page-App, ein Route-Wechsel, der als eigener Aufruf zählt. Der Pageview ist die atomare Einheit der Analyse. Jeder trägt seine Metriken, Timings und seinen Kontext, und viele zusammen ergeben eine Session und die Traffic-Summen. fastmon zählt auch Soft-Navigationen in Single-Page-Apps als Pageviews, sodass SPA-Traffic nicht unterzählt wird wie bei Tools, die nur volle Dokument-Ladevorgänge sehen. Zum ganzen Eintrag ### Collection Modes Voreinstellungen (Light, Standard, Full), die festlegen, wie viel Detail der Tracker erfasst. Nicht jede Site braucht dieselbe Tiefe. Light beschränkt Daten auf das Nötigste, Standard ist die ausgewogene Voreinstellung, und Full schaltet die reichste Diagnostik frei, etwa detaillierte Attribution und Resource Timing. Der Modus ist ein bewusster Hebel über den Datenschutz- und Daten-Kompromiss, von dir gewählt statt angenommen, und er bildet direkt ab, was das Gerät eines Besuchers abgefragt wird. Zum ganzen Eintrag ### Server-Timing Ein HTTP-Header, den dein Backend senden kann, um aufzuschlüsseln, wo Serverzeit verbraucht wurde, sichtbar im RUM. TTFB sagt, dass der Server langsam war, aber nicht warum. Mit dem Server-Timing-Header kann dein Backend seine eigenen Phasen melden (Datenbank, Cache, Rendering), und der Browser reicht sie an den Tracker weiter. Das verbindet einen langsamen Feld-TTFB mit genau dem verantwortlichen Backend-Schritt und schließt die Lücke zwischen Frontend-Symptom und Backend-Ursache. Zum ganzen Eintrag ### Cache-Status Ob eine Antwort von einem CDN-Edge, dem Origin-Server oder dem Browser-Cache kam. Dieselbe URL kann schnell oder langsam sein, je nachdem woher sie ausgeliefert wurde. Den Cache-Status pro Request zu erfassen zeigt die echte Trefferquote und deckt Ressourcen auf, die den Cache immer wieder verfehlen und den Origin treffen. Das macht aus Caching statt einer hoffnungsvollen Konfiguration etwas, das sich an echtem Traffic verifizieren lässt. Zum ganzen Eintrag Datenschutz & EU 5 Begriffe ## Datenschutz und EU Warum fastmon ohne Cookies misst und jedes Byte in Deutschland hält. ### Cookiefrei Messen, ohne etwas auf dem Gerät des Besuchers zu speichern: keine Cookies, kein localStorage. Klassische Analytics schreibt ein Cookie, um wiederkehrende Besucher zu erkennen, was Einwilligungspflichten auslöst und blockiert oder gelöscht werden kann. fastmon ist standardmäßig cookiefrei: im Read-only-Modus speichert es überhaupt nichts auf dem Gerät. Cookiefrei ist nicht dasselbe wie einwilligungsfrei. Das Lesen von Browser-Performance-APIs kann weiterhin unter Consent-Regeln fallen, aber indem es nichts speichert, beseitigt fastmon eine ganze Klasse von Datenschutz- und Genauigkeitsproblemen cookiebasierter Tools. Zum ganzen Eintrag Mehr erfahren ### Edge-IP-Verarbeitung Die IP-Adresse des Besuchers wird am Edge auf einen Country-Code reduziert und verworfen, bevor Anwendungscode sie sieht. Eine IP-Adresse ist personenbezogenes Datum. Statt sie zu loggen und später zu anonymisieren, leitet fastmon am Edge-Server nur einen groben Country-Code ab und verwirft die Roh-IP sofort, sodass sie nie Speicher oder Anwendungslogik erreicht. Das ist Datenminimierung by Design: Du bekommst weiterhin geografische Auswertungen, aber es gibt keine Roh-IP, die geleakt, angefordert oder missbraucht werden könnte, weil sie nie aufbewahrt wurde. Zum ganzen Eintrag Mehr erfahren GDPR ### DSGVO Die EU-Datenschutz-Grundverordnung, die rechtliche Grundlinie für den Umgang mit personenbezogenen Daten in Europa. Die DSGVO regelt, wie personenbezogene Daten (inklusive IP-Adressen und Identifier) erhoben, verarbeitet und gespeichert werden dürfen, und gewährt Menschen Rechte an ihren Daten. Analytics-Tools müssen rechtfertigen, was sie erheben und auf welcher Rechtsgrundlage. fastmon ist in der DSGVO gebaut statt nachträglich angepasst: minimale Daten, keine Roh-IP-Speicherung, keine Cross-Site-Profile und Verarbeitung ausschließlich in der EU, was die Compliance-Fläche by Design klein hält. Zum ganzen Eintrag Mehr erfahren ### TDDDG (Paragraf 25) Das deutsche Gesetz, das die ePrivacy-Regel umsetzt, wonach Lesen von oder Schreiben auf einem Gerät Einwilligung braucht. Paragraf 25 TDDDG (früher TTDSG) ist die deutsche Umsetzung der ePrivacy-Richtlinie. Er besagt, dass das Speichern von oder Zugreifen auf Informationen auf dem Gerät eines Nutzers grundsätzlich Einwilligung erfordert, unabhängig davon, ob diese Information personenbezogen ist. Deshalb kann selbst ein cookiefreies Tool Einwilligung brauchen: Das Lesen der Performance-APIs des Browsers ist ein Zugriff auf das Gerät. Der Website-Betreiber holt diese Einwilligung über seine Consent-Plattform ein, genau wie bei anderen Tools, wie in der Datenschutzerklärung von fastmon beschrieben. Zum ganzen Eintrag ### Datenresidenz Wo deine Daten physisch liegen und unter wessen Rechtsprechung sie fallen. Bei fastmon: Deutschland, durchgängig. Datenresidenz zählt, weil der Ort entscheidet, welche Gesetze gelten. Daten bei US-Anbietern können unter Regimen wie dem CLOUD Act erreichbar sein, selbst wenn die Server in Europa stehen. fastmon wird zu 100 Prozent in Deutschland bei Hetzner gehostet, ohne US-Anbieter im Datenpfad, sodass deine Monitoring-Daten von der Erhebung bis zur Speicherung unter EU-Rechtsprechung bleiben. Zum ganzen Eintrag Mehr erfahren ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/impressum/ Rechtliches # Impressum Stand: Juni 2026 Angaben gemäß § 5 DDG (Digitale-Dienste-Gesetz) und § 18 MStV (Medienstaatsvertrag). fastmon labs UG (haftungsbeschränkt) Stresemannallee 4 30173 Hannover Deutschland ## Vertretungsberechtigte Geschäftsführer Kamil Adrian Czujowski Lucas Röhrs (beide einzelvertretungsberechtigt) ## Handelsregister Amtsgericht Hannover HRB 230880 ## Umsatzsteuer-Identifikationsnummer Umsatzsteuer-Identifikationsnummer gemäß § 27a UStG: DE463717862 ## Kontakt E-Mail: support@fastmon.eu Datenschutz: privacy@fastmon.eu Web: fastmon.eu ## Inhaltlich Verantwortlicher Kamil Adrian Czujowski, Anschrift wie oben. ## EU-Streitschlichtung Die Europäische Kommission stellt eine Plattform zur Online-Streitbeilegung (OS) bereit: ec.europa.eu/consumers/odr . Unsere E-Mail-Adresse finden Sie oben. Wir sind nicht bereit oder verpflichtet, an Streitbeilegungsverfahren vor einer Verbraucherschlichtungsstelle teilzunehmen. ## Haftung für Inhalte Als Diensteanbieter sind wir gemäß § 7 Abs. 1 DDG für eigene Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich. Nach §§ 8 bis 10 DDG sind wir als Diensteanbieter jedoch nicht verpflichtet, übermittelte oder gespeicherte fremde Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen. Verpflichtungen zur Entfernung oder Sperrung der Nutzung von Informationen nach den allgemeinen Gesetzen bleiben hiervon unberührt. Eine diesbezügliche Haftung ist jedoch erst ab dem Zeitpunkt der Kenntnis einer konkreten Rechtsverletzung möglich. Bei Bekanntwerden entsprechender Rechtsverletzungen werden wir diese Inhalte umgehend entfernen. ## Haftung für Links Unser Angebot enthält Links zu externen Websites Dritter, auf deren Inhalte wir keinen Einfluss haben. Deshalb können wir für diese fremden Inhalte auch keine Gewähr übernehmen. Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter oder Betreiber der Seiten verantwortlich. Die verlinkten Seiten wurden zum Zeitpunkt der Verlinkung auf mögliche Rechtsverstöße überprüft. Rechtswidrige Inhalte waren zum Zeitpunkt der Verlinkung nicht erkennbar. ## Urheberrecht Die durch die Seitenbetreiber erstellten Inhalte und Werke auf diesen Seiten unterliegen dem deutschen Urheberrecht. Die Vervielfältigung, Bearbeitung, Verbreitung und jede Art der Verwertung außerhalb der Grenzen des Urheberrechtes bedürfen der schriftlichen Zustimmung des jeweiligen Autors bzw. Erstellers. --- ## https://fastmon.eu/de/kontakt/ Kontakt # Kurzer Draht, echte Antworten. Keine Ticket-Warteschleife, kein Chatbot: Deine Mail landet direkt bei den Menschen, die fastmon bauen. ## Support Fragen zum Produkt, zur Einrichtung, zu Plänen oder zu deinem Konto. support@fastmon.eu ## Datenschutz Fragen zu Datenschutz, AVV und Subauftragsverarbeitern. privacy@fastmon.eu ## Firmendetails Unternehmen fastmon labs UG (haftungsbeschränkt) Anschrift Stresemannallee 4, 30173 Hannover, Deutschland Registergericht Amtsgericht Hannover, HRB 230880 Geschäftsführer Kamil Adrian Czujowski, Lucas Röhrs ## Social Media Produkt-Updates und Einblicke aus dem Maschinenraum gibt es auf LinkedIn. LinkedIn --- ## https://fastmon.eu/de/partner/ Partnerprogramm Für Agenturen # Macht Performance messbar. Und daraus ein Geschäft. Jede Website, die ihr betreut, braucht Monitoring. Setzt fastmon ein und beteiligt euch am Umsatz, jeden Monat, solange der Kunde bleibt. Keine Setup-Gebühr, keine Exklusivität, auf einer Plattform, die in Deutschland läuft. Partner werden Zu den Leveln - Wiederkehrende Beteiligung - Solange der Kunde bleibt - Kein Mindestumsatz Für wen ## Gemacht für Teams, die für Websites geradestehen Wenn bei euch das Telefon klingelt, sobald eine Seite langsam wird, bezahlt euch dieses Programm für das Werkzeug, das ihr sowieso gebraucht hättet. ### Web- und Shop-Agenturen Shopware, TYPO3, WordPress, Next.js: Ihr baut die Seiten, fastmon zeigt, was sie beim echten Besucher leisten. Ein Account pro Kundenprojekt. ### Hoster und Managed Service Monitoring als Teil des Hosting-Pakets. Ihr sieht Core Web Vitals pro Kunde und könnt belegen, woher eine Verlangsamung kommt, bevor das Telefon klingelt. ### Performance-Beratung Vorher und nachher mit echten Nutzerdaten statt mit einem Lighthouse-Screenshot. Euer Ergebnis wird sichtbar und damit verkaufbar. ### SEO und Content Core Web Vitals sind ein Rankingsignal. Mit Felddaten aus dem 75. Perzentil argumentiert ihr im Kundengespräch mit Zahlen statt mit Vermutungen. Zwei Wege ## Empfehlen oder selbst verwalten Jeder Account zählt auf euer Level, egal über welchen Weg er läuft. Der Provisionssatz gehört zum Weg Empfehlen: Im Weg Verwalten steht dafür der Preis in eurem individuellen Angebot. Weg A ### Empfehlen Ihr bringt uns den Kunden, wir schließen ab und rechnen mit ihm ab, ihr bekommt monatlich Provision, solange er bleibt. - Kunden vorab per Mail anmelden, dann ist die Zuordnung eindeutig, auch wenn er erst Wochen später bucht - Wir hinterlegen euch am Account, danach gibt es nichts zu pflegen - Monatliche Auszahlung gegen eure Rechnung - Vertragspartner bleibt der Kunde, inklusive Support Weg B ### Verwalten Ihr seid Vertragspartner und führt eure Kundenprojekte in einer oder mehreren Organisationen. Eure Kunden können vollen Zugriff darauf bekommen, die Kosten vereinbaren wir individuell. - Eine Rechnung für alle Kundenprojekte - Ihr bestimmt den Endkundenpreis selbst - Übersicht über alle Organisationen eurer Kunden - Kunden bekommen auf Wunsch vollen Zugriff auf ihre Projekte - Individuelle Konditionen statt fester Provisionssätze Der Weg ist jederzeit wechselbar und lässt sich pro Kunde mischen. Level ## Von p75 bis p99. Core Web Vitals werden im 75. Perzentil bewertet. Partner bewerten wir genauso: p75 ist der Einstieg, p99 die Spitze. Je mehr aktive Standard-Accounts, umso höher der Satz, und er gilt für das ganze Portfolio statt nur für den nächsten Kunden. Ab 1 Standard-Account ### p75 Partner 20 % Provision Der Einstieg, ab dem ersten Kunden. - Partner-Kit: Argumente, Screenshots und Folien für euer Angebot - Eure eigenen Websites kostenlos überwacht - Partner-Badge für die eigene Website - Ein Support-Kanal, der euch direkt antwortet Ab 10 Standard-Accounts ### p90 Partner 25 % Provision Für Agenturen, die einen festen Stamm an Kundenprojekten betreuen. - Eintrag im Partner-Verzeichnis auf fastmon.eu - Priorisierter Support, auch für eure Kunden - Eine gemeinsame Case Study - Technisches Onboarding für euer Team Ab 25 Standard-Accounts ### p95 Partner 30 % Provision Der höchste feste Satz im Programm. - Leads aus unserem Sales in eurer Region oder Nische - Co-Marketing: Artikel, Webinar, Messe - Fester Ansprechpartner bei fastmon - Roadmap-Input und früher Zugang zu Features Ab 50 Standard-Accounts ### p99 Partner Individuell je nach Portfolio und Kundengröße Jenseits von 50 Accounts hilft keine Prozenttabelle mehr. Wir vereinbaren die Konditionen mit euch. - Konditionen individuell, je nach Portfolio und Größe eurer Kunden - Enterprise-Deals gemeinsam abschließen - Euer Logo auf fastmon.eu - Gemeinsame Produktentwicklung Der Satz gilt nicht nur für Neukunden. Wer von p90 auf p95 aufsteigt, verdient ab dem nächsten Monat an jedem bestehenden Account mehr. ### Fast-Track Zehn Standard-Accounts in den ersten 90 Tagen: p90 gilt ab dem Tag, an dem der zehnte Account aktiv wird, nicht erst ab dem Folgemonat. ### Level-Schutz Fällt ein Kunde weg, bleibt euer Level drei Monate erhalten. Ein gekündigter Account kostet nicht sofort den Satz. ### Monatliche Prüfung Wir schauen einmal im Monat auf die Zahl der aktiven Standard-Accounts. Ein Aufstieg wirkt ab dem Folgemonat, ein Abstieg erst nach dem Level-Schutz. Welcher Plan zählt wie ## Die Leiter läuft über Standard Wir sagen das lieber hier als auf der ersten Abrechnung: Bei 29 € im Monat bleibt kaum Marge zum Teilen. Light bringt deshalb weniger und erst, wenn Menge dahintersteht. ### Standard ab 99 € im Monat Zählt ab dem ersten Account, mit dem Satz eures Levels, und jeder Standard-Account bringt euch näher an das nächste Level. 20 bis 30 % ### Light 29 € im Monat Bringt Provision ab dem zehnten aktiven Light-Account, dann auf alle, mit festem Satz. Für die Level zählen Light-Accounts nicht mit. 10 % Ein Light-Kunde ist damit nie ein Problem, er ist nur nicht das, worauf die Leiter gebaut ist. Wenn ihr überwiegend kleine Seiten betreut, sagt es im Kennenlernen, dann schauen wir gemeinsam drauf. Rechner ## Was kommt dabei zusammen? Zieht den Regler auf die Zahl der Kundenprojekte, die ihr auf fastmon bringen würdet, und schaltet den Plan um. Kundenaccounts 10 Plan pro Kunde Light, 29 € Standard, 99 € Level p90 25 % Satz Vermittelter Umsatz 990 € pro Monat Eure Provision 248 € pro Monat 2.976 € pro Jahr Mit 25 Kundenaccounts wärt ihr p95 Partner: 30 % auf das ganze Portfolio. Beispielrechnung mit Listenpreisen, ohne Mehrwertsteuer. Verbindlich ist der Partnervertrag. Womit ihr verkauft ## Sechs Dinge, die das Gespräch leicht machen Der Prozentsatz ist die eine Hälfte. Die andere ist ein Produkt, das ihr ohne Kleingedrucktes vor einen Kunden stellen könnt. ### Ein Tool statt drei Real User Monitoring, Lighthouse-Audits nach Zeitplan und Web-Analytics in einer Oberfläche. Ein Login, eine Rechnung, ein Dashboard, das der Kunde wirklich liest. ### Felddaten statt Laborwert Core Web Vitals im 75. Perzentil von echten Besuchern, daneben der Lighthouse-Lauf. So belegt ihr eine Optimierung, statt sie zu behaupten. ### Die Datenschutzfrage, mit Herleitung Kein US-Anbieter im Datenpfad, Hosting in Deutschland, im Standardmodus wird nichts auf dem Endgerät gespeichert. Nach unserer Einschätzung braucht das keine Einwilligung nach § 25 TDDDG, die vollständige Herleitung samt Restrisiko steht offen auf unserer Cookie-Seite. ### Preise, die euer Kunde versteht 29 € für kleine Seiten, 99 € für eine Million Pageviews. Kein Enterprise-Angebot, das zwischen euch und der Unterschrift steht. ### In fünf Minuten eingebaut Ein Script-Tag, danach messt ihr. Kein SDK, kein Tag-Manager-Projekt, im Standardmodus nach unserer Einschätzung kein Consent-Layer, den ihr aushandeln müsst. ### 30 Tage testen, ohne Karte Jeder Kundenaccount startet mit 30 Tagen vollem Zugriff, ohne Kreditkarte. Ihr könnt die Zahlen zeigen, bevor jemand etwas unterschreibt. Verzeichnis ## Unsere Partner Agenturen, Hoster und Beratungen, die fastmon bei ihren Kunden einsetzen. Darunter das Unternehmen, auf dessen Plattform fastmon selbst läuft. ### ScaleCommerce Berlin p99 Partner E-Commerce-PaaS und Managed Hosting für Shopware, OXID, Magento und Spryker. Betreibt die Plattform, auf der fastmon selbst läuft. Partnerprofil ansehen ### Euer Profil im Verzeichnis Ab p90 bekommt ihr eine eigene Seite, mit euren Leistungen, euren Plattformen und einem Link auf eure Website. Wir nehmen laufend neue Agenturen, Hoster und Beratungen auf. Partner werden So läuft es ## Vier Schritte bis zur ersten Provision 01 ### Bewerbung Eine kurze Mail mit eurem Unternehmen, eurer Website und der Zahl der Kundenprojekte. 02 ### Kennenlernen Dreißig Minuten mit uns: was ihr macht, welcher Weg passt, mit welchen Kunden ihr anfangt. 03 ### Zugang Partner-Kit, ein kostenloser Account für eure eigenen Seiten, und ihr seid als Partner hinterlegt. Start in derselben Woche. 04 ### Erster Kunde Ab dem ersten aktiven Account läuft die Provision, monatlich und ohne Ablaufdatum. FAQ ## Fragen zum Programm Was Agenturen uns fragen, bevor sie einsteigen. Fehlt etwas, schreibt an partner@fastmon.eu. ### Was zählt als aktiver Kundenaccount? Ein zahlender fastmon-Account, den ihr vermittelt oder verwaltet, nach Ende der Testphase und ohne offene Rechnung. Standard-Accounts zählen ab dem ersten und bringen euch im Level weiter. Euer eigener kostenloser Partner-Account zählt nie mit. ### Warum bringt Light weniger? Bei 29 € im Monat bleibt nach dem Betrieb sehr wenig zum Teilen. Deshalb bringt Light feste 10 % und erst ab dem zehnten aktiven Light-Account. Standard ist ab dem ersten voll dabei. Wir sagen das lieber hier als auf der ersten Abrechnung. ### Wie lange läuft die Provision? Solange der Kunde zahlt. Wir kappen sie nicht nach 12 Monaten und halbieren sie nicht im zweiten Jahr. ### Wann und wie wird ausgezahlt? Monatlich gegen eure Rechnung, ab 50 € Guthaben. Was darunter liegt, bleibt stehen und läuft weiter, verfällt also nicht. Im Weg Verwalten gibt es keine Auszahlung, dort vereinbaren wir stattdessen den Preis. ### Was passiert, wenn ein Kunde kündigt? Die Provision für diesen Kunden endet mit seinem letzten bezahlten Monat. Euer Level bleibt drei Monate geschützt. ### Können wir beide Wege mischen? Ja, sogar pro Kunde. Manche Agenturen empfehlen große Kunden und verwalten die kleinen selbst. ### Gibt es Gebühren oder Mindestumsätze? Keine Aufnahmegebühr, kein Mindestumsatz, keine Kündigungsfrist. Wenn es für euch nicht funktioniert, hört ihr auf. ### Sehen wir die Daten unserer Kunden? Im Weg Verwalten führt ihr die Projekte selbst in einer oder mehreren Organisationen, und eure Kunden können vollen Zugriff darauf bekommen. Im Weg Empfehlen gehört der Account dem Kunden, Zugriff bekommt ihr, wenn er euch einlädt. ### Was kostet fastmon unsere Kunden? 29 € für 200.000 Pageviews im Monat, 99 € für eine Million, darüber nutzungsbasiert in Stufen. Alles dazu steht bei den Plänen. ## Fangt mit einem Kunden an Ein aktiver Standard-Account genügt, damit die Provision läuft. Der Rest ist eine kurze Mail und ein Gespräch. Partner werden Alle Pläne ansehen --- ## https://fastmon.eu/de/plans/ Pläne Early Adopter # Einfache, ehrliche Preise. Keine versteckten Kosten. Zwei nutzungsbasierte Pläne, pro Pageview bepreist. Light, wenn du nur Monitoring willst, Standard, wenn du alles willst. Eine Prod- und eine Dev-Applikation inklusive, EU-gehostet und im Einstieg günstiger als RUMvision, DebugBear und SpeedCurve (Listenpreise). Einstieg ## Light 29 € /Monat 200.000 Pageviews inklusive, dann 10 € je weitere 200k Für kleine Shops, die nur Monitoring wollen, kein Debugging. Kostenlos starten - Core Web Vitals und Real User Monitoring - Web-Analytics: Traffic, Quellen, Kampagnen - Alerts per E-Mail, Slack, Discord oder Webhook - Eine Prod- und eine Dev-Applikation inklusive, Anzahl der Domains egal - In Deutschland gehostet, standardmäßig cookiefrei* - Monitoring-Fokus: kein tiefes Fehler- und Netzwerk-Debugging - Optionales Sampling, um den Preis zu senken Empfohlen ## Standard 99 € /Monat 1 Million Pageviews inklusive, dann 50 € je weitere 1 Mio Alles, was fastmon kann, für Teams, die debuggen und optimieren. Kostenlos starten - Alles aus Light, plus: - Volles Debugging: Fehler-Gruppierung, Network-Waterfalls, Server-Timing - Synthetic Monitoring (Lighthouse und TTFB) - fastmon AI: Zusammenfassungen und Frag zu einem Test - Mindestens 60 Tage volle Retention, 13-Monats-Statistiken - Eine Prod- und eine Dev-Applikation inklusive, Anzahl der Domains egal - Optionales Sampling, um den Preis zu senken Individuell ## Enterprise Individuell Für traffic-starke Teams mit eigenem Pageview-Volumen, langer Retention und einem passenden Vertrag. Dieselbe EU-Plattform, auf deine Größe zugeschnitten. Mehr erfahren - Individuelles Pageview-Volumen und Retention-Fenster - Priorisierter Support mit festem Ansprechpartner - Begleitetes Onboarding und Dashboard-Setup - Debugging und Optimierung mit fastmon-Experten - Unterschriebener AVV und Security-Review Preise pro Monat, zzgl. USt. Early-Adopter-Preise, solange fastmon in der Beta ist. Preis-Rechner ## Was kostet es dich? Zieh den Regler auf deine monatlichen Pageviews und sieh beide Pläne. Sampling drückt den Preis weiter. Pageviews pro Monat 1.000.000 Light 69 € /Monat Nur Monitoring Standard 99 € /Monat Alles, mit Debugging Nicht sicher, ob jeder Pageview gemessen werden muss? Optionales Sampling senkt dein abrechenbares Volumen. Frag uns nach einem Sampling-Angebot. Enterprise ### Traffic in dieser Größe? Wir schneiden den Plan darauf zu. Ab 10 Millionen Pageviews im Monat bauen wir den Plan um dich herum: individuelles Volumen, die Retention, die du brauchst, und einen passenden Preis. Sag uns deinen Traffic und was du beobachten willst, und wir legen dir eine Zahl vor. Mehr erfahren Gegen den Markt ## Derselbe Job, ein Bruchteil des Preises. Einstiegspreise der RUM-Tools, mit denen uns Teams vergleichen. fastmon ist die günstigste Option in diesem Vergleich. | | fastmon | RUMvision | DebugBear | SpeedCurve | Einstiegspreis | ab 29 €/Monat | ab 150 €/Monat | ab 99 $/Monat | ab 90 $/Monat | Pageviews im Einstieg | 200k | 1,5 Mio. | 100k | konfigurierbar | In der EU gehostet | Ja | Ja | Nein | Nein | Langzeit-Aufbewahrung | Statistiken 13 Monate (Rohdaten 90 Tage Default) | ab ~700 €/Monat | 24 Monate | ab ~576 $/Monat Einstiegs-Listenpreise, Stand: 27. August 2026; individuelle Konditionen können abweichen, aktuelle Konditionen beim Anbieter. DebugBears günstigster Tarif mit RUM ist Startup für 99 $ bei jährlicher Zahlung (100k Pageviews), Team mit 500k kostet 249 $; SpeedCurves Einstieg bündelt RUM und Synthetic. RUMvision ist die andere EU-basierte Option. Fair von Haus aus ## Preise, die auf deiner Seite bleiben. Die Versprechen hinter dem Preis. Keine versteckten Stufen, keine Abrechnungs-Überraschungen, keine Bindung. ### Early-Adopter-Preis, fixiert Der Preis, zu dem du einsteigst, bleibt dein Preis, solange fastmon in der Beta ist. Für Early Adopter wird es nicht heimlich teurer. ### Keine Überraschungs-Rechnungen Nutzungsbasiert und transparent. Du zahlst nur für die Pageviews, die du wirklich sendest, und wir sagen Bescheid, bevor du eine Stufe überschreitest, nicht danach. ### Wir kappen dein Monitoring nie Überschreitest du dein inkludiertes Volumen, laufen deine Daten weiter. Wir melden uns, um es zu klären, statt still Pageviews zu verwerfen oder dein Dashboard zu sperren. ### Sampling behält die Kontrolle Schalte optionales Sampling jederzeit ein, um dein abrechenbares Volumen zu deckeln, und bleib auf deinem Plan, statt in einen größeren gedrängt zu werden. Support ## Produkt-Support inklusive. Expertise auf Abruf. Jeder Plan enthält Support fürs Produkt selbst. Wenn du einen Menschen brauchst, der in deine Daten eintaucht, ist das ein separater, praktischer Service. - Produkt-Support in jedem Plan, per E-Mail - Debugging-Support und Performance-Optimierung als Consulting, mit fastmon-Experten - Onboarding-Hilfe für Enterprise FAQ ## Pläne, beantwortet. Die Fragen, die man vor der Plan-Wahl stellt. ### Was zählt als Pageview? Jeder Seitenaufruf, den dein fastmon-Script meldet. Routenwechsel in Single-Page-Apps zählen als Soft Navigations. Du zahlst nur für die Pageviews, die du wirklich sendest. ### Was, wenn ich nicht weiß, wie viele Pageviews ich habe oder was es kostet? Kein Problem, dafür musst du nichts vorab wissen. Probier fastmon kostenlos aus: In der Zeit siehst du genau, wie viele Pageviews zusammenkommen und was dein Plan kosten würde, bevor du dich festlegst. ### Wie senkt Sampling den Preis? Sampling misst einen repräsentativen Anteil deines Traffics statt jeden einzelnen Pageview, das senkt dein abrechenbares Volumen und deinen Preis. Es ist optional; frag uns nach einem Sampling-Angebot. (Die Basis-Analytics-Zählung bleibt exakt und wird nicht gesampelt.) ### Wie viele Domains sind inklusive? Wir zählen nicht nach Domains, sondern pro Applikation: Eine Prod- und eine Dev-Applikation sind inklusive, jeweils mit ihren Subdomains wie einem Blog. Die Anzahl der Domains ist für uns nicht relevant. Mehrere getrennte Produkte? Das ist ein Enterprise-Thema. ### Was ist der Unterschied zwischen Light und Standard? Light ist nur Monitoring: Core Web Vitals, Analytics und Alerts, für kleine Shops, die nicht debuggen müssen. Standard ergänzt volles Debugging (Fehler-Gruppierung, Network-Waterfalls, Server-Timing), Synthetic Monitoring, fastmon AI, 60 Tage Retention und 13-Monats-Statistiken. ### Bekomme ich Hilfe bei Debugging oder Optimierung? Ja, als Consulting mit fastmon-Experten, getrennt vom Produkt-Abo. Produkt-Support ist in jedem Plan enthalten. ### Warum ist fastmon günstiger als RUMvision, DebugBear oder SpeedCurve? Early-Adopter-Preise und ein fokussiertes Produkt. RUMvision startet bei rund 150 €, DebugBears RUM-Tarif bei rund 249 $, SpeedCurve bei rund 90 $. fastmon Light startet bei 29 €, Standard bei 99 €, beide EU-gehostet. ## Volle Plattform, ab 29 € im Monat. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. In Deutschland gehostet. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/subprozessoren/ Subauftragsverarbeiter # Jeder Anbieter, offen auf dem Tisch. Ein Subauftragsverarbeiter ist ein Dienstleister, der für fastmon Kunden- oder Monitoring-Daten verarbeitet (Art. 28 DSGVO). Diese Seite listet beides: jeden Subauftragsverarbeiter im Kundendaten-Pfad und, weil Transparenz für uns nicht am Datenpfad endet, auch die internen Business-Tools, die nie Kunden- oder Monitoring-Daten sehen. Stand: 2. September 2026 ## Der Kundendaten-Pfad Jedes System, das Kunden- oder Monitoring-Daten verarbeitet. Eine kleine Zahl sorgfältig ausgewählter Subauftragsverarbeiter: jeder ein Unternehmen aus Deutschland oder der EU, jeder durch einen Auftragsverarbeitungsvertrag gebunden. Kein Anbieter im Kundendaten-Pfad ist ein US-Unternehmen; ein Zugriff über den US CLOUD Act ist damit nicht zu erwarten. ### Hosting und Infrastruktur | Anbieter | Zweck | Standort | Hetzner Online GmbH | Hosting, Storage, Backup | Deutschland Deutschland, Falkenstein | Sc ScaleCommerce GmbH | Hosting | Deutschland Deutschland, Berlin | sm smoxy GmbH | Ingress | Deutschland Deutschland, Berlin | BunnyWay d.o.o. | Autoritativer DNS-Dienst | Slowenien, Tržič ### Buchhaltung, Rechnungen und Zahlungen | Anbieter | Zweck | Standort | sd sevdesk GmbH | Buchhaltung und Rechnungserstellung | Deutschland Deutschland, Offenburg | Mo Mollie B.V. | Zahlungsabwicklung für Online-Zahlungen in Europa; regulierter Zahlungsdienstleister (PSD2) in eigener datenschutzrechtlicher Verantwortung, daher kein Subauftragsverarbeiter | Niederlande, Amsterdam ### E-Mail | Anbieter | Zweck | Standort | Lm Lettermint B.V. | Transaktionale E-Mails | Niederlande, Zwolle | So Soverin B.V. | Geschäftsmail | Niederlande, Rotterdam ### Engineering-Betrieb | Anbieter | Zweck | Standort | AQ All Quiet GmbH | On-Call-Tool fürs fastmon-Engineering | Deutschland Deutschland, Berlin ### KI (nur bei Opt-in) | Anbieter | Zweck | Standort | Mistral AI SAS | LLM-Inferenz, nur bei Opt-in der AI-Chat-Funktion | Frankreich, Paris Fünf der neun Subauftragsverarbeiter sitzen in Deutschland, die übrigen in der EU (Niederlande, Slowenien, Frankreich). Kartenzahlungen laufen über Mollie B.V. (Amsterdam), das als regulierter Zahlungsdienstleister in eigener Verantwortung handelt und daher kein Subauftragsverarbeiter ist. ## Interne Business-Tools Für den internen Geschäftsbetrieb nutzen wir außerdem die folgenden Anbieter. An sie werden keine Kunden- und keine Monitoring-Daten übertragen, sie verarbeiten keine, und sie sind deshalb keine Subauftragsverarbeiter im Sinne von Art. 28 DSGVO. Wir listen sie trotzdem, denn Transparenz endet für uns nicht am Datenpfad. | Anbieter | Zweck | Kundendaten | Standort | GitHub, Inc. Versionsverwaltung | Quellcode-Hosting, Versionsverwaltung und CI/CD-Pipelines | Keine übertragen | USA | Anthropic, PBC Entwicklung | KI-gestützte Entwicklung: Coding und Code-Reviews mit Claude Code | Keine übertragen | USA | Infomaniak Network SA Kommunikation | Interne Team-Kommunikation und Zusammenarbeit (kSuite) | Keine übertragen | Schweiz, Genf Unsere interne Richtlinie dazu ist einfach: keine Kunden- oder Monitoring-Daten in Repositories, Tickets, Chats oder Entwicklungs-Tools. Der komplette Kundendaten-Pfad bleibt in Deutschland und der EU. ## Internationale Datenübermittlungen Für den Kundendaten-Pfad findet keine Übermittlung in Drittländer statt: Alle Kunden- und Monitoring-Daten werden ausschließlich in Deutschland und der EU verarbeitet, und jeder Subauftragsverarbeiter sitzt in der EU. Für deine Daten brauchen wir deshalb weder Standardvertragsklauseln noch Angemessenheitsbeschlüsse; ein Zugriff über den US CLOUD Act ist nicht zu erwarten. Bei den internen Business-Tools sitzen zwei Anbieter in den USA und einer in der Schweiz. Sie verarbeiten keine Kunden- oder Monitoring-Daten; dort fallen nur interne Daten an, etwa Accounts unserer eigenen Mitarbeiter. Für diese internen Daten gelten die EU-Standardvertragsklauseln aus den Auftragsverarbeitungsverträgen der jeweiligen Anbieter (Art. 46 DSGVO), GitHub ist zusätzlich nach dem EU-US Data Privacy Framework zertifiziert, und die Schweiz ist durch einen Angemessenheitsbeschluss der EU-Kommission abgedeckt (Art. 45 DSGVO). ## Änderungen an dieser Liste Bevor wir einen neuen Subauftragsverarbeiter einsetzen oder einen bestehenden ersetzen, kündigen wir das mindestens 30 Tage vorab in Textform an und aktualisieren diese Seite. ## Widerspruchsrecht Als Kunde kannst du einem angekündigten neuen Subauftragsverarbeiter innerhalb von 30 Tagen aus wichtigem datenschutzrechtlichem Grund widersprechen (§ 7 AVV). Bei berechtigtem Widerspruch setzen wir den neuen Anbieter nicht für deine Daten ein, bis eine einvernehmliche Lösung gefunden ist; kommt innerhalb von 30 Tagen keine zustande, hast du ein außerordentliches Kündigungsrecht für den Hauptvertrag. Die verbindliche Fassung der Subauftragsverarbeiter-Liste ist Teil des Auftragsverarbeitungsvertrags . Fragen zum Datenpfad? Schreib an privacy@fastmon.eu. --- ## https://fastmon.eu/de/unternehmen/ Unternehmen Hannover, Deutschland # Ehrliches Monitoring, gehostet in Europa. fastmon ist ein kleines, unabhängiges Team in Deutschland. Wir bauen Real User Monitoring und Analytics, das du dir wirklich leisten kannst, und deine Daten bleiben in der EU. Keine Monatsrechnungen über mehrere tausend Euro, keine US-Clouds, keine dunklen Muster. - Sitz in Hannover - Hosting bei Hetzner (DE) - 100 % EU-Datenpfad Unsere Mission Jedes Team soll wissen, was seine Besucher wirklich erleben, ohne deren Daten zu verkaufen, zu exportieren oder dafür Enterprise-Preise zu zahlen. Warum fastmon ## Warum wir fastmon gebaut haben. Wir haben selbst traffic-starke Websites betrieben und mussten wissen, was unsere Besucher wirklich erleben. Die Tools, die uns das zeigen konnten, kosteten mehrere tausend Euro im Monat, und die meisten schickten unsere Daten in eine US-Cloud. Das fanden wir verkehrt. Zu wissen, wie schnell deine Seite für echte Menschen ist, sollte nicht mehr kosten als die Infrastruktur, auf der sie läuft, und es sollte nie bedeuten, die Daten deiner Besucher in eine andere Rechtsordnung zu geben. Also haben wir fastmon gebaut: Real User Monitoring, synthetische Checks und datenschutzfreundliche Analytics in einem Tool, vollständig in Deutschland gehostet und so bepreist, dass auch ein kleiner Shop es sich leisten kann. Unabhängig, und darauf ausgelegt, es zu bleiben. Wofür wir stehen ## Vier Dinge, bei denen wir keine Kompromisse machen. Die Prinzipien hinter jeder Entscheidung. ### Ehrliche Preise Ab 29 € im Monat statt mehrerer tausend. Nutzungsbasiert, transparent und keine Überraschungs-Rechnungen. ### Deine Daten bleiben in der EU Ausschließlich in Deutschland gehostet, kein US-Anbieter im Datenpfad. Souveränität, nicht nur Speicherort. ### Unabhängig gebaut Kein Wachstum um jeden Preis. Wir bauen fastmon so, dass es langfristig ein eigenständiges Produkt bleibt. ### Keine dunklen Muster Standardmäßig cookiefrei*, belegbare Aussagen und kein Kleingedrucktes, das gegen dich arbeitet. Team ## Die Menschen hinter fastmon. Ein kleines Team, das das Ganze baut und betreibt. ### Kamil Adrian Czujowski Co-Founder LinkedIn ### Lucas Röhrs Co-Founder LinkedIn ## Ehrliches Monitoring, unabhängig gebaut. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, in Deutschland gehostet. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/vergleich/ Vergleich # Warum Teams zu fastmon wechseln. Der ehrliche Fall gegen die Tools, die fastmon ersetzt oder ergänzt. Echte Unterschiede, keine Fake-Aussagen, und wir sagen, wo die anderen weiter gewinnen. Direktvergleich Synthetic ## vs Lighthouse Labor behalten, Feld ergänzen: Echtnutzer-Core-Web-Vitals neben deinen Lighthouse-Läufen. Zum Vergleich Analytics ## vs Google Analytics 4 Datenschutzfreundliche Analytics aus der EU, standardmäßig cookiefrei*, mit Performance inklusive. Zum Vergleich RUM ## vs Datadog Fokussiertes Web-Performance-RUM, EU-gehostet und cookiefrei*, zum Bruchteil der Enterprise-Rechnung. Zum Vergleich Was du heute auch nutzt ## Die vier Dinge, die immer gleich bleiben. Wie auch immer fastmon zu deinem aktuellen Tool steht, das hier gilt in jedem Fall. ### EU-gehostet, kein US-Recht In Deutschland verarbeitet, kein Cloudflare, AWS oder GCP; kein Anbieter im Datenpfad unterliegt US-Recht, der US CLOUD Act hat damit keinen Zugriff. ### Standardmäßig cookiefrei* Keine Cookies* im Standard-Modus, die IP am Edge verworfen, kein Fingerprinting. ### Ein Script, fünf Bereiche RUM, Synthetic Monitoring, Analytics, AI und Datenschutz aus einem einzigen Tag. ### Ab 29 € im Monat Enterprise-Fähigkeit ohne Enterprise-Rechnung, live in rund fünf Minuten. Ehrlich by Design ## Vergleiche, die du prüfen kannst. - Jede Wettbewerber-Aussage ist gegen die Doku und Preisliste des Anbieters geprüft. - Wir sagen auf jeder Seite, wo das jeweilige Tool fastmon noch schlägt. - fastmons eigene Zahlen kommen direkt aus unseren Docs und Rechtstexten. ## Ehrlich verglichen, in der EU gebaut. Web-Performance-Monitoring ohne US-Cloud: read-only im Standard, keine Cookies*, keine langlebigen Identifikatoren, ab 29 € im Monat. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/web-vitals-monitoring/ Web Vitals Monitoring # Core Web Vitals messen: live, ab dem ersten Besucher. Website-Geschwindigkeit misst man nicht im Labor, sondern bei echten Besuchern. fastmon ist Web Vitals Monitoring aus Deutschland: LCP, INP, CLS und TTFB aus jedem echten Besuch, DSGVO-konform einsetzbar und im Standard-Modus ohne Cookies*. Live in rund fünf Minuten. Live auf dieser Seite ## So sieht fastmon aus: dein Besuch, live gemessen. Kein Screenshot, keine Demo-Daten: Diese Seite misst sich selbst mit dem fastmon-Tracker. Unten stehen die Werte deines Besuchs auf dieser Seite, live gemessen mit deinem Gerät, deinem Netz, deinem Browser. Genau so würdest du jeden Besucher deiner eigenen Website sehen. Live: diese Seite misst sich gerade selbst dein Besuch TTFB FCP LCP CLS Dieselben Browser-APIs wie das fastmon-Skript. Ohne Cookies*. Navigationstyp ··· Nur echte Werte: Fehlt eine Zahl, kann dein Browser die Metrik nicht messen (Safari liefert zum Beispiel kein LCP). Genau so ehrlich misst fastmon auch auf deiner Website. Die Metriken ## LCP, INP, CLS und TTFB, kurz erklärt. Die drei Core Web Vitals, nach denen Google rankt, plus TTFB als Server-Diagnose. fastmon bewertet sie am p75 gegen die Schwellen von Google: Grün heißt, 75 % deiner Besucher waren mindestens so schnell. LCP ### Wie schnell erscheint der Hauptinhalt? Largest Contentful Paint ist der Moment, in dem das größte sichtbare Element (ein Hero-Bild, Video-Poster oder die Überschrift) gerendert ist. fastmon zerlegt es in seine vier Subparts, von TTFB bis Element-Render-Delay, damit du siehst, wo die Wartezeit steckt. Gut ≤ 2,5 s Grenzwertig ≤ 4,0 s Schlecht > 4,0 s INP ### Reagiert die Seite sofort auf Taps und Klicks? Interaction to Next Paint ist die Worst-Case-Verzögerung zwischen einer Interaktion und dem nächsten Frame. Sie ersetzte FID im März 2024 als Core Web Vital. Long Animation Frames (über 50 ms) zeigen auf das Script, das die Antwort blockiert hat. Gut ≤ 200 ms Grenzwertig ≤ 500 ms Schlecht > 500 ms CLS ### Springt das Layout beim Laden herum? Cumulative Layout Shift bewertet, wie viel sichtbarer Inhalt sich unerwartet verschiebt. fastmon meldet das schlechteste Shift-Fenster pro Besuch, damit ein spät ladender Banner, der deinen Inhalt nach unten schiebt, sich nicht im Durchschnitt versteckt. Gut ≤ 0,1 Grenzwertig ≤ 0,25 Schlecht > 0,25 TTFB ### Wie schnell antwortet dein Server? Time to First Byte ist die Zeit vom Klick bis zum ersten Byte der Server-Antwort: DNS, Verbindung, TLS und die Arbeit deines Backends. Kein Core Web Vital, aber ein hoher TTFB bremst alles danach, auch dein LCP. Die erste Stellschraube, wenn alles langsam ist. Gut ≤ 0,8 s Grenzwertig ≤ 1,8 s Schlecht > 1,8 s Modellrechnung ## Was kostet dich eine langsame Website? Die Deloitte/Google-Studie 'Milliseconds Make Millions' (2020) hat bei 37 Marken und über 30 Millionen Sessions gemessen, wie 0,1 s schnellere mobile Ladezeit mit Conversion und Umsatz zusammenhängen. Rechne das Modell mit deinen eigenen Zahlen durch. Deine Zahlen Besucher pro Monat Conversion-Rate in % Durchschnittlicher Warenkorb in € Was dich 0,1 s kostet 1.344 € /Monat Modellrechnung, keine Prognose Bei deinen Zahlen entspräche eine um 0,1 s schnellere Seite in diesem Modell rund 1.344 € mehr Umsatz pro Monat. Umsatz heute (Modell) 16.000 € Umsatz bei 0,1 s schnellerer Seite (Modell) 17.344 € Differenz pro Monat 1.344 € Differenz pro Jahr 16.128 € Modellrechnung auf Basis der Deloitte/Google-Studie 'Milliseconds Make Millions' (2020). Keine Ergebniszusage: dein tatsächlicher Effekt hängt von deiner Website, deiner Branche und deiner Umsetzung ab. fastmon misst, wo du Zeit verlierst; die Optimierung liegt bei dir. Transparenz ### So rechnen wir Umsatz = Besucher x Conversion-Rate x Warenkorb. Modellfaktor: +8,4 % Conversion je 0,1 s schnellerer mobiler Ladezeit, der Retail-Wert aus der Deloitte/Google-Studie 'Milliseconds Make Millions' (2020). Die Differenz oben ist also Umsatz x 0,084. Dieselbe Studie hat im Retail außerdem +9,2 % Warenkorbwert und im Travel-Segment +10,1 % Conversion gemessen; unser Modell nutzt bewusst nur den Retail-Conversion-Faktor. Zur Einordnung: Nach Google/SOASTA-Daten (2017) steigt die Absprungwahrscheinlichkeit um 32 %, wenn die Ladezeit von 1 s auf 3 s wächst. Quellen: Deloitte/Google 'Milliseconds Make Millions' (2020), Google/SOASTA Research (2017). FAQ ## Web Vitals Monitoring, beantwortet. Die Fragen, die man stellt, bevor man die Geschwindigkeit seiner Website misst. ### Was sind Core Web Vitals? Core Web Vitals sind die drei Nutzererlebnis-Metriken, die Google für jede Website misst und ins Ranking einbezieht: LCP (wie schnell erscheint der Hauptinhalt), INP (wie schnell reagiert die Seite auf Eingaben) und CLS (wie stark springt das Layout). Google bewertet sie am 75. Perzentil; gut heißt LCP ≤ 2,5 s, INP ≤ 200 ms und CLS ≤ 0,1. fastmon misst alle drei aus echten Besuchen, dazu Diagnose-Metriken wie TTFB, FCP und Page Load Time. ### Wie messe ich die Geschwindigkeit meiner Website? Es gibt zwei Wege, die sich ergänzen. Ein Labortest (Lighthouse, PageSpeed Insights) lädt deine Seite auf einem simulierten Gerät: reproduzierbar, aber er zeigt nicht, was deine Besucher erleben. Web Vitals Monitoring (Real User Monitoring) misst jede echte Ladezeit im Browser deiner Besucher, auf deren Geräten und in deren Netzen, aggregiert am p75. fastmon macht diese Felddaten ab dem ersten Besucher sichtbar, ohne 28-Tage-Durchschnitte, und ergänzt auf Wunsch geplante Lighthouse-Audits. ### Brauche ich für Web Vitals Monitoring einen Cookie-Banner? Nein, in den Modi Minimal und Standard nicht. Es wird nichts auf dem Endgerät gespeichert, und die Werte, die gelesen werden, lagen vorher nicht dort: sie entstehen erst beim Seitenaufruf. Es genügt, fastmon in deiner Datenschutzerklärung zu nennen. Im Modus Full brauchst du eine Einwilligung, weil dort eine Kennung in den sessionStorage geschrieben wird. Diese Einordnung ist mit unserem externen Datenschutzbeauftragten geprüft; ein Restrisiko bleibt, weil zu dieser Konstellation kein Urteil vorliegt. Die ganze Herleitung, mit Normtext und Gegenauffassung ### Macht eine schnellere Website wirklich mehr Umsatz? Es gibt belastbare Feldstudien dazu. Die Deloitte/Google-Studie 'Milliseconds Make Millions' (2020) hat bei 37 Marken über 30 Millionen Sessions gemessen, dass 0,1 s schnellere mobile Ladezeit im Retail-Segment mit +8,4 % Conversion und +9,2 % Warenkorbwert einherging, im Travel-Segment mit +10,1 % Conversion. Nach Google/SOASTA-Daten (2017) steigt die Absprungwahrscheinlichkeit um 32 %, wenn die Ladezeit von 1 s auf 3 s wächst. Das sind Korrelationen aus Feldstudien, keine Garantie für deine Seite: dein Effekt hängt von deiner Website, deiner Branche und deiner Umsetzung ab. Deshalb rechnet unser Rechner transparent mit einem offengelegten Modellfaktor und sagt dir nichts zu. ### Was kostet Web Vitals Monitoring mit fastmon? fastmon Light startet bei 29 € im Monat mit 200.000 Pageviews: Core Web Vitals, Real User Monitoring, Web-Analytics und Alerts. Standard ab 99 € ergänzt volles Debugging, Synthetic Monitoring und fastmon AI. Beide in Deutschland gehostet, live in rund fünf Minuten, zum Start ohne Kreditkarte. ## Web Vitals Monitoring, ab 29 € im Monat. Live ab dem ersten Besucher, read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren. In Deutschland gehostet. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/blog/browser-cdn-origin-cache/ Zurück zum Blog Performance # Browser-Cache, CDN-Cache, Origin-Cache: was bedeutet das? Wenn jemand sagt: schalt doch den Cache ein. Welchen denn? Es gibt drei, sie liegen hintereinander, und zwischen der ersten und der letzten Schicht liegt eine halbe Sekunde Wartezeit für deine Besucher. Kamil Adrian Czujowski 30. Juli 2026 · 6 Min. Lesezeit Ganz ehrlich: Über Caches denkt niemand freiwillig nach. Bis die Seite langsam ist, im Meeting jemand “aktivier doch mal den Cache” sagt und die nächste Frage im Raum steht: welchen denn? Denn es sind drei. Sie liegen hintereinander, und jede weitere kostet Zeit. Dabei ist ein Cache immer dasselbe: eine fertige Kopie, damit dieselbe Arbeit nicht zweimal gemacht werden muss. Interessant ist nur, wo diese Kopie liegt und wie weit sie von deinem Besucher entfernt ist. Ein Besucher ruft deine Seite auf 1. Browser-Cache Kopie liegt schon auf dem Gerät des Besuchers 0 ms nicht da, also weiter 2. CDN-Cache Kopie liegt im Rechenzentrum in seiner Nähe ~20 ms nicht da, also weiter 3. Origin-Cache fertige Seite liegt auf deinem eigenen Server ~150 ms nicht da, also weiter Kein Cache mehr die Seite wird komplett neu gebaut: Datenbank, Preise, Templates ~600 ms Die erste Schicht, in der die Kopie liegt, antwortet. Alles darunter kostet zusätzlich Zeit. Die Werte sind typische Größenordnungen, keine Garantien. ## Die drei Schichten, in normaler Sprache ### Der Browser-Cache: die Kopie beim Besucher Der schnellste Cache ist der, bei dem gar keine Anfrage rausgeht. Der Browser hat die Datei noch auf dem Gerät und nimmt sie von dort. Kein Netz, keine Wartezeit. Der Haken liegt auf der Hand: Beim ersten Besuch ist dieser Cache leer. Für jeden neuen Besucher, also für jeden, den deine Kampagne gerade bringt, existiert er nicht. Der Browser-Cache belohnt Stammkunden. Neukunden sieht er nie. ### Der CDN-Cache: die Kopie in der Nähe Ein CDN ist ein Netz aus Servern in vielen Ländern, das deine Seite von dem Standort ausliefert, der dem Besucher am nächsten ist. Gespart wird hier nicht nur Arbeit, sondern Entfernung: Ein Besucher in Sydney bekommt seine Antwort aus Sydney statt aus Frankfurt. Der große Hebel steckt darin, auch die Seite selbst zu cachen, nicht nur Bilder und Skripte. Bei Bildern macht das jeder, bei der Seite kaum jemand. Und genau dort sitzt die Wartezeit, die der Besucher vor dem leeren Bildschirm verbringt. ### Der Origin-Cache: die fertige Seite auf deinem Server Kommt die Anfrage doch bei dir an, entscheidet die dritte Schicht, wie teuer sie wird. Der Origin-Cache hält die fertig gebaute Seite bereit, statt sie jedes Mal neu zusammenzusetzen. Hier ist der Unterschied am größten. Mit Kopie: einmal rausschicken. Ohne Kopie: Datenbank fragen, Preise rechnen, Templates rendern, Verfügbarkeiten prüfen. Deshalb der Sprung von 150 auf 600 Millisekunden in der Grafik. Für den Besucher sind diese drei Schichten übrigens nicht unterscheidbar. Er merkt nur, ob die Seite sofort da ist oder nicht. ## HIT und MISS: die zwei Wörter, die zählen Caches beschreiben ihr Ergebnis immer mit denselben Wörtern. Zwei davon reichen für den Anfang: - HIT : Die Kopie war da, sie ging direkt raus. Der gute Fall. - MISS : Die Kopie war nicht da, die Anfrage musste eine Schicht tiefer. Sobald du in ein Dashboard oder ein Server-Log schaust, tauchen ein paar Zwischenstufen auf. Du musst sie nicht auswendig kennen, nur einordnen können: EXPIRED heißt, die Kopie war zu alt und wurde erneuert. STALE heißt, eine alte Kopie ging bewusst raus, um Zeit zu sparen. REVALIDATED heißt, die Kopie wurde geprüft und war noch gültig. BYPASS , PASS , DYNAMIC und NONE heißen alle dasselbe in Varianten: Für diese Anfrage war der Cache nicht zuständig. Ein Punkt ist dabei wichtig, weil er oft untergeht: Diese Wörter gelten pro Schicht. Ein HIT im CDN und ein MISS im Origin-Cache sind zwei getrennte Aussagen. Erst zusammen ergeben sie ein Bild davon, wer eigentlich geantwortet hat. ## Warum das nicht nur Technik ist Die Zeit bis zum ersten Byte, in Berichten TTFB genannt, ist der Boden, auf dem alles andere steht. Solange sie läuft, sieht dein Besucher nichts. Kein Bild, keine Überschrift, keinen Button. Der Browser kann nichts anzeigen, was er noch nicht bekommen hat. Zwei Konsequenzen, die über die Technik hinausgehen: Google bewertet, was echte Besucher erleben. Für das Ranking zählen die Core Web Vitals aus echten Chrome-Besuchen, nicht der Testlauf auf dem Rechner deiner Agentur. Welche Cache-Schicht geantwortet hat, ist damit ein Ranking-Faktor, auch wenn er auf keiner Rechnung steht. Wartezeit kostet genau dort, wo du sie am wenigsten brauchst. Bezahlten Traffic schickst du auf Landingpages. Deren Besucher kommen zum ersten Mal, haben also keinen Browser-Cache, und landen oft auf URLs mit Kampagnen-Parametern. Wenn irgendwo die Kopie fehlt, zahlt genau dieser Besuch die Wartezeit. Und hier ist die Falle, die moderne Hosting-Plattformen aufstellen. Antworten aus dem Edge-Cache sehen fantastisch aus, ein Fehlschlag daneben kann zehnmal langsamer sein. Im Durchschnitt verschwindet dieser Unterschied vollständig. Deshalb ist die Trefferquote die Zahl, auf die es ankommt, nicht der Mittelwert. Ein Cache ist also kein Schalter, den man einmal umlegt. Er ist eine Quote, und die schwankt. ## Was einen Cache im Alltag kaputt macht Drei Dinge erklären die meisten schlechten Trefferquoten, und alle drei kommen selten aus der Technik-Ecke: - Kampagnen-Parameter. Hängt an jedem Link ein ?utm_source=... , ist das für viele Caches eine andere Adresse und damit eine eigene Kopie. Im schlimmsten Fall bekommt jeder Kampagnen-Klick einen MISS. Gut konfigurierte Caches ignorieren bekannte Tracking-Parameter beim Nachschauen. Das muss man ihnen aber sagen. - Cookies. Setzt eine Antwort ein Cookie oder liest eines, behandeln viele Caches sie als persönlich und cachen sie gar nicht. Ein neu eingebautes Tool, ein Consent-Banner, ein A/B-Test: Solche Dinge können eine gute Trefferquote über Nacht halbieren, ohne dass jemand etwas “an der Performance” geändert hat. - Jeder Release. Nach einem Deploy ist der Cache erst einmal leer. Die ersten Besucher danach bezahlen den Wiederaufbau. Bei zehn Deploys pro Woche ist das kein Randfall, sondern Alltag. Alle drei sieht man nicht, wenn man auf einen Durchschnitt schaut. Man sieht sie, wenn man die Trefferquote pro Schicht kennt und weiß, wann sie gefallen ist. ## Was du deinen Entwicklern sagen kannst Deine Server kennen jede dieser Antworten. Sie sagen es nur niemandem, solange man sie nicht darum bittet. Dafür gibt es einen Standard-Header, den der Browser bei jedem Besuch mitliefert: Server-Timing: cdn-cache;desc="HIT", fm-fpc;desc="MISS", db;dur=48 Übersetzt: Das CDN hatte die Kopie, der Origin-Cache nicht, und die Datenbank brauchte 48 Millisekunden. Vier Zeilen in der Server-Konfiguration reichen dafür. fastmon liest beide Schichten getrennt aus, aus jedem echten Besuch, und stellt die Trefferquote direkt neben die Ladezeit. Seitenaufrufe ohne Angabe erscheinen als “Unbekannt”, und auch das ist eine Aussage: Dort weiß aktuell niemand, was passiert. Hinweis: Welche Header-Namen fastmon erkennt und was jeder Status bedeutet, steht in unserer Doku zu Server-Timing . Der Link ist genau das, was deine Entwickler brauchen. ## Was du mitnimmst Drei Schichten, eine Reihenfolge, eine Frage: Wer hat geantwortet? Der Browser-Cache hilft nur Wiederkehrern. Das CDN entscheidet über die Entfernung, wenn du auch die Seite selbst cachst. Der Origin-Cache entscheidet, wie teuer ein Fehlschlag wird. Und die Trefferquote ist keine Einstellung, die man abhaken kann. Sie ist eine Zahl, die man im Blick behält. Real User Monitoring zeigt sie dir aus jedem echten Besuch, statt sie im Labor zu schätzen. Über den Autor Kamil Adrian Czujowski Co-Founder Seit 2009 im E-Commerce zu Hause. Kennt Online-Shops von beiden Seiten: vom Entwickeln von Bots für Sneaker-Releases bis zur Absicherung von E-Commerce-Plattformen gegen genau solche Angriffe. Sein Fokus bei fastmon liegt auf Performance und Zuverlässigkeit unter Last: kurze Ladezeiten, hohe Verfügbarkeit und ein sauberes, datenschutzfreundliches Setup. LinkedIn --- ## https://fastmon.eu/de/blog/deploy-regressions/ Zurück zum Blog Performance # Jeder Deploy kann deine Performance kaputt machen. Merkst du es? Regressionen hängen fast immer an einem Deploy. Warum der Durchschnitt sie versteckt, wie ein Release-Marker aus der CI/CD sie sichtbar macht und was du am p75 wirklich vergleichst. Kamil Adrian Czujowski 6. August 2026 · 4 Min. Lesezeit Ganz ehrlich: Kaum jemand deployt und denkt dabei an sein LCP. Man merged den Branch, die Pipeline wird grün, das Feature ist live. Fertig. Dass genau dieser Deploy die Ladezeit von 2,1 auf 3,4 Sekunden geschoben hat, steht in keiner Fehlermeldung. Nichts ist “kaputt”. Es ist nur langsamer geworden. Und das ist das Tückische an Performance-Regressionen: Sie werfen keinen Fehler. Sie schleichen sich mit einem ganz normalen, erfolgreichen Deploy ein und bleiben, bis jemand sie zufällig bemerkt. Meistens Wochen später, meistens ein Kunde. ## Warum Regressionen fast immer an einem Deploy hängen Deine Seite wird nicht über Nacht von selbst langsamer. Sie wird langsamer, weil sich etwas geändert hat: eine neue Library im Bundle, ein Bild ohne Größenangabe, ein Skript von einem Dritten, ein Font, der jetzt blockiert, eine Query, die eine Spalte mehr zieht. All das kommt mit einem Deploy. Deshalb ist die ehrlichste Frage bei jeder Regression nicht “was ist langsam?”, sondern “seit wann?”. Und “seit wann” ist fast immer “seit welchem Deploy”. Wer den Zeitpunkt kennt, hat den Verdächtigen. Wer ihn nicht kennt, sucht im Nebel. ## Warum du es im Durchschnitt nicht siehst Jetzt kommt der Teil, der die meisten austrickst. Du schaust auf dein Performance-Dashboard, siehst die letzten 7 Tage, und die Kurve ist… unauffällig. Kein Ausschlag, kein Alarm. Also alles gut? Nein. Zwei Dinge verstecken die Regression: Der Durchschnitt glättet sie weg. Wenn ein Deploy die Hälfte deiner Seiten verlangsamt, die andere Hälfte aber gleich bleibt, bewegt sich der Mittelwert kaum. Deshalb schaut man in der Web-Performance nicht auf den Durchschnitt, sondern auf das 75. Perzentil, kurz p75. p75 heißt: 75 % deiner Besucher waren mindestens so schnell. Der Durchschnitt schmeichelt. p75 zeigt dir das Erlebnis derer, die es trifft. Das lange Fenster verdünnt sie. Eine Regression, die vor zwei Tagen live ging, ertrinkt in fünf Tagen alter, guter Daten davor. Über eine Woche gemittelt ist der Sprung ein kleiner Hügel. Über die 24 Stunden davor und danach ist er eine Wand. Beides zusammen sorgt dafür, dass ausgerechnet die Zahl, die den Schaden zeigt, die ist, auf die kaum jemand schaut: p75, in einem kurzen Fenster, rund um den Deploy. ## Der Release-Marker: ein Zeitpunkt, mehr nicht Damit man “rund um den Deploy” überhaupt sagen kann, muss das System wissen, wann der Deploy war. Genau das ist ein Release: ein benannter Zeitpunkt auf deiner Seite. Mehr steckt nicht dahinter. Eine Version ( v2.4.1 , ein Git-SHA, ein Datum, egal was) und ein Zeitstempel. Keine Deploy-Datenbank, kein Changelog, nur der Marker. Am saubersten setzt du ihn automatisch, am Ende deines Deploy-Jobs, nach erfolgreichem Deploy: - name: Tag fastmon release if: success() env: FASTMON_TOKEN: ${{ secrets.FASTMON_TOKEN }} FASTMON_SITE_ID: ${{ vars.FASTMON_SITE_ID }} run: curl -fsS https://api.fastmon.eu/v1/sites/$FASTMON_SITE_ID/releases \ -H "Authorization: Bearer $FASTMON_TOKEN" \ -H "Content-Type: application/json" \ -d "{ \"version\": \"${{ github.sha }}\" }" Vier Zeilen, einmal eingerichtet. Ab dann trägt jeder erfolgreiche Deploy seinen eigenen Marker, ganz ohne dass sich jemand merken muss, wann was live ging. ## Was du danach vergleichst Mit dem Marker wird aus “ist das schlechter geworden?” eine einzige Abfrage. Du wählst im Release-Picker den Deploy aus, und das Chart legt Vorher und Nachher übereinander. Programmatisch heißt der Hebel compare_to_release_id . Und jetzt der wichtige Teil, den man einmal verstanden haben muss: Das “Vorher”-Fenster ist genau so lang wie dein “Nachher”-Fenster und endet exakt zum Zeitpunkt des Releases. Fragst du die 24 Stunden nach dem Deploy ab, vergleicht das System sie mit den 24 Stunden direkt davor. Gleiche Länge, gleiche Tageszeit, gleicher Wochentag-Mix. Nur der Deploy liegt dazwischen. Daraus folgt ein einfacher Rat: Halt das Fenster kurz. Eine 7-Tage-Abfrage vergleicht gegen die 7 Tage davor und verwischt den Sprung wieder. Willst du eine Regression scharf sehen, nimm 1 bis 24 Stunden. ## Die drei Stolperfallen Drei Dinge lassen den Vergleich in der Praxis haken, und keins davon ist kompliziert: - Der Zeitstempel muss stimmen. Lässt du released_at weg, setzt der Server “jetzt”. Meistens passt das. Aber wenn dein Deploy-Job Minuten vor dem echten Live-Gehen läuft, etwa bei einem Blue/Green-Flip, dann datier den Marker auf den Moment, in dem die neue Version wirklich Traffic bekommt. Sonst schneidest du am falschen Punkt. - Releases hängen an einer Seite. Wer in einem Monorepo drei Sites ausliefert, braucht drei Release-Calls, auch wenn der Version-String identisch ist. - Ein Rollback ist auch ein Release. Tagg ihn genauso, gerne als rollback-v2.4.0 . Dann siehst du im Chart alle drei Übergänge: den kaputten Release live, die Regression und den Rollback, der die Kurve wieder einfängt. Ehrlicher lässt sich ein schlechter Tag nicht dokumentieren. Hinweis: Den kompletten Ablauf, von API-Token über den Release-Call aus GitHub Actions, GitLab CI oder Vercel bis zur Vergleichs-Query, findest du in unserer Doku zu Releases vergleichen . Das ist genau die Seite, die deine Entwickler brauchen. ## Zwei Netze statt einem Am besten fängst du eine Regression, bevor sie überhaupt live geht. Genau dafür laufen synthetische Tests: ein Labortest unter immer gleichen Bedingungen, der einen Sprung meldet, bevor der Deploy echte Besucher erreicht. Mehr zu Synthetic Monitoring . Aber das Labor kennt nicht jedes Gerät und jedes Netz. Was durchrutscht, fängst du im Feld: an echten Besuchern, am p75, im kurzen Fenster rund um den Release-Marker. Mehr zu Real User Monitoring . Zwei Netze, hintereinander. Das eine vor dem Deploy, das andere danach. ## Was du mitnimmst Regressionen werfen keinen Fehler, sie hängen an einem Deploy, und der Durchschnitt über eine Woche versteckt sie zuverlässig. Sichtbar werden sie erst, wenn drei Dinge zusammenkommen: ein Marker auf dem Deploy, der p75 statt des Durchschnitts und ein kurzes Fenster rund um den Marker. Der Marker kostet dich vier Zeilen in der CI. Den Rest macht die Abfrage. Und die nächste Regression bekommt dann keinen Wochen-Vorsprung mehr. Über den Autor Kamil Adrian Czujowski Co-Founder Seit 2009 im E-Commerce zu Hause. Kennt Online-Shops von beiden Seiten: vom Entwickeln von Bots für Sneaker-Releases bis zur Absicherung von E-Commerce-Plattformen gegen genau solche Angriffe. Sein Fokus bei fastmon liegt auf Performance und Zuverlässigkeit unter Last: kurze Ladezeiten, hohe Verfügbarkeit und ein sauberes, datenschutzfreundliches Setup. LinkedIn --- ## https://fastmon.eu/de/blog/mcp-server/ Zurück zum Blog Produkt # Frag deine KI nach deiner Web-Performance: fastmon hat jetzt einen MCP-Server Verbinde Claude, Claude Code oder Cursor mit fastmon und frag nach deinen Felddaten, statt sie im Dashboard zusammenzuklicken. Neunzehn lesende Werkzeuge, OAuth statt Schlüssel, und eine ehrliche Notiz dazu, wer dabei deine Daten bekommt. Kamil Adrian Czujowski 8. September 2026 · 7 Min. Lesezeit Deine KI schreibt inzwischen deine Commit-Messages, liest deine Logs und erklärt dir fremden Code. Deine Felddaten waren nicht dabei. Für die bist du weiter ins Dashboard gegangen, hast einen Zeitraum gewählt, ein Land gefiltert und die Zahl danach abgetippt. Seit dem 2. September kannst du stattdessen fragen. fastmon hat einen MCP-Server. Du verbindest deinen eigenen KI-Client damit, Claude, Claude Code oder Cursor, und der holt sich die Daten selbst. Das Modell bleibt deins. Was das für deine Daten bedeutet, steht weiter unten, ungekürzt. ## Was MCP ist MCP steht für Model Context Protocol, ein offener Standard, mit dem sich ein KI-Client an fremde Dienste hängt. Statt Zahlen aus einem Dashboard in einen Chat zu kopieren, ruft der Client sie selbst ab. In Claude heißen diese Verbindungen Connectors, in Cursor MCP-Server, in anderen Clients wieder anders. Das Protokoll darunter ist überall dasselbe. Für dich heißt das: eine Adresse einmal eintragen, einmal per OAuth anmelden, danach fragen wie einem Kollegen, der Zugriff aufs Dashboard hat. ## Was du fragen kannst Neunzehn Werkzeuge stehen bereit, alle lesend. Was sie liefern, sind dieselben Aggregate und Ranglisten, die auch hinter deinem Dashboard stecken. Drei Situationen, in denen wir es selbst benutzen. ### Die Regression nach dem Deploy Freitagnachmittag ist ein Release rausgegangen, montags ist irgendwas langsamer. Statt zwei Zeiträume im Dashboard nebeneinanderzulegen, lässt du vergleichen. - Vergleiche LCP und INP der letzten sieben Tage mit den sieben Tagen davor - Was hat sich seit dem Release am Freitag verändert? Dahinter arbeiten compare_periods und detect_changes . Das zweite sucht die Auffälligkeiten selbst, statt darauf zu warten, dass du die richtige Dimension errätst. ### Die Frage aus dem Meeting Jemand will wissen, warum die Seite auf dem Handy schlechter dasteht, und erwartet keinen Vortrag über Perzentile, sondern eine Antwort. - Wie ist LCP p75 in Deutschland auf Mobil, aufgeschlüsselt nach Seitentyp? - Welche Drittanbieter kosten am meisten Ladezeit? get_breakdown liefert die Aufschlüsselung, get_cwv_distribution die Verteilung dahinter, get_third_party_impact die Fremdskripte. Bei fünfzig Zeilen ist Schluss, was für ein Gespräch reicht und für einen Export nicht gedacht ist. ### Der Fehler, den nur Safari sieht Ein JS-Fehler taucht auf, betrifft aber vielleicht nur eine Browserversion, und du willst wissen, ob sich die Arbeit lohnt. - Welche JS-Fehler sind diese Woche neu? - Zeig mir Details zu diesem Fehler, welche Browser und welche Seiten get_errors und get_error_detail . Was zurückkommt, sind Fehlersignaturen und Zählungen, keine Sessions einzelner Besucher. ## Was dabei herauskommt Eine der ersten Fragen, die wir dem Server gestellt haben, war die langweiligste: wie die Zugriffe heute aussehen. Die Antwort war keine Zahl. Gefragt war nach Zugriffen, geantwortet wurde mit einer Diagnose. Null Seitenaufrufe, aber nicht, weil niemand da war: der Tracker meldete seit dem 3. September, 08:37 Uhr gar nichts mehr. Das kommt aus get_data_freshness , und der Client hat von selbst nachgesehen, bevor er eine Null berichtet. Danach hat er die naheliegende Erklärung gleich mitgeliefert und gefragt, ob das Snippet noch eingebunden ist. Zur Ehrlichkeit gehört: das ist eine lokale Entwicklungsumgebung, Domain localhost , Shopware, mit Zahlen im zweistelligen Bereich. Ein Vorzeigebild ist das nicht. Es zeigt aber genau den Unterschied zwischen einer Zahl und einer Antwort, und deshalb steht es hier statt eines schöneren Bildes. ## Was der Server nicht kann Alle neunzehn Werkzeuge sind lesend. Es gibt keins, das eine Einstellung ändert, etwas löscht oder einen synthetischen Lauf startet. Wenn dein Client auf die Idee kommt, es zu versuchen, findet er nichts vor. Rohdaten gibt es auch nicht. Zurück kommen Aggregate und Ranglisten, keine einzelnen Beacon-Zeilen. Dazu ein paar harte Grenzen: | Grenze | Wert | Zeitraum je Abfrage | maximal 90 Tage | Zeilen je Aufschlüsselung | maximal 50 | Anfragen je Person | 120 pro Minute | Minutengenaue Buckets | nur bis 6 Stunden Zeitraum | Laufzeit je Abfrage | Abbruch nach 30 Sekunden Das Ratenlimit gilt pro Person, nicht pro Organisation, damit ein redefreudiger Client nicht die Kollegen blockiert. Wer es reißt, bekommt eine 429 mit der Wartezeit in Sekunden. Drei der neunzehn Werkzeuge betreffen Lighthouse-Läufe und brauchen zusätzlich Synthetic Monitoring im Abo sowie den Scope synthetic:read . Fehlt eines von beiden, sagt der Server das, statt eine leere Liste zu schicken. ## KI und Datenschutz Hier wird es interessant, denn in dem Moment, in dem du deinen Client verbindest, gehen Daten an eine Stelle, die nicht wir sind. Was rausgeht, sind dieselben Felddaten, die dein Dashboard zeigt: Seiten-URLs, Referrer, UTM-Parameter, Land, Gerät und Browser, Zeitstempel, Fehlersignaturen. Empfänger ist der KI-Anbieter, der deinen Client betreibt. Nicht fastmon. Wir wählen diesen Anbieter nicht aus und sind an dem Verhältnis nicht beteiligt, was im Klartext heißt: die Verantwortung für diese Weitergabe liegt bei deiner Organisation. Wir schreiben das so deutlich hin, weil es der Punkt ist, an dem MCP sich von jedem anderen Feature unterscheidet, das wir gebaut haben. Was auf unserer Seite möglich war, haben wir gemacht: - Standardmäßig aus. Ein Owner muss MCP in den Einstellungen der Organisation einschalten. Das erzeugt einen Eintrag im Audit-Log, damit später niemand rätseln muss, ab wann der Zugang offen war. - OAuth statt Schlüssel. Es gibt keinen Key zum Kopieren. Persönliche Keys, Organisations-Keys und Session-Cookies lehnt der Endpunkt ab, weil ein Key keine Audience trägt und deshalb nicht sagen kann, ob er für diesen Endpunkt ausgestellt wurde. - Die Verbindung gehört dir, nicht der Organisation. Ihre Rechte kommen bei jedem Request aus deiner aktuellen Rolle. Wirst du zurückgestuft, wirkt das sofort. Verlässt du das Team, ist die Verbindung wertlos. - Trennen dauert einen Klick. Unter Konto und Zugang kappst du die Verbindung, die Access Tokens laufen innerhalb von Minuten ab. - Kein Konfigurationszugriff. Tokens, Mitglieder, Abrechnung: dafür gibt es kein Werkzeug. Nicht verwechseln solltest du das mit dem Ask-Assistenten im Dashboard. Der läuft unter unserer eigenen AVV, ist also ein anderer Empfänger mit einer anderen Zustimmung. Wer keine Daten an einen dritten Anbieter geben will, benutzt Ask und lässt MCP aus. ## So verbindest du deinen Client Ein Owner schaltet MCP unter Einstellungen und MCP-Server ein, danach dauert der Rest zwei Minuten. Jeder Client benutzt dieselbe Adresse, genau so, ohne Slash am Ende: https://api.fastmon.eu/mcp ### Claude Code Eine Zeile im Terminal: claude mcp add --transport http fastmon https://api.fastmon.eu/mcp Danach /mcp öffnen, fastmon auswählen und anmelden. ### Claude und Cursor In Claude unter Einstellungen und Connectors, in Cursor unter MCP, jeweils die Adresse eintragen. Die OAuth-Felder bleiben leer. Beide schicken dich zu fastmon, wo du siehst, wer da eigentlich fragt: Der Hinweis, dass wir die App nicht geprüft haben, steht da bewusst. Jeder kann eine App unter jedem Namen registrieren. Auf diesem Bildschirm wählst du auch die Organisation. Kein Werkzeug nimmt später eine Organisation als Parameter, der Kontext steht mit deiner Zustimmung fest. Beim ersten Werkzeugaufruf fragt dein Client noch einmal, diesmal auf seiner Seite: Zwei Zustimmungen auf zwei Ebenen: fastmon fragt für den Zugriff, dein Client für jeden Werkzeugaufruf. ## Für Agenturen Partner verbinden sich einzeln zu jeder Kundenorganisation, und der Kunde steht auf dem Zustimmungsbildschirm. Die Rechte lösen sich pro Request auf. Endet die Partnerschaft, endet der Zugriff im selben Moment. Ob MCP überhaupt offen ist, entscheidet weiterhin der Kunde. ## Die ganze Liste Alle neunzehn Werkzeuge mit ihren Parametern, die OAuth-Details für eigene Clients samt resource -Parameter nach RFC 8707 und dem Well-known-Dokument nach RFC 9728, dazu die Einrichtung in weiteren Clients: das steht in der MCP-Doku . Und wenn du es ausprobierst und dein Client etwas nicht findet, das er finden sollte, schreib uns. Neunzehn Werkzeuge sind ein Anfang, keine fertige Liste. fastmon kostenlos starten Oder direkt die MCP-Doku lesen Über den Autor Kamil Adrian Czujowski Co-Founder Seit 2009 im E-Commerce zu Hause. Kennt Online-Shops von beiden Seiten: vom Entwickeln von Bots für Sneaker-Releases bis zur Absicherung von E-Commerce-Plattformen gegen genau solche Angriffe. Sein Fokus bei fastmon liegt auf Performance und Zuverlässigkeit unter Last: kurze Ladezeiten, hohe Verfügbarkeit und ein sauberes, datenschutzfreundliches Setup. LinkedIn --- ## https://fastmon.eu/de/blog/real-user-monitoring-tools/ Zurück zum Blog Performance # Real User Monitoring Tools 2026: acht Anbieter, ehrlich verglichen Acht Real-User-Monitoring-Tools im Vergleich: Preise, Hosting und was auf dem Endgerät landet. Listenpreise vom 2. September 2026, mit ehrlicher Empfehlung. Kamil Adrian Czujowski 2. September 2026 · 16 Min. Lesezeit Ganz ehrlich, gleich im ersten Satz: Wir bauen eines der Tools in dieser Liste. Du liest einen Vergleich auf dem Blog eines Anbieters, und das gehört an den Anfang, nicht ins Kleingedruckte. Deshalb machen wir es anders als die meisten Listen dieser Art. Die Kriterien stehen vorne, bevor das erste Tool kommt. Jeder Preis ist ein Listenpreis mit Prüfdatum. Wo wir eine Angabe nicht belegen konnten, steht “nicht geprüft” statt einer Vermutung. Und bei jedem Tool steht dabei, wann es die bessere Wahl ist als fastmon. Das sind keine Höflichkeitsfloskeln: bei mehreren Anbietern in dieser Liste gibt es Situationen, in denen wir selbst zu ihnen greifen würden. ## Was Real User Monitoring misst, und was nicht Real User Monitoring misst die Erfahrung echter Besucher, während sie deine Seite benutzen. Ein kleines Script im Browser erfasst, wie lange es bis zum größten sichtbaren Element gedauert hat, wie schnell die Seite auf den ersten Klick reagiert hat und wie stark der Inhalt beim Laden gesprungen ist. Diese Werte gehen an den Anbieter, der sie über alle Besucher hinweg auswertet. Der Unterschied zum Labortest ist der Grund, warum es RUM überhaupt gibt. Ein Lighthouse-Lauf misst eine Seite unter festgelegten Bedingungen: ein Gerät, ein Netz, ein Standort. Deine Besucher sind aber keine festgelegte Bedingung. Sie sitzen auf vier Jahre alten Android-Geräten im überlasteten Mobilfunknetz, im Bürocomputer mit Glasfaser oder im Zug mit wechselnder Verbindung. RUM zeigt diese Verteilung, und deshalb ist es die Datengrundlage, auf die auch Google schaut. Wichtig ist, was RUM nicht kann. Es sagt dir nicht reproduzierbar, warum etwas langsam war, weil jede Messung unter anderen Bedingungen entstand. Es misst nichts, bevor der erste echte Besucher da war, taugt also nicht als Test vor dem Deploy. Und bei wenig Traffic wird die Statistik dünn: unter etwa tausend Seitenaufrufen im Monat sind die Perzentile nicht mehr stabil genug für Entscheidungen. ## RUM oder synthetisches Monitoring? Diese Frage taucht in jeder Toolauswahl auf, und die ehrliche Antwort lautet: beides, wenn es geht. | Real User Monitoring | Synthetisches Monitoring | Datenquelle | echte Besucher | geplante Testläufe | Bedingungen | wechselnd, wie die Realität | festgelegt und wiederholbar | Findet ein Problem | wenn Besucher es erleben | bevor Besucher es erleben | Beantwortet | wen trifft es, wie oft, wo | warum genau, reproduzierbar | Blinder Fleck | seltene Seiten ohne Traffic | alles, was nur in echt passiert | Eignung für Alarme | mittel, braucht Volumen | hoch, stabile Basislinie | Core Web Vitals | LCP, INP, CLS als Felddaten | LCP und CLS, INP nur näherungsweise Der letzte Punkt entscheidet oft die Auswahl. Interaction to Next Paint lässt sich im Labor nicht sauber messen, weil dort niemand klickt. Lighthouse liefert stattdessen Total Blocking Time als Näherung. Wer INP wirklich wissen will, kommt an Felddaten nicht vorbei. ## Wonach wir verglichen haben Alle acht Tools messen echte Besucher. Sie unterscheiden sich in sechs Punkten, die im Alltag wirklich weh tun: Einstiegspreis und Inklusivvolumen. Nicht der Listenpreis allein, sondern was er an Pageviews oder Sessions enthält. Ein günstiger Tarif mit 100.000 Pageviews ist für einen mittleren Shop teurer als ein teurerer mit 1,5 Millionen. Wo die Daten liegen und wer darauf zugreifen darf. Für ein europäisches Unternehmen ist das keine Geschmacksfrage, sondern eine Frage, die in jeder Beschaffung gestellt wird. Es zählt nicht allein der Serverstandort, sondern die Rechtsordnung des Anbieters: eine EU-Region ändert nichts daran, unter welchem Recht das Unternehmen steht. Was im Standardmodus auf dem Endgerät landet. Cookie, localStorage oder nichts. Das entscheidet darüber, wie die Einwilligungsfrage aussieht, und es ist der Punkt, an dem sich die Tools am deutlichsten unterscheiden. Ob Feld und Labor im selben Werkzeug stecken. Wer beides braucht und getrennt einkauft, zahlt zweimal und vergleicht am Ende Zahlen aus zwei Systemen mit unterschiedlichen Definitionen. Wie lange die Daten bleiben. Ein Jahresvergleich braucht dreizehn Monate Historie. Bei mehreren Anbietern kostet genau das ein Vielfaches des Einstiegspreises. Wofür das Tool ursprünglich gebaut wurde. Ein Uptime-Dienst mit RUM-Funktion verhält sich anders als ein Web-Performance-Werkzeug. Beides ist legitim, aber es entscheidet darüber, ob du dich in der Oberfläche zurechtfindest. ## Die Übersicht ### Preis und Volumen | Tool | Einstieg | Dafür enthalten | Gebaut für | fastmon | 29 €/Monat | 200k Pageviews | Web-Performance, EU | Datadog RUM | 0,15 $/1.000 Sessions | nutzungsbasiert | Full-Stack-Observability | New Relic | 0 $ bis 100 GB | 100 GB Ingest | eine Plattform für alles | Pingdom | 14,33 €/Monat | 100k Pageviews | Uptime zuerst | SpeedCurve | 90 $/Monat | konfigurierbar | Performance-Kultur | DebugBear | 99 $/Monat | 100k Pageviews | Core Web Vitals, Labor | RUMvision | 150 €/Monat | 1,5 Mio. Pageviews | RUM-Spezialist, EU | Raygun | 80 $/Monat | 100k Sessions | Fehler und RUM ### Datenpfad und Endgerät | Tool | Sitz und Verarbeitung | Auf dem Endgerät | fastmon | Deutschland, Datenpfad vollständig EU | nichts im Standardmodus | Datadog RUM | US-Unternehmen, EU-Region optional | Cookie ( _dd_s ) | New Relic | US-Unternehmen, EU-Region gegen Aufpreis | nicht geprüft | Pingdom | SolarWinds, Hauptsitz Austin, Texas; Verarbeitungsort nicht geprüft | nicht geprüft | SpeedCurve | US-Unternehmen, AWS us-east-1 | Session-Cookie ( lux_uid ) | DebugBear | UK, Google Cloud, EU-Proxy als Opt-in | kein Cookie im Standard | RUMvision | Niederlande, Edge über AWS CloudFront | localStorage im Standard | Raygun | AWS, Region nicht dokumentiert | nicht geprüft Listenpreise, geprüft am 2. September 2026. DebugBear und Raygun zu den Jahrespreisen, monatlich zahlen kostet dort mehr. Angaben zu Hosting und Endgerät stammen aus den Anbieterdokumenten, geprüft am 14. Juli 2026. Wo “nicht geprüft” steht, haben wir keine belastbare öffentliche Quelle gefunden und behaupten deshalb nichts. Konditionen ändern sich, prüf sie vor einer Entscheidung beim Anbieter nach. ## Die acht Tools im Einzelnen ### fastmon Real User Monitoring, geplante Lighthouse-Audits und Web-Analytics in einer Oberfläche, entwickelt und gehostet in Deutschland. Light kostet 29 € für 200.000 Pageviews, Standard 99 € für eine Million, darüber nutzungsbasiert in Stufen. Eine Produktions- und eine Entwicklungs-Applikation sind enthalten, die Zahl der Domains spielt keine Rolle. Im Standardmodus wird nichts auf dem Endgerät gespeichert. Der Besucher-Identifier wird kurzlebig am Edge abgeleitet, die IP-Adresse wird dort auf einen Ländercode reduziert und erreicht den Anwendungscode nie. Zum Debugging gehören Fehler-Gruppierung, Network-Waterfalls und eine Aufschlüsselung der Serverzeit in neun Phasen über den Server-Timing-Header, inklusive getrennter Phasen für Suchindex und Key-Value-Store. Deploys lassen sich als Release markieren, danach vergleicht eine Abfrage Vorher und Nachher am 75. Perzentil. Für Shops erkennt fastmon Warenkorb, Checkout und Abschluss aus den URL-Mustern der gängigen Systeme, ohne Änderung am Tracker. Nimm etwas anderes, wenn du Session Replay brauchst, Logs und APM im selben Tool erwartest oder native Mobile-Apps messen willst. Das kann fastmon nicht. Synthetic Monitoring und Analytics sind außerdem als Beta gekennzeichnet. ### Datadog RUM Der Maßstab für Teams, die Frontend, Backend, Infrastruktur und Logs in einer Oberfläche korrelieren wollen. Wenn ein Ausfall im Frontend auffällt und die Ursache drei Ebenen tiefer liegt, ist Datadog dort, wo andere Tools aufhören. Die Preise sind in getrennte Posten aufgeteilt, und das ist beim Kalkulieren die eigentliche Aufgabe. RUM Measure kostet 0,15 $ je 1.000 Sessions im Jahresvertrag, für reine Kennzahlen erstaunlich günstig. Sobald du einzelne Sessions untersuchen willst, kommt RUM Investigate mit 3 $ je 1.000 gefilterten Sessions dazu, Session Replay mit 2,50 $ und Product Analytics mit 0,80 $. Wer nur aggregierte Kennzahlen braucht, bleibt beim Einstiegsposten; wer einzelne Sessions aufmacht, rechnet mit mehreren. Datadog ist ein US-Unternehmen, die EU-Region ist eine Option und keine Voreinstellung, und das Browser-SDK setzt im Standard ein Cookie namens _dd_s , um Sessions über Seiten hinweg zusammenzuhalten. Nimm Datadog, wenn ihr ohnehin dort seid und Frontend-Daten neben Traces und Logs sehen wollt. Diese Korrelation kann kein spezialisiertes Tool ersetzen, unseres eingeschlossen. Wir haben dazu eine eigene Gegenüberstellung fastmon gegen Datadog . ### New Relic Die großzügigste kostenlose Stufe im Feld: 100 GB Ingest pro Monat kosten nichts, danach 0,40 $ je GB, mit Data Plus 0,60 $. Browser-Monitoring ist Teil der Plattform und kein eigener Posten, du zahlst also für Datenmenge, nicht für Pageviews. Die Nutzerpreise sind der Teil, der Teams überrascht. Ein Core-Nutzer kostet 49 $ im Monat, ein voller Plattform-Nutzer 349 $ im Jahr und mehr, je nach Stufe. Bei einem größeren Team ist das schnell der dominierende Posten, nicht die Datenmenge. Eine EU-Region gibt es, sie kostet 0,05 $ je GB extra. Auch hier ist der Anbieter ein US-Unternehmen. Nimm New Relic, wenn du eine breite Observability-Plattform willst, mit einem verbrauchsbasierten Modell leben kannst und die kostenlose Stufe zum Ausprobieren nutzen möchtest. ### Pingdom Der bekannteste Name für Uptime-Überwachung, mit RUM als zweitem Standbein. Der Einstieg ist mit 14,33 € im Monat bei jährlicher Zahlung für 100.000 Pageviews der günstigste in dieser Liste. Synthetic Monitoring wird getrennt berechnet und kostet dasselbe, wer beides will, liegt bei rund 344 € im Jahr. Die Testphase über 30 Tage enthält beides. Die Produktseite beschreibt eine Live-Karte der Besucher, Auswertung nach Browser, Gerät und Plattform, Ladezeit mit Apdex-Score, Sitzungsverläufe und teilbare Reports. Core Web Vitals sind ebenfalls Teil des RUM-Produkts. Der Schwerpunkt liegt erkennbar auf Verfügbarkeit und klassischer Ladezeit, und genau dafür ist Pingdom seit zwanzig Jahren der Name, den man kennt. Für europäische Käufer ist die Herkunft relevant. Pingdom wurde 2005 in Schweden gegründet und gehört heute zu SolarWinds mit Hauptsitz in Austin, Texas. Auf den Seiten, die wir geprüft haben, steht nicht, wo die RUM-Daten verarbeitet und gespeichert werden. Wer eine Verarbeitung ausschließlich in der EU braucht, sollte sich das vor dem Kauf schriftlich geben lassen. Nimm Pingdom, wenn Uptime euer Hauptthema ist und RUM die Ergänzung dazu. Wenn der Verarbeitungsort für euch entscheidend ist, klärt ihn vorher. ### SpeedCurve Das Tool mit der stärksten Kultur um Performance herum: Dashboards, die man ins Team hängt, Vergleiche gegen Wettbewerber, Lab und Feld nebeneinander. Wer Performance zu einem Thema machen will, über das andere Abteilungen mitreden, findet hier die beste Darstellung. Der Einstieg kostet 90 $ im Monat, Volumen für RUM und Synthetic konfigurierst du über Regler, es gibt also keinen festen Inklusivwert. Dreizehn Monate Historie gibt es ab dem Growth-Tarif für 576 $, der Jahresvergleich ist dort also ein eigener Kostenfaktor. Gehostet wird in der AWS-Region us-east-1. Die Eigentümerschaft hat sich bewegt: SpeedCurve gehörte zu Embrace und firmiert inzwischen als Palo Alto Networks Company, bleibt also US-amerikanisch. Im Standard setzt SpeedCurve ein Session-Cookie namens lux_uid , das dreißig Minuten nach dem letzten Seitenaufruf abläuft. Nimm SpeedCurve, wenn ihr Performance als Team-Thema etablieren wollt und Wert auf gute Visualisierung legt. ### DebugBear Der Spezialist für Core Web Vitals mit der größten Tiefe im Labor-Teil. Experimente, in denen du eine Änderung simulierst, bevor du sie baust, sind dort eine eigene Funktion, und für die Frage “was bringt es, wenn wir dieses Skript entfernen?” gibt es kein besseres Werkzeug in dieser Liste. Seit kurzem enthält schon der Startup-Tarif für 99 $ im Monat bei jährlicher Zahlung 100.000 RUM-Pageviews plus 4.000 synthetische Tests. Team mit 500.000 Pageviews kostet 249 $, Corporate mit zwei Millionen 699 $. Vierzehn Tage Test ohne Kreditkarte. DebugBear ist ein britisches Unternehmen und nutzt Google Cloud. Ein Proxy in Deutschland ist möglich, damit IP-Adressen die EU nicht verlassen, aber er ist Opt-in und nicht die Voreinstellung. Cookies setzt das RUM im Standard keine. Nimm DebugBear, wenn synthetische Tests und Lab-Debugging euer Schwerpunkt sind und das Feld die Ergänzung ist. Bei uns ist es umgekehrt. ### RUMvision Die andere europäische Option in dieser Liste, aus den Niederlanden, und ein reiner RUM-Spezialist. Der Einstieg kostet 150 € im Monat und enthält 1,5 Millionen Pageviews für zwei Domains, weitere Domains kosten 20 € extra. Gemessen am Volumen ist das fair: wer die 1,5 Millionen ausnutzt, zahlt pro Pageview weniger als bei den meisten anderen hier. Wer sie nicht ausnutzt, zahlt den höchsten Einstiegspreis im Feld. Dreizehn Monate Aufbewahrung gibt es erst im Scale-Tarif ab 700 €. Im Standard nutzt RUMvision localStorage und sessionStorage, um neue von wiederkehrenden Besuchern zu unterscheiden. Das ist kein Cookie, aber es ist ein Zugriff auf das Endgerät, und für die Einwilligungsfrage macht das einen Unterschied. Beides lässt sich abschalten, dann entfällt laut Anbieter auch die Einwilligung. Ein Punkt, der beim Stichwort EU leicht untergeht: die Erfassung läuft über AWS CloudFront und AWS WAF. RUMvision beschreibt das Verfahren offen und sauber, die IP wird am Edge nur so lange gesehen, bis der Ländercode feststeht, und dann verworfen; in die Datenbank geht ausschließlich der ISO-Code. Wer den Anbieter aber nach dem Datenpfad auswählt, sollte wissen, dass damit ein US-Hyperscaler im Pfad steht, auch wenn das Unternehmen selbst niederländisch ist. Nimm RUMvision, wenn du viel Volumen auf wenigen Domains hast und einen EU-Anbieter willst, dem RUM allein reicht. ### Raygun Fehler-Tracking, Crash-Reporting und RUM aus einer Hand, mit starkem Blick auf einzelne Nutzersitzungen. Wenn dich interessiert, was ein bestimmter Nutzer erlebt hat, bevor der Fehler kam, liegt darin die Stärke von Raygun. Real User Monitoring beginnt bei 80 $ im Monat mit jährlicher Zahlung für 100.000 Sessions, monatlich sind es 120 $, weitere Sessions kosten 0,002 $ pro Stück. Vierzehn Tage Test ohne Verpflichtung. Raygun läuft laut eigener Security-Seite auf AWS. Welche Region das ist und ob es eine EU-Option gibt, steht dort nicht, und wir haben es nicht anderweitig belegen können. Nimm Raygun, wenn ihr Fehler und Performance auf Sitzungsebene zusammen betrachten wollt und der Serverstandort für euch keine Rolle spielt. ## Core Web Vitals im Vergleich Wer wegen Google kauft, sollte auf diese Zeile achten. Alle Werte beziehen sich auf Felddaten, also auf echte Besucher. | Tool | LCP, INP, CLS | Segmentierung | Attribution | fastmon | ja, im 75. Perzentil | Seite, Seitentyp, Gerät, Land, Browser | ja, Element und Phase pro Aufruf | Datadog RUM | ja | umfangreich | teilweise, über Session-Details | New Relic | ja | umfangreich | teilweise | Pingdom | ja | Browser, Gerät, Standort | nicht geprüft | SpeedCurve | ja | umfangreich, inkl. Wettbewerbsvergleich | ja | DebugBear | ja | umfangreich | ja, mit Lab-Verknüpfung | RUMvision | ja | umfangreich | ja | Raygun | ja | Sitzung, Gerät, Standort | teilweise Segmentierung und Attribution haben wir anhand der öffentlichen Produkt- und Doku-Seiten der Anbieter eingeordnet, Stand 2. September 2026. “Teilweise” heißt, dass eine Zuordnung möglich ist, aber nicht als eigene Ansicht pro Metrik. Wo “nicht geprüft” steht, haben wir keine belastbare Quelle gefunden. Attribution ist der Punkt, der am meisten Zeit spart. Zu wissen, dass LCP bei 3,4 Sekunden liegt, hilft wenig. Zu wissen, dass es das Hero-Bild auf der Kategorieseite ist und dass die Zeit in der Ladeverzögerung steckt und nicht im Rendern, ist der Unterschied zwischen Raten und Arbeiten. ## Und wenn es nichts kosten darf Für den Einstieg gibt es zwei kostenlose Wege, die überraschend weit tragen. Der Chrome UX Report liefert Felddaten echter Chrome-Nutzer für jede hinreichend besuchte Domain, ohne dass du irgendetwas einbaust. Und PageSpeed Insights zeigt diese Felddaten neben einem Lighthouse-Lauf, also Feld und Labor auf einem Bildschirm. Die Grenze merkst du schnell. CrUX kennt nur Chrome-Nutzer, aggregiert über 28 Tage und zeigt dir keine einzelne Seite deines Shops in dem Moment, in dem sie langsam war. Es gibt keine Fehlerdaten, keine Netzwerk-Wasserfälle und keine Möglichkeit, einen Deploy von gestern mit dem von vorgestern zu vergleichen. Für “wie stehen wir da?” reicht es. Für “was ist gestern passiert?” nicht. Mehr dazu in unserem Vergleich mit Lighthouse . ## Welches Tool für welche Lage Wenn du in einer dieser Situationen steckst, ist die Antwort ziemlich eindeutig: - Europäischer Shop oder europäische Agentur, Datenschutz kommt in jedem Termin auf: fastmon oder RUMvision. Beide Unternehmen sitzen in der EU. Sie unterscheiden sich im Preis, im Inklusivvolumen, darin dass bei uns im Standardmodus nichts auf dem Endgerät landet, und im Datenpfad: RUMvision erfasst über AWS CloudFront, bei uns ist jeder Anbieter im Kundendaten-Pfad ein EU-Unternehmen. - Ihr habt schon Datadog oder New Relic: bleibt dort, außer die Rechnung oder die Datenschutzfrage zwingt euch weg. Ein zweites Tool neben einer Observability-Plattform lohnt sich selten. - Uptime ist das Hauptthema, Performance die Zugabe: Pingdom, günstig und mit einem Namen, den die Geschäftsführung kennt. - Ihr optimiert Ladezeiten als Kernaufgabe und arbeitet viel im Labor: DebugBear oder SpeedCurve. - Fehler und einzelne Nutzersitzungen stehen im Vordergrund: Raygun. - Ihr wollt Feld, Labor und Analytics in einem Werkzeug, ohne Enterprise-Vertrag: dafür haben wir fastmon gebaut. ## Worauf du bei der Auswahl achten solltest Drei Fehler sehen wir immer wieder, und alle drei kosten später Geld oder Nerven. Nach Listenpreis kaufen statt nach Preis pro Pageview. Rechne deinen tatsächlichen Monatsverkehr gegen das Inklusivvolumen. Ein Tarif für 10 $ mit 100.000 Pageviews ist teurer als einer für 150 € mit 1,5 Millionen, sobald du zwei Millionen Aufrufe hast. Die Aufbewahrung vergessen. Fast alle Anbieter verkaufen die kurze Historie günstig und die lange teuer. Wenn ihr im Januar wissen wollt, wie der Vorjahres-Dezember war, braucht ihr dreizehn Monate, und genau das ist bei mehreren Anbietern der Sprung in den nächsten Tarif. Den Datenpfad erst in der Beschaffung prüfen. Die Frage, wo die Daten liegen und wer rechtlich darauf zugreifen kann, kommt in jedem größeren Unternehmen. Sie erst zu stellen, wenn das Tool schon eingebaut ist, führt zu Migrationen, die niemand eingeplant hat. ## Was wir selbst anders machen Drei Dinge, an denen wir uns messen lassen, alle drei nachprüfbar. Der günstigste EU-gehostete Einstieg in diesem Vergleich. 29 € für 200.000 Pageviews gegen 150 € bei RUMvision, dem einzigen anderen EU-Anbieter in dieser Liste. Günstiger geht es insgesamt bei Pingdom mit 14,33 €, und New Relic hat eine kostenlose Stufe. Beide sind keine EU-Anbieter, und darum geht es bei dieser Aussage: unter den Werkzeugen mit europäischem Datenpfad sind wir der günstigste Einstieg. Nichts auf dem Endgerät. Im Standardmodus schreibt fastmon weder Cookie noch localStorage. Nach unserer Einschätzung braucht das keine Einwilligung nach § 25 TDDDG, und die vollständige Herleitung samt Restrisiko steht offen auf unserer Cookie-Seite . Wir kennen kein anderes Tool in dieser Liste, das seine eigene Rechtslage in dieser Ausführlichkeit öffentlich herleitet. Der Datenpfad bleibt in der EU. Entwickelt und gehostet in Deutschland, und jeder Anbieter im Kundendaten-Pfad ist ein Unternehmen aus Deutschland oder der EU, nachlesbar in unserer Subprozessoren-Liste . Kein Cloudflare, kein AWS, kein GCP. Was wir nicht können, steht oben im Abschnitt zu fastmon, und es ändert nichts daran, dass für manche Teams eines der anderen sieben Tools die richtige Wahl ist. ## Ausprobieren statt vergleichen Am Ende entscheidet keine Tabelle, sondern die Frage, ob du in der Oberfläche findest, was du suchst. Jeder fastmon-Account startet mit 30 Tagen vollem Zugriff, ohne Kreditkarte, und das Script ist ein Tag im Head. Nach fünf Minuten siehst du deine ersten echten Besucher. Etwas stimmt nicht? Alle Angaben zu anderen Anbietern sind Listenpreise und öffentliche Produktangaben, geprüft am 2. September 2026. Preise und Funktionen ändern sich, manchmal in derselben Woche. Wenn dir etwas auffällt, das nicht mehr stimmt oder nie gestimmt hat, schreib an support@fastmon.eu . Wir korrigieren es und schreiben das Datum der Änderung dazu. Das gilt ausdrücklich auch für die Anbieter selbst. fastmon kostenlos starten Oder erst alle Pläne ansehen Über den Autor Kamil Adrian Czujowski Co-Founder Seit 2009 im E-Commerce zu Hause. Kennt Online-Shops von beiden Seiten: vom Entwickeln von Bots für Sneaker-Releases bis zur Absicherung von E-Commerce-Plattformen gegen genau solche Angriffe. Sein Fokus bei fastmon liegt auf Performance und Zuverlässigkeit unter Last: kurze Ladezeiten, hohe Verfügbarkeit und ein sauberes, datenschutzfreundliches Setup. LinkedIn --- ## https://fastmon.eu/de/blog/ttfb-server-timing/ Zurück zum Blog Performance # Deine Seite braucht 800 ms bis zum ersten Byte. Wofür eigentlich? TTFB ist eine einzige Zahl für alles, was vor dem ersten Byte passiert. Wie du sie mit einem Response-Header in Phasen zerlegst, warum Suche und Key-Value-Store eigene Phasen verdient haben und wieso Early Hints dein TTFB schöner aussehen lassen, als es ist. Kamil Adrian Czujowski 27. August 2026 · 5 Min. Lesezeit Ganz ehrlich: TTFB ist die undankbarste Zahl im Dashboard. Sie steht da, sagt 800 ms, und danach hört die Auskunft auf. War es die Datenbank? Ein Template, das zu viel rendert? Der Zahlungsanbieter, dessen API heute schlecht drauf ist? Der Cache, der nicht gegriffen hat? Die Zahl weiß es. Sie sagt es nur nicht. Dabei ist die Antwort meistens einen Response-Header weit weg. ## TTFB ist eine Summe, keine Diagnose Time to First Byte misst die Spanne vom Klick bis zum ersten Byte der Antwort. Da steckt alles drin: DNS, Verbindungsaufbau, TLS, der Weg zur Edge, der Weg von der Edge zum Origin und dann die komplette Arbeit deiner Anwendung. Ein einziger Wert für ein halbes Dutzend Stationen. Solange er klein ist, ist das egal. Wird er groß, wird jede Optimierung zur Wette. Man baut die Datenbank-Query um, deployt, wartet zwei Tage auf genug Daten, schaut. Keine Bewegung. Also das Template. Deployt, wartet, schaut. Immer noch nichts. Nach der dritten Runde stellt sich heraus: Es war der Suchindex, an den nie jemand gedacht hat. Das ist kein Können-Problem, das ist ein Sichtbarkeits-Problem. Du optimierst eine Summe, ohne ihre Summanden zu kennen. ## Der Header ist drei Zeilen im Backend Server-Timing ist ein Standard-Response-Header, mit dem dein Backend an jede Antwort dranschreibt, wo die Zeit geblieben ist. Kein SDK, kein zusätzlicher Request, keine Instrumentierung im Browser. Du misst ohnehin schon irgendwo im Code, du schreibst die Werte nur noch in einen Header: $response->headers->set('Server-Timing', sprintf( 'db;dur=%.1f, render;dur=%.1f, cache;dur=%.1f', $dbMs, $renderMs, $cacheMs Das ist Symfony, also auch die Welt von Shopware. Für Flask, Express und andere steht dasselbe in drei Zeilen in der Doku. Der Browser liest den Header ohnehin mit, und unser Beacon liest ihn bei jedem Seitenaufruf aus der Dokument-Antwort mit aus. Ab da ist die Aufschlüsselung Teil deiner Felddaten, gemessen an echten Besuchern statt an einem Testlauf. ## Neun Phasen, und was hinter ihnen steckt Damit aus fremden Metriknamen etwas Vergleichbares wird, normalisiert fastmon sie auf neun Phasen: - Edge ( edge_dur ) und Origin ( origin_dur ): der Weg. Zeit an der Edge und Zeit zwischen Edge und Ursprungsserver. - Backend ( backend_dur ): die Anwendung insgesamt. Hier landet auch, was WordPress als wp-total schickt. - Datenbank ( db_dur ) und Rendering ( render_dur ): die zwei Klassiker, relationale Queries und das Bauen der Seite. - Cache ( cache_dur ), Externe Aufrufe ( external_dur ), Suche ( search_dur ) und Key-Value-Store ( kv_dur ): die vier, die aufsummiert werden, weil pro Request mehrere davon vorkommen. Die üblichen Namen kennt fastmon schon: elasticsearch , opensearch und solr landen in der Suche, redis und valkey im Key-Value-Store, http , fetch und api bei den externen Aufrufen. Wer es eindeutig will, schickt die Phasen direkt unter den fm- -Namen, die haben Vorrang vor allem anderen. Sichtbar wird das Ganze unter Analytics, Server-Timing, im Wasserfall der Response-Aufschlüsselung und als Spalte im Explorer, jeweils als p50, p75 und p95. Perzentile, nicht Durchschnitt, aus demselben Grund wie überall sonst: Der Durchschnitt schmeichelt, das p75 zeigt dir die Besucher, die es wirklich trifft. ## Was du danach abliest Der Moment, in dem sich die drei Zeilen bezahlt machen, sieht ungefähr so aus: Backend 60 ms, Datenbank 25 ms, Rendering 30 ms, Suche 240 ms. Die Diskussion über Query-Optimierung ist damit vorbei, bevor sie angefangen hat. Nicht die Datenbank ist langsam, der Suchindex ist es. Oder: Alles unter 50 ms, nur externe Aufrufe stehen bei 300 ms. Dann liegt dein TTFB nicht an deinem Code, sondern an einem Dienst, den jemand vor zwei Monaten synchron in den Seitenaufbau gehängt hat. Oder der unangenehme Fall: Cache-Phase hoch, Cache-Hit-Rate gut. Dann ist der Cache nicht das Problem, sondern die Lösung, die zu lange braucht, meistens weil er über das Netz statt über den lokalen Socket angesprochen wird. Keiner der drei Fälle ist aus einer einzigen Zahl zu erkennen. Aus vier Zahlen springen sie dich in zehn Sekunden an. ## Zwei neue Phasen, und eine Stufe im Chart Suche und Key-Value-Store sind seit dem 27. August eigene Phasen. Vorher lag beides in cache_dur , was für Redis noch irgendwie stimmte und für Elasticsearch schon lange nicht mehr. Beides in einen Topf zu werfen, hieß: Man sieht, dass ein Store bremst, aber nicht welcher. Das hat eine ehrliche Nebenwirkung, die du kennen solltest, bevor sie dir auffällt: Weil Redis aus der Cache-Phase in den Key-Value-Store umgezogen ist, wird cache_dur ab diesem Deploy kleiner. Im Chart ist das eine Stufe nach unten. Das ist keine Verbesserung, das ist eine Umsortierung. Die bereits gespeicherten Werte haben wir nicht angefasst, deshalb ist die Stufe da und bleibt sichtbar. ## Early Hints: wenn dein TTFB plötzlich lügt Und dann gibt es noch den Fall, in dem dein TTFB besser wird, ohne dass irgendetwas schneller geworden ist. Mit 103 Early Hints schickt dein Server, meistens die Edge davor, vorab eine vorläufige Antwort mit preload - und preconnect -Hinweisen, während dein Backend noch arbeitet. Der Browser fängt schon mal an, Dateien zu holen. Für deine Besucher ist das ein echter Gewinn. Für deine Messung ist es eine Falle: Das erste Byte, das ankommt, ist die 103, nicht deine eigentliche Antwort. Seit Chrome 133 zählt responseStart diese vorläufige Antwort mit, und weil fast alle Tools ihr TTFB daraus ableiten, fällt dein Wert nach dem Einschalten von Early Hints. Dein Server braucht exakt gleich lang. Deshalb liest der fastmon-Tracker zusätzlich den Zeitpunkt der finalen Response-Header und legt ihn als ttfb_final daneben. Aus zwei Werten wird dann eine klare Auskunft: - Beide gleich: Es gab keine vorläufige Antwort, dein TTFB ist dein TTFB. - ttfb_final größer: Die Differenz ist genau der Vorsprung, den die Edge deinen Besuchern verschafft hat. Auf der TTFB-Seite steht er am gewählten Perzentil, in der Response-Aufschlüsselung als eigene Zeile vom ersten Byte bis zu den finalen Headern. - Leer: Der Browser meldet es nicht, oder es war eine Soft-Navigation. Und daraus folgt die Faustregel, an der man sich sonst gern verrechnet: Edge- und Backend-Phase müssen in ttfb_final passen, nicht in ttfb . Wer gegen das kleinere der beiden rechnet, wundert sich über Phasen, die angeblich länger dauern als die ganze Antwort. Hinweis: Welche Metriknamen auf welche Phase abgebildet werden, wie eigene Namen dazukommen und welche Grenzen für Werte und Beschreibungen gelten, steht vollständig in unserer Doku zu Server-Timing . Das ist die Seite für deine Entwickler. ## Was du mitnimmst TTFB sagt dir, dass es langsam war. Server-Timing sagt dir, wo. Der Unterschied zwischen beiden sind drei Zeilen in deinem Backend und danach eine Diskussion, die mit Zahlen statt mit Vermutungen geführt wird. Fang mit db , render und cache an, das deckt die meisten Fälle ab. Wenn ein Suchindex oder ein Key-Value-Store im Spiel ist, nimm die zwei dazu, sie haben es sich verdient. Und wenn du Early Hints einsetzt, schau auf ttfb_final , bevor du dich über ein plötzlich hervorragendes TTFB freust. Gemessen wird das alles an echten Besuchern, nicht im Labor. Mehr zu Real User Monitoring . Über den Autor Kamil Adrian Czujowski Co-Founder Seit 2009 im E-Commerce zu Hause. Kennt Online-Shops von beiden Seiten: vom Entwickeln von Bots für Sneaker-Releases bis zur Absicherung von E-Commerce-Plattformen gegen genau solche Angriffe. Sein Fokus bei fastmon liegt auf Performance und Zuverlässigkeit unter Last: kurze Ladezeiten, hohe Verfügbarkeit und ein sauberes, datenschutzfreundliches Setup. LinkedIn --- ## https://fastmon.eu/de/blog/warum-europa/ Zurück zum Blog Datenschutz # Warum wir auf Europa setzen. Und was das wirklich bedeutet. Kein Cloudflare, kein AWS, kein GCP: warum wir den unbequemeren Weg gegangen sind und was davon konkret bei deinen Daten ankommt. Kamil Adrian Czujowski 12. Juli 2026 · 4 Min. Lesezeit Ganz ehrlich: Der bequeme Weg hätte anders ausgesehen. Ein AWS-Konto, Cloudflare davor, ein Vercel-Deploy, fertig. So bauen heute die meisten, und wir verstehen jeden, der das tut. Die Werkzeuge sind ausgereift, die Doku ist gut, alles geht schnell. Wir haben uns trotzdem dagegen entschieden. Im kompletten Datenpfad von fastmon steckt kein einziger US-Anbieter. Kein Cloudflare, kein AWS, kein GCP, kein Vercel. Warum wir uns das antun und was davon konkret bei deinen Daten ankommt: Darum geht es hier. ## “EU-Hosting” steht inzwischen überall drauf Die meisten Tools, die sich datenschutzfreundlich nennen, sind US-Unternehmen mit einem Rechenzentrum in Frankfurt. Die Server stehen in Europa. Das Unternehmen untersteht trotzdem US-Recht, und der US CLOUD Act greift auf dessen Daten zu, wo immer sie liegen. Eine EU-Region ist eben nicht dasselbe wie EU-Jurisdiktion. Das ist der Unterschied zwischen einem Tool aus der EU und einem mit EU-Region. Genau da wollten wir nicht landen. ## Was bei uns konkret dahintersteht Die fastmon labs UG ist ein deutsches Unternehmen aus Hannover. Alle Kunden- und Monitoring-Daten werden ausschließlich in der EU verarbeitet und in Deutschland gespeichert: Hetzner, Rechenzentrum Falkenstein. Und der Rest? Auch europäisch, durchgehend. Ein paar Beispiele aus unserer Anbieter-Liste: - Hosting, Storage und Backup: Hetzner, Deutschland - Ingress: ein Unternehmen aus Berlin - DNS: ein Anbieter aus Slowenien - Transaktionale E-Mails und Geschäftsmail: zwei Anbieter aus den Niederlanden - KI-Inferenz: Mistral AI aus Paris, und das nur, wenn du dich aktiv dafür entscheidest Neun Subauftragsverarbeiter insgesamt, fünf davon sitzen in Deutschland, der Rest in der EU. Die komplette Liste ist keine Verhandlungssache hinter einem Vertriebsgespräch, sie steht öffentlich in unserem AVV. Und volle Transparenz, weil die Frage sonst irgendwann kommt: Für unseren internen Werkzeugkasten nutzen wir auch US-Tools. Unser Code liegt auf GitHub, Tickets laufen durch Linear, und beim Entwickeln hilft Claude Code von Anthropic. Der Unterschied: Da fließen keine Kunden- und keine Monitoring-Daten durch, unsere interne Richtlinie verbietet genau das, und deshalb sind diese Tools auch keine Subauftragsverarbeiter. Wir listen sie trotzdem offen in unserer Anbieter-Liste. Der Datenpfad, also alles, was deine Daten und die deiner Besucher anfasst, bleibt in Deutschland und der EU. ## Der CLOUD Act, ohne Drama Der US CLOUD Act verpflichtet US-Unternehmen, Daten herauszugeben, egal wo deren Server stehen. Deshalb hilft die Frankfurt-Region eben nicht weiter. Bei fastmon unterliegt kein Anbieter im Datenpfad US-Recht; ein Zugriff ist damit nicht zu erwarten. Mehr behaupten wir absichtlich nicht. Recht ist kein Schalter, den man einmal umlegt, und Wörter wie “unmöglich” haben in einem Datenpfad nichts verloren. Aber die Ausgangslage ist eine grundlegend andere, wenn kein Beteiligter einer US-Anordnung unterliegt. ## Was davon bei deinen Daten ankommt Jurisdiktion ist die eine Hälfte. Die andere ist, was überhaupt anfällt. Da setzen wir auf Architektur statt auf Versprechen: - Die IP deiner Besucher wird am Edge auf einen Ländercode reduziert, nur das Land, ISO-2, und sofort verworfen. Keine rohe IP und kein User-Agent erreicht je das Backend. - Im Standard-Modus setzt fastmon keine Cookies* und speichert nichts auf dem Gerät. - Kein Fingerprinting, keine seitenübergreifenden IDs, keine Anreicherung durch Dritte. Das Sternchen hinter “Cookies” ist übrigens Absicht. Cookiefrei heißt nicht automatisch einwilligungsfrei. Dazu gleich mehr. ## Der Teil, den dir niemand abnimmt Jetzt der unbequeme Teil, den viele Anbieter gern weglassen. Ob die Einbindung eines Analyse-Tools eine Einwilligung nach § 25 TDDDG braucht, ist umstritten. Der strenge Maßstab, zu dem Deutschland und der EDSA tendieren, sieht Analytics- und Performance-Messung als nicht unbedingt erforderlich an. Wir gehen von genau diesem strengen Maßstab aus und bauen und dokumentieren konservativ. Im Klartext: in den Modi Light und Standard brauchst du nach unserer Einschätzung keinen Consent-Banner, weil nichts auf dem Endgerät gespeichert wird und die gelesenen Werte vorher nicht dort lagen. Im Modus Full brauchst du ihn, dort wird eine Kennung geschrieben. Die Verantwortung für die Einbindung bleibt in jedem Fall bei dir. Die Einschätzung für deine eigene Seite triffst du, idealerweise mit deiner Datenschutzbeauftragten. Ein Tool, das dir hier pauschal Entwarnung gibt, solltest du genau deshalb hinterfragen. Hinweis: Das ist keine Rechtsberatung. Es beschreibt, wie fastmon gebaut und dokumentiert ist; die Prüfung für deinen konkreten Einsatz liegt bei dir. ## Warum wir uns das antun Weil das Produkt sonst unglaubwürdig wäre. Ein Monitoring-Tool, das Datenschutz verspricht und die Daten dann doch durch US-Clouds schickt, wäre genau das Kleingedruckte, das wir oben kritisieren. Der Weg ist unbequemer, das geben wir offen zu. Weniger fertige Bausteine, mehr Eigenbetrieb, und bei jedem neuen Anbieter zuerst die Frage: Sitzt der in der EU? Aber ehrlich: Die europäischen Anbieter, mit denen wir arbeiten, sind kein Kompromiss. Sie sind nur nicht der Default. Vielleicht sollte sich genau das ändern. Alles hier steht ausführlicher, mit jeder Zahl und jedem Anbieter, auf unserer Seite zu EU & Datenschutz . Über den Autor Kamil Adrian Czujowski Co-Founder Seit 2009 im E-Commerce zu Hause. Kennt Online-Shops von beiden Seiten: vom Entwickeln von Bots für Sneaker-Releases bis zur Absicherung von E-Commerce-Plattformen gegen genau solche Angriffe. Sein Fokus bei fastmon liegt auf Performance und Zuverlässigkeit unter Last: kurze Ladezeiten, hohe Verfügbarkeit und ein sauberes, datenschutzfreundliches Setup. LinkedIn --- ## https://fastmon.eu/de/blog/web-vitals-buzzwords/ Zurück zum Blog Performance # LCP, FCP, TTFB: alles nur Buzzwords für dich? Fünf Abkürzungen, übersetzt in normale Sprache: was deine Besucher wirklich spüren, wenn diese Zahlen schlecht sind, und warum Google sie ernst nimmt. Kamil Adrian Czujowski 15. Juli 2026 · 4 Min. Lesezeit Ganz ehrlich: Niemand wacht morgens auf und denkt an sein LCP. Deine Besucher schon gar nicht. Die denken: Warum sehe ich noch nichts? Warum reagiert der Button nicht? Warum springt der Text weg, genau in dem Moment, in dem ich klicken will? Genau das messen diese Abkürzungen. Jede von ihnen ist die Antwort auf eine Frage, die sich ein Besucher wirklich stellt. Mehr steckt nicht dahinter. Gehen wir sie einmal durch, in normaler Sprache. ## Fünf Abkürzungen, fünf Fragen ### TTFB: tut sich da überhaupt was? Time to First Byte. Die Zeit vom Aufruf bis zum ersten Byte, das dein Server zurückschickt. Solange passiert im Browser: nichts. Ein schlechter TTFB zieht alles andere nach hinten, denn der Browser kann nichts rendern, was er noch nicht bekommen hat. Als Richtwert: bis 800 ms gilt als gut. ### FCP: wann sehe ich endlich irgendwas? First Contentful Paint. Der Moment, in dem der Browser zum ersten Mal Inhalt zeichnet. Ein Stück Text, ein Logo, irgendwas. Vorher ist die Seite einfach weiß. FCP ist das erste Lebenszeichen deiner Seite. Gut heißt hier: bis 1,8 s. ### LCP: wann sehe ich das, weswegen ich hier bin? Largest Contentful Paint. Der Moment, in dem das größte sichtbare Element fertig gerendert ist: das Hero-Bild, das Video-Poster, die große Überschrift. Ab diesem Punkt fühlt sich die Seite “da” an. Die Schwellen von Google: bis 2,5 s gut, über 4,0 s schlecht. Dazwischen liegt eine Menge Alltag. ### INP: warum ruckelt der Button? Interaction to Next Paint. Die Worst-Case-Verzögerung zwischen einem Tap oder Klick und dem nächsten sichtbaren Frame. Wenn Besucher zweimal klicken, weil “nichts passiert ist”: Das ist INP. Bis 200 ms gut, über 500 ms schlecht. INP hat im März 2024 FID als Core Web Vital abgelöst. ### CLS: warum springt hier alles herum? Cumulative Layout Shift. Bewertet, wie viel sichtbarer Inhalt sich unerwartet verschiebt. Der Klassiker: Ein Banner lädt nach, der Text rutscht runter, du triffst den falschen Link. CLS ist keine Zeit, sondern ein Score: bis 0,1 gut, über 0,25 schlecht. Hinweis: Core Web Vitals im engen Sinn sind nur drei davon: LCP, INP und CLS. FCP und TTFB sind Diagnose-Metriken. Sie erklären, warum die großen drei so aussehen, wie sie aussehen. ## Lighthouse sagt 95. Und trotzdem beschweren sich Leute. Beides kann gleichzeitig stimmen, und das verwirrt am Anfang alle. Lighthouse ist ein Labortest: ein simuliertes Gerät, ein Standort, ideale Bedingungen, voll reproduzierbar. Genau dafür ist er gut. Weil sich die Bedingungen nie ändern, fängt er Regressionen, bevor sie live gehen . Aber der Test weiß nichts von dem drei Jahre alten Android im Mobilfunknetz, auf dem deine Seite gerade wirklich geöffnet wird. Felddaten messen genau das: jeden echten Seitenaufruf, auf echten Geräten, in echten Netzen. Das nennt man Real User Monitoring, kurz RUM. Verrauschter als das Labor, ja. Aber echt. Und weil Felddaten streuen, schaut man nicht auf den Durchschnitt, sondern auf das 75. Perzentil, kurz p75. p75 heißt: 75 % deiner Besucher waren mindestens so schnell. Der Durchschnitt schmeichelt. p75 zeigt dir das Erlebnis derer, die leiden. Ein Detail noch: INP ist eine reine Feld-Metrik. Ein Labortest klickt nicht wie ein Mensch, also kommt INP aus dem Feld, nicht aus dem Labor. ## Warum Google das ernst nimmt Google rankt nach den echten Core Web Vitals von Chrome-Nutzern, gesammelt im Chrome UX Report (CrUX). Nicht nach deinem Lighthouse-Score. Dein Labor kann 95 sagen und dein Feld etwas ganz anderes, und fürs Ranking zählt das Feld. Die Logik dahinter ist simpel: Google will Ergebnisse verlinken, die sich gut anfühlen, und zwar auf den Geräten, die Menschen wirklich benutzen. Man kann das streng finden. Unfair ist es nicht. ## Was du damit anfängst Fang nicht beim Score an, fang bei den Fragen an. Sehen deine Besucher schnell etwas? Reagiert die Seite auf den ersten Klick? Bleibt das Layout, wo es ist? Wenn du das beantworten willst, brauchst du Zahlen von echten Besuchern, bewertet am p75 statt am Durchschnitt. Genau das ist der Job von fastmon: die Core Web Vitals aus jedem echten Besuch, am p75 gegen die Schwellen von Google. Wenn du sehen willst, wie das aussieht: Mehr zu Real User Monitoring . Ab jetzt sind es keine Buzzwords mehr. Versprochen. Über den Autor Kamil Adrian Czujowski Co-Founder Seit 2009 im E-Commerce zu Hause. Kennt Online-Shops von beiden Seiten: vom Entwickeln von Bots für Sneaker-Releases bis zur Absicherung von E-Commerce-Plattformen gegen genau solche Angriffe. Sein Fokus bei fastmon liegt auf Performance und Zuverlässigkeit unter Last: kurze Ladezeiten, hohe Verfügbarkeit und ein sauberes, datenschutzfreundliches Setup. LinkedIn --- ## https://fastmon.eu/de/funktionen/ai/ fastmon AI Neu # fastmon AI. Deine Daten, in Klartext. fastmon AI arbeitet auf den Monitoring-Daten, die du ohnehin schon hast. Es macht aus einem Lighthouse-Bericht eine kurze Zusammenfassung und lässt dich Folgefragen zu einem bestimmten Test stellen oder einen einzelnen Fehler untersuchen. Es ist kein allgemeiner Chatbot und liest nur deine eigenen Monitoring-Daten. Was ist fastmon AI? ## Kein Chatbot. Ein Assistent für deine Daten. fastmon AI ist kein Allzweck-Assistent, der alles beantwortet. Es sitzt auf den Monitoring-Daten, die du ohnehin erfasst, und macht ein paar Dinge gut: es erklärt einen synthetischen Test in Klartext und hilft dir, einen Fehler zu verstehen. Mehr nicht, und das ist Absicht. Ein Lighthouse-Bericht ist dicht. Ein Klick macht daraus eine kurze Zusammenfassung, auf Deutsch oder Englisch, damit du das Wesentliche siehst, ohne jeden Audit zu lesen. Tiefer einsteigen? Frag zu diesem Test öffnet einen Assistenten mit dem Lauf im Kontext, und du stellst Folgefragen zu genau den Audits, die zählen. Im Dashboard macht die Fehleranalyse per ‚Frag zu diesem Test‘ dasselbe für einen einzelnen Fehler: eine Zusammenfassung und eine Zeitreihe, damit du siehst, was kaputtging und wann, ohne von Hand eine Query zu bauen. Jede AI-Funktion ist optional und über die AI-Einstellung deiner Organisation gesteuert, du entscheidest also, ob du sie überhaupt nutzt. Was es kann ## Drei Dinge, gut gemacht. Keine Wunderkiste. Drei konkrete Funktionen, die auf deinen Lighthouse- und Fehlerdaten aufsetzen. ### Ein-Klick-Zusammenfassung Macht aus einem Lighthouse-Bericht eine kurze Zusammenfassung, auf Deutsch oder Englisch. Einmal erzeugt, dann gespeichert und wiederverwendet, erneutes Lesen kostet nichts. ### Frag zu diesem Test Öffnet den fastmon-AI-Assistenten mit dem Lauf im Kontext, damit du Folgefragen zu genau den Audits stellen kannst, die für dich zählen. ### Fehleranalyse per ‚Frag zu diesem Test‘ Untersuche im Dashboard einen einzelnen Fehler: der Assistent liefert eine Zusammenfassung und eine Zeitreihe, damit du siehst, was brach und wie es sich entwickelte. Ehrlich gesagt ## Was es kann, und was nicht. Uns ist eng und ehrlich lieber, als eine Wunderkiste zu versprechen. Hier steht genau, wo fastmon AI hilft, und wo nicht. Was fastmon AI kann - Einen Lighthouse-Bericht auf Deutsch oder Englisch zusammenfassen - Folgefragen zu einem bestimmten synthetischen Test beantworten - Einen einzelnen Fehler mit Zusammenfassung und Zeitreihe untersuchen - Optional bleiben, über die AI-Einstellung deiner Organisation gesteuert Was es nicht ist - Kein Allzweck-Chatbot: es bleibt auf deinen fastmon-Daten - Keine Frag-alles-Box: jede Antwort ist an einen Test oder Fehler gebunden - Keine neue Datenquelle: es erklärt, was fastmon ohnehin erfasst - Nicht unbegrenzt: das Erzeugen von Zusammenfassungen ist auf 30 pro Organisation und Stunde begrenzt Neu und noch in Entwicklung. Die Verfügbarkeit wird pro Organisation gesteuert. FAQ ## fastmon AI, beantwortet. Die Fragen, die man zu den AI-Funktionen stellt. ### Ist fastmon AI ein allgemeiner Chatbot? Nein. Es arbeitet nur auf deinen fastmon-Monitoring-Daten. Jede Antwort ist an einen bestimmten synthetischen Test oder einen bestimmten Fehler gebunden; es gibt keinen Frag-alles-Modus. ### Was macht die Ein-Klick-Zusammenfassung? Sie macht aus einem Lighthouse-Bericht eines synthetischen Tests eine kurze Zusammenfassung, auf Deutsch oder Englisch. Sie wird einmal erzeugt, dann gespeichert und wiederverwendet, erneutes Lesen kostet also nichts. Das Erzeugen neuer Zusammenfassungen ist auf 30 pro Organisation und Stunde begrenzt. ### Was ist die Fehleranalyse per ‚Frag zu diesem Test‘? Im Dashboard kannst du einen einzelnen Fehler untersuchen, und der Assistent liefert eine Zusammenfassung und eine Zeitreihe, damit du siehst, was brach und wie es sich entwickelte, ohne von Hand eine Query zu bauen. ### Muss ich die AI-Funktionen nutzen? Nein. Jede AI-Funktion ist optional und über die AI-Einstellung deiner Organisation gesteuert. Ist sie aus, läuft der Rest von fastmon genau wie zuvor. ### Welches KI-Modell nutzt ihr? Wir konzentrieren uns darauf, was der Assistent tut, statt darauf, welches Modell ihn antreibt, denn das kann sich mit der Zeit ändern. Fest bleibt der Rahmen: Zusammenfassungen in Klartext und Folgefragen auf deinen eigenen Test- und Fehlerdaten, und es bleibt pro Organisation optional. ## KI, die deine Daten in Europa hält. Zusammenfassungen und Fragen zu Tests, read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren. In der EU. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/funktionen/analytics/ Web-Analytics Beta # Web-Analytics. Traffic und Performance, ein Tool. fastmon Analytics ist die Explorations-Ebene auf denselben Beacons, die deine Web Vitals messen. Wer auf der Seite ist, woher er kommt, welche Seiten aufgerufen werden, welche Fehler feuern. Ohne Cookies*, nur das Land, gehostet in der EU. Was ist fastmon Analytics? ## Dieselben Daten, eine andere Frage. Analytics ist die Explorations-Ebene auf allem, was deine Beacons ohnehin schon erfassen. Das Web-Vitals-Dashboard fragt, wie schnell die Seite ist; Analytics fragt, was auf ihr passiert. Dieselben Daten, eine andere Frage, ein Script-Tag. So liegen Traffic und Performance an einem Ort. Du schnallst kein zweites Tool auf die Seite und gleichst am Monatsende keine zwei Dashboards ab. Wer da war und wie schnell es für ihn war, stehen nebeneinander. Und es zählt so, wie der Rest von fastmon arbeitet: im Standard-Modus keine Cookies*, das Land am Edge aus der IP abgeleitet, die IP selbst weg, bevor irgendein Code sie sieht. Analytics ist in der Beta, Layout und Metriken können sich also noch ändern, das Datenschutzmodell nicht. Live und Kennzahlen ## Wer gerade da ist, und wie viele. Drei Kern-Kennzahlen, Unique Visitors, Pageviews und Views pro Besuch, jede mit ihrem Trend gegen die Vorperiode. Dazu die Besucher der letzten fünf Minuten, aufklappbar zu einem Chart pro Minute. Schlüssle alles nach Quelle, Seite, Ort oder Gerät auf. In den Docs ansehen Live · jetzt Demo Live · letzte 5 Min Unique Visitors 1.284 Pageviews 3.902 Quellen Demo Quelle / Medium Besuche - google / cpc gclid 412 - facebook / paid 233 - (direct) 301 - newsletter / email 188 Aufschlüsselungen ## Vier Wege, den Traffic zu lesen. Jede Metrik lässt sich über vier Panels aufschlüsseln, jedes mit eigenen Unter-Tabs. ### Quellen Kanal gegen UTM-Quelle: woher der Traffic kommt, von Direktaufrufen bis zu einzelnen bezahlten Kampagnen. ### Seiten Welche Seiten aufgerufen werden, mit einem Umschalter für meistbesucht, beste und schlechteste, damit langsame neben beliebten Seiten auftauchen. ### Orte Nach Land, ISO-2, am Edge aus der IP abgeleitet. Keine Stadt, keine Region, keine gespeicherte rohe IP. ### Geräte Browser gegen OS, Gerätetyp, Verbindung und Viewport, alles als Buckets statt exakter Fingerabdrücke. Kampagnen-Attribution ## Volle UTM-Abdeckung, der Klick-Wert bleibt draußen. fastmon liest die Kampagnen-Tags auf deinen eigenen Ausgangs-URLs: den vollen UTM-Satz und welche Ad-Plattform den Klick geschickt hat. Der Klick-ID-Wert selbst wird bewusst verworfen, damit bezahlter Traffic zur Kampagne zurückführt, nie zur einzelnen Person. - utm_source, utm_medium, utm_campaign, utm_term und utm_content, je auf 64 Zeichen begrenzt - Die Klick-ID-Bezeichnung (zum Beispiel gclid) wird erkannt; der Klick-ID-Wert selbst wird verworfen - Schlüssle den Traffic nach Quelle, Medium und Kampagne auf - Kein seitenübergreifendes Tracking und keine Personen-Profile darin Zur Analytics-Doku Aus deiner Kampagnen-URL # gelesen aus deiner eigenen Ausgangs-URL utm_source = "google" utm_medium = "cpc" utm_campaign = "spring_sale" click_id_param = "gclid" # nur die Bezeichnung, max. 64 Zeichen # der Klick-ID-Wert (Cj0KCQ...) wird verworfen fastmon gegen GA4 ## Warum Teams von GA4 wechseln. Ein datenschutzfreundliches Analytics-Tool aus der EU, direkt neben den Performance-Daten, die GA4 nie hatte. | | fastmon | Google Analytics 4 | Keine Cookies* im Standard-Modus | Ja | Nein | In der EU gehostet, kein US-Recht | Ja | Nein | Core Web Vitals im selben Tool Traffic und Performance zusammen | Ja | Teilweise | Ungesampelte Daten | Ja | Teilweise | Rohdaten-Aufbewahrung | 90 Tage Default, bis 13 Monate (Enterprise) | 14 Monate (Standard) GA4-Verhalten hängt von der Konfiguration ab; der Vergleich spiegelt typische Defaults. fastmon Analytics ist in der Beta. Stand: 14. Juli 2026; Listenpreise bzw. typische Konfiguration, individuelle Konditionen können abweichen. FAQ ## Web-Analytics, beantwortet. Die Fragen, die man vor dem Wechsel stellt. ### Ist fastmon Analytics ein Ersatz für Google Analytics? Für die meisten Seiten ja: es deckt Besucher, Quellen, Seiten, Orte, Geräte und Kampagnen ab, direkt neben deinen Performance-Daten. Was es bewusst nicht tut: Funnels als Report, Conversion-Ziele, Custom Events, A/B-Tests oder Session Replay. Es ist außerdem in der Beta, Layout und Metriken können sich also noch ändern. ### Zählt ihr Besucher ohne Cookies? Ja. fastmon setzt im Standard-Modus keine Cookies*. Unique Visitors werden aus einem kurzen pseudonymen Signal gezählt, das am Edge berechnet wird (ein HMAC mit einem Salt, der alle 24 Stunden rotiert und den Edge-Speicher nie verlässt), pro Domain und auf rund 24 Stunden begrenzt. Mehr auf der Seite zu EU und Datenschutz. ### Welche Kennzahlen bekomme ich? Drei Kern-Kennzahlen, Unique Visitors, Pageviews und Views pro Besuch, jede mit Trend; die aktuellen Besucher der letzten fünf Minuten; besucherbezogene Metriken wie Besuchsdauer, Seiten pro Besuch und Fehleranzahl; und die Fehlerrate über die Zeit. Aufschlüsselungen gibt es nach Quellen, Seiten, Orten und Geräten. ### Trackt ihr gclid und fbclid? fastmon erfasst die UTM-Tags auf deinen Ausgangs-URLs und erkennt, welche Ad-Plattform einen Klick geschickt hat (die Klick-ID-Bezeichnung, zum Beispiel gclid). Der Klick-ID-Wert selbst wird verworfen, du bekommst also Kampagnen-Attribution, ohne einen personenbezogenen Identifier zu speichern. fbclid ist kein Wert, den wir behalten. ### Kann ich Performance und Traffic zusammen sehen? Ja, genau das ist der Punkt. Analytics und Web Vitals laufen auf denselben Beacons und derselben Query-API. Der Explorer liefert sogar Presets, die Traffic und Performance mischen, von Core Web Vitals bis Fehler und Backend-Timing. ### Wo werden die Daten gespeichert? Ausschließlich in der EU, auf in Deutschland betriebener Infrastruktur, ohne US-eigenen Subauftragsverarbeiter im Datenpfad. Keine Cookies*, nur das Land, und eine Default-Aufbewahrung von 90 Tagen, die du pro Website einstellst. Mehr auf der Seite zu EU und Datenschutz. ## Analytics ohne Cookies*, ohne Langzeit-Profile. Traffic und Kampagnen ohne Tracking: read-only im Standard, keine Cookies*, keine langlebigen Identifikatoren. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/funktionen/rum/ Real User Monitoring # Real User Monitoring. Echte Nutzer, echte Zahlen. fastmon misst die Web-Performance direkt im Browser deiner Besucher: echte Geräte, echte Netze, die Core Web Vitals, nach denen Google dich rankt. Kein Labor, keine Schätzung, keine 28-Tage-Durchschnitte. Was ist RUM? ## Die Performance, die deine Besucher wirklich bekommen. Real User Monitoring (RUM) misst, wie deine Website in den Browsern deiner echten Besucher läuft, auf deren eigenen Geräten und in deren Netzen, so wie sie es erleben. Ein kleines Script liest bei jedem Seitenaufruf die nativen Performance-APIs des Browsers und meldet die Zeiten zurück. Das sind Felddaten, das Gegenteil eines Labortests auf einer schnellen Maschine im Büro. Genau dieser Unterschied ist der Punkt. Ein synthetisches Tool sagt dir, wie schnell ein simuliertes Gerät deine Seite unter idealen Bedingungen geladen hat. RUM sagt dir, wie schnell es für den Besucher auf einem drei Jahre alten Android im Mobilfunknetz war. Es ist die Wahrheit, verrauscht und träger, aggregiert am 75. Perzentil, damit du das Erlebnis der Nutzer siehst, die leiden, nicht einen schmeichelnden Durchschnitt. Es ist auch keine Web-Analytics. Analytics zählt Besuche und Quellen. RUM misst die Performance jedes Besuchs: die Core Web Vitals, nach denen Google rankt, JavaScript-Fehler und wohin die Zeit wirklich geht. fastmon liefert dir alles davon aus einem Script, ohne Cookies*, komplett in der EU gehostet. Warum RUM ## Sieh, was ein Labortest dir nie zeigt. Drei Dinge, die Felddaten können und synthetische Checks und Analytics nicht. ### Sieh, was echte Nutzer erleben Jeder echte Seitenaufruf meldet seine Core Web Vitals, damit du die Performance siehst, die deine Besucher wirklich bekommen, nach Gerät, Netz und Land aufgeschlüsselt, kein einzelner Durchschnitt. ### Fixe das Richtige p75-Perzentile, LCP-Subparts, Request-Waterfalls und Fehler-Fingerprints zeigen dir die Seiten und Ursachen, die zählen, statt einem Laborwert hinterherzujagen. ### Werde alarmiert, bevor Nutzer sich beschweren Schwellen- und Regressions-Regeln auf den Vitals, an E-Mail, Slack, Discord oder Webhook, mit Release-Markern, damit du weißt, welcher Deploy schuld war. Core Web Vitals ## Die drei Metriken, nach denen Google rankt. fastmon meldet LCP, INP und CLS aus echten Besuchen, aggregiert am p75 gegen die Schwellen von Google. Grün heißt: 75 % deiner Besucher waren mindestens so schnell. LCP ### Wie schnell erscheint der Hauptinhalt? Largest Contentful Paint ist der Moment, in dem das größte sichtbare Element (ein Hero-Bild, Video-Poster oder die Überschrift) gerendert ist. fastmon zerlegt es in seine vier Subparts, von TTFB bis Element-Render-Delay, damit du siehst, wo die Wartezeit steckt. Gut ≤ 2,5 s Grenzwertig ≤ 4,0 s Schlecht > 4,0 s INP ### Reagiert die Seite sofort auf Taps und Klicks? Interaction to Next Paint ist die Worst-Case-Verzögerung zwischen einer Interaktion und dem nächsten Frame. Sie ersetzte FID im März 2024 als Core Web Vital. Long Animation Frames (über 50 ms) zeigen auf das Script, das die Antwort blockiert hat. Gut ≤ 200 ms Grenzwertig ≤ 500 ms Schlecht > 500 ms CLS ### Springt das Layout beim Laden herum? Cumulative Layout Shift bewertet, wie viel sichtbarer Inhalt sich unerwartet verschiebt. fastmon meldet das schlechteste Shift-Fenster pro Besuch, damit ein spät ladender Banner, der deinen Inhalt nach unten schiebt, sich nicht im Durchschnitt versteckt. Gut ≤ 0,1 Grenzwertig ≤ 0,25 Schlecht > 0,25 ### Eine Zahl fürs Meeting: der Experience Score. fastmon verdichtet die Vitals plus Fehlerrate und Ladezeit zu einem einzigen Experience Score von 0 bis 10, benotet von A+ bis F. Sieben gewichtete Signale: LCP 25 %, INP, FCP und Fehlerrate je 15 %, Page Load Time, CLS und TTFB je 10 %. Jedes wird per linearer Interpolation gegen seine Gut- und Schlecht-Schwelle auf einen Sub-Score gemappt. Netzwerk-Timing · p75 982 ms GET / app.4f2.js main.a1c.css api/cart 0 0,5 s 1 s DNS TCP TTFB Transfer TypeError Fehlerrate 0,4 % Cannot read properties of undefined (reading 'map') 3 Besucher betroffen · zuerst vor 2 h · checkout.js:42 Fehler & Netzwerk ## Wohin die Zeit geht, und was bricht. Langsam ist das eine Problem, kaputt das andere. fastmon meldet beides aus denselben echten Besuchen, bis auf die Backend-Phase und den exakten Fehler-Fingerprint. - JavaScript-Fehler nach Fingerprint gruppiert (Typ, Meldung, Stack-Form), mit Häufigkeit, betroffenen Besuchern und First-/Last-Occurrence - Error Rate over Time: Anteil der Pageviews mit mindestens einem Fehler, Fehler von Adblocker-blockierten Trackern und Teardown-Rauschen ausgenommen - Navigation- und Resource-Timing, dazu Fetch- und XHR-Calls am p75 und p95 mit Request-Waterfall - Server-Timing-Breakdown in sieben Phasen entlang des Request-Pfads (Edge, Origin, Backend, Datenbank, Render, Cache, External) - Cache-Monitoring über Browser-, CDN- und Origin-Ebene, inklusive bfcache-Hit-Rate Zur Analytics-Doku Geo · Demo nach Land Deutschland 90 % · 1,3M Segmente ## Schlüssle nach Land, Gerät und Seite auf. Ein Durchschnitt versteckt die Nutzer, die leiden. Mit fastmon brichst du jede Metrik herunter, bis du das Segment findest, das wirklich langsam ist. - Geografie nach Land, am Edge aus der IP abgeleitet (die rohe IP erreicht das Backend nie) - Gerätetyp, Browser, OS, Viewport und Verbindungstyp - Pro Seite und pro Template, damit du siehst, welche Routen langsam sind - Visitor Explorer: einzelne Besuche mit Dauer, Gerät und Web Vitals sowie Fehlern pro Seite - Single-Page-Apps: clientseitige Routenwechsel werden als Soft Navigations erfasst Mehr zu Web-Analytics Gebaut für Produktion ## Alerts, Releases und eine API. RUM nützt nur, wenn es in deinen Workflow passt. fastmon klinkt sich in die Tools ein, die du schon nutzt. ### Alerts, die sich selbst routen Regeln auf LCP, INP, CLS, FCP, TTFB, Fehlerrate, Pageviews oder Visitors, absolut oder als Prozent-Änderung, an E-Mail, Slack, Discord oder Webhook. ### Release-Tracking Tagge einen Deploy mit einem API-Call aus GitHub Actions, GitLab oder Vercel. fastmon vergleicht die Vitals davor und danach am p75. ### REST API mit OpenAPI Frag jede Metrik über die Analytics-API ab, mit Bearer-Token-Auth, Offset- und Cursor-Pagination und einem OpenAPI-Schema. Datenschutz ## Innerhalb der DSGVO entworfen. Nicht nachträglich angepasst. Das ist der Unterschied zwischen einem Monitoring-Tool aus der EU und einem mit EU-Region. Hier ist das Datenblatt: die ehrliche Version, mit Fußnote. * In den Modi Minimal und Standard setzt fastmon kein Cookie und speichert nichts auf dem Endgerät; gelesen werden nur Statuswerte, die der Browser zur Laufzeit selbst erzeugt. Im Modus Full wird eine Kennung geschrieben, dort ist eine Einwilligung nach § 25 TDDDG erforderlich. Die Prüfung obliegt dem jeweiligen Website-Betreiber, der fastmon einbindet. Datenblatt Cookies 0* strikt speicherfrei: kein localStorage, kein sessionStorage IP-Adresse am Edge entfernt bevor irgendein Application-Code sie sieht Standort nur Land zweistelliger ISO-Code, mehr nicht Datenpfad 100 % EU kein Cloudflare, kein AWS, kein GCP Aufbewahrung 90 Tage Default, pro Website einstellbar Fingerprinting keins kein Canvas, keine Font-Enumeration Mehr zu EU & Datenschutz Wo es hingehört ## RUM, Synthetic und Analytics. Drei verschiedene Jobs. fastmon macht alle drei aus einem Script, aber sie beantworten verschiedene Fragen. Real User Monitoring Diese Seite Die Performance, die echte Besucher bekommen, aus dem Feld, am p75. Beantwortet: wie schnell ist meine Seite wirklich, und für wen? Synthetic Monitoring Ergänzend Geplante Labortests auf einem simulierten Gerät unter idealen Bedingungen. Reproduzierbar, ideal, um Regressionen vor einem Deploy zu fangen. Web-Analytics Gleiches Tool Wer besucht, woher, über welche Kampagne. Misst Traffic, keine Performance. In fastmon liegt es direkt neben den Vitals. Setup ## Live in rund fünf Minuten. Ein Script-Tag im Head, kein Build-Step, keine Konfiguration. Läuft mit jedem Stack, von statischem HTML bis Next.js, WordPress und Shopware. index.html 1 < script defer src = "https://fastmon.site/s/{source_hash}.js" > 01 ### Tag einbauen Vanilla JS, ~40 KB komprimiert, lädt mit defer. 02 ### Mit 204 prüfen Der Collector antwortet mit 204 No Content. Ein Blick in den Network-Tab. 03 ### Daten ankommen sehen Deine ersten Besucher erscheinen rund eine Minute später im Dashboard. Installations-Guide in den Docs FAQ ## Real User Monitoring, beantwortet. Die Fragen, die man stellt, bevor man den Tag einbaut. ### Was ist der Unterschied zwischen RUM und Synthetic Monitoring? RUM ist passiv: es misst echte Besuche in echten Browsern und erfasst so das tatsächliche Erlebnis über jedes Gerät und Netz, aggregiert am p75. Synthetic Monitoring ist aktiv: es fährt geplante Tests auf einem simulierten Gerät unter idealen, reproduzierbaren Bedingungen. Sie ergänzen einander, und fastmon macht beides aus demselben Script. ### Ist RUM nur ein weiteres Analyse-Tool? Nein. Analytics zählt Besuche, Quellen und Kampagnen. RUM misst die Performance jedes Besuchs: Core Web Vitals, JavaScript-Fehler und Netzwerk-Timing. fastmon zeigt beides nebeneinander, aber die RUM-Daten drehen sich um Geschwindigkeit und Stabilität, nicht um Traffic. ### Welche Metriken misst fastmon? Die drei Core Web Vitals (LCP, INP, CLS) am p75 gegen die Google-Schwellen, dazu die Diagnose-Metriken FCP, TTFB und Page Load Time, JavaScript-Fehler und Netzwerk-Timing inklusive Server-Timing-Phasen. Alles verdichtet sich zu einem Experience Score von 0 bis 10. ### Brauche ich für RUM einen Cookie-Banner? Nein, in den Modi Minimal und Standard nicht. Es wird nichts auf dem Endgerät gespeichert, und die Werte, die gelesen werden, lagen vorher nicht dort: sie entstehen erst beim Seitenaufruf. Es genügt, fastmon in deiner Datenschutzerklärung zu nennen. Im Modus Full brauchst du eine Einwilligung, weil dort eine Kennung in den sessionStorage geschrieben wird. Diese Einordnung ist mit unserem externen Datenschutzbeauftragten geprüft; ein Restrisiko bleibt, weil zu dieser Konstellation kein Urteil vorliegt. Die ganze Herleitung, mit Normtext und Gegenauffassung ### Wo werden die Daten gespeichert? Komplett in der EU, auf in Deutschland betriebener Infrastruktur. Kein Cloudflare, kein AWS, kein GCP, kein US-Subauftragsverarbeiter im Datenpfad. Daten werden per Default 90 Tage aufbewahrt, pro Website einstellbar. ### Wie schnell ist das Setup und macht es meine Seite langsamer? Rund fünf Minuten: ein Script-Tag mit defer, kein Build-Step. Das Script ist Vanilla JS, rund 40 KB komprimiert, und liest die nativen Performance-APIs des Browsers. Die Daten gehen über navigator.sendBeacon raus, in einem bewusst schlanken Wire-Format, gebündelt über den Seiten-Lifecycle. ## Sieh, was deine Besucher wirklich erleben. Core Web Vitals von echten Geräten, read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/funktionen/synthetic/ Synthetic Monitoring # Synthetic Monitoring. Das Labor neben dem Feld. Geplante Lighthouse-Audits auf einem simulierten Gerät, dazu leichte TTFB-Checks, unter idealen und reproduzierbaren Bedingungen, direkt neben den Felddaten deiner echten Besucher. Regressionen fangen, bevor sie live gehen. Was ist Synthetic Monitoring? ## Ein kontrollierter Lauf, nach Zeitplan. Synthetic Monitoring schickt deine Seite nach festem Zeitplan durch ein Test-Labor: ein simuliertes Gerät, ein Standort, ideale Bedingungen, voll reproduzierbar. Weil sich die Bedingungen nie ändern, ist ein synthetischer Lauf das saubere Signal, das dir sagt, dass eine Regression live gegangen ist, bevor deine echten Nutzer sie spüren. Es ist das Gegenstück zu Real User Monitoring, kein Ersatz. RUM ist die Wahrheit aus dem Feld, verrauscht, aber echt. Synthetic ist die kontrollierte Basislinie, reproduzierbar, aber blind für echte Bedingungen. fastmon fährt beides aus demselben Setup, damit du Labor und Realität nebeneinander liest. Synthetic Monitoring ist aktuell in der Beta. Gemessen wird nicht in fastmon selbst: Jeden Lauf führt Commerce-Score aus, der Performance-Analyzer der ScaleCommerce GmbH, des Unternehmens hinter fastmon. Deshalb ist es ein Opt-In, und deshalb verlassen nur die Seiten-URLs, die du überwachst, je die Plattform. Powered by ### Commerce-Score Jeden synthetischen Lauf in fastmon misst Commerce-Score, der Open-Source-Performance-Analyzer der ScaleCommerce GmbH. Er bewertet über 20 Metriken pro Seite auf Mobile und Desktop, von Core Web Vitals und TTFB über Third-Party-Gewicht bis zu den Lighthouse-Kategorien. fastmon plant die Läufe, hält die Ergebnisse und legt sie neben die Felddaten deiner echten Besucher. - Standardmäßig aus: Externe Messungen schaltet der Owner der Organisation frei. - Übermittelt werden nur die Seiten-URLs, die du überwachst, nie Besucherdaten. - Open Source, gebaut von der ScaleCommerce GmbH in Deutschland, dem Unternehmen hinter fastmon. commerce-score.io besuchen Zwei Testarten Beta ## Lighthouse und TTFB, nach Zeitplan. Jede überwachte Seite fährt automatisch zwei Arten von Test. Lighthouse · alle 24 h ### Voller Lighthouse-Audit - Ein voller Lauf alle 24 Stunden, Desktop und Mobile in einem Durchgang - Vier Kategorien: Performance, Accessibility, Best Practices, SEO - Lab-Metriken: LCP, FCP, CLS, TBT, Speed Index, TTFB - Cache-Bypass standardmäßig an, du misst den ungecachten Worst Case TTFB · alle 5 Min ### Leichter Server-Check - Ein Server-Response-Check etwa alle 5 Minuten - Zerlegt in DNS, TCP, SSL, Server und Transfer - Fängt Backend-Einbrüche zwischen den vollen Audits - Läuft im selben Zeitplan, kein Extra-Setup Zur Synthetic-Doku Der Audit ## Vier Kategorien, ein Lauf. Jeder Lighthouse-Audit bewertet deine Seite in denselben vier Kategorien wie Google, auf Desktop und Mobile. ### Performance Die Lab-Metriken hinter dem Score: LCP, FCP, CLS, TBT und Speed Index auf einem kontrollierten Gerät. ### Accessibility Automatische Checks für Kontrast, Labels, Rollen und die Struktur, auf die assistive Technik angewiesen ist. ### Best Practices Modern-Web-Checks: HTTPS, korrekte Bildgrößen, Konsolen-Fehler und sichere Defaults. ### SEO Die technischen Basics, die Suchmaschinen erwarten: Meta-Tags, Crawlbarkeit und valides Markup. Pläne ## Wie viele Seiten du überwachst. Manuelle Seiten fügst du selbst hinzu, dazu Auto-Seiten aus deinem Top-RUM-Traffic. One-Shot-Ad-hoc-Tests sind immer unbegrenzt. | Plan | Manuelle Seiten | Auto-Seiten | Beta | 5 | 5 | Light | 2 | 3 | Standard | 5 | 10 | Enterprise | 25 | 50 One-Shot-Tests laufen auf Abruf ohne Zeitplan und sind bewusst unbegrenzt. Limits während der Beta; die Plan-Zuordnung kann sich noch ändern. Labor und Feld ## Zwei Ansichten, eine Wahrheit. Keine der beiden Ansichten ist das ganze Bild. Das Labor ist reproduzierbar, aber blind für echte Bedingungen; das Feld ist echt, aber verrauscht. fastmon zeigt beides, damit eine Regression im Labor und ihre Wirkung im Feld zusammenpassen. Labor · Synthetic - Simuliertes Gerät, ein Standort, ideale Bedingungen - Reproduzierbar, ideal, um Regressionen zu fangen - Läuft nach Zeitplan, vor und nach einem Deploy Feld · RUM - Alle echten Besucher, echte Netze, echte Geräte - Aggregiert am p75, die Wahrheit über das Erlebnis - Inklusive INP, das das Labor nicht messen kann Mehr zu Real User Monitoring FAQ ## Synthetic Monitoring, beantwortet. Die Fragen, bevor du deinen ersten Test planst. ### Wie oft läuft ein Test? Ein voller Lighthouse-Audit läuft alle 24 Stunden und misst Desktop und Mobile in einem Durchgang. Ein leichterer TTFB-Check läuft etwa alle 5 Minuten, um Backend-Einbrüche dazwischen zu fangen. Zusätzlich kannst du jederzeit einen One-Shot-Test auslösen. ### Was ist der Unterschied zu Real User Monitoring? Synthetic ist ein kontrollierter Labortest auf einem simulierten Gerät unter idealen Bedingungen, reproduzierbar und ideal, um Regressionen zu fangen. RUM misst deine echten Besucher im Feld am p75. Sie ergänzen einander, und fastmon fährt beides. INP ist übrigens eine reine Feld-Metrik und kommt aus RUM, nicht aus dem Labor. ### Welche Lighthouse-Kategorien werden gemessen? Alle vier: Performance, Accessibility, Best Practices und SEO, auf Desktop und Mobile im selben Lauf. Cache-Bypass ist standardmäßig an, damit du immer den ungecachten Worst Case misst. ### Wie viele Seiten kann ich überwachen? Das hängt vom Plan ab. Light überwacht 2 manuelle plus 3 Auto-Seiten, Standard 5 plus 10, bis Enterprise mit 25 plus 50. Auto-Seiten werden aus deinem Top-RUM-Traffic gewählt. One-Shot-Ad-hoc-Tests sind immer unbegrenzt. ### Wer führt die synthetischen Tests aus? Commerce-Score, der Open-Source-Performance-Analyzer der ScaleCommerce GmbH, des Unternehmens hinter fastmon. Weil es ein externer Dienst ist, ist er ein Subauftragsverarbeiter, und darum bleibt Synthetic Monitoring aus, bis der Owner der Organisation externe Messungen freigibt. Ab dann gehen nur die Seiten-URLs, die du überwachst, dorthin; Besucherdaten verlassen fastmon nie. Den Analyzer selbst kannst du unter commerce-score.io ausprobieren. ## Fang Regressionen ab, bevor sie live gehen. Lighthouse-Audits nach Zeitplan, read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren. In Deutschland gehostet. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/alerting/ Methoden # Alarmierung Benachrichtigungsregeln, die melden, wenn eine Metrik einen Schwellenwert reißt oder sich verschlechtert, bevor Kunden sich beschweren. Dashboards helfen nur, wenn jemand hinschaut. Alarmierung beobachtet die Zahlen für dich und feuert, wenn ein Core Web Vital, eine Fehlerrate oder ein Experience Score eine von dir gesetzte Linie überschreitet oder in die falsche Richtung tendiert. Gute Alarmierung ist spezifisch genug, um ihr zu vertrauen: begrenzt auf die Seiten und Metriken, die zählen, sodass eine kritisch werdende Seite die richtigen Leute erreicht, statt unterzugehen. Verwandte Begriffe - RUM Real User Monitoring Performance aus den Browsern deiner echten Besucher messen, auf ihren realen Geräten und Netzwerken. - Synthetic Monitoring Geplante, wiederholbare Tests, die eine Seite in kontrollierter Umgebung in festem Intervall laden. - Labordaten vs Felddaten Labordaten stammen aus einem kontrollierten Test, Felddaten von echten Besuchern. Beides zählt, aus verschiedenen Gründen. - Lighthouse Googles Open-Source-Tool, das eine Seite in einem Labordurchlauf prüft und Performance, Barrierefreiheit, SEO und mehr bewertet. - CrUX Chrome UX Report Googles öffentlicher Datensatz realer Core Web Vitals, aggregiert aus zustimmenden Chrome-Nutzern. - p75 Perzentil (p75) Der Wert, unter den ein bestimmter Anteil der Besuche fällt. p75 heißt, 75 Prozent waren mindestens so schnell. - Web Vitals Attribution Die zusätzlichen Diagnosedaten, die erklären, warum eine Metrik langsam war, nicht nur wie langsam. - Web-Analytics Messung von Traffic und Verhalten: Seitenaufrufe, Besucher, Referrer und Journeys, gemeinsam mit Performance. - Error Tracking Erfassen von JavaScript-Fehlern und fehlgeschlagenen Requests aus echten Sitzungen, gruppiert, sodass die echten Probleme sichtbar werden. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/beacon/ Bausteine # Beacon Das kleine Datenpaket, das der Tracker mit den Messwerten eines Besuchs an fastmon sendet. Wenn eine Seite mit dem Messen fertig ist, packt der Tracker Metriken, Timings und etwaige Fehler in eine kompakte Nutzlast und sendet sie, typischerweise über die Beacon-API, sodass die Zustellung die Seite nicht blockiert oder verlangsamt. Was ein Beacon genau enthält, lässt sich mit der fastmon Beacon-Inspector-Browsererweiterung prüfen, Teil davon, wie fastmon transparent hält, was es erfasst. Verwandte Begriffe - Tracker Das leichtgewichtige Skript, das du einmal einbindest; es misst Core Web Vitals und Fehler direkt im Browser. - Stitch fastmons kurzlebiger, am Edge abgeleiteter Identifier, der einen Besuch ohne Cookies oder Cross-Site-Tracking gruppiert. - Session Ein zusammenhängender Besuch: die Abfolge von Seitenaufrufen und Interaktionen, bevor ein Besucher inaktiv wird. - Pageview Ein einzelner Seitenaufruf oder, in einer Single-Page-App, ein Route-Wechsel, der als eigener Aufruf zählt. - Collection Modes Voreinstellungen (Light, Standard, Full), die festlegen, wie viel Detail der Tracker erfasst. - Server-Timing Ein HTTP-Header, den dein Backend senden kann, um aufzuschlüsseln, wo Serverzeit verbraucht wurde, sichtbar im RUM. - Cache-Status Ob eine Antwort von einem CDN-Edge, dem Origin-Server oder dem Browser-Cache kam. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/cache-status/ Bausteine # Cache-Status Ob eine Antwort von einem CDN-Edge, dem Origin-Server oder dem Browser-Cache kam. Dieselbe URL kann schnell oder langsam sein, je nachdem woher sie ausgeliefert wurde. Den Cache-Status pro Request zu erfassen zeigt die echte Trefferquote und deckt Ressourcen auf, die den Cache immer wieder verfehlen und den Origin treffen. Das macht aus Caching statt einer hoffnungsvollen Konfiguration etwas, das sich an echtem Traffic verifizieren lässt. Verwandte Begriffe - Beacon Das kleine Datenpaket, das der Tracker mit den Messwerten eines Besuchs an fastmon sendet. - Tracker Das leichtgewichtige Skript, das du einmal einbindest; es misst Core Web Vitals und Fehler direkt im Browser. - Stitch fastmons kurzlebiger, am Edge abgeleiteter Identifier, der einen Besuch ohne Cookies oder Cross-Site-Tracking gruppiert. - Session Ein zusammenhängender Besuch: die Abfolge von Seitenaufrufen und Interaktionen, bevor ein Besucher inaktiv wird. - Pageview Ein einzelner Seitenaufruf oder, in einer Single-Page-App, ein Route-Wechsel, der als eigener Aufruf zählt. - Collection Modes Voreinstellungen (Light, Standard, Full), die festlegen, wie viel Detail der Tracker erfasst. - Server-Timing Ein HTTP-Header, den dein Backend senden kann, um aufzuschlüsseln, wo Serverzeit verbraucht wurde, sichtbar im RUM. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/cls/ Metriken CLS # Cumulative Layout Shift Ein einheitenloser Wert dafür, wie stark sich sichtbarer Inhalt unerwartet verschiebt, während die Seite lädt und läuft. Gut <= 0.1 Ausbaufähig 0.1 to 0.25 Schlecht > 0.25 Felddaten (75. Perzentil) CLS ist das Core-Web-Vital für visuelle Stabilität. Jedes Mal, wenn sich ein Element ohne Nutzeraktion verschiebt, bewertet der Browser, wie viel des Viewports sich wie weit bewegt hat. CLS summiert den schlimmsten Schub dieser Verschiebungen während des Besuchs. Es ist die Metrik hinter dem bekannten Ärger, wenn ein Button im Moment des Antippens wegspringt, weil ein spätes Banner oder Bild lädt. Anders als die zeitbasierten Vitals hat es keine Einheit: kleiner ist besser, und 0 heißt, nichts hat sich bewegt. Was es beeinflusst - Bilder und Embeds ohne Breite und Höhe (oder Seitenverhältnis). - Werbung, Banner und iframes, die über bestehenden Inhalt eingefügt werden. - Web-Fonts, die Text umbrechen, wenn sie geladen sind. - Dynamisch eingefügter Inhalt ohne reservierten Platz. Mehr erfahren Verwandte Begriffe - CWV Core Web Vitals Googles Satz aus drei Feld-Metriken für Ladezeit (LCP), Interaktivität (INP) und visuelle Stabilität (CLS) einer Seite. - LCP Largest Contentful Paint Die Zeit, bis das größte sichtbare Element im Viewport (Bild, Video oder Textblock) gerendert ist. - INP Interaction to Next Paint Wie lange die Seite braucht, um nach einer Nutzerinteraktion sichtbar zu reagieren, gemessen über den gesamten Besuch. - FCP First Contentful Paint Der Moment, in dem der Browser den ersten Inhalt rendert: Text, ein Bild oder ein Canvas. - TTFB Time to First Byte Die Zeit vom Start der Navigation bis der Browser das erste Byte der Antwort empfängt. - FID First Input Delay (abgelöst) Die Verzögerung zwischen der ersten Interaktion eines Besuchers und dem Beginn ihrer Verarbeitung durch den Browser. Durch INP ersetzt. - TBT Total Blocking Time Die Gesamtzeit, in der der Main-Thread zwischen erstem Paint und Interaktivität von langen Tasks blockiert war, im Labor gemessen. - SI Speed Index Eine Labor-Metrik dafür, wie schnell sich die sichtbaren Teile einer Seite während des Ladens füllen, basierend auf Videoaufnahme. - TTI Time to Interactive (veraltet) Eine Labor-Metrik dafür, wann eine Seite gerendert ist und zuverlässig schnell auf Eingaben reagieren kann. - Page Load Das klassische Load-Event: alles auf der Erstseite, inklusive Bilder und Subressourcen, ist fertig geladen. - Route Load Die Ladezeit einer In-App-Navigation in einer Single-Page-App, bei der kein voller Seiten-Reload passiert. - Long Tasks & LoAF Jedes Stück JavaScript, das den Main-Thread länger als 50 ms belegt und die Seite am Reagieren hindert. - Experience Score Eine einzelne Zahl von 0 bis 10, die fastmon aus LCP, INP, CLS, FCP, TTFB, Ladezeit und Fehlerrate bildet. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/collection-modes/ Bausteine # Collection Modes Voreinstellungen (Light, Standard, Full), die festlegen, wie viel Detail der Tracker erfasst. Nicht jede Site braucht dieselbe Tiefe. Light beschränkt Daten auf das Nötigste, Standard ist die ausgewogene Voreinstellung, und Full schaltet die reichste Diagnostik frei, etwa detaillierte Attribution und Resource Timing. Der Modus ist ein bewusster Hebel über den Datenschutz- und Daten-Kompromiss, von dir gewählt statt angenommen, und er bildet direkt ab, was das Gerät eines Besuchers abgefragt wird. Verwandte Begriffe - Beacon Das kleine Datenpaket, das der Tracker mit den Messwerten eines Besuchs an fastmon sendet. - Tracker Das leichtgewichtige Skript, das du einmal einbindest; es misst Core Web Vitals und Fehler direkt im Browser. - Stitch fastmons kurzlebiger, am Edge abgeleiteter Identifier, der einen Besuch ohne Cookies oder Cross-Site-Tracking gruppiert. - Session Ein zusammenhängender Besuch: die Abfolge von Seitenaufrufen und Interaktionen, bevor ein Besucher inaktiv wird. - Pageview Ein einzelner Seitenaufruf oder, in einer Single-Page-App, ein Route-Wechsel, der als eigener Aufruf zählt. - Server-Timing Ein HTTP-Header, den dein Backend senden kann, um aufzuschlüsseln, wo Serverzeit verbraucht wurde, sichtbar im RUM. - Cache-Status Ob eine Antwort von einem CDN-Edge, dem Origin-Server oder dem Browser-Cache kam. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/cookieless/ Datenschutz & EU # Cookiefrei Messen, ohne etwas auf dem Gerät des Besuchers zu speichern: keine Cookies, kein localStorage. Klassische Analytics schreibt ein Cookie, um wiederkehrende Besucher zu erkennen, was Einwilligungspflichten auslöst und blockiert oder gelöscht werden kann. fastmon ist standardmäßig cookiefrei: im Read-only-Modus speichert es überhaupt nichts auf dem Gerät. Cookiefrei ist nicht dasselbe wie einwilligungsfrei. Das Lesen von Browser-Performance-APIs kann weiterhin unter Consent-Regeln fallen, aber indem es nichts speichert, beseitigt fastmon eine ganze Klasse von Datenschutz- und Genauigkeitsproblemen cookiebasierter Tools. Mehr erfahren Verwandte Begriffe - Edge-IP-Verarbeitung Die IP-Adresse des Besuchers wird am Edge auf einen Country-Code reduziert und verworfen, bevor Anwendungscode sie sieht. - GDPR DSGVO Die EU-Datenschutz-Grundverordnung, die rechtliche Grundlinie für den Umgang mit personenbezogenen Daten in Europa. - TDDDG (Paragraf 25) Das deutsche Gesetz, das die ePrivacy-Regel umsetzt, wonach Lesen von oder Schreiben auf einem Gerät Einwilligung braucht. - Datenresidenz Wo deine Daten physisch liegen und unter wessen Rechtsprechung sie fallen. Bei fastmon: Deutschland, durchgängig. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/core-web-vitals/ Metriken CWV # Core Web Vitals Googles Satz aus drei Feld-Metriken für Ladezeit (LCP), Interaktivität (INP) und visuelle Stabilität (CLS) einer Seite. Core Web Vitals sind die Teilmenge der Performance-Signale, die Google als essenziell für die Nutzererfahrung wertet und ins Ranking einfließen lässt. Jede Metrik erfasst einen anderen Moment: wie schnell der Hauptinhalt erscheint, wie schnell die Seite auf Eingaben reagiert und wie stark das Layout springt. Als bestanden gilt eine Seite nur, wenn alle drei im 75. Perzentil echter Besuche im grünen Bereich liegen. Labor-Tools können sie schätzen, die offizielle Bewertung nutzt aber immer Felddaten echter Nutzer. Mehr erfahren Verwandte Begriffe - LCP Largest Contentful Paint Die Zeit, bis das größte sichtbare Element im Viewport (Bild, Video oder Textblock) gerendert ist. - INP Interaction to Next Paint Wie lange die Seite braucht, um nach einer Nutzerinteraktion sichtbar zu reagieren, gemessen über den gesamten Besuch. - CLS Cumulative Layout Shift Ein einheitenloser Wert dafür, wie stark sich sichtbarer Inhalt unerwartet verschiebt, während die Seite lädt und läuft. - FCP First Contentful Paint Der Moment, in dem der Browser den ersten Inhalt rendert: Text, ein Bild oder ein Canvas. - TTFB Time to First Byte Die Zeit vom Start der Navigation bis der Browser das erste Byte der Antwort empfängt. - FID First Input Delay (abgelöst) Die Verzögerung zwischen der ersten Interaktion eines Besuchers und dem Beginn ihrer Verarbeitung durch den Browser. Durch INP ersetzt. - TBT Total Blocking Time Die Gesamtzeit, in der der Main-Thread zwischen erstem Paint und Interaktivität von langen Tasks blockiert war, im Labor gemessen. - SI Speed Index Eine Labor-Metrik dafür, wie schnell sich die sichtbaren Teile einer Seite während des Ladens füllen, basierend auf Videoaufnahme. - TTI Time to Interactive (veraltet) Eine Labor-Metrik dafür, wann eine Seite gerendert ist und zuverlässig schnell auf Eingaben reagieren kann. - Page Load Das klassische Load-Event: alles auf der Erstseite, inklusive Bilder und Subressourcen, ist fertig geladen. - Route Load Die Ladezeit einer In-App-Navigation in einer Single-Page-App, bei der kein voller Seiten-Reload passiert. - Long Tasks & LoAF Jedes Stück JavaScript, das den Main-Thread länger als 50 ms belegt und die Seite am Reagieren hindert. - Experience Score Eine einzelne Zahl von 0 bis 10, die fastmon aus LCP, INP, CLS, FCP, TTFB, Ladezeit und Fehlerrate bildet. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/crux/ Methoden CrUX # Chrome UX Report Googles öffentlicher Datensatz realer Core Web Vitals, aggregiert aus zustimmenden Chrome-Nutzern. CrUX ist die Felddatenquelle hinter der Core-Web-Vitals-Bewertung der Google-Suche und dem Feldbereich von PageSpeed Insights. Es meldet das 75. Perzentil je Metrik, monatlich aggregiert über berechtigten Chrome-Traffic. Es ist wertvoll, aber grob: monatlich, auf Origin- oder Seitengruppen-Ebene, nur Chrome, und nur für Seiten mit genug Traffic. Das eigene RUM füllt diese Lücken mit Daten pro Seite, in Echtzeit und über alle Browser. Verwandte Begriffe - RUM Real User Monitoring Performance aus den Browsern deiner echten Besucher messen, auf ihren realen Geräten und Netzwerken. - Synthetic Monitoring Geplante, wiederholbare Tests, die eine Seite in kontrollierter Umgebung in festem Intervall laden. - Labordaten vs Felddaten Labordaten stammen aus einem kontrollierten Test, Felddaten von echten Besuchern. Beides zählt, aus verschiedenen Gründen. - Lighthouse Googles Open-Source-Tool, das eine Seite in einem Labordurchlauf prüft und Performance, Barrierefreiheit, SEO und mehr bewertet. - p75 Perzentil (p75) Der Wert, unter den ein bestimmter Anteil der Besuche fällt. p75 heißt, 75 Prozent waren mindestens so schnell. - Web Vitals Attribution Die zusätzlichen Diagnosedaten, die erklären, warum eine Metrik langsam war, nicht nur wie langsam. - Web-Analytics Messung von Traffic und Verhalten: Seitenaufrufe, Besucher, Referrer und Journeys, gemeinsam mit Performance. - Error Tracking Erfassen von JavaScript-Fehlern und fehlgeschlagenen Requests aus echten Sitzungen, gruppiert, sodass die echten Probleme sichtbar werden. - Alarmierung Benachrichtigungsregeln, die melden, wenn eine Metrik einen Schwellenwert reißt oder sich verschlechtert, bevor Kunden sich beschweren. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/data-residency/ Datenschutz & EU # Datenresidenz Wo deine Daten physisch liegen und unter wessen Rechtsprechung sie fallen. Bei fastmon: Deutschland, durchgängig. Datenresidenz zählt, weil der Ort entscheidet, welche Gesetze gelten. Daten bei US-Anbietern können unter Regimen wie dem CLOUD Act erreichbar sein, selbst wenn die Server in Europa stehen. fastmon wird zu 100 Prozent in Deutschland bei Hetzner gehostet, ohne US-Anbieter im Datenpfad, sodass deine Monitoring-Daten von der Erhebung bis zur Speicherung unter EU-Rechtsprechung bleiben. Mehr erfahren Verwandte Begriffe - Cookiefrei Messen, ohne etwas auf dem Gerät des Besuchers zu speichern: keine Cookies, kein localStorage. - Edge-IP-Verarbeitung Die IP-Adresse des Besuchers wird am Edge auf einen Country-Code reduziert und verworfen, bevor Anwendungscode sie sieht. - GDPR DSGVO Die EU-Datenschutz-Grundverordnung, die rechtliche Grundlinie für den Umgang mit personenbezogenen Daten in Europa. - TDDDG (Paragraf 25) Das deutsche Gesetz, das die ePrivacy-Regel umsetzt, wonach Lesen von oder Schreiben auf einem Gerät Einwilligung braucht. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/edge-ip/ Datenschutz & EU # Edge-IP-Verarbeitung Die IP-Adresse des Besuchers wird am Edge auf einen Country-Code reduziert und verworfen, bevor Anwendungscode sie sieht. Eine IP-Adresse ist personenbezogenes Datum. Statt sie zu loggen und später zu anonymisieren, leitet fastmon am Edge-Server nur einen groben Country-Code ab und verwirft die Roh-IP sofort, sodass sie nie Speicher oder Anwendungslogik erreicht. Das ist Datenminimierung by Design: Du bekommst weiterhin geografische Auswertungen, aber es gibt keine Roh-IP, die geleakt, angefordert oder missbraucht werden könnte, weil sie nie aufbewahrt wurde. Mehr erfahren Verwandte Begriffe - Cookiefrei Messen, ohne etwas auf dem Gerät des Besuchers zu speichern: keine Cookies, kein localStorage. - GDPR DSGVO Die EU-Datenschutz-Grundverordnung, die rechtliche Grundlinie für den Umgang mit personenbezogenen Daten in Europa. - TDDDG (Paragraf 25) Das deutsche Gesetz, das die ePrivacy-Regel umsetzt, wonach Lesen von oder Schreiben auf einem Gerät Einwilligung braucht. - Datenresidenz Wo deine Daten physisch liegen und unter wessen Rechtsprechung sie fallen. Bei fastmon: Deutschland, durchgängig. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/error-tracking/ Methoden # Error Tracking Erfassen von JavaScript-Fehlern und fehlgeschlagenen Requests aus echten Sitzungen, gruppiert, sodass die echten Probleme sichtbar werden. Eine Seite kann perfekte Vitals erreichen und für ein Nutzersegment trotzdem kaputt sein, weil ein Skript wirft. Error Tracking erfasst diese Fehler aus dem Browser, mit genug Kontext (Seite, Browser, Ablauf), um sie zu reproduzieren. Ähnliche Fehler werden zu einem Fingerprint zusammengefasst, sodass tausend Vorkommen desselben Bugs als ein einzelnes, priorisiertes Problem erscheinen statt als Rauschen. Verwandte Begriffe - RUM Real User Monitoring Performance aus den Browsern deiner echten Besucher messen, auf ihren realen Geräten und Netzwerken. - Synthetic Monitoring Geplante, wiederholbare Tests, die eine Seite in kontrollierter Umgebung in festem Intervall laden. - Labordaten vs Felddaten Labordaten stammen aus einem kontrollierten Test, Felddaten von echten Besuchern. Beides zählt, aus verschiedenen Gründen. - Lighthouse Googles Open-Source-Tool, das eine Seite in einem Labordurchlauf prüft und Performance, Barrierefreiheit, SEO und mehr bewertet. - CrUX Chrome UX Report Googles öffentlicher Datensatz realer Core Web Vitals, aggregiert aus zustimmenden Chrome-Nutzern. - p75 Perzentil (p75) Der Wert, unter den ein bestimmter Anteil der Besuche fällt. p75 heißt, 75 Prozent waren mindestens so schnell. - Web Vitals Attribution Die zusätzlichen Diagnosedaten, die erklären, warum eine Metrik langsam war, nicht nur wie langsam. - Web-Analytics Messung von Traffic und Verhalten: Seitenaufrufe, Besucher, Referrer und Journeys, gemeinsam mit Performance. - Alarmierung Benachrichtigungsregeln, die melden, wenn eine Metrik einen Schwellenwert reißt oder sich verschlechtert, bevor Kunden sich beschweren. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/experience-score/ Metriken # Experience Score Eine einzelne Zahl von 0 bis 10, die fastmon aus LCP, INP, CLS, FCP, TTFB, Ladezeit und Fehlerrate bildet. Einzelne Metriken sind präzise, aber über viele Seiten hinweg schwer auf einen Blick zu verfolgen. Der Experience Score fasst sie zu einer Zahl zusammen, sodass ein Team die Gesundheit einer Seite, eines Segments oder einer ganzen Site auf einmal sieht und bei einem Einbruch gezielt tiefer geht. Er ersetzt nie die zugrunde liegenden Vitals: Er zeigt, wo man hinschauen sollte, und die Metrik-Karten sagen, warum. Zur Dokumentation Verwandte Begriffe - CWV Core Web Vitals Googles Satz aus drei Feld-Metriken für Ladezeit (LCP), Interaktivität (INP) und visuelle Stabilität (CLS) einer Seite. - LCP Largest Contentful Paint Die Zeit, bis das größte sichtbare Element im Viewport (Bild, Video oder Textblock) gerendert ist. - INP Interaction to Next Paint Wie lange die Seite braucht, um nach einer Nutzerinteraktion sichtbar zu reagieren, gemessen über den gesamten Besuch. - CLS Cumulative Layout Shift Ein einheitenloser Wert dafür, wie stark sich sichtbarer Inhalt unerwartet verschiebt, während die Seite lädt und läuft. - FCP First Contentful Paint Der Moment, in dem der Browser den ersten Inhalt rendert: Text, ein Bild oder ein Canvas. - TTFB Time to First Byte Die Zeit vom Start der Navigation bis der Browser das erste Byte der Antwort empfängt. - FID First Input Delay (abgelöst) Die Verzögerung zwischen der ersten Interaktion eines Besuchers und dem Beginn ihrer Verarbeitung durch den Browser. Durch INP ersetzt. - TBT Total Blocking Time Die Gesamtzeit, in der der Main-Thread zwischen erstem Paint und Interaktivität von langen Tasks blockiert war, im Labor gemessen. - SI Speed Index Eine Labor-Metrik dafür, wie schnell sich die sichtbaren Teile einer Seite während des Ladens füllen, basierend auf Videoaufnahme. - TTI Time to Interactive (veraltet) Eine Labor-Metrik dafür, wann eine Seite gerendert ist und zuverlässig schnell auf Eingaben reagieren kann. - Page Load Das klassische Load-Event: alles auf der Erstseite, inklusive Bilder und Subressourcen, ist fertig geladen. - Route Load Die Ladezeit einer In-App-Navigation in einer Single-Page-App, bei der kein voller Seiten-Reload passiert. - Long Tasks & LoAF Jedes Stück JavaScript, das den Main-Thread länger als 50 ms belegt und die Seite am Reagieren hindert. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/fcp/ Metriken FCP # First Contentful Paint Der Moment, in dem der Browser den ersten Inhalt rendert: Text, ein Bild oder ein Canvas. Gut <= 1.8 s Ausbaufähig 1.8 to 3 s Schlecht > 3 s Felddaten (75. Perzentil) FCP markiert den Übergang vom leeren Bildschirm zum ersten sichtbaren Zeichen, dass die Seite lädt. Es ist selbst kein Core Web Vital, aber ein starker Frühindikator und ein häufiges Diagnosemittel für einen langsamen LCP. Ein schneller FCP signalisiert Besuchern, dass etwas passiert. Ist FCP langsam, liegt die Ursache fast immer davor: Serverzeit, DNS, Weiterleitungen oder render-blockierende Ressourcen. Was es beeinflusst - Hoher TTFB und langsame erste Serverantwort. - Render-blockierende Stylesheets und synchrone Skripte. - Langsame Font-Auslieferung, die Text bis zur Ankunft verbirgt. Verwandte Begriffe - CWV Core Web Vitals Googles Satz aus drei Feld-Metriken für Ladezeit (LCP), Interaktivität (INP) und visuelle Stabilität (CLS) einer Seite. - LCP Largest Contentful Paint Die Zeit, bis das größte sichtbare Element im Viewport (Bild, Video oder Textblock) gerendert ist. - INP Interaction to Next Paint Wie lange die Seite braucht, um nach einer Nutzerinteraktion sichtbar zu reagieren, gemessen über den gesamten Besuch. - CLS Cumulative Layout Shift Ein einheitenloser Wert dafür, wie stark sich sichtbarer Inhalt unerwartet verschiebt, während die Seite lädt und läuft. - TTFB Time to First Byte Die Zeit vom Start der Navigation bis der Browser das erste Byte der Antwort empfängt. - FID First Input Delay (abgelöst) Die Verzögerung zwischen der ersten Interaktion eines Besuchers und dem Beginn ihrer Verarbeitung durch den Browser. Durch INP ersetzt. - TBT Total Blocking Time Die Gesamtzeit, in der der Main-Thread zwischen erstem Paint und Interaktivität von langen Tasks blockiert war, im Labor gemessen. - SI Speed Index Eine Labor-Metrik dafür, wie schnell sich die sichtbaren Teile einer Seite während des Ladens füllen, basierend auf Videoaufnahme. - TTI Time to Interactive (veraltet) Eine Labor-Metrik dafür, wann eine Seite gerendert ist und zuverlässig schnell auf Eingaben reagieren kann. - Page Load Das klassische Load-Event: alles auf der Erstseite, inklusive Bilder und Subressourcen, ist fertig geladen. - Route Load Die Ladezeit einer In-App-Navigation in einer Single-Page-App, bei der kein voller Seiten-Reload passiert. - Long Tasks & LoAF Jedes Stück JavaScript, das den Main-Thread länger als 50 ms belegt und die Seite am Reagieren hindert. - Experience Score Eine einzelne Zahl von 0 bis 10, die fastmon aus LCP, INP, CLS, FCP, TTFB, Ladezeit und Fehlerrate bildet. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/fid/ Metriken FID # First Input Delay (abgelöst) Die Verzögerung zwischen der ersten Interaktion eines Besuchers und dem Beginn ihrer Verarbeitung durch den Browser. Durch INP ersetzt. Gut <= 100 ms Ausbaufähig 100 to 300 ms Schlecht > 300 ms Felddaten (75. Perzentil) FID war das ursprüngliche Reaktions-Core-Web-Vital. Es mass nur die Eingabeverzögerung der allerersten Interaktion, und nur diese Verzögerung, nicht die folgende Arbeit oder das Rendering, sodass eine Seite einen guten FID erreichen und sich trotzdem träge anfühlen konnte. Google hat FID am 12. März 2024 zugunsten von INP abgelöst, das die komplette Interaktion über den gesamten Besuch misst. FID steht hier zur Einordnung: In älteren Reports und Tools kann es noch auftauchen. Verwandte Begriffe - CWV Core Web Vitals Googles Satz aus drei Feld-Metriken für Ladezeit (LCP), Interaktivität (INP) und visuelle Stabilität (CLS) einer Seite. - LCP Largest Contentful Paint Die Zeit, bis das größte sichtbare Element im Viewport (Bild, Video oder Textblock) gerendert ist. - INP Interaction to Next Paint Wie lange die Seite braucht, um nach einer Nutzerinteraktion sichtbar zu reagieren, gemessen über den gesamten Besuch. - CLS Cumulative Layout Shift Ein einheitenloser Wert dafür, wie stark sich sichtbarer Inhalt unerwartet verschiebt, während die Seite lädt und läuft. - FCP First Contentful Paint Der Moment, in dem der Browser den ersten Inhalt rendert: Text, ein Bild oder ein Canvas. - TTFB Time to First Byte Die Zeit vom Start der Navigation bis der Browser das erste Byte der Antwort empfängt. - TBT Total Blocking Time Die Gesamtzeit, in der der Main-Thread zwischen erstem Paint und Interaktivität von langen Tasks blockiert war, im Labor gemessen. - SI Speed Index Eine Labor-Metrik dafür, wie schnell sich die sichtbaren Teile einer Seite während des Ladens füllen, basierend auf Videoaufnahme. - TTI Time to Interactive (veraltet) Eine Labor-Metrik dafür, wann eine Seite gerendert ist und zuverlässig schnell auf Eingaben reagieren kann. - Page Load Das klassische Load-Event: alles auf der Erstseite, inklusive Bilder und Subressourcen, ist fertig geladen. - Route Load Die Ladezeit einer In-App-Navigation in einer Single-Page-App, bei der kein voller Seiten-Reload passiert. - Long Tasks & LoAF Jedes Stück JavaScript, das den Main-Thread länger als 50 ms belegt und die Seite am Reagieren hindert. - Experience Score Eine einzelne Zahl von 0 bis 10, die fastmon aus LCP, INP, CLS, FCP, TTFB, Ladezeit und Fehlerrate bildet. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/gdpr/ Datenschutz & EU GDPR # DSGVO Die EU-Datenschutz-Grundverordnung, die rechtliche Grundlinie für den Umgang mit personenbezogenen Daten in Europa. Die DSGVO regelt, wie personenbezogene Daten (inklusive IP-Adressen und Identifier) erhoben, verarbeitet und gespeichert werden dürfen, und gewährt Menschen Rechte an ihren Daten. Analytics-Tools müssen rechtfertigen, was sie erheben und auf welcher Rechtsgrundlage. fastmon ist in der DSGVO gebaut statt nachträglich angepasst: minimale Daten, keine Roh-IP-Speicherung, keine Cross-Site-Profile und Verarbeitung ausschließlich in der EU, was die Compliance-Fläche by Design klein hält. Mehr erfahren Verwandte Begriffe - Cookiefrei Messen, ohne etwas auf dem Gerät des Besuchers zu speichern: keine Cookies, kein localStorage. - Edge-IP-Verarbeitung Die IP-Adresse des Besuchers wird am Edge auf einen Country-Code reduziert und verworfen, bevor Anwendungscode sie sieht. - TDDDG (Paragraf 25) Das deutsche Gesetz, das die ePrivacy-Regel umsetzt, wonach Lesen von oder Schreiben auf einem Gerät Einwilligung braucht. - Datenresidenz Wo deine Daten physisch liegen und unter wessen Rechtsprechung sie fallen. Bei fastmon: Deutschland, durchgängig. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/inp/ Metriken INP # Interaction to Next Paint Wie lange die Seite braucht, um nach einer Nutzerinteraktion sichtbar zu reagieren, gemessen über den gesamten Besuch. Gut <= 200 ms Ausbaufähig 200 to 500 ms Schlecht > 500 ms Felddaten (75. Perzentil) INP ist das Reaktions-Core-Web-Vital. Es beobachtet jeden Klick, Tap und Tastendruck während eines Besuchs, misst die Verzögerung bis zum nächsten gezeichneten Frame und meldet nahezu den schlechtesten Wert. Ein niedriger INP bedeutet, die Oberfläche fühlt sich sofort an. INP hat First Input Delay im März 2024 abgelöst. Anders als FID, das nur die Eingabeverzögerung der ersten Interaktion betrachtete, deckt INP die komplette Interaktion inklusive Event-Verarbeitung und Rendering ab und bildet echte Trägheit deutlich besser ab. Was es beeinflusst - Lange JavaScript-Tasks, die den Main-Thread während der Interaktion blockieren. - Schwere Event-Handler, die vor dem nächsten Paint viel Arbeit erledigen. - Große DOM-Updates oder Layout-Thrashing durch eine Interaktion. - Third-Party-Skripte, die um den Main-Thread konkurrieren. Mehr erfahren Verwandte Begriffe - CWV Core Web Vitals Googles Satz aus drei Feld-Metriken für Ladezeit (LCP), Interaktivität (INP) und visuelle Stabilität (CLS) einer Seite. - LCP Largest Contentful Paint Die Zeit, bis das größte sichtbare Element im Viewport (Bild, Video oder Textblock) gerendert ist. - CLS Cumulative Layout Shift Ein einheitenloser Wert dafür, wie stark sich sichtbarer Inhalt unerwartet verschiebt, während die Seite lädt und läuft. - FCP First Contentful Paint Der Moment, in dem der Browser den ersten Inhalt rendert: Text, ein Bild oder ein Canvas. - TTFB Time to First Byte Die Zeit vom Start der Navigation bis der Browser das erste Byte der Antwort empfängt. - FID First Input Delay (abgelöst) Die Verzögerung zwischen der ersten Interaktion eines Besuchers und dem Beginn ihrer Verarbeitung durch den Browser. Durch INP ersetzt. - TBT Total Blocking Time Die Gesamtzeit, in der der Main-Thread zwischen erstem Paint und Interaktivität von langen Tasks blockiert war, im Labor gemessen. - SI Speed Index Eine Labor-Metrik dafür, wie schnell sich die sichtbaren Teile einer Seite während des Ladens füllen, basierend auf Videoaufnahme. - TTI Time to Interactive (veraltet) Eine Labor-Metrik dafür, wann eine Seite gerendert ist und zuverlässig schnell auf Eingaben reagieren kann. - Page Load Das klassische Load-Event: alles auf der Erstseite, inklusive Bilder und Subressourcen, ist fertig geladen. - Route Load Die Ladezeit einer In-App-Navigation in einer Single-Page-App, bei der kein voller Seiten-Reload passiert. - Long Tasks & LoAF Jedes Stück JavaScript, das den Main-Thread länger als 50 ms belegt und die Seite am Reagieren hindert. - Experience Score Eine einzelne Zahl von 0 bis 10, die fastmon aus LCP, INP, CLS, FCP, TTFB, Ladezeit und Fehlerrate bildet. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/lab-vs-field/ Methoden # Labordaten vs Felddaten Labordaten stammen aus einem kontrollierten Test, Felddaten von echten Besuchern. Beides zählt, aus verschiedenen Gründen. Labordaten sind reproduzierbar: gleiches Gerät, gleiches Netzwerk, gleiche Schritte, perfekt für Debugging und CI. Aber eine Maschine kann nicht jeden Besucher abbilden, daher kann es rosig aussehen, während echte Nutzer kämpfen. Felddaten sind unordentlich und ehrlich: Sie erfassen die volle Bandbreite an Geräten und Verbindungen. Core Web Vitals werden offiziell auf Felddaten bewertet. Der gesündeste Workflow nutzt Labordaten gegen Regressionen und Felddaten, um das reale Ergebnis zu bestätigen. Verwandte Begriffe - RUM Real User Monitoring Performance aus den Browsern deiner echten Besucher messen, auf ihren realen Geräten und Netzwerken. - Synthetic Monitoring Geplante, wiederholbare Tests, die eine Seite in kontrollierter Umgebung in festem Intervall laden. - Lighthouse Googles Open-Source-Tool, das eine Seite in einem Labordurchlauf prüft und Performance, Barrierefreiheit, SEO und mehr bewertet. - CrUX Chrome UX Report Googles öffentlicher Datensatz realer Core Web Vitals, aggregiert aus zustimmenden Chrome-Nutzern. - p75 Perzentil (p75) Der Wert, unter den ein bestimmter Anteil der Besuche fällt. p75 heißt, 75 Prozent waren mindestens so schnell. - Web Vitals Attribution Die zusätzlichen Diagnosedaten, die erklären, warum eine Metrik langsam war, nicht nur wie langsam. - Web-Analytics Messung von Traffic und Verhalten: Seitenaufrufe, Besucher, Referrer und Journeys, gemeinsam mit Performance. - Error Tracking Erfassen von JavaScript-Fehlern und fehlgeschlagenen Requests aus echten Sitzungen, gruppiert, sodass die echten Probleme sichtbar werden. - Alarmierung Benachrichtigungsregeln, die melden, wenn eine Metrik einen Schwellenwert reißt oder sich verschlechtert, bevor Kunden sich beschweren. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/lcp/ Metriken LCP # Largest Contentful Paint Die Zeit, bis das größte sichtbare Element im Viewport (Bild, Video oder Textblock) gerendert ist. Gut <= 2.5 s Ausbaufähig 2.5 to 4 s Schlecht > 4 s Felddaten (75. Perzentil) LCP ist das Lade-Core-Web-Vital. Es beantwortet die Frage, die Besucher am meisten interessiert: Wann sieht die Seite fertig aus? Die Uhr startet mit der Navigation und stoppt, sobald das größte Element oberhalb der Falz gezeichnet ist. Weil das größte Element meist ein Hero-Bild oder eine Überschrift ist, wird LCP davon bestimmt, wie schnell der Server antwortet und wie schnell diese eine Ressource geliefert und dekodiert werden kann. Was es beeinflusst - Langsame Serverantwort (hoher TTFB) verzögert alles Nachfolgende. - Große oder unoptimierte Hero-Bilder, oder Bilder ohne Priority-Hint. - Render-blockierendes CSS und JavaScript im Dokumentenkopf. - Client-seitiges Rendering, das den Hauptinhalt spät zeichnet. Mehr erfahren Verwandte Begriffe - CWV Core Web Vitals Googles Satz aus drei Feld-Metriken für Ladezeit (LCP), Interaktivität (INP) und visuelle Stabilität (CLS) einer Seite. - INP Interaction to Next Paint Wie lange die Seite braucht, um nach einer Nutzerinteraktion sichtbar zu reagieren, gemessen über den gesamten Besuch. - CLS Cumulative Layout Shift Ein einheitenloser Wert dafür, wie stark sich sichtbarer Inhalt unerwartet verschiebt, während die Seite lädt und läuft. - FCP First Contentful Paint Der Moment, in dem der Browser den ersten Inhalt rendert: Text, ein Bild oder ein Canvas. - TTFB Time to First Byte Die Zeit vom Start der Navigation bis der Browser das erste Byte der Antwort empfängt. - FID First Input Delay (abgelöst) Die Verzögerung zwischen der ersten Interaktion eines Besuchers und dem Beginn ihrer Verarbeitung durch den Browser. Durch INP ersetzt. - TBT Total Blocking Time Die Gesamtzeit, in der der Main-Thread zwischen erstem Paint und Interaktivität von langen Tasks blockiert war, im Labor gemessen. - SI Speed Index Eine Labor-Metrik dafür, wie schnell sich die sichtbaren Teile einer Seite während des Ladens füllen, basierend auf Videoaufnahme. - TTI Time to Interactive (veraltet) Eine Labor-Metrik dafür, wann eine Seite gerendert ist und zuverlässig schnell auf Eingaben reagieren kann. - Page Load Das klassische Load-Event: alles auf der Erstseite, inklusive Bilder und Subressourcen, ist fertig geladen. - Route Load Die Ladezeit einer In-App-Navigation in einer Single-Page-App, bei der kein voller Seiten-Reload passiert. - Long Tasks & LoAF Jedes Stück JavaScript, das den Main-Thread länger als 50 ms belegt und die Seite am Reagieren hindert. - Experience Score Eine einzelne Zahl von 0 bis 10, die fastmon aus LCP, INP, CLS, FCP, TTFB, Ladezeit und Fehlerrate bildet. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/lighthouse/ Methoden # Lighthouse Googles Open-Source-Tool, das eine Seite in einem Labordurchlauf prüft und Performance, Barrierefreiheit, SEO und mehr bewertet. Lighthouse lädt eine Seite unter simulierten Bedingungen und erzeugt aus Labor-Metriken wie FCP, LCP, TBT, CLS und Speed Index einen Performance-Score von 0 bis 100, plus konkrete Empfehlungen. Es treibt die Laborseite von PageSpeed Insights an. Die synthetischen Checks von fastmon führen Lighthouse nach Zeitplan aus, sodass die Diagnostik kontinuierlich vorliegt und nicht nur, wenn zufällig jemand ein Audit startet. Verwandte Begriffe - RUM Real User Monitoring Performance aus den Browsern deiner echten Besucher messen, auf ihren realen Geräten und Netzwerken. - Synthetic Monitoring Geplante, wiederholbare Tests, die eine Seite in kontrollierter Umgebung in festem Intervall laden. - Labordaten vs Felddaten Labordaten stammen aus einem kontrollierten Test, Felddaten von echten Besuchern. Beides zählt, aus verschiedenen Gründen. - CrUX Chrome UX Report Googles öffentlicher Datensatz realer Core Web Vitals, aggregiert aus zustimmenden Chrome-Nutzern. - p75 Perzentil (p75) Der Wert, unter den ein bestimmter Anteil der Besuche fällt. p75 heißt, 75 Prozent waren mindestens so schnell. - Web Vitals Attribution Die zusätzlichen Diagnosedaten, die erklären, warum eine Metrik langsam war, nicht nur wie langsam. - Web-Analytics Messung von Traffic und Verhalten: Seitenaufrufe, Besucher, Referrer und Journeys, gemeinsam mit Performance. - Error Tracking Erfassen von JavaScript-Fehlern und fehlgeschlagenen Requests aus echten Sitzungen, gruppiert, sodass die echten Probleme sichtbar werden. - Alarmierung Benachrichtigungsregeln, die melden, wenn eine Metrik einen Schwellenwert reißt oder sich verschlechtert, bevor Kunden sich beschweren. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/long-tasks/ Metriken # Long Tasks & LoAF Jedes Stück JavaScript, das den Main-Thread länger als 50 ms belegt und die Seite am Reagieren hindert. Während eine lange Task läuft, kann der Browser keine Klicks, Scrolls oder Paints verarbeiten, was Besucher genau als Ruckeln wahrnehmen. Long Animation Frames (LoAF) ist die neuere API, die weiter geht und einen langsamen Frame dem verantwortlichen Skript und sogar der Quellzeile zuordnet. Long Tasks sind das Rohmaterial hinter einem schlechten INP oder TBT. Sie zu finden und aufzubrechen, oder Arbeit vom Main-Thread zu verlagern, ist der direkteste Weg zu einer schnell wirkenden Oberfläche. Verwandte Begriffe - CWV Core Web Vitals Googles Satz aus drei Feld-Metriken für Ladezeit (LCP), Interaktivität (INP) und visuelle Stabilität (CLS) einer Seite. - LCP Largest Contentful Paint Die Zeit, bis das größte sichtbare Element im Viewport (Bild, Video oder Textblock) gerendert ist. - INP Interaction to Next Paint Wie lange die Seite braucht, um nach einer Nutzerinteraktion sichtbar zu reagieren, gemessen über den gesamten Besuch. - CLS Cumulative Layout Shift Ein einheitenloser Wert dafür, wie stark sich sichtbarer Inhalt unerwartet verschiebt, während die Seite lädt und läuft. - FCP First Contentful Paint Der Moment, in dem der Browser den ersten Inhalt rendert: Text, ein Bild oder ein Canvas. - TTFB Time to First Byte Die Zeit vom Start der Navigation bis der Browser das erste Byte der Antwort empfängt. - FID First Input Delay (abgelöst) Die Verzögerung zwischen der ersten Interaktion eines Besuchers und dem Beginn ihrer Verarbeitung durch den Browser. Durch INP ersetzt. - TBT Total Blocking Time Die Gesamtzeit, in der der Main-Thread zwischen erstem Paint und Interaktivität von langen Tasks blockiert war, im Labor gemessen. - SI Speed Index Eine Labor-Metrik dafür, wie schnell sich die sichtbaren Teile einer Seite während des Ladens füllen, basierend auf Videoaufnahme. - TTI Time to Interactive (veraltet) Eine Labor-Metrik dafür, wann eine Seite gerendert ist und zuverlässig schnell auf Eingaben reagieren kann. - Page Load Das klassische Load-Event: alles auf der Erstseite, inklusive Bilder und Subressourcen, ist fertig geladen. - Route Load Die Ladezeit einer In-App-Navigation in einer Single-Page-App, bei der kein voller Seiten-Reload passiert. - Experience Score Eine einzelne Zahl von 0 bis 10, die fastmon aus LCP, INP, CLS, FCP, TTFB, Ladezeit und Fehlerrate bildet. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/page-load/ Metriken # Page Load Das klassische Load-Event: alles auf der Erstseite, inklusive Bilder und Subressourcen, ist fertig geladen. Page Load (das window-Load-Event) ist der älteste Performance-Meilenstein. Er ist leicht verständlich und als grobes Signal weiterhin nützlich, sagt aber nichts darüber, wann die Seite nutzbar aussah oder sich so anfühlte, weshalb es die Core Web Vitals gibt. fastmon erfasst ihn neben den Vitals, sodass die vertraute Zahl bleibt, während die Metriken sichtbar werden, die Erfahrung wirklich abbilden. Verwandte Begriffe - CWV Core Web Vitals Googles Satz aus drei Feld-Metriken für Ladezeit (LCP), Interaktivität (INP) und visuelle Stabilität (CLS) einer Seite. - LCP Largest Contentful Paint Die Zeit, bis das größte sichtbare Element im Viewport (Bild, Video oder Textblock) gerendert ist. - INP Interaction to Next Paint Wie lange die Seite braucht, um nach einer Nutzerinteraktion sichtbar zu reagieren, gemessen über den gesamten Besuch. - CLS Cumulative Layout Shift Ein einheitenloser Wert dafür, wie stark sich sichtbarer Inhalt unerwartet verschiebt, während die Seite lädt und läuft. - FCP First Contentful Paint Der Moment, in dem der Browser den ersten Inhalt rendert: Text, ein Bild oder ein Canvas. - TTFB Time to First Byte Die Zeit vom Start der Navigation bis der Browser das erste Byte der Antwort empfängt. - FID First Input Delay (abgelöst) Die Verzögerung zwischen der ersten Interaktion eines Besuchers und dem Beginn ihrer Verarbeitung durch den Browser. Durch INP ersetzt. - TBT Total Blocking Time Die Gesamtzeit, in der der Main-Thread zwischen erstem Paint und Interaktivität von langen Tasks blockiert war, im Labor gemessen. - SI Speed Index Eine Labor-Metrik dafür, wie schnell sich die sichtbaren Teile einer Seite während des Ladens füllen, basierend auf Videoaufnahme. - TTI Time to Interactive (veraltet) Eine Labor-Metrik dafür, wann eine Seite gerendert ist und zuverlässig schnell auf Eingaben reagieren kann. - Route Load Die Ladezeit einer In-App-Navigation in einer Single-Page-App, bei der kein voller Seiten-Reload passiert. - Long Tasks & LoAF Jedes Stück JavaScript, das den Main-Thread länger als 50 ms belegt und die Seite am Reagieren hindert. - Experience Score Eine einzelne Zahl von 0 bis 10, die fastmon aus LCP, INP, CLS, FCP, TTFB, Ladezeit und Fehlerrate bildet. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/pageview/ Bausteine # Pageview Ein einzelner Seitenaufruf oder, in einer Single-Page-App, ein Route-Wechsel, der als eigener Aufruf zählt. Der Pageview ist die atomare Einheit der Analyse. Jeder trägt seine Metriken, Timings und seinen Kontext, und viele zusammen ergeben eine Session und die Traffic-Summen. fastmon zählt auch Soft-Navigationen in Single-Page-Apps als Pageviews, sodass SPA-Traffic nicht unterzählt wird wie bei Tools, die nur volle Dokument-Ladevorgänge sehen. Verwandte Begriffe - Beacon Das kleine Datenpaket, das der Tracker mit den Messwerten eines Besuchs an fastmon sendet. - Tracker Das leichtgewichtige Skript, das du einmal einbindest; es misst Core Web Vitals und Fehler direkt im Browser. - Stitch fastmons kurzlebiger, am Edge abgeleiteter Identifier, der einen Besuch ohne Cookies oder Cross-Site-Tracking gruppiert. - Session Ein zusammenhängender Besuch: die Abfolge von Seitenaufrufen und Interaktionen, bevor ein Besucher inaktiv wird. - Collection Modes Voreinstellungen (Light, Standard, Full), die festlegen, wie viel Detail der Tracker erfasst. - Server-Timing Ein HTTP-Header, den dein Backend senden kann, um aufzuschlüsseln, wo Serverzeit verbraucht wurde, sichtbar im RUM. - Cache-Status Ob eine Antwort von einem CDN-Edge, dem Origin-Server oder dem Browser-Cache kam. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/percentile-p75/ Methoden p75 # Perzentil (p75) Der Wert, unter den ein bestimmter Anteil der Besuche fällt. p75 heißt, 75 Prozent waren mindestens so schnell. Durchschnitte verbergen Schmerz: Eine Handvoll sehr langsamer Sitzungen kann von vielen schnellen überdeckt werden. Perzentile beschreiben stattdessen die Verteilung. Das 75. Perzentil ist die Schwelle der Core Web Vitals, damit drei von vier Besuchen repräsentiert sind und das schlechteste Viertel nicht wegdurchschnittet wird. p75 zu beobachten (und p90 oder p95 für den Long Tail) zeigt, was die meisten Menschen erleben und wie schlimm es für die Unglücklichen wird, was ein Durchschnitt nie verrät. Verwandte Begriffe - RUM Real User Monitoring Performance aus den Browsern deiner echten Besucher messen, auf ihren realen Geräten und Netzwerken. - Synthetic Monitoring Geplante, wiederholbare Tests, die eine Seite in kontrollierter Umgebung in festem Intervall laden. - Labordaten vs Felddaten Labordaten stammen aus einem kontrollierten Test, Felddaten von echten Besuchern. Beides zählt, aus verschiedenen Gründen. - Lighthouse Googles Open-Source-Tool, das eine Seite in einem Labordurchlauf prüft und Performance, Barrierefreiheit, SEO und mehr bewertet. - CrUX Chrome UX Report Googles öffentlicher Datensatz realer Core Web Vitals, aggregiert aus zustimmenden Chrome-Nutzern. - Web Vitals Attribution Die zusätzlichen Diagnosedaten, die erklären, warum eine Metrik langsam war, nicht nur wie langsam. - Web-Analytics Messung von Traffic und Verhalten: Seitenaufrufe, Besucher, Referrer und Journeys, gemeinsam mit Performance. - Error Tracking Erfassen von JavaScript-Fehlern und fehlgeschlagenen Requests aus echten Sitzungen, gruppiert, sodass die echten Probleme sichtbar werden. - Alarmierung Benachrichtigungsregeln, die melden, wenn eine Metrik einen Schwellenwert reißt oder sich verschlechtert, bevor Kunden sich beschweren. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/route-load/ Metriken # Route Load Die Ladezeit einer In-App-Navigation in einer Single-Page-App, bei der kein voller Seiten-Reload passiert. In einer Single-Page-Application tauscht ein Klick den Inhalt client-seitig aus, statt ein frisches Dokument zu laden, sodass das klassische Load-Event nie wieder feuert. Route Load misst diese Soft-Navigationen: wie lange ein Ansichtswechsel vom Klick bis zum gezeichneten Inhalt dauert. Ohne das wirken SPAs künstlich schnell, weil nur der allererste Ladevorgang gemessen wird. fastmon erkennt Soft-Navigationen und misst jeden Route-Wechsel, sodass die Zahlen abbilden, worauf Besucher wirklich warten. Verwandte Begriffe - CWV Core Web Vitals Googles Satz aus drei Feld-Metriken für Ladezeit (LCP), Interaktivität (INP) und visuelle Stabilität (CLS) einer Seite. - LCP Largest Contentful Paint Die Zeit, bis das größte sichtbare Element im Viewport (Bild, Video oder Textblock) gerendert ist. - INP Interaction to Next Paint Wie lange die Seite braucht, um nach einer Nutzerinteraktion sichtbar zu reagieren, gemessen über den gesamten Besuch. - CLS Cumulative Layout Shift Ein einheitenloser Wert dafür, wie stark sich sichtbarer Inhalt unerwartet verschiebt, während die Seite lädt und läuft. - FCP First Contentful Paint Der Moment, in dem der Browser den ersten Inhalt rendert: Text, ein Bild oder ein Canvas. - TTFB Time to First Byte Die Zeit vom Start der Navigation bis der Browser das erste Byte der Antwort empfängt. - FID First Input Delay (abgelöst) Die Verzögerung zwischen der ersten Interaktion eines Besuchers und dem Beginn ihrer Verarbeitung durch den Browser. Durch INP ersetzt. - TBT Total Blocking Time Die Gesamtzeit, in der der Main-Thread zwischen erstem Paint und Interaktivität von langen Tasks blockiert war, im Labor gemessen. - SI Speed Index Eine Labor-Metrik dafür, wie schnell sich die sichtbaren Teile einer Seite während des Ladens füllen, basierend auf Videoaufnahme. - TTI Time to Interactive (veraltet) Eine Labor-Metrik dafür, wann eine Seite gerendert ist und zuverlässig schnell auf Eingaben reagieren kann. - Page Load Das klassische Load-Event: alles auf der Erstseite, inklusive Bilder und Subressourcen, ist fertig geladen. - Long Tasks & LoAF Jedes Stück JavaScript, das den Main-Thread länger als 50 ms belegt und die Seite am Reagieren hindert. - Experience Score Eine einzelne Zahl von 0 bis 10, die fastmon aus LCP, INP, CLS, FCP, TTFB, Ladezeit und Fehlerrate bildet. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/rum/ Methoden RUM # Real User Monitoring Performance aus den Browsern deiner echten Besucher messen, auf ihren realen Geräten und Netzwerken. RUM sammelt Metriken aus jeder echten Sitzung: den Smartphones, Laptops, Browsern und Verbindungen, die dein Publikum tatsächlich nutzt. Das sind Felddaten, und nur so weiß man, was Menschen wirklich erleben, inklusive des langsamen Long Tail, den Labortests verpassen. Es ist die Grundlage der Core-Web-Vitals-Bewertung. Das RUM von fastmon ist standardmäßig cookiefrei und entfernt IP-Adressen am Edge, sodass die Feld-Wahrheit ohne Besucherprofile entsteht. Mehr erfahren Verwandte Begriffe - Synthetic Monitoring Geplante, wiederholbare Tests, die eine Seite in kontrollierter Umgebung in festem Intervall laden. - Labordaten vs Felddaten Labordaten stammen aus einem kontrollierten Test, Felddaten von echten Besuchern. Beides zählt, aus verschiedenen Gründen. - Lighthouse Googles Open-Source-Tool, das eine Seite in einem Labordurchlauf prüft und Performance, Barrierefreiheit, SEO und mehr bewertet. - CrUX Chrome UX Report Googles öffentlicher Datensatz realer Core Web Vitals, aggregiert aus zustimmenden Chrome-Nutzern. - p75 Perzentil (p75) Der Wert, unter den ein bestimmter Anteil der Besuche fällt. p75 heißt, 75 Prozent waren mindestens so schnell. - Web Vitals Attribution Die zusätzlichen Diagnosedaten, die erklären, warum eine Metrik langsam war, nicht nur wie langsam. - Web-Analytics Messung von Traffic und Verhalten: Seitenaufrufe, Besucher, Referrer und Journeys, gemeinsam mit Performance. - Error Tracking Erfassen von JavaScript-Fehlern und fehlgeschlagenen Requests aus echten Sitzungen, gruppiert, sodass die echten Probleme sichtbar werden. - Alarmierung Benachrichtigungsregeln, die melden, wenn eine Metrik einen Schwellenwert reißt oder sich verschlechtert, bevor Kunden sich beschweren. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/server-timing/ Bausteine # Server-Timing Ein HTTP-Header, den dein Backend senden kann, um aufzuschlüsseln, wo Serverzeit verbraucht wurde, sichtbar im RUM. TTFB sagt, dass der Server langsam war, aber nicht warum. Mit dem Server-Timing-Header kann dein Backend seine eigenen Phasen melden (Datenbank, Cache, Rendering), und der Browser reicht sie an den Tracker weiter. Das verbindet einen langsamen Feld-TTFB mit genau dem verantwortlichen Backend-Schritt und schließt die Lücke zwischen Frontend-Symptom und Backend-Ursache. Verwandte Begriffe - Beacon Das kleine Datenpaket, das der Tracker mit den Messwerten eines Besuchs an fastmon sendet. - Tracker Das leichtgewichtige Skript, das du einmal einbindest; es misst Core Web Vitals und Fehler direkt im Browser. - Stitch fastmons kurzlebiger, am Edge abgeleiteter Identifier, der einen Besuch ohne Cookies oder Cross-Site-Tracking gruppiert. - Session Ein zusammenhängender Besuch: die Abfolge von Seitenaufrufen und Interaktionen, bevor ein Besucher inaktiv wird. - Pageview Ein einzelner Seitenaufruf oder, in einer Single-Page-App, ein Route-Wechsel, der als eigener Aufruf zählt. - Collection Modes Voreinstellungen (Light, Standard, Full), die festlegen, wie viel Detail der Tracker erfasst. - Cache-Status Ob eine Antwort von einem CDN-Edge, dem Origin-Server oder dem Browser-Cache kam. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/session/ Bausteine # Session Ein zusammenhängender Besuch: die Abfolge von Seitenaufrufen und Interaktionen, bevor ein Besucher inaktiv wird. Eine Session verbindet die Seiten, Timings und Fehler eines einzelnen Besuchs, sodass du einer Journey folgen kannst statt isolierten Treffern. Sie ist die Einheit hinter Metriken wie Seiten pro Session und der Frage, wo in einem Flow Menschen abspringen. In fastmon ist eine Session durch den kurzlebigen Stitch-Identifier begrenzt, sodass sie einen Besuch abbildet und kein dauerhaftes Profil wird. Verwandte Begriffe - Beacon Das kleine Datenpaket, das der Tracker mit den Messwerten eines Besuchs an fastmon sendet. - Tracker Das leichtgewichtige Skript, das du einmal einbindest; es misst Core Web Vitals und Fehler direkt im Browser. - Stitch fastmons kurzlebiger, am Edge abgeleiteter Identifier, der einen Besuch ohne Cookies oder Cross-Site-Tracking gruppiert. - Pageview Ein einzelner Seitenaufruf oder, in einer Single-Page-App, ein Route-Wechsel, der als eigener Aufruf zählt. - Collection Modes Voreinstellungen (Light, Standard, Full), die festlegen, wie viel Detail der Tracker erfasst. - Server-Timing Ein HTTP-Header, den dein Backend senden kann, um aufzuschlüsseln, wo Serverzeit verbraucht wurde, sichtbar im RUM. - Cache-Status Ob eine Antwort von einem CDN-Edge, dem Origin-Server oder dem Browser-Cache kam. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/speed-index/ Metriken SI # Speed Index Eine Labor-Metrik dafür, wie schnell sich die sichtbaren Teile einer Seite während des Ladens füllen, basierend auf Videoaufnahme. Gut <= 3.4 s Ausbaufähig 3.4 to 5.8 s Schlecht > 5.8 s Labordaten (Lighthouse) Speed Index nimmt den Lade-Filmstreifen auf und bewertet, wie schnell die Pixel oberhalb der Falz visuell vollständig werden. Zwei Seiten mit gleichem LCP können sehr unterschiedliche Speed-Index-Werte haben, wenn eine sich nach und nach füllt und die andere auf einen Schlag erscheint. Es ist eine Lighthouse-Labor-Metrik, nützlich um die gefühlte Ladegeschwindigkeit zwischen Builds zu vergleichen, wird aber nicht an echten Nutzern gemessen. Verwandte Begriffe - CWV Core Web Vitals Googles Satz aus drei Feld-Metriken für Ladezeit (LCP), Interaktivität (INP) und visuelle Stabilität (CLS) einer Seite. - LCP Largest Contentful Paint Die Zeit, bis das größte sichtbare Element im Viewport (Bild, Video oder Textblock) gerendert ist. - INP Interaction to Next Paint Wie lange die Seite braucht, um nach einer Nutzerinteraktion sichtbar zu reagieren, gemessen über den gesamten Besuch. - CLS Cumulative Layout Shift Ein einheitenloser Wert dafür, wie stark sich sichtbarer Inhalt unerwartet verschiebt, während die Seite lädt und läuft. - FCP First Contentful Paint Der Moment, in dem der Browser den ersten Inhalt rendert: Text, ein Bild oder ein Canvas. - TTFB Time to First Byte Die Zeit vom Start der Navigation bis der Browser das erste Byte der Antwort empfängt. - FID First Input Delay (abgelöst) Die Verzögerung zwischen der ersten Interaktion eines Besuchers und dem Beginn ihrer Verarbeitung durch den Browser. Durch INP ersetzt. - TBT Total Blocking Time Die Gesamtzeit, in der der Main-Thread zwischen erstem Paint und Interaktivität von langen Tasks blockiert war, im Labor gemessen. - TTI Time to Interactive (veraltet) Eine Labor-Metrik dafür, wann eine Seite gerendert ist und zuverlässig schnell auf Eingaben reagieren kann. - Page Load Das klassische Load-Event: alles auf der Erstseite, inklusive Bilder und Subressourcen, ist fertig geladen. - Route Load Die Ladezeit einer In-App-Navigation in einer Single-Page-App, bei der kein voller Seiten-Reload passiert. - Long Tasks & LoAF Jedes Stück JavaScript, das den Main-Thread länger als 50 ms belegt und die Seite am Reagieren hindert. - Experience Score Eine einzelne Zahl von 0 bis 10, die fastmon aus LCP, INP, CLS, FCP, TTFB, Ladezeit und Fehlerrate bildet. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/stitch/ Bausteine # Stitch fastmons kurzlebiger, am Edge abgeleiteter Identifier, der einen Besuch ohne Cookies oder Cross-Site-Tracking gruppiert. Um eindeutige Besucher zu zählen und die Seiten eines Besuchs zu verbinden, braucht es einen Identifier. Stitch wird am Edge abgeleitet und rotiert im 24-Stunden-Takt, sodass er eine Sitzung gruppieren, aber niemandem über Tage, Sites oder Geräte folgen kann. So vermeidet fastmon das Doppelzählen und die verwaisten Sitzungen rein cookiefreier Ansätze und setzt trotzdem keine Cookies und baut keine langlebigen Profile. Verwandte Begriffe - Beacon Das kleine Datenpaket, das der Tracker mit den Messwerten eines Besuchs an fastmon sendet. - Tracker Das leichtgewichtige Skript, das du einmal einbindest; es misst Core Web Vitals und Fehler direkt im Browser. - Session Ein zusammenhängender Besuch: die Abfolge von Seitenaufrufen und Interaktionen, bevor ein Besucher inaktiv wird. - Pageview Ein einzelner Seitenaufruf oder, in einer Single-Page-App, ein Route-Wechsel, der als eigener Aufruf zählt. - Collection Modes Voreinstellungen (Light, Standard, Full), die festlegen, wie viel Detail der Tracker erfasst. - Server-Timing Ein HTTP-Header, den dein Backend senden kann, um aufzuschlüsseln, wo Serverzeit verbraucht wurde, sichtbar im RUM. - Cache-Status Ob eine Antwort von einem CDN-Edge, dem Origin-Server oder dem Browser-Cache kam. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/synthetic/ Methoden # Synthetic Monitoring Geplante, wiederholbare Tests, die eine Seite in kontrollierter Umgebung in festem Intervall laden. Synthetic Monitoring schickt eine Seite nach Zeitplan durch ein Labor (bei fastmon geplante Lighthouse- und TTFB-Checks), jedes Mal vom gleichen Geräteprofil und Netzwerk. Weil die Bedingungen fix sind, sind Ergebnisse stabil und vergleichbar, ideal um Regressionen zu fangen und Seiten zu testen, bevor sie Traffic haben. Es ergänzt RUM, statt es zu ersetzen: Synthetic sagt, dass sich eine Seite verändert hat, RUM sagt, ob echte Nutzer es gespürt haben. Mehr erfahren Verwandte Begriffe - RUM Real User Monitoring Performance aus den Browsern deiner echten Besucher messen, auf ihren realen Geräten und Netzwerken. - Labordaten vs Felddaten Labordaten stammen aus einem kontrollierten Test, Felddaten von echten Besuchern. Beides zählt, aus verschiedenen Gründen. - Lighthouse Googles Open-Source-Tool, das eine Seite in einem Labordurchlauf prüft und Performance, Barrierefreiheit, SEO und mehr bewertet. - CrUX Chrome UX Report Googles öffentlicher Datensatz realer Core Web Vitals, aggregiert aus zustimmenden Chrome-Nutzern. - p75 Perzentil (p75) Der Wert, unter den ein bestimmter Anteil der Besuche fällt. p75 heißt, 75 Prozent waren mindestens so schnell. - Web Vitals Attribution Die zusätzlichen Diagnosedaten, die erklären, warum eine Metrik langsam war, nicht nur wie langsam. - Web-Analytics Messung von Traffic und Verhalten: Seitenaufrufe, Besucher, Referrer und Journeys, gemeinsam mit Performance. - Error Tracking Erfassen von JavaScript-Fehlern und fehlgeschlagenen Requests aus echten Sitzungen, gruppiert, sodass die echten Probleme sichtbar werden. - Alarmierung Benachrichtigungsregeln, die melden, wenn eine Metrik einen Schwellenwert reißt oder sich verschlechtert, bevor Kunden sich beschweren. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/tbt/ Metriken TBT # Total Blocking Time Die Gesamtzeit, in der der Main-Thread zwischen erstem Paint und Interaktivität von langen Tasks blockiert war, im Labor gemessen. Gut <= 200 ms Ausbaufähig 200 to 600 ms Schlecht > 600 ms Labordaten (Lighthouse) TBT ist eine Labor-Metrik und der nächste Labor-Stellvertreter für INP. Es summiert den blockierenden Anteil (alles über 50 ms) jeder langen Task nach dem FCP und zeigt, wie lange eine Seite Eingaben ignorieren würde, während Skripte laufen. Weil es in einem kontrollierten Labordurchlauf gemessen wird, ist TBT stabil und ideal, um Regressionen in der CI zu fangen, bevor sie echte Nutzer als schlechten INP treffen. Was es beeinflusst - Große JavaScript-Bundles, die beim Laden geparst und ausgeführt werden. - Teure Hydration in client-gerenderten Frameworks. - Third-Party-Tags, die schwere Arbeit auf dem Main-Thread erledigen. Verwandte Begriffe - CWV Core Web Vitals Googles Satz aus drei Feld-Metriken für Ladezeit (LCP), Interaktivität (INP) und visuelle Stabilität (CLS) einer Seite. - LCP Largest Contentful Paint Die Zeit, bis das größte sichtbare Element im Viewport (Bild, Video oder Textblock) gerendert ist. - INP Interaction to Next Paint Wie lange die Seite braucht, um nach einer Nutzerinteraktion sichtbar zu reagieren, gemessen über den gesamten Besuch. - CLS Cumulative Layout Shift Ein einheitenloser Wert dafür, wie stark sich sichtbarer Inhalt unerwartet verschiebt, während die Seite lädt und läuft. - FCP First Contentful Paint Der Moment, in dem der Browser den ersten Inhalt rendert: Text, ein Bild oder ein Canvas. - TTFB Time to First Byte Die Zeit vom Start der Navigation bis der Browser das erste Byte der Antwort empfängt. - FID First Input Delay (abgelöst) Die Verzögerung zwischen der ersten Interaktion eines Besuchers und dem Beginn ihrer Verarbeitung durch den Browser. Durch INP ersetzt. - SI Speed Index Eine Labor-Metrik dafür, wie schnell sich die sichtbaren Teile einer Seite während des Ladens füllen, basierend auf Videoaufnahme. - TTI Time to Interactive (veraltet) Eine Labor-Metrik dafür, wann eine Seite gerendert ist und zuverlässig schnell auf Eingaben reagieren kann. - Page Load Das klassische Load-Event: alles auf der Erstseite, inklusive Bilder und Subressourcen, ist fertig geladen. - Route Load Die Ladezeit einer In-App-Navigation in einer Single-Page-App, bei der kein voller Seiten-Reload passiert. - Long Tasks & LoAF Jedes Stück JavaScript, das den Main-Thread länger als 50 ms belegt und die Seite am Reagieren hindert. - Experience Score Eine einzelne Zahl von 0 bis 10, die fastmon aus LCP, INP, CLS, FCP, TTFB, Ladezeit und Fehlerrate bildet. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/tdddg/ Datenschutz & EU # TDDDG (Paragraf 25) Das deutsche Gesetz, das die ePrivacy-Regel umsetzt, wonach Lesen von oder Schreiben auf einem Gerät Einwilligung braucht. Paragraf 25 TDDDG (früher TTDSG) ist die deutsche Umsetzung der ePrivacy-Richtlinie. Er besagt, dass das Speichern von oder Zugreifen auf Informationen auf dem Gerät eines Nutzers grundsätzlich Einwilligung erfordert, unabhängig davon, ob diese Information personenbezogen ist. Deshalb kann selbst ein cookiefreies Tool Einwilligung brauchen: Das Lesen der Performance-APIs des Browsers ist ein Zugriff auf das Gerät. Der Website-Betreiber holt diese Einwilligung über seine Consent-Plattform ein, genau wie bei anderen Tools, wie in der Datenschutzerklärung von fastmon beschrieben. Verwandte Begriffe - Cookiefrei Messen, ohne etwas auf dem Gerät des Besuchers zu speichern: keine Cookies, kein localStorage. - Edge-IP-Verarbeitung Die IP-Adresse des Besuchers wird am Edge auf einen Country-Code reduziert und verworfen, bevor Anwendungscode sie sieht. - GDPR DSGVO Die EU-Datenschutz-Grundverordnung, die rechtliche Grundlinie für den Umgang mit personenbezogenen Daten in Europa. - Datenresidenz Wo deine Daten physisch liegen und unter wessen Rechtsprechung sie fallen. Bei fastmon: Deutschland, durchgängig. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/tracker/ Bausteine # Tracker Das leichtgewichtige Skript, das du einmal einbindest; es misst Core Web Vitals und Fehler direkt im Browser. Der Tracker ist das Snippet, das die Messung macht. Er hängt sich in Standard-Browser-APIs ein (Performance-API, PerformanceObserver, Error-Events) und ist auf dieselbe web-vitals-Library abgestimmt, die Google nutzt, sodass die Zahlen mit denen von Chrome vergleichbar sind. Er ist klein und lädt ohne das Rendering zu blockieren, sodass das Hinzufügen von Monitoring nicht selbst die Performance beschädigt, die du messen willst. Verwandte Begriffe - Beacon Das kleine Datenpaket, das der Tracker mit den Messwerten eines Besuchs an fastmon sendet. - Stitch fastmons kurzlebiger, am Edge abgeleiteter Identifier, der einen Besuch ohne Cookies oder Cross-Site-Tracking gruppiert. - Session Ein zusammenhängender Besuch: die Abfolge von Seitenaufrufen und Interaktionen, bevor ein Besucher inaktiv wird. - Pageview Ein einzelner Seitenaufruf oder, in einer Single-Page-App, ein Route-Wechsel, der als eigener Aufruf zählt. - Collection Modes Voreinstellungen (Light, Standard, Full), die festlegen, wie viel Detail der Tracker erfasst. - Server-Timing Ein HTTP-Header, den dein Backend senden kann, um aufzuschlüsseln, wo Serverzeit verbraucht wurde, sichtbar im RUM. - Cache-Status Ob eine Antwort von einem CDN-Edge, dem Origin-Server oder dem Browser-Cache kam. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/ttfb/ Metriken TTFB # Time to First Byte Die Zeit vom Start der Navigation bis der Browser das erste Byte der Antwort empfängt. Gut <= 0.8 s Ausbaufähig 0.8 to 1.8 s Schlecht > 1.8 s Felddaten (75. Perzentil) TTFB erfasst alles, was passiert, bevor das Rendern überhaupt beginnen kann: DNS-Auflösung, Verbindungsaufbau, TLS-Handshake, Weiterleitungen und die Erzeugung der Antwort durch den Server. Es ist das Fundament, auf dem jede andere Lade-Metrik aufsetzt. Ein hoher TTFB begrenzt, wie schnell FCP und LCP je sein können, weshalb es das Erste ist, was man bei einer langsamen Seite prüft. Server-Logik, Datenbankabfragen und kalte Caches sind die üblichen Verdächtigen. Was es beeinflusst - Langsame Backend-Verarbeitung oder ungecachte Datenbankabfragen. - Kein CDN, sodass entfernte Besucher die Rundreise bezahlen. - Weiterleitungsketten vor dem finalen Dokument. Verwandte Begriffe - CWV Core Web Vitals Googles Satz aus drei Feld-Metriken für Ladezeit (LCP), Interaktivität (INP) und visuelle Stabilität (CLS) einer Seite. - LCP Largest Contentful Paint Die Zeit, bis das größte sichtbare Element im Viewport (Bild, Video oder Textblock) gerendert ist. - INP Interaction to Next Paint Wie lange die Seite braucht, um nach einer Nutzerinteraktion sichtbar zu reagieren, gemessen über den gesamten Besuch. - CLS Cumulative Layout Shift Ein einheitenloser Wert dafür, wie stark sich sichtbarer Inhalt unerwartet verschiebt, während die Seite lädt und läuft. - FCP First Contentful Paint Der Moment, in dem der Browser den ersten Inhalt rendert: Text, ein Bild oder ein Canvas. - FID First Input Delay (abgelöst) Die Verzögerung zwischen der ersten Interaktion eines Besuchers und dem Beginn ihrer Verarbeitung durch den Browser. Durch INP ersetzt. - TBT Total Blocking Time Die Gesamtzeit, in der der Main-Thread zwischen erstem Paint und Interaktivität von langen Tasks blockiert war, im Labor gemessen. - SI Speed Index Eine Labor-Metrik dafür, wie schnell sich die sichtbaren Teile einer Seite während des Ladens füllen, basierend auf Videoaufnahme. - TTI Time to Interactive (veraltet) Eine Labor-Metrik dafür, wann eine Seite gerendert ist und zuverlässig schnell auf Eingaben reagieren kann. - Page Load Das klassische Load-Event: alles auf der Erstseite, inklusive Bilder und Subressourcen, ist fertig geladen. - Route Load Die Ladezeit einer In-App-Navigation in einer Single-Page-App, bei der kein voller Seiten-Reload passiert. - Long Tasks & LoAF Jedes Stück JavaScript, das den Main-Thread länger als 50 ms belegt und die Seite am Reagieren hindert. - Experience Score Eine einzelne Zahl von 0 bis 10, die fastmon aus LCP, INP, CLS, FCP, TTFB, Ladezeit und Fehlerrate bildet. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/tti/ Metriken TTI # Time to Interactive (veraltet) Eine Labor-Metrik dafür, wann eine Seite gerendert ist und zuverlässig schnell auf Eingaben reagieren kann. TTI schätzte den Punkt, ab dem der Main-Thread lange genug ruhig war, damit die Seite Interaktionen verlässlich verarbeiten konnte. Es war einst eine zentrale Lighthouse-Kennzahl. Lighthouse hat TTI in Version 10 (2023) aus der Bewertung entfernt, weil TBT und INP die Reaktionsfähigkeit zuverlässiger beschreiben. Es steht hier zur Einordnung älterer Audits. Verwandte Begriffe - CWV Core Web Vitals Googles Satz aus drei Feld-Metriken für Ladezeit (LCP), Interaktivität (INP) und visuelle Stabilität (CLS) einer Seite. - LCP Largest Contentful Paint Die Zeit, bis das größte sichtbare Element im Viewport (Bild, Video oder Textblock) gerendert ist. - INP Interaction to Next Paint Wie lange die Seite braucht, um nach einer Nutzerinteraktion sichtbar zu reagieren, gemessen über den gesamten Besuch. - CLS Cumulative Layout Shift Ein einheitenloser Wert dafür, wie stark sich sichtbarer Inhalt unerwartet verschiebt, während die Seite lädt und läuft. - FCP First Contentful Paint Der Moment, in dem der Browser den ersten Inhalt rendert: Text, ein Bild oder ein Canvas. - TTFB Time to First Byte Die Zeit vom Start der Navigation bis der Browser das erste Byte der Antwort empfängt. - FID First Input Delay (abgelöst) Die Verzögerung zwischen der ersten Interaktion eines Besuchers und dem Beginn ihrer Verarbeitung durch den Browser. Durch INP ersetzt. - TBT Total Blocking Time Die Gesamtzeit, in der der Main-Thread zwischen erstem Paint und Interaktivität von langen Tasks blockiert war, im Labor gemessen. - SI Speed Index Eine Labor-Metrik dafür, wie schnell sich die sichtbaren Teile einer Seite während des Ladens füllen, basierend auf Videoaufnahme. - Page Load Das klassische Load-Event: alles auf der Erstseite, inklusive Bilder und Subressourcen, ist fertig geladen. - Route Load Die Ladezeit einer In-App-Navigation in einer Single-Page-App, bei der kein voller Seiten-Reload passiert. - Long Tasks & LoAF Jedes Stück JavaScript, das den Main-Thread länger als 50 ms belegt und die Seite am Reagieren hindert. - Experience Score Eine einzelne Zahl von 0 bis 10, die fastmon aus LCP, INP, CLS, FCP, TTFB, Ladezeit und Fehlerrate bildet. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/web-analytics/ Methoden # Web-Analytics Messung von Traffic und Verhalten: Seitenaufrufe, Besucher, Referrer und Journeys, gemeinsam mit Performance. Analytics beantwortet, wer besucht hat, woher und was getan wurde. Mit Performance-Daten kombiniert wird es weit nützlicher: Man sieht, ob eine langsame Seite Conversions kostet oder welche Traffic-Quelle auf den schlechtesten Erfahrungen landet. Die Analytics von fastmon ist datenschutzfreundlich: keine Cookies im Standardmodus, kein Cross-Site-Tracking und IPs am Edge auf einen Country-Code reduziert. Im Standardmodus wird nichts auf dem Endgerät gespeichert, sodass nach unserer Einschätzung auch kein Consent-Banner nötig ist. Mehr erfahren Verwandte Begriffe - RUM Real User Monitoring Performance aus den Browsern deiner echten Besucher messen, auf ihren realen Geräten und Netzwerken. - Synthetic Monitoring Geplante, wiederholbare Tests, die eine Seite in kontrollierter Umgebung in festem Intervall laden. - Labordaten vs Felddaten Labordaten stammen aus einem kontrollierten Test, Felddaten von echten Besuchern. Beides zählt, aus verschiedenen Gründen. - Lighthouse Googles Open-Source-Tool, das eine Seite in einem Labordurchlauf prüft und Performance, Barrierefreiheit, SEO und mehr bewertet. - CrUX Chrome UX Report Googles öffentlicher Datensatz realer Core Web Vitals, aggregiert aus zustimmenden Chrome-Nutzern. - p75 Perzentil (p75) Der Wert, unter den ein bestimmter Anteil der Besuche fällt. p75 heißt, 75 Prozent waren mindestens so schnell. - Web Vitals Attribution Die zusätzlichen Diagnosedaten, die erklären, warum eine Metrik langsam war, nicht nur wie langsam. - Error Tracking Erfassen von JavaScript-Fehlern und fehlgeschlagenen Requests aus echten Sitzungen, gruppiert, sodass die echten Probleme sichtbar werden. - Alarmierung Benachrichtigungsregeln, die melden, wenn eine Metrik einen Schwellenwert reißt oder sich verschlechtert, bevor Kunden sich beschweren. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/glossar/web-vitals-attribution/ Methoden # Web Vitals Attribution Die zusätzlichen Diagnosedaten, die erklären, warum eine Metrik langsam war, nicht nur wie langsam. Zu wissen, dass LCP 4 Sekunden war, ist nur die halbe Geschichte. Attribution zerlegt eine Metrik in ihre Phasen (bei LCP: Time to First Byte, Ressourcen-Ladeverzögerung, Ladezeit, Render-Verzögerung) und benennt das verantwortliche Element oder den CSS-Selektor hinter einer Layoutverschiebung oder langsamen Interaktion. Das macht aus einer Zahl eine Handlung: statt zu raten, siehst du genau das Bild, Skript oder Element, das behoben werden muss. Verwandte Begriffe - RUM Real User Monitoring Performance aus den Browsern deiner echten Besucher messen, auf ihren realen Geräten und Netzwerken. - Synthetic Monitoring Geplante, wiederholbare Tests, die eine Seite in kontrollierter Umgebung in festem Intervall laden. - Labordaten vs Felddaten Labordaten stammen aus einem kontrollierten Test, Felddaten von echten Besuchern. Beides zählt, aus verschiedenen Gründen. - Lighthouse Googles Open-Source-Tool, das eine Seite in einem Labordurchlauf prüft und Performance, Barrierefreiheit, SEO und mehr bewertet. - CrUX Chrome UX Report Googles öffentlicher Datensatz realer Core Web Vitals, aggregiert aus zustimmenden Chrome-Nutzern. - p75 Perzentil (p75) Der Wert, unter den ein bestimmter Anteil der Besuche fällt. p75 heißt, 75 Prozent waren mindestens so schnell. - Web-Analytics Messung von Traffic und Verhalten: Seitenaufrufe, Besucher, Referrer und Journeys, gemeinsam mit Performance. - Error Tracking Erfassen von JavaScript-Fehlern und fehlgeschlagenen Requests aus echten Sitzungen, gruppiert, sodass die echten Probleme sichtbar werden. - Alarmierung Benachrichtigungsregeln, die melden, wenn eine Metrik einen Schwellenwert reißt oder sich verschlechtert, bevor Kunden sich beschweren. Alle Begriffe ## Monitoring, das in die EU gehört. Read-only im Standard: keine Cookies*, keine langlebigen Identifikatoren, kein US-Anbieter im Datenpfad. Live in rund fünf Minuten. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/kontakt/sales/ Sales # Sprechen wir über Enterprise. Individuelles Pageview-Volumen, lange Retention und ein passender Vertrag, auf derselben EU-gehosteten Plattform. Sag uns deinen Traffic und was du beobachten willst, und wir legen dir eine Zahl vor. - EU-gehostet - Unterschriebener AVV - DSGVO-konform - Hosting in Deutschland ## Was Enterprise umfasst - Individuelles Pageview-Volumen und Retention-Fenster - Priorisierter Support mit festem Ansprechpartner - Begleitetes Onboarding und Dashboard-Setup - Debugging und Optimierung mit fastmon-Experten - Unterschriebener AVV und Security-Review ## Sprich mit uns Kein Formular, kein Chatbot. Deine Nachricht landet direkt beim Gründerteam. Mail an unser Sales-Team Antwort direkt von den Gründern Kamil & Lucas Hilfreich in deiner ersten Mail: deine monatlichen Pageviews, was du beobachten willst, und etwaige Compliance-Anforderungen. Alle Pläne ansehen Allgemeine Anfrage ## So geht's weiter 01 ### Deine Anfrage Schreib uns kurz deinen Traffic und was du beobachten willst. 02 ### Abstimmung Wir analysieren Volumen, Retention und Compliance-Anforderungen gemeinsam mit dir. 03 ### Persönliches Angebot Du erhältst einen passenden Plan und ein individuelles Angebot, auf deine Größe zugeschnitten. --- ## https://fastmon.eu/de/partner/scalecommerce/ Partnerprofil p99 Partner # ScaleCommerce Performance-Hosting aus Berlin. E-Commerce-PaaS und Managed Hosting für Shopware, OXID, Magento und Spryker. fastmon selbst läuft auf der Plattform von ScaleCommerce. scale.sc besuchen Sitz Berlin, Deutschland Rolle Hosting-Partner Schwerpunkt E-Commerce-PaaS, Managed Hosting Plattformen Shopware, OXID, Magento, Spryker Wer sie sind ## Hosting, das sich an Performance messen lässt ScaleCommerce betreibt Onlineshops und Webanwendungen als Plattformdienst: git-basierte Deployments, CI/CD, Caching, Bot-Schutz, Backups und Security-Updates inklusive. Der Stack deckt Shopware, OXID, Magento und Spryker ab, dazu eigene Anwendungen auf Node.js oder Next.js. Was sie für uns zum passenden Partner macht, ist ihr Maßstab. ScaleCommerce verkauft nicht nur Verfügbarkeit, sondern Shop-Performance, und optimiert auf Ladezeit und Conversion. Das ist dieselbe Zahl, die fastmon auf den Schirm bringt, gemessen an echten Besuchern statt im Labor. Die Zusammenarbeit reicht bis in unsere eigene Infrastruktur: fastmon läuft auf der Plattform von ScaleCommerce, die Daten liegen auf Servern in Deutschland. Beide stehen in unserer Subprozessoren-Liste, ScaleCommerce und der Rechenzentrumsbetreiber Hetzner, dort kann das jeder nachlesen. Zur Subprozessoren-Liste Leistungen ## Was sie für Kunden betreiben ### Managed E-Commerce-Hosting Platform as a Service für Shops: git-basierte Deployments, CI/CD, Redis, automatische Backups und Security-Updates, Betrieb inklusive. ### Shop-Performance Optimierung auf Ladezeit und Conversion, nicht nur auf Verfügbarkeit. Engstellen werden in der Anwendung angefasst, nicht nur in der Infrastruktur. ### Lastspitzen Verteilte Infrastruktur, damit Kampagnen, Sale-Tage und TV-Spots nicht der Grund sind, warum Wachstum aufhört. ### Best-Practice-Bundle Über 20 vorkonfigurierte Bausteine, vom Bot-Schutz bis zu Edge Functions, statt eines Projekts, das jedes Mal bei null anfängt. Warum das passt ## Was die Kombination bringt ### Ein Maßstab auf beiden Seiten ScaleCommerce macht Shops schnell, fastmon zeigt, was davon beim echten Besucher ankommt. Ihr diskutiert mit dem Kunden über Ergebnisse statt über Messmethoden. ### fastmon läuft dort Wir setzen selbst ein, was wir empfehlen: fastmon läuft auf der Plattform von ScaleCommerce, die Daten liegen in Deutschland. Betreut ihr Kunden dort, liegen Shop und Monitoring am selben Ort. ### Ein Datenpfad, der in der EU bleibt Kein US-Anbieter dazwischen, für euch und für die Besucher eurer Kunden. Eine Frage weniger in jeder Beschaffung. p99 Partner ### Das höchste Level im Programm p99 ist das höchste der vier Partner-Level. Dazu gehören individuell vereinbarte Konditionen, Enterprise-Deals, die wir zusammen abschließen, und gemeinsame Produktarbeit. Wie die Level funktionieren ## Selbst Partner werden Das Programm ist offen für jede Agentur, jeden Hoster und jede Beratung, die Websites betreut. Gleiche Leiter, gleiche Bedingungen. Partner werden Zum Partnerprogramm --- ## https://fastmon.eu/de/partner/werden/ Partner werden # Zwei Absätze, dann sprechen wir. Kein Bewerbungsportal, kein Vertriebstunnel. Sagt uns, wer ihr seid und wie viele Kundenprojekte ihr betreut, den Rest klären wir in einem kurzen Gespräch. - Keine Aufnahmegebühr - Kein Mindestumsatz - Kündigung jederzeit ## Was in die erste Mail gehört - Euer Unternehmen und eure Website - Wie viele Kundenprojekte ihr betreut - Welcher Weg zu euch passt: empfehlen oder selbst verwalten - Womit ihr arbeitet: Shopware, WordPress, TYPO3, eigener Stack - Optional: zwei Kundenprojekte, mit denen ihr starten würdet ## Schreibt uns Kein Formular, kein Chatbot. Eure Nachricht landet direkt beim Gründerteam. Mail an unser Partner-Team Antwort direkt von den Gründern Kamil & Lucas Lieber sprechen? Schreibt zwei Zeitfenster in die Mail, wir schicken einen Link. Zurück zum Programm Alle Pläne ansehen ## So geht es weiter 01 ### Eure Bewerbung Die Mail landet direkt beim Gründerteam, nicht in einem Vertriebspostfach. Geantwortet wird persönlich. 02 ### Kennenlernen Ein halbstündiges Videogespräch, ohne Präsentation: eure Kunden, euer Stack, welcher Weg zu euch passt. 03 ### Zugang und Startpaket Ihr werdet als Partner hinterlegt und bekommt das Partner-Kit sowie einen kostenlosen Account für eure eigenen Seiten. Voraussetzungen ## Wir nehmen euch auf, wenn - ihr Websites oder Shops für Kunden baut, betreibt oder betreut - ihr fastmon selbst einsetzt, mindestens auf der eigenen Seite - ihr eure Kunden fachlich begleitet und nicht nur einen Link platziert Gutschein- und Cashback-Seiten nehmen wir nicht auf. Eigenkäufe und Gebote auf unsere Marke in Suchanzeigen sind ausgeschlossen. Konditionen ## Die Bedingungen in Kurzform - 20 % ab dem ersten aktiven Standard-Account, 25 % ab zehn, 30 % ab 25. Ab 50 wird individuell verhandelt. - Light (29 €) bringt feste 10 %, ab dem zehnten aktiven Light-Account, und zählt nicht für die Level. - Im Weg Verwalten zählen die Accounts auf euer Level, statt einer Provision vereinbaren wir dort den Preis. - Die Provision läuft, solange der Kunde zahlt. Keine Begrenzung auf 12 Monate. - Meldet den Kunden vor seiner Registrierung per Mail an, dann ist die Zuordnung eindeutig. - Auszahlung monatlich gegen eure Rechnung, ab 50 € Guthaben, netto zzgl. USt. oder Reverse Charge innerhalb der EU. - Level-Prüfung monatlich, nach einer Kündigung drei Monate Level-Schutz, zehn Accounts in den ersten 90 Tagen bringen p90 sofort. - Kündigung jederzeit möglich, ohne Frist. Verbindlich ist der Partnervertrag, den ihr vor dem Start bekommt. Diese Seite ist die Zusammenfassung. ## Fragen, die hier nicht stehen? Schreibt sie direkt in die Mail. Sie landet beim Gründerteam, nicht in einer Vertriebsschleife. Mail an unser Partner-Team --- ## https://fastmon.eu/de/vergleich/datadog/ fastmon vs Datadog RUM # Real User Monitoring, ohne die Enterprise-Rechnung. Datadog RUM ist Teil einer vollen Observability-Suite, für Enterprises gebaut und bepreist. fastmon ist fokussiertes Web-Performance-RUM: leichter, EU-gehostet und ein Bruchteil der Kosten. Datadog ist eine ernstzunehmende Full-Stack-Observability-Plattform: APM, Logs, Infrastruktur und RUM. Wenn du all das an einem Ort brauchst, kann es weit mehr als fastmon, und das tun wir nicht kleinreden. Aber speziell für Web-Performance ist Datadog RUM schwer, nutzt Cookies, kommt von einem US-Unternehmen unter dem CLOUD Act und wird bei echtem Traffic schnell teuer. fastmon erledigt den Web-Performance-Job: Core Web Vitals, Fehler und Netzwerk-Timing von echten Nutzern, standardmäßig cookiefrei*, in Deutschland gehostet, ab 29 € im Monat. Fokussiertes Web-RUM ## Zum Bruchteil der Kosten. Speziell für Web-Performance sind die Unterschiede deutlich. | | fastmon | Datadog RUM | Core Web Vitals von echten Nutzern | Ja | Ja | JavaScript-Fehler und Netzwerk-Timing | Ja | Ja | Alerts und Release-Tracking | Ja | Ja | Cookiefrei* im Standard-Modus | Ja | Nein | In der EU gehostet, kein US-Recht | Ja | Nein | Leichtes Script | ~40 KB | ~60 KB gzip | Einrichtung | Ein Script-Tag | SDK und Konfig | Session Replay | Nein, bewusst | Ja | Full-Stack-Observability (APM, Logs, Infra) | Nein | Ja | Rohdaten-Aufbewahrung | 90 Tage (Default), bis 13 Monate (Enterprise) | Events 15 bis 30 Tage (Metriken länger) | Preis bei rund 1 Mio. Sessions Datadog rechnet pro Session ab, fastmon pro Pageview; 1 Mio. Sessions sind typisch 2 bis 4 Mio. Pageviews | ca. 169 bis 200 €/Monat (bei ~3 Mio. Pageviews) | ab ~150 $/Monat (RUM Measure, Jahresbindung); Investigate 3 $ je 1.000 Sessions Datadog hat die RUM-Preise 2026 neu strukturiert: RUM Measure ab 0,15 $ je 1.000 Sessions (Jahresbindung), RUM Investigate 3 $ je 1.000 gefilterte Sessions, Session Replay extra. Preise variieren je nach Vertrag. Datadog kann weit mehr als Web-RUM. Stand: 14. Juli 2026; Listenpreise bzw. typische Konfiguration, individuelle Konditionen können abweichen. Warum Teams fastmon fürs Web-RUM nehmen ## Leichter, EU-gehostet, bezahlbar. Wenn Web-Performance das ist, was du wirklich beobachten musst. ### Ein Bruchteil der Kosten Ab 29 € im Monat. Datadog hat modulare Listenpreise pro Session; Debugging-Funktionen liegen im höherpreisigen Investigate-Tarif. ### EU-gehostet und cookiefrei* In Deutschland, kein US-Anbieter im Datenpfad, keine Cookies* im Standard-Modus. Datadog ist ein US-Unternehmen und bleibt unter dem CLOUD Act, auch in seiner EU-Region. ### Live in fünf Minuten Ein Script-Tag, rund 40 KB, kein Agent, kein Build-Step. Fokussiert auf Web-Performance, nichts zu konfigurieren. Fair bleiben ## Wo Datadog die richtige Wahl ist. Wenn du APM, Log-Management, Infrastruktur-Monitoring und RUM in einer Plattform brauchst, ist Datadog genau dafür gebaut und kann weit mehr als fastmon. fastmon ist die fokussierte, EU-gehostete, bezahlbare Wahl, wenn Web-Performance das ist, was du beobachten musst. FAQ ## fastmon und Datadog. Die Fragen, die man vor dem Wechsel stellt. ### Ist fastmon ein Datadog-Ersatz? Fürs Web-Performance-RUM ja, und zum Bruchteil des Preises. Für volle Observability, also APM, Logs und Infrastruktur, nein: Datadog ist eine viel breitere Plattform. fastmon macht bewusst eine Sache gut. ### Wie viel günstiger ist fastmon? fastmon startet bei 29 € im Monat. Datadog hat modulare Listenpreise pro Session; Debugging-Funktionen liegen im höherpreisigen Investigate-Tarif, die Kosten hängen von Vertrag und Modulen ab. Speziell für Web-Performance deckt fastmon das Wesentliche für weit weniger ab. ## Ehrlich verglichen, in der EU gebaut. Web-Performance-Monitoring ohne US-Cloud: read-only im Standard, keine Cookies*, keine langlebigen Identifikatoren, ab 29 € im Monat. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/vergleich/ga4/ fastmon vs Google Analytics 4 # Analytics ohne den Cookie-Ballast. GA4 zählt Besuche mit Cookies und schickt die Daten zu Google. fastmon liefert datenschutzfreundliche Web-Analytics aus der EU, dazu die Core Web Vitals, die GA4 nicht von Haus aus misst. GA4 ist mächtig und kostenlos, und für tiefe Marketing-Analytics kann es viel. Aber es setzt Cookies, sampelt deine Daten in Explorationen und verarbeitet sie als US-Unternehmen. In der EU heißt das meist Consent-Banner und Schrems-förmige Kopfschmerzen. fastmon ist Analytics, Privacy-first gebaut: keine Cookies* im Standard-Modus, die IP am Edge verworfen, in Deutschland gehostet, kein US-Anbieter im Datenpfad. Und weil es auf denselben Beacons wie deine Web Vitals läuft, liegen Traffic und Performance in einem Tool. Privacy first ## Und Performance inklusive. Die Unterschiede, die für ein EU-Team zählen, dem auch Speed wichtig ist. | | fastmon | Google Analytics 4 | Keine Cookies* im Standard-Modus | Ja | Nein | In der EU gehostet, kein US-Recht | Ja | Nein | IP-Verarbeitung ohne US-Konzern | Ja | Nein | Ungesampelte Daten | Ja | Teilweise | Core Web Vitals im selben Tool Traffic und Performance zusammen | Ja | Teilweise | Fehler-Gruppierung und Netzwerk-Timing (RUM) | Ja | Nein | Kampagnen-Attribution (UTM, Klick-ID-Label) | Ja | Ja | Daten zur Verbesserung von Ad-Produkten | Nie | Konfigurierbar | Rohdaten-Aufbewahrung | 90 Tage (Default), bis 13 Monate (Enterprise) | 2 oder 14 Monate | Marketing-Funnels und Audiences | Nein | Ja | Preis | ab 29 €/Monat | Kostenlos GA4-Verhalten hängt von der Konfiguration ab; der Vergleich spiegelt die Standard-Defaults (kostenloses GA4). GA4 360 erhöht Aufbewahrung (bis 50 Monate) und Sampling-Grenzen. fastmon Analytics ist in der Beta. Stand: 14. Juli 2026; Listenpreise bzw. typische Konfiguration, individuelle Konditionen können abweichen. Warum Teams von GA4 wechseln ## Datenschutz, Souveränität und Speed. Die Gründe, die EU-Teams für den Wechsel ihrer Analytics zu fastmon nennen. ### Kein Cookie-Ballast Im Standard-Modus cookiefrei* und speicherfrei, du vermeidest die Cookies von GA4 komplett. Nach unserer Einschätzung entfällt damit auch der Banner, im Modus Full brauchst du ihn. ### Deine Daten bleiben in der EU In Deutschland verarbeitet und gespeichert, kein US-Anbieter im Datenpfad; der US CLOUD Act hat damit keinen Zugriff. ### Performance im selben Blick Traffic und Core Web Vitals auf denselben Beacons, damit du siehst, welche langsamen Seiten dich still Conversions kosten. Fair bleiben ## Wo GA4 weiter gewinnt. GA4 ist kostenlos, eng mit Google Ads verzahnt und bietet Funnels, Audiences und Event-Modeling, die fastmon nicht hat. Wenn sich deine Welt um Google Ads und fortgeschrittene Marketing-Analytics dreht, ist GA4 schwer zu schlagen. fastmon ist für Teams, die datenschutzfreundlichen Traffic und Performance in einem EU-gehosteten Tool wollen. FAQ ## fastmon und GA4. Die Fragen, die man vor dem Wechsel stellt. ### Ist fastmon ein voller GA4-Ersatz? Für die meisten Seiten ja: Besucher, Quellen, Seiten, Orte, Geräte und Kampagnen, neben deinen Performance-Daten. Es macht bewusst keine Funnels als Report, keine Conversion-Ziele, keine Custom Events und kein A/B-Testing, und es ist in der Beta. ### Brauche ich noch einen Cookie-Banner? fastmon setzt im Standard-Modus keine Cookies* und schreibt nichts auf das Gerät, du vermeidest also die Cookies von GA4. Nach unserer Einschätzung brauchst du in Minimal und Standard auch keine Einwilligung, weil die gelesenen Werte vorher nicht im Gerät lagen; im Modus Full dagegen schon. Bei GA4 ist der Banner Pflicht, dort werden Cookies gesetzt. Die ganze Herleitung, mit Normtext und Gegenauffassung ## Ehrlich verglichen, in der EU gebaut. Web-Performance-Monitoring ohne US-Cloud: read-only im Standard, keine Cookies*, keine langlebigen Identifikatoren, ab 29 € im Monat. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen --- ## https://fastmon.eu/de/vergleich/lighthouse/ fastmon vs Lighthouse # Behalte das Labor. Nimm das Feld dazu. Lighthouse sagt dir, wie schnell ein simuliertes Gerät deine Seite geladen hat. fastmon zeigt dir, wie schnell es für deine echten Besucher war, und fährt Lighthouse trotzdem für dich, nach Zeitplan. Lighthouse ist ein großartiges, kostenloses Labor-Tool. Es lädt deine Seite einmal auf einem simulierten Gerät unter idealen Bedingungen und bewertet sie. Perfekt, um Regressionen vor dem Release zu fangen, und genau das fährt fastmon für dich als Synthetic Monitoring. Aber ein Laborwert ist nicht das, was deine Besucher fühlen. Ein drei Jahre altes Handy im Mobilfunknetz ist kein idealisierter Desktop. fastmon ergänzt Real User Monitoring: die Core Web Vitals, die deine echten Besucher wirklich bekommen, aggregiert am p75, direkt neben dem Laborlauf. Du behältst das Labor und gewinnst das Feld. Labor und Feld ## Nebeneinander, in einem Tool. fastmon fährt Lighthouse für dich und ergänzt die Echtnutzer-Daten, die ein Labortest nie sieht. | | fastmon | Lighthouse | Labor-Audits (Lighthouse) | Ja | Ja | Echtnutzer-Felddaten (RUM) | Ja | Nein | Misst die echten Geräte deiner Besucher | Ja | Nein | Core Web Vitals am p75 von echten Besuchern | Ja | Nein | INP (nur im Feld messbar) | Ja | Nein | JavaScript-Fehler aus Produktion | Ja | Nein | Server-Timing und Netzwerk aus echten Besuchen | Ja | Nur ein Ladevorgang | Segmente nach Land, Gerät und Seite | Ja | Nein | Geplantes, kontinuierliches Monitoring | Ja | Manuell oder CI | Alerts und Release-Tracking | Ja | Nein | Dashboard mit Historie | Ja | Einmal-Report | Preis | ab 29 €/Monat | Kostenlos Lighthouse ist kostenlos und Open Source, und fastmon nutzt es für sein Synthetic Monitoring. Dieser Vergleich geht um Labor-allein gegen Labor-plus-Feld. Stand: 14. Juli 2026; Listenpreise bzw. typische Konfiguration, individuelle Konditionen können abweichen. Was das Feld ergänzt ## Die drei Dinge, die ein Labor nicht zeigt. Alles darunter existiert erst, wenn echte Besucher deine Seite laden. ### Das Erlebnis, keine Simulation Echte Geräte, echte Netze, aggregiert am p75, damit du siehst, was Besucher wirklich bekommen, nicht einen idealisierten Lauf. ### INP und echte Fehler Interaction to Next Paint und JavaScript-Fehler gibt es nur im Feld. Lighthouse kann sie gar nicht messen. ### Kontinuierlich, mit Alerts fastmon beobachtet jeden Besuch und alarmiert bei Regressionen, statt eines Laufs, den du von Hand anstoßen musst. Fair bleiben ## Wo Lighthouse allein reicht. Wenn du nur einen schnellen Laborwert in der CI brauchst und nie auf Echtnutzer-Daten schaust, ist Lighthouse allein kostenlos und exzellent. fastmon ist für Teams, die zusätzlich kontinuierlich wissen wollen, was ihre echten Besucher erleben. FAQ ## fastmon und Lighthouse. Die Fragen, die man vor dem Wechsel stellt. ### Ersetzt fastmon Lighthouse? Nein, es enthält es. fastmon fährt geplante Lighthouse-Audits für Desktop und Mobile als Synthetic Monitoring und ergänzt Real User Monitoring obendrauf. Du bekommst Labor und Feld in einem Tool. ### Warum sind Felddaten besser als ein Lighthouse-Wert? Sie sind nicht besser, sie sind anders, und du willst beides. Lighthouse ist ein sauberes, reproduzierbares Laborsignal. Felddaten sind die verrauschte Wahrheit echter Geräte und Netze am p75, inklusive INP und Fehlern, die ein Labor nicht sieht. ## Ehrlich verglichen, in der EU gebaut. Web-Performance-Monitoring ohne US-Cloud: read-only im Standard, keine Cookies*, keine langlebigen Identifikatoren, ab 29 € im Monat. Light 29 € /Monat 200.000 Pageviews inklusive. Kostenlos starten Pläne ansehen Debugging und alle Features? Standard ab 99 € für 1 Mio. Pageviews. Enterprise auf Anfrage. Alle Pläne ansehen