Wissensdatenbank — Web-Performance, DSGVO, WCAG & SEOKnowledge Base — Web Performance, GDPR, WCAG & SEO

Alle Metriken erklärt — was sie messen, warum sie wichtig sind und wie Sie Ihre Werte verbessern. All metrics explained — what they measure, why they matter, and how to improve your scores.

Messmethodik

Measurement Methodology

Lab

fepo misst Lab-Metriken mit dem Geräteprofil Moto G4 (360×640 px, 4-fache CPU-Drosselung, 10 Mbit/s mobiles Netz). Dieser Standard entspricht dem ursprünglichen Lighthouse-Profil und ist bewusst strenger als PageSpeed Insights, das seit 2023 ein Moto G Power-Profil (412×823 px, 1,2-fache CPU-Drosselung) verwendet. Fepo-Werte können daher schlechter ausfallen als PSI — sie sind realistischer für Nutzer mit mittlerer Hardware.

fepoPageSpeed Insights
GerätMoto G4Moto G Power
Auflösung360×640 px412×823 px
CPU-Drosselung1,2×
Netzwerk10 Mbit/s10 Mbit/s
fepoPageSpeed Insights
DeviceMoto G4Moto G Power
Viewport360×640 px412×823 px
CPU throttle1.2×
Network10 Mbit/s10 Mbit/s
Core Web Vitals Core Web Vitals

LCP — Largest Contentful Paint

Core Web Vital

Wie schnell wird der Hauptinhalt der Seite geladen? LCP misst die Zeit, bis das größte sichtbare Element — meist ein Hero-Bild, ein Video-Thumbnail oder ein großer Textblock — vollständig gerendert ist. Aus Nutzersicht: Wann ist der wichtigste Inhalt endlich sichtbar?

Gut: ≤ 2.500 msGood: ≤ 2,500 ms Verbesserungswürdig: 2.500–4.000 msNeeds improvement: 2,500–4,000 ms Schlecht: > 4.000 msPoor: > 4,000 ms
Warum es wichtig ist

LCP ist einer der drei Core Web Vitals und fließt direkt in das Google-Suchranking ein. Ein hoher Wert bedeutet, dass Besucher lange auf den Hauptinhalt warten — die Absprungrate steigt, bevor die Seite fertig ist.

Typische Ursachen & Tipps
  • Bilder komprimieren und in modernen Formaten (WebP, AVIF) ausliefern
  • Server-Response-Zeit verkürzen (TTFB optimieren, Caching aktivieren)
  • Render-blockierende Ressourcen (CSS, JavaScript) reduzieren
  • Beim Hero-Bild fetchpriority="high" setzen (niemals loading="lazy")
  • <link rel="preload" as="image" href="hero.jpg" fetchpriority="high"> als erstes <link> im <head> einfügen — Browser startet den Download sofort beim HTML-Parsen
  • CDN einsetzen, um Ladezeiten weltweit zu verkürzen
Why it matters

LCP is one of the three Core Web Vitals and directly influences Google search rankings. A high LCP score means visitors wait a long time for the main content — bounce rates rise before the page finishes loading.

Common causes & tips
  • Compress images and serve them in modern formats (WebP, AVIF)
  • Reduce server response time (optimise TTFB, enable caching)
  • Remove render-blocking resources (CSS, JavaScript)
  • Set fetchpriority="high" on the hero image (never loading="lazy")
  • Add <link rel="preload" as="image" href="hero.jpg" fetchpriority="high"> as the first <link> in <head> — the browser starts downloading the image immediately during HTML parsing
  • Use a CDN to reduce load times globally

INP — Interaction to Next Paint

Core Web Vital

Wie schnell reagiert die Seite auf Nutzereingaben? INP misst die Zeit von einer Interaktion — Klick, Tippen, Tastendruck — bis zur nächsten sichtbaren Aktualisierung. Es bewertet die Reaktionsfähigkeit der gesamten Seite über die gesamte Nutzungsdauer.

Gut: ≤ 200 msGood: ≤ 200 ms Verbesserungswürdig: 200–500 msNeeds improvement: 200–500 ms Schlecht: > 500 msPoor: > 500 ms
Warum es wichtig ist

INP hat FID im März 2024 als Core Web Vital abgelöst und bewertet die Interaktivität über die gesamte Seiten-Session — nicht nur die erste Eingabe. Langsame Reaktionen lassen die Seite eingefroren wirken und frustrieren Nutzer nachhaltig.

Typische Ursachen & Tipps
  • Lange JavaScript-Tasks aufteilen (mit setTimeout oder scheduler.yield())
  • Schwere Event-Handler optimieren — keine teuren Berechnungen direkt im Click-Handler
  • Unnötige DOM-Änderungen reduzieren, die Browser-Rendering auslösen
  • Code-Splitting einsetzen, damit der Main Thread nicht blockiert wird
Why it matters

INP replaced FID in March 2024 as a Core Web Vital and evaluates interactivity across the entire page session — not just the first input. Slow responses make pages feel frozen and frustrate users over time.

Common causes & tips
  • Break up long JavaScript tasks (using setTimeout or scheduler.yield())
  • Optimise heavy event handlers — avoid expensive calculations directly in click handlers
  • Reduce unnecessary DOM changes that trigger browser rendering
  • Use code splitting to keep the main thread unblocked

CLS — Cumulative Layout Shift

Core Web Vital

Springen Elemente beim Laden unerwartet umher? CLS misst, wie stark sich sichtbare Inhalte während des Ladens verschieben. Hoher CLS: Nutzer klicken auf einen Button und treffen plötzlich etwas anderes, weil ein Bild oder eine Anzeige den Inhalt nach unten geschoben hat.

Gut: ≤ 0,1Good: ≤ 0.1 Verbesserungswürdig: 0,1–0,25Needs improvement: 0.1–0.25 Schlecht: > 0,25Poor: > 0.25
Warum es wichtig ist

Layout-Sprünge sind frustrierend und führen zu Fehlklicks. Google bewertet CLS als Core Web Vital — besonders auf mobilen Geräten ist ein stabiles Layout ein wichtiges Rankingkriterium. Der Score ergibt sich aus Verschiebungsgröße × Bewegungsdistanz.

Typische Ursachen & Tipps
  • Bilder und Videos immer mit width und height definieren, damit der Browser Platz reserviert
  • Werbebanner und eingebettete Inhalte mit fester Platzhaltergröße versehen
  • Keine Elemente dynamisch über bestehendem Inhalt einblenden (z.B. Cookie-Banner oben)
  • Web-Schriften mit font-display: optional laden, um Schrift-bedingte Verschiebungen zu vermeiden
Why it matters

Layout shifts frustrate users and cause accidental clicks. Google counts CLS as a Core Web Vital — a stable layout is an important ranking factor, especially on mobile. The score is calculated from shift fraction × movement distance.

Common causes & tips
  • Always set width and height on images and videos so the browser can reserve space
  • Give ads and embedded content a fixed placeholder size
  • Don't inject elements dynamically above existing content (e.g. cookie banners at the top)
  • Load web fonts with font-display: optional to avoid font-induced shifts
Weitere Metriken Further Metrics

FCP — First Contentful Paint

Diagnose

Wann erscheint das erste sichtbare Element? FCP misst die Zeit vom Navigationsstart bis zum ersten gerenderten Pixel — Text, Bild oder SVG. Es ist das erste Zeichen für den Nutzer, dass die Seite überhaupt reagiert.

Gut: ≤ 1.800 msGood: ≤ 1,800 ms Verbesserungswürdig: 1.800–3.000 msNeeds improvement: 1,800–3,000 ms Schlecht: > 3.000 msPoor: > 3,000 ms
Warum es wichtig ist

FCP beeinflusst die wahrgenommene Ladegeschwindigkeit maßgeblich. Wenn lange nichts erscheint, fühlt sich die Seite "kaputt" an — auch wenn sie technisch noch lädt. FCP geht mit 10% in den Lighthouse Performance Score ein.

Typische Ursachen & Tipps
  • Server-Response-Zeit (TTFB) verbessern — Verzögerungen hier wirken sich direkt auf FCP aus
  • Render-blockierende CSS und JavaScript entfernen oder verzögert laden
  • Web-Schriften mit font-display: swap laden, damit Text sofort sichtbar ist
  • Kritisches CSS direkt im <head> inline einbetten
Why it matters

FCP heavily influences perceived loading speed. When nothing appears for a long time, the page feels "broken" — even if it's technically still loading. FCP contributes 10% to the Lighthouse Performance score.

Common causes & tips
  • Improve server response time (TTFB) — any delay here directly impacts FCP
  • Remove or defer render-blocking CSS and JavaScript
  • Load web fonts with font-display: swap so text is immediately visible
  • Inline critical CSS directly in the <head>

TTFB — Time to First Byte

Diagnose

Wie lange dauert es bis zur ersten Serverantwort? TTFB misst die Zeit vom Navigationsstart bis zum Eintreffen des ersten Datenbytes — inklusive DNS-Auflösung, TCP-Verbindung, TLS-Handshake und Serververarbeitungszeit.

Gut: ≤ 800 msGood: ≤ 800 ms Verbesserungswürdig: 800–1.800 msNeeds improvement: 800–1,800 ms Schlecht: > 1.800 msPoor: > 1,800 ms
Warum es wichtig ist

TTFB ist die Basis für alle anderen Metriken — ein langsamer Server zieht FCP, LCP und alle weiteren Werte nach unten. Gleichzeitig ist TTFB oft der beste erste Ansatzpunkt: Hosting-Qualität, Caching und CDN haben hier den größten Hebel.

Typische Ursachen & Tipps
  • Server-seitiges Caching aktivieren (Redis, Varnish, Page-Cache-Plugins)
  • CDN einsetzen, damit Inhalte vom nächstgelegenen Server ausgeliefert werden
  • Hosting-Paket upgraden oder zu einem schnelleren Anbieter wechseln
  • Datenbankabfragen optimieren und unnötige Server-seitige Berechnungen reduzieren
  • HTTP/2 oder HTTP/3 aktivieren
Why it matters

TTFB is the foundation for all other metrics — a slow server drags FCP, LCP and everything else down with it. At the same time, TTFB is often the best first point of attack: hosting quality, caching, and CDN have the biggest impact here.

Common causes & tips
  • Enable server-side caching (Redis, Varnish, page cache plugins)
  • Use a CDN so content is served from the nearest server
  • Upgrade your hosting plan or switch to a faster provider
  • Optimise database queries and reduce unnecessary server-side processing
  • Enable HTTP/2 or HTTP/3

RTT — Round Trip Time

Netzwerk

RTT ist die Zeit, die ein Datenpaket benötigt, um vom Browser zum Server zu reisen — und die Antwort wieder zurückzukommen. RTT hängt von der physischen Distanz zum Server, der Netzwerkqualität und der Routing-Infrastruktur ab. Es ist keine Metrik die eine Webseite direkt beeinflussen kann, aber sie erklärt warum ein Server mit kurzem TTFB trotzdem langsam wirkt.

Gut: < 50 msGood: < 50 ms Verbesserungswürdig: 50–150 msNeeds improvement: 50–150 ms Schlecht: > 150 msPoor: > 150 ms
Warum es wichtig ist

Jede HTTP-Anfrage kostet mindestens 1 RTT — beim TLS-Handshake sind es sogar 2–3. Bei einem RTT von 170 ms (wie im fepo Mobile-4G-Testprofil) summiert sich das schnell. Ein CDN mit Standort nahe beim Nutzer ist die wirksamste Maßnahme um RTT zu reduzieren.

Typische Ursachen & Tipps
  • CDN einsetzen — Inhalte werden vom nächstgelegenen Edge-Server ausgeliefert
  • HTTP/2 oder HTTP/3 nutzen — mehrere Anfragen über eine einzige Verbindung
  • Anzahl der Anfragen reduzieren — jede vermiedene Anfrage spart 1 RTT
  • preconnect für wichtige Drittanbieter-Domains setzen
Why it matters

Every HTTP request costs at least 1 RTT — for the TLS handshake it's even 2–3. With an RTT of 170 ms (as in the fepo Mobile 4G test profile) this adds up fast. A CDN with a location close to the user is the most effective measure to reduce RTT.

Common causes & tips
  • Use a CDN — content is served from the nearest edge server
  • Use HTTP/2 or HTTP/3 — multiple requests over a single connection
  • Reduce the number of requests — every avoided request saves 1 RTT
  • Set preconnect for important third-party domains

TBT — Total Blocking Time

Lighthouse

Wie stark blockiert JavaScript den Browser beim Laden? TBT summiert alle Zeitanteile über 50 ms, in denen der Browser durch lange JavaScript-Tasks blockiert war — gemessen während der Ladephase. In dieser Zeit kann der Browser nicht auf Eingaben reagieren.

Gut: < 200 msGood: < 200 ms Verbesserungswürdig: 200–600 msNeeds improvement: 200–600 ms Schlecht: > 600 msPoor: > 600 ms
Warum es wichtig ist

TBT hat in Lighthouse v10 mit 30% die höchste Gewichtung aller Metriken — es ist der stärkste Lab-Indikator für wahrgenommene Interaktivität und korreliert gut mit dem realen INP-Wert. TBT wird nur im Labor gemessen, nicht aus echten Nutzerdaten (CrUX).

Typische Ursachen & Tipps
  • Lange JavaScript-Tasks (> 50 ms) im Performance Profiler identifizieren und aufteilen
  • Unused JavaScript entfernen (Tree Shaking, Code Splitting)
  • Drittanbieter-Skripte (Analytics, Chat, Werbung) per async/defer laden oder lazy-loaden
  • Tracking-Pixel komplett aus dem Browser entfernen mit Server-Side Tagging (SST) — reduziert Drittanbieter-JS auf null
  • Main Thread durch Web Workers entlasten
Why it matters

TBT has the highest weighting of all metrics in Lighthouse v10 at 30% — it is the strongest lab indicator of perceived interactivity and correlates well with real-world INP. TBT is only measured in the lab, not from real user data (CrUX).

Common causes & tips
  • Identify and break up long JavaScript tasks (> 50 ms) using the Performance Profiler
  • Remove unused JavaScript (tree shaking, code splitting)
  • Load third-party scripts (analytics, chat, ads) with async/defer or lazy-load them
  • Remove tracking pixels from the browser entirely with Server-Side Tagging (SST) — reduces third-party JS to zero
  • Offload work to Web Workers to free the main thread

SI — Speed Index

Lighthouse

Wie schnell füllt sich die Seite visuell? Speed Index misst nicht einen einzelnen Zeitpunkt, sondern die durchschnittliche Geschwindigkeit, mit der die Seite sichtbar aufgebaut wird. Berechnet wird er aus einer Video-Aufnahme des Ladevorgangs — Frame für Frame.

Gut: ≤ 3.400 msGood: ≤ 3,400 ms Verbesserungswürdig: 3.400–5.800 msNeeds improvement: 3,400–5,800 ms Schlecht: > 5.800 msPoor: > 5,800 ms
Warum es wichtig ist

SI bewertet das gesamte visuelle Ladeerlebnis, nicht nur einen einzelnen Moment. Er geht mit 10% in den Lighthouse Score ein. Eine langsam aufbauende Seite wirkt träge — auch wenn einzelne Elemente technisch schnell laden.

Typische Ursachen & Tipps
  • Kritisches CSS inline einbetten, damit Above-the-Fold-Inhalte sofort erscheinen
  • Render-blockierende Ressourcen reduzieren
  • Bilder unterhalb der Sichtlinie lazy-loaden (loading="lazy")
  • Animationen und Transitions erst nach dem Laden starten
Why it matters

SI evaluates the overall visual loading experience, not just a single moment. It contributes 10% to the Lighthouse score. A slowly building page feels sluggish — even if individual elements technically load quickly.

Common causes & tips
  • Inline critical CSS so above-the-fold content appears immediately
  • Reduce render-blocking resources
  • Lazy-load images below the fold (loading="lazy")
  • Start animations and transitions only after loading completes
Lighthouse Performance Score Lighthouse Performance Score

Lighthouse Performance Score

Lighthouse v10

Der Lighthouse Performance-Score (0–100) ist ein gewichteter Durchschnitt aus fünf Lab-Metriken. Er wird im kontrollierten Labor gemessen — nicht aus echten Nutzerdaten (CrUX). Ein Score von 90–100 gilt als gut.

TBT
30%
LCP
25%
CLS
25%
FCP
10%
SI
10%
90–100 GutGood 50–89 VerbesserungswürdigNeeds improvement 0–49 SchlechtPoor
Wichtig zu wissen

Der Lighthouse Score und die CrUX-Daten im Dashboard messen unterschiedliche Dinge: Lighthouse läuft im Lab mit simulierten Bedingungen (gedrosseltes Netz, emuliertes Mobile). CrUX zeigt echte Nutzerdaten aus Chrome. Beide Perspektiven ergänzen sich — ein guter Lab-Score ist kein Garant für gute Felddaten, und umgekehrt.

fepo Lighthouse vs. PageSpeed Insights

fepo zeigt zwei Lighthouse-Messungen: unsere eigene (Programmatic Lighthouse, lokal auf unserem Server) und den PageSpeed Insights Score (Google's Infrastruktur). Abweichungen zwischen beiden Werten sind normal und haben mehrere Ursachen:

  • Hardware: Unser Server (Xeon E3-1275 v5) hat eine andere CPU-Baseline als Google's Testumgebung. CPU-Throttling (4×) ist relativ zur Host-Hardware — gleicher Faktor, unterschiedliches Ergebnis.
  • Standort: fepo misst aus Frankfurt (DE), PageSpeed Insights von Google's Infrastruktur. Bei Servern in der EU kann die Latenz aus Google's Perspektive höher sein.
  • Normale Varianz: Lighthouse-Ergebnisse schwanken zwischen einzelnen Runs um ±5–10 Punkte. Das ist kein Fehler, sondern systembedingt — Netzwerkschwankungen, Server-Last und Rendering-Unterschiede beeinflussen jede Messung.
Important to know

The Lighthouse score and the CrUX data in your dashboard measure different things: Lighthouse runs in a lab with simulated conditions (throttled network, emulated mobile). CrUX shows real user data from Chrome. Both perspectives complement each other — a good lab score doesn't guarantee good field data, and vice versa.

fepo Lighthouse vs. PageSpeed Insights

fepo shows two Lighthouse measurements: our own (Programmatic Lighthouse, running locally on our server) and the PageSpeed Insights score (Google's infrastructure). Differences between both values are normal and have several causes:

  • Hardware: Our server (Xeon E3-1275 v5) has a different CPU baseline than Google's test environment. CPU throttling (4×) is relative to the host hardware — same factor, different result.
  • Location: fepo measures from Frankfurt (DE), PageSpeed Insights from Google's infrastructure. For EU-based servers, latency from Google's perspective may be higher.
  • Normal variance: Lighthouse results fluctuate between runs by ±5–10 points. This is not a bug but systemic — network jitter, server load, and rendering differences affect every measurement.

fepo Score

0 – 100

Der fepo Score (0–100) ist eine gewichtete Gesamtbewertung Ihrer Website — berechnet aus Performance, Sicherheit, SEO, Accessibility, CSS-Qualität, Bildoptimierung und Kompression. Ein einziger Wert, der den Zustand Ihrer gesamten Web-Performance auf einen Blick zeigt.

Berechnung

Jede Komponente fließt mit einem festen Gewicht in den Score ein. Wenn eine Datenquelle nicht verfügbar ist (z.B. kein Lighthouse-Lauf), wird ihr Gewicht auf die übrigen Komponenten verteilt — der Score bleibt dadurch immer fair und vergleichbar.

How it's calculated

Each component contributes with a fixed weight. If a data source is unavailable (e.g. no Lighthouse run), its weight is redistributed across the remaining components — keeping the score fair and comparable at all times.

KomponenteComponentGewichtWeight
Lighthouse Performance25 %
SicherheitSecurity15 %
PageSpeed Insights Performance10 %
Lighthouse Accessibility12 %
Lighthouse Best Practices12 %
Lighthouse SEO11 %
CrUX (nur wenn verfügbar) (only when available)5 %
CSS5 %
BilderImages3 %
Compression2 %
80–100 Sehr gutExcellent 60–79 GutGood 40–59 MittelFair 0–39 SchlechtPoor
Unterschied zu Lighthouse

Der Lighthouse Performance Score bewertet ausschließlich die Ladegeschwindigkeit. Der fepo Score bewertet Ihre Website ganzheitlich — er berücksichtigt zusätzlich Sicherheit, SEO, Barrierefreiheit, CSS-Qualität, Bilder und Kompression. Wenn CrUX-Felddaten (echte Nutzer) verfügbar sind, fließen diese ebenfalls ein und erhöhen die Aussagekraft des Scores.

Difference from Lighthouse

The Lighthouse Performance score evaluates loading speed only. The fepo Score rates your website holistically — it additionally considers security, SEO, accessibility, CSS quality, images and compression. When CrUX field data (real users) is available, it is incorporated too, further sharpening the score.

Cookies & Tracking Cookies & Tracking

Server-Side Tagging (SST)

Datenschutz

Server-Side Tagging verlagert das Tracking vom Browser des Nutzers auf einen eigenen Server. Anstatt dass Marketing-Pixel direkt im Browser feuern, sendet die Website nur Daten an Ihren eigenen Server — der leitet sie dann an Google Analytics, Meta, TikTok & Co. weiter. Für den Browser ist der Tracking-Server eine First-Party-Domain.

Vorteile gegenüber Client-Side Tracking
  • Ad-Blocker und Browser-Tracking-Schutz greifen nicht — die Daten kommen zuverlässig an
  • Tracker feuern nicht mehr im Browser des Nutzers, wodurch Consent-Probleme (DSGVO) minimiert werden
  • Externe Tracking-Skripte (Google Tag Manager, Meta Pixel, TikTok Pixel…) werden vollständig aus dem Browser entfernt — die Seite lädt schneller
  • Datenkontrolle: Sie entscheiden, welche Daten wirklich an Drittanbieter weitergeleitet werden
  • Bessere Datenqualität durch weniger Browser-Interferenzen (ITP, ETP, SameSite-Cookie-Einschränkungen)
Welche Services über SST laufen
  • Google Analytics 4 — vollständig über SST abbildbar inkl. E-Commerce-Events
  • Google Ads — Conversion-Tracking und Remarketing
  • Meta (Facebook) Pixel — Conversions API (CAPI) als serverseitiges Pendant
  • TikTok Pixel — Events API
  • LinkedIn Insight Tag — Conversion-Tracking
  • Pinterest Tag, Snapchat Pixel, Criteo, Hotjar — je nach Anbieter vollständig oder teilweise
  • Jeder Service, der über Google Tag Manager (GTM) eingebunden wird, kann serverseitig verwaltet werden
  • Scripts, die das DOM direkt manipulieren (z. B. Live-Chat-Widgets, Session-Recording-Tools, visuelle A/B-Testing-Snippets), können nicht über SST ausgeführt werden
Anbieter
  • TAGGRSDediziertes WooCommerce-Plugin, befüllt den GTM-Datalayer automatisch. Ideal für WooCommerce-Shops.
  • Stape.ioManaged GTM Server-Side Hosting. WordPress-Plugin verfügbar, kostengünstigster Einstieg.
  • AddingwellFranzösischer Anbieter. Hochverfügbarkeit, Premium-Support — ideal für Agenturen und hohen Traffic.
  • TracklutionManaged Server-Side-Tracking aus der EU (Helsinki), First-Party-CNAME, ISO-27001-/SOC-2-zertifiziert. Wartungsfrei, code-los — ideal für DSGVO-sensible Werbetreibende.
  • Selbst gehostetGTM Server-Side Container auf eigenem Cloud Run, VPS oder Kubernetes. Maximale Kontrolle, erfordert technisches Know-how.
Advantages over client-side tracking
  • Ad-blockers and browser tracking protection don't interfere — data arrives reliably
  • Trackers no longer fire in the user's browser, minimising consent issues (GDPR)
  • External tracking scripts (Google Tag Manager, Meta Pixel, TikTok Pixel…) are removed from the browser entirely — the page loads faster
  • Data control: you decide exactly what data gets forwarded to third parties
  • Better data quality with fewer browser interferences (ITP, ETP, SameSite cookie restrictions)
Which services work with SST
  • Google Analytics 4 — fully supported via SST including e-commerce events
  • Google Ads — conversion tracking and remarketing
  • Meta (Facebook) Pixel — Conversions API (CAPI) as the server-side equivalent
  • TikTok Pixel — Events API
  • LinkedIn Insight Tag — conversion tracking
  • Pinterest Tag, Snapchat Pixel, Criteo, Hotjar — fully or partially supported depending on provider
  • Any service managed via Google Tag Manager (GTM) can be handled server-side
  • Scripts that directly manipulate the DOM (e.g. live chat widgets, session recording tools, visual A/B testing snippets) cannot be run via SST
Providers
  • TAGGRSDedicated WooCommerce plugin, automatically populates the GTM data layer. Ideal for WooCommerce stores.
  • Stape.ioManaged GTM server-side hosting. WordPress plugin available, most cost-effective entry point.
  • AddingwellFrench provider. High availability, premium support — ideal for agencies and high-traffic sites.
  • TracklutionManaged server-side tracking based in the EU (Helsinki), first-party CNAME, ISO 27001 / SOC 2 certified. Maintenance-free, no-code — ideal for GDPR-conscious advertisers.
  • Self-hostedGTM server-side container on your own Cloud Run, VPS or Kubernetes. Maximum control, requires technical expertise.

CMP-Sichtbarkeit & Consent-Banner

CMP Visibility & Consent Banners

Datenschutz

Ein DSGVO-konformer Consent-Banner muss sofort beim Seitenaufruf sichtbar sein — bevor Nutzer scrollen oder interagieren. fepo prüft beim Audit, ob der Banner initial im Viewport liegt und ob er ohne Scroll erreichbar ist. Banner, die erst nach Scroll erscheinen oder per CSS unsichtbar sind, gelten als Verstoß.

Warum das relevant ist
  • Art. 12 DSGVO (Transparenz) — die Einwilligung muss in verständlicher und leicht zugänglicher Form eingeholt werden. Ein Banner unterhalb des Folds erfüllt das nicht.
  • § 25 TDDDG — Cookies/Tracking dürfen erst nach Einwilligung gesetzt werden. Wenn der Banner gar nicht sichtbar ist, kann der Nutzer auch nicht zustimmen.
  • EuGH C-673/17 (Planet49) — Einwilligung muss aktiv, informiert und freiwillig erteilt werden. Verzögerte Sichtbarkeit untergräbt das.
  • Dark Patterns — versteckte oder verzögerte Banner sind in der EDPB-Leitlinie 03/2022 als Verstoß kategorisiert.
Was fepo prüft
  • Initialer Viewport — ist der Banner direkt nach dem Page-Load sichtbar?
  • Scroll-Trigger (scroll_triggered: true) — Banner erschien erst nach Scroll-Aktion. Im Report wird ein Warnhinweis unter dem Screenshot angezeigt.
  • CSS-Verstecken (hidden_via_css: true) — Banner per display:none, visibility:hidden oder Off-Canvas verborgen. Klar bußgeldrelevant.
  • Reject-Pfad — gibt es einen gleichwertigen "Ablehnen"-Button? (Art. 7 Abs. 3 DSGVO: Einwilligung muss so einfach widerrufbar wie erteilbar sein.)
Häufige Fehler
  • CMP wird per JavaScript dynamisch eingefügt und braucht ~2-3 Sekunden — in dieser Zeit feuern Tracker bereits.
  • Banner liegt bewusst unterhalb der ersten Bildschirmhöhe, um "Akzeptieren"-Conversions zu erhöhen.
  • Mobile-Layout zeigt Banner, Desktop-Layout nicht (oder umgekehrt) — fepo prüft im Mobile-Profil (Moto G4, 360×640).
  • Anti-Bot-Heuristiken (Cloudflare, Akamai) blockieren den Banner für Crawler — sieht für Nutzer korrekt aus, der Audit-Crawler sieht aber nichts. In dem Fall flaggt fepo es als cmp_ghost.
Why it matters
  • Art. 12 GDPR (transparency) — consent must be obtained in a clear and easily accessible form. A banner below the fold doesn't meet that bar.
  • § 25 TDDDG (German implementation of ePrivacy) — cookies/tracking only after consent. If the banner isn't visible, the user can't consent.
  • CJEU C-673/17 (Planet49) — consent must be active, informed, and freely given. Delayed visibility undermines that.
  • Dark patterns — hidden or delayed banners are categorised as violations in EDPB Guidelines 03/2022.
What fepo checks
  • Initial viewport — is the banner visible right after page load?
  • Scroll trigger (scroll_triggered: true) — banner only appeared after scrolling. The report adds a warning hint below the screenshot.
  • CSS hiding (hidden_via_css: true) — banner hidden via display:none, visibility:hidden, or off-canvas. Clearly grounds for a fine.
  • Reject path — is there an equivalent "Reject" button? (Art. 7(3) GDPR: withdrawing consent must be as easy as giving it.)
Common mistakes
  • The CMP is injected dynamically via JavaScript and takes ~2-3 seconds — trackers fire in that window.
  • Banner is intentionally placed below the fold to boost "Accept" conversion.
  • Mobile layout shows the banner, desktop doesn't (or vice versa) — fepo audits in the mobile profile (Moto G4, 360×640).
  • Anti-bot heuristics (Cloudflare, Akamai) block the banner for crawlers — looks fine to users, but our crawler sees nothing. fepo flags this as cmp_ghost.

Tracker-Kategorien & Schweregrade

Tracker Categories & Severity

Datenschutz

Wenn fepo einen Tracker vor der Consent-Einholung erkennt, klassifiziert er ihn nach Kategorie (was tut der Tracker fachlich?) und Schweregrad (wie hoch ist das DSGVO-Risiko?). Diese Übersicht erklärt beide Achsen.

Schweregrade
  • medium — Tracker mit klarer DSGVO-Relevanz, aber begrenztem Risikoumfang (z.B. anonymisierte Analytics, CMP-eigenes Logging). Pflicht für Consent, aber kein direkter Personenbezug ohne weitere Verknüpfung.
  • high — Tracker mit erheblichem DSGVO-Risiko: identifiziert Personen oder Firmen, sammelt PII (E-Mail, Telefon, Name), profiliert via Fingerprint oder Reverse-IP-Lookup. Klare Bußgeldgefahr bei Pre-Consent.
  • critical — Aggressive Tracker mit Cross-Domain-Profiling, Daten-Verkauf an Dritte oder bekannten Compliance-Problemen. Höchste Priorität für Korrektur.
  • medium — Tracker with clear GDPR relevance but limited risk scope (e.g. anonymized analytics, CMP-own logging). Consent required, but no direct personal identification without further linkage.
  • high — Tracker with substantial GDPR risk: identifies persons or companies, collects PII (email, phone, name), profiles via fingerprint or reverse-IP lookup. Clear fine risk if loaded pre-consent.
  • critical — Aggressive trackers with cross-domain profiling, data sale to third parties or known compliance issues. Highest priority for correction.
Kategorien
KategorieWas tut der Tracker? What it doesBeispiel-Anbieter Examples
advertisingWerbe-Tracking: Conversion-Pixel, Retargeting, Ad-Attribution Ad tracking: conversion pixels, retargeting, ad attributionFacebook Pixel, Google Ads, LinkedIn Insight Tag
analyticsWeb-Analytics: Page-Views, Sessions, User-Verhalten Web analytics: page views, sessions, user behaviorGoogle Analytics, HubSpot Analytics, Matomo
audioAudio-Streaming-Embeds (Podcast-Player etc.) Audio streaming embeds (podcast players etc.)SoundCloud, Spotify Embed
b2b_reverse_ipB2B-Sales-Intelligence: identifiziert besuchende Firmen via Reverse-IP-Lookup, korreliert mit Form-Submissions zu Personen-Profilen B2B sales intelligence: identifies visiting companies via reverse-IP lookup, correlates with form submissions for person profilesLeadfeeder (Dealfront), Leadinfo, Albacross
cmp_trackingEigenes Logging des Consent-Management-Plattform-Anbieters (Heimkehr-Datentransfer) CMP-vendor's own logging (home-call data transfer)CookieYes Tracking, Cookiebot Telemetry
crmCustomer-Relationship-Tools: Live-Chat, Visitor-ID-Tracking, E-Mail-Identifikation Customer relationship tools: live chat, visitor ID tracking, email identificationHubSpot, Intercom, Drift
formForm-Tracking: Field-Analytics, Conversion-Optimization von Form-Submissions Form tracking: field analytics, form-submission conversion optimizationHotjar Forms, Mouseflow
heatmapHeatmap- & Session-Recording-Tools: zeichnen Mausbewegungen, Klicks, Scroll-Verhalten auf — oft inklusive vollständiger Session-Replays Heatmap & session recording tools: capture mouse movements, clicks, scroll behavior — often including full session replaysHotjar, Mouseflow, Clarity
marketing_platformMarketing-Automation-Plattformen: Email-Tracking, Cross-Touchpoint-Profile Marketing automation platforms: email tracking, cross-touchpoint profilesMarketo, Pardot, Eloqua
push_notificationsBrowser-Push-Notifications: Subscription-Tracking, Device-ID Browser push notifications: subscription tracking, device IDOneSignal, Pushwoosh
schedulingTermin-Buchungs-Tools mit Visitor-Tracking Appointment booking tools with visitor trackingCalendly, HubSpot Meetings
socialSocial-Media-Widgets & Share-Buttons mit eingebautem Tracking Social media widgets & share buttons with built-in trackingFacebook Like, Twitter Embed, AddThis
tag_managerTag-Management-Systeme: laden andere Tracker dynamisch nach (Single-Point-of-Many-Failures) Tag management systems: load other trackers dynamically (single point of many failures)Google Tag Manager (GTM), Tealium, Adobe Launch
videoVideo-Embeds mit Tracking (Play-Events, Watch-Duration, Cookie-Setting) Video embeds with tracking (play events, watch duration, cookie setting)YouTube Embed, Vimeo, Wistia
Was tun bei Pre-Consent-Treffer?
  • Tracker im CMP korrekt kategorisieren und Auto-Block aktivieren bis Consent erteilt
  • Hardcoded <script>-Tags im <head> entfernen — Tracker stattdessen via Tag-Manager laden lassen (der das Consent-Event respektiert)
  • Bei CMP-Tracking selbst: Vendor wechseln oder selbst hosten, falls Anbieter eigene Telemetrie nicht abschaltbar macht
  • Severity high/critical hat Priorität — diese sind oft bußgeldrelevant bei Aufsichtsbehörden-Prüfungen
  • Properly categorize trackers in your CMP and enable auto-blocking until consent is given
  • Remove hardcoded <script> tags from <head> — load trackers via a tag manager that respects the consent event
  • For CMP tracking itself: switch vendor or self-host if the provider's own telemetry can't be turned off
  • Severity high/critical takes priority — these often trigger fines during regulator audits

WCAG — Barrierefreiheit

Barrierefreiheit

Die Web Content Accessibility Guidelines (WCAG) 2.2 definieren, wie Webinhalte für Menschen mit Behinderungen zugänglich gemacht werden. fepo prüft automatisch Level A und AA — die beiden Konformitätsstufen, die gesetzlich gefordert werden.

Gesetzliche Grundlagen
  • BFSG (Barrierefreiheitsstärkungsgesetz) — Deutschland, verpflichtend ab 28. Juni 2025 für digitale Produkte und Dienstleistungen
  • EAA (European Accessibility Act) — EU-weit, Richtlinie (EU) 2019/882, nationale Umsetzung in allen Mitgliedstaaten
  • ADA / Section 508 — USA, Americans with Disabilities Act und Section 508 des Rehabilitation Act
  • Technischer Standard: EN 301 549 referenziert WCAG 2.1 Level AA als Mindestanforderung
Impact-Stufen
  • Kritisch — Inhalte sind für bestimmte Nutzergruppen komplett unzugänglich (z.B. fehlende Alt-Texte bei Bildern, kein Tastatur-Zugang)
  • Schwerwiegend — Nutzung stark eingeschränkt (z.B. unzureichender Farbkontrast, fehlende Formular-Labels)
  • Mittel — Nutzung erschwert aber möglich (z.B. fehlende Landmarks, unklare Link-Texte)
  • Gering — Best-Practice-Verstöße mit minimalem Einfluss auf die Zugänglichkeit
Häufige Verstöße
  • color-contrast — Text hat nicht genug Kontrast zum Hintergrund (mindestens 4.5:1 für normalen Text, 3:1 für großen Text)
  • image-alt — Bilder ohne Alt-Text, Screenreader können den Inhalt nicht vorlesen
  • label — Formularfelder ohne zugehöriges Label-Element
  • link-name — Links ohne erkennbaren Text (z.B. leere <a>-Tags oder nur Icons)
  • html-has-lang — Das <html>-Element hat kein lang-Attribut
Legal Framework
  • BFSG (Barrierefreiheitsstärkungsgesetz) — Germany, mandatory from June 28, 2025 for digital products and services
  • EAA (European Accessibility Act) — EU-wide, Directive (EU) 2019/882, national implementation in all member states
  • ADA / Section 508 — USA, Americans with Disabilities Act and Section 508 of the Rehabilitation Act
  • Technical standard: EN 301 549 references WCAG 2.1 Level AA as the minimum requirement
Impact Levels
  • Critical — Content completely inaccessible to certain user groups (e.g. missing alt text on images, no keyboard access)
  • Serious — Usage severely restricted (e.g. insufficient colour contrast, missing form labels)
  • Moderate — Usage hindered but possible (e.g. missing landmarks, unclear link text)
  • Minor — Best practice violations with minimal impact on accessibility
Common Violations
  • color-contrast — Text does not have sufficient contrast against its background (at least 4.5:1 for normal text, 3:1 for large text)
  • image-alt — Images without alt text, screen readers cannot convey the content
  • label — Form fields without an associated label element
  • link-name — Links without discernible text (e.g. empty <a> tags or icon-only links)
  • html-has-lang — The <html> element is missing a lang attribute
Assets & Ressourcen Assets & Resources

Bilder

Images

Performance

Bilder sind auf den meisten Websites die größte Ressource. fepo analysiert jedes Bild auf Format-Effizienz, Dateigröße und ob es überdimensioniert geladen wird.

Moderne Formate
  • AVIF — Bestes Kompressionsverhältnis, 40–60% kleiner als JPEG bei gleicher Qualität. Unterstützung: Chrome, Firefox, Safari 16.4+
  • WebP — 25–35% kleiner als JPEG, breite Browser-Unterstützung seit 2020
  • <picture>-Element nutzen: AVIF als erste Source, WebP als Fallback, Originalformat als <img>-Fallback
Überdimensionierte Bilder
  • fepo misst die tatsächliche Darstellungsgröße jedes Bildes auf einem Desktop-Viewport (2560×1440 px)
  • Ein Bild gilt als überdimensioniert, wenn seine intrinsische Breite mehr als 2× die angezeigte Breite beträgt (Retina-Toleranz)
  • Beispiel: Ein 3840 px breites Bild, das nur 800 px breit angezeigt wird, könnte auf 1600 px verkleinert werden — Einsparung ~75% der Pixel
  • srcset und sizes nutzen, damit der Browser die passende Auflösung wählt
Weitere Optimierungen
  • loading="lazy" — Bilder unterhalb des Viewports erst bei Bedarf laden (aber nicht für das LCP-Bild!)
  • width/height-Attribute setzen, um Layout-Shifts (CLS) zu vermeiden
  • fetchpriority="high" — Für das Hero-/LCP-Bild, damit es priorisiert geladen wird
Modern Formats
  • AVIF — Best compression ratio, 40–60% smaller than JPEG at equal quality. Support: Chrome, Firefox, Safari 16.4+
  • WebP — 25–35% smaller than JPEG, broad browser support since 2020
  • Use the <picture> element: AVIF as first source, WebP as fallback, original format as <img> fallback
Oversized Images
  • fepo measures the actual displayed size of each image on a desktop viewport (2560×1440 px)
  • An image is flagged as oversized when its intrinsic width exceeds 2× the displayed width (Retina tolerance)
  • Example: A 3840 px wide image displayed at only 800 px could be resized to 1600 px — saving ~75% of pixels
  • Use srcset and sizes so the browser picks the appropriate resolution
Further Optimisations
  • loading="lazy" — Defer off-screen images until needed (but not the LCP image!)
  • Set width/height attributes to prevent layout shifts (CLS)
  • fetchpriority="high" — For the hero/LCP image so it loads with priority

Fonts

Performance

Web-Fonts beeinflussen sowohl die Ladezeit als auch den Cumulative Layout Shift (CLS). fepo prüft, ob Fonts effizient geladen werden und wie viel durch Self-Hosting und Subsetting gespart werden kann.

Self-Hosting statt Google Fonts CDN
  • DSGVO-Pflicht — Google Fonts über fonts.googleapis.com zu laden überträgt die IP-Adresse des Nutzers an Google. Seit dem Urteil des LG München (Az. 3 O 17493/20) ist das ohne Einwilligung unzulässig
  • Performance — Self-Hosted Fonts eliminieren DNS-Lookup + TCP-Verbindung zu Google. Eine externe Domain weniger = schnellerer LCP
  • Tools: google-webfonts-helper generiert fertige @font-face-Regeln mit WOFF2-Dateien
Subsetting
  • Die meisten Fonts enthalten tausende Glyphen (Kyrillisch, Griechisch, CJK). Für eine deutsche Website reichen Latin + Latin Extended
  • Subsetting reduziert die Dateigröße oft um 50–80%
  • unicode-range in @font-face nutzen, damit der Browser nur die benötigten Subsets lädt
font-display
  • font-display: swap — Text sofort mit Fallback-Font anzeigen, dann tauschen wenn der Web-Font geladen ist. Verhindert unsichtbaren Text (FOIT)
  • font-display: optional — Für nicht-essentielle Fonts. Browser zeigt den Font nur an, wenn er bereits im Cache ist. Beste Performance, kein Layout-Shift
  • Font-Dateien mit rel="preload" vorladen: <link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>
Self-Hosting Instead of Google Fonts CDN
  • GDPR requirement — Loading Google Fonts via fonts.googleapis.com sends the user's IP address to Google. Under EU law, this requires explicit consent
  • Performance — Self-hosted fonts eliminate a DNS lookup + TCP connection to Google. One fewer external domain = faster LCP
  • Tools: google-webfonts-helper generates ready-to-use @font-face rules with WOFF2 files
Subsetting
  • Most fonts contain thousands of glyphs (Cyrillic, Greek, CJK). For a German website, Latin + Latin Extended is sufficient
  • Subsetting typically reduces file size by 50–80%
  • Use unicode-range in @font-face so the browser only downloads the required subsets
font-display
  • font-display: swap — Show text immediately with a fallback font, then swap when the web font loads. Prevents invisible text (FOIT)
  • font-display: optional — For non-essential fonts. Browser only uses the font if it's already cached. Best performance, no layout shift
  • Preload font files: <link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

Komprimierung

Compression

Performance

HTTP-Komprimierung reduziert die Übertragungsgröße von Text-Assets (HTML, CSS, JS, SVG, JSON) um 60–90%. fepo prüft jede Ressource auf korrekte Komprimierung.

Verfahren im Vergleich
  • Brotli (br) — Bestes Verfahren, 15–25% kleiner als Gzip. Standard in allen modernen Browsern seit 2017. Erfordert HTTPS
  • Gzip (gz) — Universell unterstützt, gute Kompression. Fallback wenn Brotli nicht verfügbar
  • Zstd — Neues Verfahren von Facebook/Meta, noch geringe Browser-Unterstützung (Chrome 123+)
  • Unkomprimiert — Verschwendung. Jede Text-Ressource ohne Komprimierung verschwendet 60–90% Bandbreite
Server-Konfiguration
  • Apachemod_brotli aktivieren: AddOutputFilterByType BROTLI_COMPRESS text/html text/css application/javascript
  • Nginxbrotli on; brotli_types text/html text/css application/javascript;
  • Statische Vorab-Komprimierung.br und .gz Dateien neben den Originalen ablegen. Der Server liefert automatisch die komprimierte Version
  • Bilder (JPEG, PNG, WebP, AVIF) nicht komprimieren — sie sind bereits komprimiert, Gzip/Brotli bringt keinen Gewinn
Methods Compared
  • Brotli (br) — Best method, 15–25% smaller than Gzip. Supported by all modern browsers since 2017. Requires HTTPS
  • Gzip (gz) — Universally supported, good compression. Fallback when Brotli is unavailable
  • Zstd — New method by Facebook/Meta, limited browser support so far (Chrome 123+)
  • Uncompressed — Wasteful. Every text resource served without compression wastes 60–90% of bandwidth
Server Configuration
  • Apache — Enable mod_brotli: AddOutputFilterByType BROTLI_COMPRESS text/html text/css application/javascript
  • Nginxbrotli on; brotli_types text/html text/css application/javascript;
  • Static pre-compression — Place .br and .gz files alongside the originals. The server automatically serves the compressed version
  • Don't compress images (JPEG, PNG, WebP, AVIF) — they're already compressed; Gzip/Brotli adds no benefit
Sicherheit Security

Content Security Policy (CSP)

Sicherheit

Einfach erklärt: Eine CSP ist wie eine Gästeliste für Ihre Website. Sie legen fest, wer rein darf (erlaubte Domains für Scripts, Styles, Bilder) — und jeder der nicht auf der Liste steht wird vom Browser abgewiesen. Ohne Gästeliste kann jeder rein — auch Einbrecher (XSS-Angriffe).

Technisch gesehen ist eine Content Security Policy ein HTTP-Response-Header, der dem Browser vorschreibt, welche Quellen für Skripte, Styles, Bilder und andere Ressourcen erlaubt sind. Verstößt eine Ressource gegen die Policy, blockiert der Browser sie — unabhängig davon, ob sie von einem Angreifer injiziert wurde oder aus einer nicht genehmigten Domain geladen wird.

Wogegen schützt eine CSP
  • XSS (Cross-Site Scripting) — verhindert das Ausführen injizierter Skripte, auch wenn ein Angreifer schadhaften Code in die Seite einschleusen konnte
  • Clickjackingframe-ancestors 'none' verhindert das Einbetten Ihrer Seite in fremde iframes
  • Datenlecksconnect-src schränkt ein, wohin die Seite Daten per fetch/XHR/WebSocket senden darf
  • Mixed Content — verhindert, dass HTTPS-Seiten unsichere HTTP-Ressourcen laden
Die wichtigsten Direktiven
  • default-src 'self' — Fallback für alle nicht explizit gesetzten Direktiven: nur die eigene Domain
  • script-src — erlaubte Skript-Quellen (kritischste Direktive — Fehler hier öffnen XSS-Lücken)
  • style-src — erlaubte CSS-Quellen
  • img-src 'self' data: https: — eigene Domain + Base64-Bilder + alle HTTPS-Bildquellen
  • font-src 'self' https://fonts.gstatic.com — eigene Fonts + Google Fonts CDN
  • connect-src 'self' — fetch/XHR/WebSocket nur zur eigenen Domain
  • frame-ancestors 'none' — Seite darf nirgendwo eingebettet werden (ersetzt den älteren X-Frame-Options: DENY Header)
Report-Only: Testen ohne Risiko

Statt Content-Security-Policy zunächst Content-Security-Policy-Report-Only verwenden. Der Browser blockiert nichts, loggt aber alle Verstöße in der Konsole (DevTools → Console). So können Sie die Policy 2–4 Wochen beobachten und anpassen, bevor sie aktiv Ressourcen blockiert.

'unsafe-inline' vermeiden

'unsafe-inline' in script-src erlaubt alle Inline-Skripte und hebt damit den XSS-Schutz weitgehend auf. Besser:

  • Nonce — serverseitig pro Request ein zufälliger Wert generiert, der gleichzeitig im Header und im <script nonce="...">-Tag steht. Nur dieses eine Script wird ausgeführt. Erfordert serverseitige Implementierung (PHP, Node.js, etc.).
  • Hash — SHA-256-Hash des Inline-Script-Inhalts in die Policy schreiben ('sha256-abc123...'). Geeignet für statischen Inline-Code, der sich nicht ändert.
  • 'unsafe-inline' in style-src ist weniger kritisch als in script-src, sollte aber langfristig ebenfalls entfernt werden
WordPress

WordPress-Core und viele Plugins setzen Inline-Skripte und -Styles. Empfohlene Vorgehensweise:

  • CSP zunächst als Report-Only in der .htaccess setzen
  • Browser-Konsole 2–4 Wochen beobachten und notieren, welche Quellen blockiert würden
  • Policy schrittweise erweitern, bis keine Verstöße mehr erscheinen
  • Danach auf Content-Security-Policy umstellen
  • Plugins, die ausschließlich externe Drittanbieter-Domains laden, explizit zur Policy hinzufügen (z. B. Google Analytics: connect-src https://www.google-analytics.com)
Einstiegs-Policy (.htaccess)
<IfModule mod_headers.c>
  Header always set Content-Security-Policy-Report-Only \
    "default-src 'self'; \
     script-src 'self' 'unsafe-inline'; \
     style-src 'self' 'unsafe-inline'; \
     img-src 'self' data: https:; \
     font-src 'self' https://fonts.gstatic.com; \
     connect-src 'self'; \
     frame-ancestors 'none'"
</IfModule>

Sobald keine Verstöße mehr auftreten, Report-Only durch Content-Security-Policy ersetzen und 'unsafe-inline' schrittweise durch Nonces oder Hashes ablösen.

What a CSP protects against
  • XSS (Cross-Site Scripting) — prevents injected scripts from executing, even if an attacker managed to insert malicious code into the page
  • Clickjackingframe-ancestors 'none' prevents your page from being embedded in third-party iframes
  • Data leaksconnect-src restricts where the page can send data via fetch/XHR/WebSocket
  • Mixed content — prevents HTTPS pages from loading insecure HTTP resources
The most important directives
  • default-src 'self' — fallback for all directives not explicitly set: own domain only
  • script-src — allowed script sources (most critical directive — mistakes here open XSS vulnerabilities)
  • style-src — allowed CSS sources
  • img-src 'self' data: https: — own domain + base64 images + all HTTPS image sources
  • font-src 'self' https://fonts.gstatic.com — own fonts + Google Fonts CDN
  • connect-src 'self' — fetch/XHR/WebSocket to own domain only
  • frame-ancestors 'none' — page cannot be embedded anywhere (replaces the older X-Frame-Options: DENY header)
Report-Only: test without risk

Instead of Content-Security-Policy, start with Content-Security-Policy-Report-Only. The browser blocks nothing but logs all violations to the console (DevTools → Console). This lets you observe and refine the policy over 2–4 weeks before it actively blocks any resources.

Avoid 'unsafe-inline'

'unsafe-inline' in script-src permits all inline scripts and largely defeats XSS protection. Better alternatives:

  • Nonce — a random value generated server-side per request, included in both the header and the <script nonce="..."> tag. Only that specific script executes. Requires server-side implementation (PHP, Node.js, etc.).
  • Hash — write the SHA-256 hash of the inline script content into the policy ('sha256-abc123...'). Suitable for static inline code that never changes.
  • 'unsafe-inline' in style-src is less critical than in script-src, but should also be removed over time
WordPress

WordPress core and many plugins inject inline scripts and styles. Recommended approach:

  • Start with CSP in Report-Only mode via .htaccess
  • Monitor the browser console for 2–4 weeks, note which sources would be blocked
  • Gradually extend the policy until no violations appear
  • Switch to Content-Security-Policy
  • Plugins loading third-party domains must be added explicitly (e.g. Google Analytics: connect-src https://www.google-analytics.com)
Starter policy (.htaccess)
<IfModule mod_headers.c>
  Header always set Content-Security-Policy-Report-Only \
    "default-src 'self'; \
     script-src 'self' 'unsafe-inline'; \
     style-src 'self' 'unsafe-inline'; \
     img-src 'self' data: https:; \
     font-src 'self' https://fonts.gstatic.com; \
     connect-src 'self'; \
     frame-ancestors 'none'"
</IfModule>

Once no violations appear, replace Report-Only with Content-Security-Policy and gradually replace 'unsafe-inline' with nonces or hashes.

Report-Panels Report Panels

CSS-AnalyseCSS Analysis

Das CSS-Panel analysiert die Stylesheets Ihrer Website: Gesamtgröße, ungenutztes CSS und Drittanbieter-Anteil. Zu viel CSS verlangsamt den Seitenaufbau — der Browser muss alle Stylesheets parsen bevor er etwas rendern kann (CSS ist render-blocking).

Warum es wichtig ist

CSS blockiert das Rendering: Kein Pixel wird gezeichnet bevor alle CSS-Dateien geladen und geparst sind. Jedes Kilobyte unbenutztes CSS verzögert den First Contentful Paint (FCP) und den Largest Contentful Paint (LCP) direkt.

Typische Ursachen & Tipps
  • Unbenutztes CSS entfernen — Tools wie PurgeCSS oder der Coverage-Tab in Chrome DevTools zeigen genau welche Regeln nicht verwendet werden
  • Critical CSS inlinen — die Styles für den sichtbaren Bereich direkt im <head> als <style> einbetten
  • CSS-Dateien zusammenführen — weniger HTTP-Requests beschleunigen den Ladevorgang
  • Drittanbieter-CSS prüfen — Plugins und Widgets laden oft eigene Stylesheets die auf vielen Seiten ungenutzt bleiben
  • CSS minifizieren — Whitespace und Kommentare entfernen spart 10–30%
Why it matters

CSS blocks rendering: not a single pixel is painted until all CSS files are loaded and parsed. Every kilobyte of unused CSS directly delays First Contentful Paint (FCP) and Largest Contentful Paint (LCP).

Common causes & tips
  • Remove unused CSS — tools like PurgeCSS or the Coverage tab in Chrome DevTools show exactly which rules aren't used
  • Inline critical CSS — embed above-the-fold styles directly in the <head> as a <style> tag
  • Combine CSS files — fewer HTTP requests speed up loading
  • Review third-party CSS — plugins and widgets often load their own stylesheets that remain unused on many pages
  • Minify CSS — removing whitespace and comments saves 10–30%

DOM-Hygiene

Das DOM-Panel analysiert die Struktur Ihres HTML-Dokuments: Anzahl der Elemente (Nodes), Verschachtelungstiefe und den Anteil von <div>-Elementen. Ein aufgeblähtes DOM verlangsamt Rendering, Layout-Berechnungen und JavaScript-Operationen.

Warum es wichtig ist

Jeder DOM-Node kostet Speicher und Rechenzeit. Bei über 1.500 Nodes werden Layout-Neuberechnungen spürbar langsamer, bei über 3.000 kann die Seite auf mobilen Geräten merklich ruckeln. Tiefe Verschachtelung (> 15 Ebenen) belastet CSS-Selektor-Matching und Event-Bubbling zusätzlich.

Typische Ursachen & Tipps
  • Unnötige Wrapper-<div>s entfernen — Page-Builder erzeugen oft 3–5 Verschachtelungsebenen für ein einzelnes Element
  • Listen und Tabellen virtualisieren — bei hunderten Einträgen nur die sichtbaren rendern
  • Lazy Rendering für Below-the-Fold-Inhalte — erst beim Scrollen ins DOM einfügen
  • HTML-Struktur vereinfachen — semantische Elemente (<section>, <article>) statt verschachtelter <div>s
Why it matters

Every DOM node costs memory and CPU time. Above 1,500 nodes, layout recalculations become noticeably slower; above 3,000, the page may visibly stutter on mobile devices. Deep nesting (> 15 levels) further impacts CSS selector matching and event bubbling.

Common causes & tips
  • Remove unnecessary wrapper <div>s — page builders often create 3–5 nesting levels for a single element
  • Virtualise lists and tables — only render visible items when dealing with hundreds of entries
  • Lazy-render below-the-fold content — insert into the DOM only when scrolled into view
  • Simplify HTML structure — use semantic elements (<section>, <article>) instead of nested <div>s

Head & Meta

Das Head-Panel prüft den <head>-Bereich Ihres HTML-Dokuments: Title-Tag, Meta-Description, Open-Graph-Tags, Canonical-URL, Viewport-Meta und hreflang-Attribute. Fehlende oder fehlerhafte Meta-Daten beeinflussen wie Ihre Seite in Suchmaschinen und sozialen Netzwerken erscheint.

Warum es wichtig ist

Meta-Tags sind der erste Eindruck Ihrer Seite — in Google-Suchergebnissen, bei Social-Media-Shares und für Crawler. Ein fehlender Title kostet Klicks, fehlende OG-Tags machen Shares unattraktiv, und ohne Canonical riskieren Sie Duplicate Content.

Typische Ursachen & Tipps
  • Title: 50–60 Zeichen, einzigartig pro Seite, Keyword am Anfang
  • Meta Description: 150–160 Zeichen, aussagekräftig, mit Call-to-Action
  • Open Graph: Mindestens og:title, og:description, og:image für ansprechende Social-Media-Previews
  • Canonical: Auf jeder Seite eine <link rel="canonical"> setzen um Duplicate Content zu vermeiden
  • Viewport: <meta name="viewport" content="width=device-width, initial-scale=1"> ist Pflicht für Mobile
Why it matters

Meta tags are your page's first impression — in Google search results, social media shares, and for crawlers. A missing title costs clicks, missing OG tags make shares unattractive, and without a canonical URL you risk duplicate content issues.

Common causes & tips
  • Title: 50–60 characters, unique per page, keyword at the start
  • Meta description: 150–160 characters, descriptive, with a call to action
  • Open Graph: At least og:title, og:description, og:image for appealing social media previews
  • Canonical: Set a <link rel="canonical"> on every page to avoid duplicate content
  • Viewport: <meta name="viewport" content="width=device-width, initial-scale=1"> is mandatory for mobile

Browser-KonsoleBrowser Console

Das Konsolen-Panel zeigt JavaScript-Fehler und Warnungen die beim Laden Ihrer Seite auftreten. Fehler können Funktionen blockieren (z.B. Formulare, Navigation, Tracker), Warnungen deuten auf veraltete APIs oder Kompatibilitätsprobleme hin.

Warum es wichtig ist

JS-Fehler sind für Besucher unsichtbar aber oft geschäftskritisch: ein kaputtes Tracking-Script bedeutet fehlende Daten, ein fehlerhaftes Checkout-Script kostet direkt Umsatz. Jeder Fehler ist auch ein Hinweis auf technische Schulden.

Typische Ursachen & Tipps
  • Fehlende Ressourcen (404) — Scripts oder Stylesheets die nicht mehr existieren
  • CORS-Fehler — Drittanbieter-Scripts die von einer falschen Domain geladen werden
  • Veraltete APIs — document.write(), synchrone XHR, nicht-sichere Cookies
  • Plugin-Konflikte — mehrere Scripts die auf dasselbe DOM-Element zugreifen
  • Mixed Content — HTTP-Ressourcen auf einer HTTPS-Seite
Why it matters

JS errors are invisible to visitors but often business-critical: a broken tracking script means missing data, a faulty checkout script directly costs revenue. Every error is also a sign of technical debt.

Common causes & tips
  • Missing resources (404) — scripts or stylesheets that no longer exist
  • CORS errors — third-party scripts loaded from the wrong domain
  • Deprecated APIs — document.write(), synchronous XHR, insecure cookies
  • Plugin conflicts — multiple scripts accessing the same DOM element
  • Mixed content — HTTP resources on an HTTPS page

Plattform-ErkennungPlatform Detection

Das Plattform-Panel erkennt automatisch welches CMS, Framework oder welchen Hosting-Stack Ihre Website verwendet. Diese Information bestimmt welche Optimierungen möglich sind und welche von der Plattform eingeschränkt werden.

Warum es wichtig ist

Jede Plattform hat eigene Stärken und Limitierungen. WordPress erlaubt volle Kontrolle über CSS und JS, Shopify beschränkt den Zugriff auf das Theme und liefert eigene Scripts aus. Zu wissen welche Plattform im Einsatz ist, hilft bei der Einschätzung welche Empfehlungen umsetzbar sind.

Was wir erkennen
  • CMS: WordPress, Shopify, Wix, Squarespace, TYPO3, Drupal, Joomla, HubSpot, Webflow
  • Page Builder: Elementor, Divi, WPBakery, Oxygen, Bricks
  • Frameworks: Next.js, Nuxt, Gatsby, SvelteKit, Astro
  • Server: Apache, Nginx, LiteSpeed, Cloudflare, Vercel, Netlify
  • Optimierbar vs. eingeschränkt: Wir zeigen welche Bereiche (CSS, JS, Bilder, Fonts) bei Ihrer Plattform optimiert werden können und welche nicht
Why it matters

Every platform has its own strengths and limitations. WordPress allows full control over CSS and JS, while Shopify restricts access to the theme and ships its own scripts. Knowing the platform helps assess which recommendations are actionable.

What we detect
  • CMS: WordPress, Shopify, Wix, Squarespace, TYPO3, Drupal, Joomla, HubSpot, Webflow
  • Page builders: Elementor, Divi, WPBakery, Oxygen, Bricks
  • Frameworks: Next.js, Nuxt, Gatsby, SvelteKit, Astro
  • Servers: Apache, Nginx, LiteSpeed, Cloudflare, Vercel, Netlify
  • Optimisable vs. restricted: We show which areas (CSS, JS, images, fonts) can be optimised on your platform and which cannot

AI-Sichtbarkeit (GEO)

AI Visibility (GEO)

GEO (Generative Engine Optimization) prüft ob Ihre Website für KI-Suchsysteme wie ChatGPT, Perplexity, Google AI Overviews und Claude optimiert ist. Wenn KI Ihre Seite nicht finden und zitieren kann, verlieren Sie zunehmend Traffic an Wettbewerber die in KI-Antworten erscheinen.

Was geprüft wird
  • robots.txt: Sind AI-Crawler (GPTBot, ClaudeBot, PerplexityBot, etc.) erlaubt? Wenn blockiert, kann keine KI Ihre Inhalte indexieren.
  • llms.txt: Eine neue Datei die KI-Systemen beschreibt was Ihre Seite bietet — ähnlich wie robots.txt für Suchmaschinen.
  • Schema.org Markup: FAQPage, Article, Organization, Author — strukturierte Daten die KI versteht und zitiert. FAQ-Schema erhöht die KI-Zitationsrate um ~28%.
  • Content-Struktur: Überschriften als Fragen formuliert? Antwort in den ersten 40-60 Wörtern? TL;DR-Block vorhanden? KI extrahiert bevorzugt klar strukturierte Inhalte.
  • Quellenangaben: Externe Links zu Primärquellen. KI vertraut belegten Inhalten (+41% Sichtbarkeit).
  • Aktualität: datePublished und dateModified im Schema/Meta — KI bevorzugt aktuelle Inhalte.
  • Open Graph: og:title, og:description, og:image — verbessert die Darstellung in KI-Antworten und Social Media.
Warum es wichtig ist

Immer mehr Nutzer suchen über KI statt über klassische Suchmaschinen. Google AI Overviews, ChatGPT Search, Perplexity — diese Systeme zitieren Websites die technisch und inhaltlich für KI optimiert sind. Wer nicht optimiert ist, wird nicht zitiert und verliert Sichtbarkeit.

Was Sie tun können
  • AI-Crawler in der robots.txt erlauben (GPTBot, ClaudeBot, PerplexityBot)
  • Eine llms.txt Datei erstellen die Ihre Website beschreibt
  • FAQ-Schema für häufig gestellte Fragen einbauen (JSON-LD im <head>)
  • Überschriften als Fragen formulieren und direkt beantworten
  • Statistiken und Aussagen mit Quellen belegen
  • Veröffentlichungsdatum und Änderungsdatum im Schema pflegen
  • Open Graph Tags vollständig einrichten

fepo generiert für jeden fehlgeschlagenen Check eine konkrete Empfehlung mit Copy-Paste-Code — Schema.org JSON-LD, Open Graph Tags, llms.txt Template — alles basierend auf dem tatsächlichen Inhalt Ihrer Seite.

What we check
  • robots.txt: Are AI crawlers (GPTBot, ClaudeBot, PerplexityBot, etc.) allowed? If blocked, no AI can index your content.
  • llms.txt: A new file that tells AI systems what your site offers — similar to robots.txt for search engines.
  • Schema.org Markup: FAQPage, Article, Organization, Author — structured data that AI understands and cites. FAQ schema increases AI citation rate by ~28%.
  • Content structure: Headings as questions? Answer in the first 40-60 words? TL;DR block? AI preferably extracts clearly structured content.
  • Citations: External links to primary sources. AI trusts cited content (+41% visibility).
  • Freshness: datePublished and dateModified in Schema/Meta — AI prefers current content.
  • Open Graph: og:title, og:description, og:image — improves presentation in AI answers and social media.
Why it matters

More and more users search via AI instead of traditional search engines. Google AI Overviews, ChatGPT Search, Perplexity — these systems cite websites that are technically and content-wise optimised for AI. Those who are not optimised will not be cited and lose visibility.

What you can do
  • Allow AI crawlers in robots.txt (GPTBot, ClaudeBot, PerplexityBot)
  • Create an llms.txt file describing your website
  • Add FAQ schema for frequently asked questions (JSON-LD in <head>)
  • Phrase headings as questions and answer them directly
  • Back up statistics and claims with source links
  • Maintain publication and modification dates in schema
  • Set up complete Open Graph tags

fepo generates a concrete recommendation with copy-paste code for each failed check — Schema.org JSON-LD, Open Graph tags, llms.txt template — all based on the actual content of your page.

fepo-Bot fepo Bot

fepo-Bot freischalten

Allowing the fepo Bot

Konfiguration Configuration

fepo verwendet zwei Crawler-Identitäten: den Playwright-Crawler (regulärer Chrome-UA, für alle Lab-Metriken) und den Lighthouse-Crawler (UA: Chrome-Lighthouse). Manche WAFs, Firewall-Regeln oder robots.txt-Einträge blockieren einen oder beide — was zu unvollständigen Messungen führt. Diese Seite zeigt, wie Sie den fepo-Bot freigeben.

robots.txt

Wenn Lighthouse-Metriken fehlen oder im Report als "blockiert" markiert sind, prüfen Sie Ihre robots.txt. Fügen Sie folgende Zeilen hinzu, um den Lighthouse-Crawler explizit zu erlauben:

If Lighthouse metrics are missing or marked as "blocked" in the report, check your robots.txt. Add the following lines to explicitly allow the Lighthouse crawler:

User-agent: Chrome-Lighthouse
Allow: /

User-agent: Cruxvis
Allow: /

Falls Sie alle Bots außer bestimmten sperren, stellen Sie sicher, dass diese Einträge vor dem User-agent: *-Block stehen.

If you block all bots except specific ones, make sure these entries appear before the User-agent: * block.

Cloudflare — Bot Fight Mode / WAF

Cloudflares Bot Fight Mode und Super Bot Fight Mode können den fepo-Crawler blockieren oder mit CAPTCHA-Challenges bremsen. Erstellen Sie eine WAF-Bypass-Regel für die fepo-Server-IP:

Cloudflare's Bot Fight Mode and Super Bot Fight Mode can block the fepo crawler or slow it down with CAPTCHA challenges. Create a WAF bypass rule for the fepo server IP:

  1. Cloudflare Dashboard → Security → WAF → Custom rules
  2. Neue Regel: Field = IP Source Address, Operator = equals, Value = fepo-IP (siehe unten)
  3. Action = Skip → All remaining custom rules + Bot Fight Mode überspringen aktivieren
  4. Cloudflare Dashboard → Security → WAF → Custom rules
  5. New rule: Field = IP Source Address, Operator = equals, Value = fepo IP (see below)
  6. Action = Skip → All remaining custom rules + enable Skip Bot Fight Mode

Die aktuelle fepo-Server-IP erhalten Sie auf Anfrage an support@fepo.app.

The current fepo server IP is available on request at support@fepo.app.

Andere WAFs (nginx, Apache, Sucuri, Wordfence …)

Erlauben Sie die fepo-Server-IP in Ihrer Firewall-Konfiguration oder erstellen Sie eine Ausnahmeregel für den User-Agent Chrome-Lighthouse. Bei Wordfence: Firewall → Whitelisted IPs. Bei Sucuri: Settings → Allowlisting.

Allow the fepo server IP in your firewall configuration or create an exception rule for the user agent Chrome-Lighthouse. For Wordfence: Firewall → Whitelisted IPs. For Sucuri: Settings → Allowlisting.

WPT als Fallback

Wenn der fepo-Crawler durch eine WAF blockiert wird, kann fepo automatisch auf WebPageTest (WPT) umschalten. WPT-Testserver sind bei vielen WAFs bekannt und whitelisted. Lighthouse-Metriken werden dann über die WPT-API gemessen statt lokal — mit identischem Throttling-Profil (Moto G4, Mobile 4G).

If the fepo crawler is blocked by a WAF, fepo can automatically fall back to WebPageTest (WPT). WPT test servers are known and whitelisted by many WAFs. Lighthouse metrics are then measured via the WPT API instead of locally — with an identical throttling profile (Moto G4, Mobile 4G).