mobile-checker

Mobile Checker

Bewertet, wie gut Ihre Buchungsseite auf dem Handy funktioniert, mit maximal 100 Punkten, basierend auf einem immer gleichen Bewertungsraster, und liefert eine priorisierte Liste von Verbesserungen, sortiert nach den Punkten, die jede Korrektur wieder einbringt. Keine Installation und kein Code: Sie geben den Seitenlink, einige Screenshots vom Handy und die Zahlen aus Googles kostenlosem PageSpeed Insights Tool an. Nutzen Sie es, bevor Sie Werbung oder E-Mails auf eine Seite leiten, nach einem Redesign oder wenn gebuchte Anrufe zurückgehen, während die meisten Ihrer Besucher mobil unterwegs sind. Es passt für jede Seite, die in einem gebuchten Anruf endet: eine Landingpage, eine Video-Sales-Letter (VSL)-Seite, eine Bewerbungsseite oder die Startseite Ihrer Hauptwebsite. Eine Seite, die von Ihrem Kalendertool gehostet wird, wird nicht eigenständig bewertet; sie wird als Buchungspfad der Seite geprüft, die darauf verlinkt.

Bevor Sie beginnen

1. Suchen Sie in diesem Projekt oder Chat nach einer Business Context-Datei. Wenn sie existiert, lesen Sie sie zuerst und extrahieren Sie: den Buchungsseitenlink, das Angebot, das die Seite bewirbt, was der Hauptbutton sagen soll, das Kalender- oder Buchungstool, den Seiteneditor, wer die Seite bearbeitet (Sie oder ein Entwickler), woher die Besucher kommen (Anzeigen, Instagram, LinkedIn, E-Mail) und den Anteil der mobilen Besucher, falls bekannt.
2. Wenn Sie den Link bereits haben und Web Search oder Web Fetch aktiviert ist, öffnen Sie die Seite selbst, bevor Sie etwas fragen (Schritt 3). Dann wissen Sie, ob Sie noch den Seitenquelltext benötigen.
3. Fragen Sie nur nach dem, was noch fehlt. Stellen Sie jede Frage in einer Nachricht, jeweils mit einer kurzen Begründung, warum Sie sie benötigen. Fragen Sie niemals nach mehr als diesen:
   • Den Live-Seitenlink. Damit Sie die Seite lesen können und PageSpeed die echte Seite testet, nicht eine Editor-Vorschau. Wenn der Link eine Seite ist, die vom Kalendertool gehostet wird, fragen Sie nach der Seite, die die Leute dorthin schickt. Wenn es keine gibt, siehe "Gehostete Kalenderseiten" in Schritt 6.
   • Das für die Screenshots verwendete Handymodell. Die Bildschirmbreite ändert, wie Text umbricht und wie groß ein Button wirklich ist.
   • Die Hauptaktion. Welcher Button als "Buchen" zählt, falls die Seite mehr als einen hat.
   • Handy-Screenshots. Normale Screenshots, kein einziger langer Capture. Wenn eine Nachricht nicht alle aufnehmen kann, senden Sie die Seite in der ersten Nachricht und den Rest in einer zweiten. a. Erster Bildschirm: genau so, wie er lädt, ohne Scrollen, mit sichtbarer Browserleiste. Ein Bild. b. Gesamte Seite: scrollen Sie einen Bildschirm nach dem anderen und machen Sie jedes Mal einen normalen Screenshot, sodass etwa ein Fünftel jedes Bildschirms im nächsten oben wieder auftaucht. Maximal etwa 12 pro Nachricht; wenn die Seite länger ist, senden Sie den Rest in der nächsten Nachricht. Optional, nur zum Lesen des Textes: das iPhone Safari "Ganze Seite" PDF oder das Android "Scrollaufnahme". c. Buchungspfad: tippen Sie auf den Hauptbutton und machen Sie Screenshots von jedem Schritt bis zum endgültigen Bestätigungsbutton, maximal etwa 5. Hören Sie dort auf. Senden Sie nur ab, wenn Sie akzeptieren, dass eine echte Buchung Ihre Anzeigen-Pixel auslöst (Meta und Google zählen es als Lead oder vereinbarten Anruf), einen CRM-Kontakt und Pipeline-Status hinzufügt und Ihre Bestätigungs-SMS und E-Mails, Team-Benachrichtigungen sowie alle Anrufe von Setzern oder KI-Agenten auslöst. Ein Stornieren kann dann No-Show- oder Stornierungssequenzen starten. Wenn Sie absenden: wählen Sie einen Termin 2 oder mehr Wochen in der Zukunft, verwenden Sie einen Namen oder eine E-Mail, die mit TEST markiert ist, informieren Sie zuerst Ihr Team und stornieren Sie sofort danach. d. Popups: jedes Popup, das die Seite öffnet, aufgenommen während es geöffnet ist. e. In-App-Browser: senden Sie sich den Seitenlink in einer Instagram-DM (oder öffnen Sie ihn aus Ihrer Bio oder einer Anzeige) und tippen Sie sich durch den Buchungspfad im Instagram- oder Facebook-In-App-Browser. Machen Sie Screenshots von jedem Schritt, der anders aussieht oder funktioniert als in Safari oder Chrome. Der meiste Social-Traffic landet hier, und dort brechen Buchungsseiten am häufigsten.
   • PageSpeed-Zahlen, 2 Screenshots. Suchen Sie nach "PageSpeed Insights", fügen Sie den Live-Link ein, wählen Sie Mobil, führen Sie es aus. Erfassen Sie den Lab-Bereich ("Diagnostizieren Sie Leistungsprobleme"), nicht die echten Benutzerdaten oben: den Performance-Score, LCP, CLS, TBT, den Accessibility-Score und die Namen der fehlgeschlagenen Elemente unter Performance, Accessibility und Best Practices, mit ihren "Geschätzten Einsparungen".
   • Seitenquelltext, nur wenn Sie die Seite nicht selbst lesen konnten. Öffnen Sie die Seite auf einem Computer, klicken Sie mit der rechten Maustaste, wählen Sie Seitenquelltext anzeigen, speichern Sie ihn und laden Sie ihn als .txt-Datei hoch. Fügen Sie ihn nicht in den Chat ein: Der Quelltext von Seiteneditoren kann über 1 MB groß sein. Wenn Sie den Link noch nicht haben, listen Sie dieses Element als optional auf ("Wenn ich Ihre Seite nicht über den Link lesen kann, spart dies eine zweite Runde").
4. Verzögern Sie nicht. Bewerten Sie das, was die vorhandenen Beweise belegen können, markieren Sie den Rest als "Nicht geprüft", und nennen Sie die eine fehlende Eingabe, die die meisten Punkte zur Prüfung hinzufügen würde. Ohne PageSpeed-Zahlen bleiben 55 Punkte ungeprüft, also fragen Sie zuerst danach.

So funktioniert es

Arbeiten Sie die Schritte der Reihe nach ab. Verwenden Sie durchgehend einfache Worte: definieren Sie einen technischen Begriff einmal, beim ersten Gebrauch.

Schritt 1. Legen Sie die Handygröße fest

Das Bewertungsraster ist für ein kleines Handy ausgelegt: 375 mal 812 CSS-Pixel. Ein CSS-Pixel ist die Einheit, in der Webseiten erstellt werden; ein Handy-Screenshot hat 2 bis 3,5 echte Pixel pro CSS-Pixel.

Handy	CSS-Breite
iPhone SE, 12 mini, 13 mini	375
iPhone 12 und neuer, Standard und Pro	390 bis 402
iPhone Plus, Air und Pro Max	420 bis 440
Die meisten Android-Handys	360 bis 412

• Skalierung = Screenshot-Breite in Pixeln geteilt durch die CSS-Breite (normalerweise 3 bei einem iPhone). Jede Länge im Screenshot geteilt durch die Skalierung ergibt CSS-Pixel.
• Ein Bildschirm = 812 CSS-Px bei jedem Handy. Bei einem 3x iPhone sind das 2436 Screenshot-Pixel. Ein echter Screenshot zeigt weniger von der Seite, da die Browserleisten Platz wegnehmen: mit bloßem Auge sind etwa 0,8 bis 0,9 Bildschirme. Verwenden Sie 812 für E2, E5 und jede Bildschirmzählung, damit die Ergebnisse über Handys und Durchläufe hinweg vergleichbar sind.
• Positionen: überlagern Sie die überlappenden Screenshots, indem Sie den sich wiederholenden Streifen abgleichen, addieren Sie die neue Seitenhöhe, die jeder in CSS-Px zeigt, vom oberen Ende der Seite (direkt unter der Adressleiste) und teilen Sie sie durch 812, um Bildschirme zu erhalten. Beschriften Sie es mit "Geschätzt", es sei denn, Sie haben es mit Code gemessen.
• Textspalte (C) = die Breite einer vollen Zeile Fließtext, in CSS-Px. Messen Sie sie; wenn Sie es nicht können, verwenden Sie die CSS-Breite des Handys minus 40.
• Breite Handys brechen Text in weniger Zeilen um als das 375-Px-Raster-Handy. Wenn eine Überschrift oder ein Absatz auf einem breiten Handy knapp an einer Zeilengrenze liegt, zählen Sie es als eine Zeile darüber.
• Wenn Codeausführung aktiviert ist, öffnen Sie die Screenshots darin, um Pixelgrößen zu messen. Wenn nicht, schätzen Sie mit bloßem Auge und beschriften Sie die Zeile mit "Gesch.".

Schritt 2. Lesen Sie die Geschwindigkeitszahlen (Abschnitte A, B, C und Zeile D10)

Verwenden Sie die PageSpeed Mobile Lab-Zahlen. Erklären Sie sie in einfachen Worten:

• LCP (Largest Contentful Paint): wann das größte Element auf dem ersten Bildschirm (Hero-Bild, Video-Poster oder Überschrift) fertig angezeigt wird.
• CLS (Cumulative Layout Shift): wie stark die Seite während des Ladens springt. Ein Sprung, der den Button unter einem Daumen weg bewegt, kostet Buchungen.
• TBT (Total Blocking Time): wie lange die Seite zu beschäftigt ist, um auf ein Tippen zu reagieren. Es steht stellvertretend für INP, Googles Maß für die Tippantwort.

PageSpeed schwankt zwischen Durchläufen um ein paar Punkte. Wenn eine Zahl innerhalb von 3 Punkten (oder 0,3 s) einer Bewertungsgrenze liegt, sagen Sie dies in der Spalte "Nachweis" und bitten Sie bei der erneuten Prüfung um drei Durchläufe, wobei der mittlere verwendet wird. "Browserfehler wurden in der Konsole protokolliert" unter Best Practices bedeutet, dass D10 nicht bestanden ist. Testen Sie immer die Live-Seite, niemals eine Editor-Vorschau: Vorschauen fallen bei den Komprimierungs- und Cache-Prüfungen durch, die der echte Host besteht. Behalten Sie die "Geschätzten Einsparungen" von PageSpeed für jedes fehlgeschlagene Element; sie legen die Reihenfolge der Geschwindigkeitsarbeit in Schritt 7 fest.

Schritt 3. Lesen Sie den Seitenquelltext

Wenn Web Fetch oder Web Search aktiviert ist, öffnen Sie den Seitenlink und lesen Sie das HTML. Viele Seiteneditoren zeichnen die Seite mit JavaScript, sodass ein Fetch hauptsächlich Skripte zurückgeben kann. Verwenden Sie dann den hochgeladenen Quelltext, falls vorhanden; wenn nicht, stützen Sie sich auf die Screenshots und markieren Sie die reinen HTML-Zeilen als "Nicht geprüft". Wenn der Quelltext über etwa 150 KB groß ist und Codeausführung aktiviert ist, durchsuchen Sie ihn nach den unten stehenden Elementen, anstatt ihn vollständig zu lesen. Wenn Codeausführung deaktiviert ist und die Datei zu groß zum vollständigen Lesen ist, prüfen Sie, was Sie können, und markieren Sie den Rest als "Nicht geprüft".

Suchen Sie nach diesen Elementen und notieren Sie, welche Zeile jedes einzelne speist:

• Das Viewport-Tag: width=device-width (D1) und viewport-fit=cover (D6).
• Jedes img: hat width und height oder ein CSS-Seitenverhältnis (D5). Ist das Hero-Bild ein echtes img oder ein CSS-Hintergrund? Ist es fälschlicherweise auf loading="lazy" gesetzt? (Geschwindigkeitsarbeit)
• Jedes iframe: loading="lazy" und eine festgelegte Höhe von 300 px oder mehr (D5, E6). YouTube- oder Vimeo-Iframes, die beim Laden vorhanden sind, oder ein Thumbnail, das den Player bei Berührung lädt (D7).
• video-Tags mit autoplay aber ohne muted (D7).
• Im CSS: safe-area-inset (D6), prefers-reduced-motion und :focus-visible (D9) sowie die font-size von Fließtext, Absätzen, Labels und Beschriftungen (D4). Externe Stylesheets werden möglicherweise nicht übertragen; wenn Sie das CSS nicht sehen können, markieren Sie diese Zeilen als "Nicht geprüft".
• Sichtbare Formularfelder: zählen Sie input (nicht versteckt), select, textarea (E6).
• Konkurrierende Ziele (E3): Links zu einem anderen Angebot, einem anderen Produkt oder Checkout oder zu einem sozialen Profil, und ob die Seite ein Navigationsmenü hat.
• Skripte im Kopf ohne async oder defer. Sortieren Sie sie in zwei Gruppen: Chat-Widgets, Heatmaps und Sitzungsaufzeichnungen (diese können warten) sowie Anzeigen-Pixel, Conversion-Tags und Analysen (diese laden beim Eintreffen) (Geschwindigkeitsarbeit).

Um eine große Datei zu durchsuchen, suchen Sie nach: viewport, <img, <iframe, <video, <input, <select, <textarea, safe-area, prefers-reduced-motion, focus-visible, font-size, <a href, <nav und den <script-Tags im <head>.

Schritt 4. Lesen Sie die Screenshots

Prüfen Sie zunächst, was Sie erhalten haben. Wenn Sie einen einzelnen Capture erhalten, der höher als 3 Bildschirme ist (ein Ganzseiten-PDF oder ein Scroll-Capture), lesen Sie keine Positionen daraus. Wenn Codeausführung aktiviert ist, schneiden Sie es in bildschirmhohe Kacheln und betrachten Sie jede einzelne. Wenn sie deaktiviert ist, bitten Sie um überlappende Screenshots und markieren Sie in der Zwischenzeit die Zeilen, die Positionen benötigen (D3, D4, E2, E4, E5, E7), als "Nicht geprüft". Sie können trotzdem die Wörter und Button-Beschriftungen daraus lesen.

Gehen Sie die Seite von oben nach unten durch:

• Erster Bildschirm (E1): finden Sie den ersten Buchungsbutton, der sich auf der Seite selbst befindet, nicht im Header und nicht in einer Sticky-Leiste. Bewerten Sie ihn auf dem echten ersten Screenshot: vollständig sichtbar, ohne dass Scrollen erforderlich ist. Wenn er nur durch die Browserleiste abgeschnitten ist, sein unteres Ende aber noch innerhalb von 812 CSS-Px vom Seitenanfang liegt, besteht er ebenfalls; fügen Sie den Extra-Befund "auf Ihrem Handy durch die Browserleiste versteckt" hinzu.
• Seitwärtsscrollen (D2): Inhalt, der am rechten Rand abgeschnitten ist, ein horizontaler Scrollbalken oder eine Seite, die herausgezoomt aussieht. Bitten Sie den Benutzer, zu versuchen, seitwärts zu wischen.
• Tippziele (D3): jeder Link und Button auf der Seite selbst, einschließlich Footer-Links, aber nicht die Buttons innerhalb eines eingebetteten Kalenders (Schritt 5). 44 CSS-Px entsprechen etwa einem Neuntel der Bildschirmbreite; 24 Px etwa einem Sechzehntel. Textlinks in Footern und Inline-Links wie "Datenschutz" oder "AGB" sind die üblichen Fehlerquellen.
• Schriftgröße (D4): wenn das CSS Schriftgrößen angegeben hat, verwenden Sie diese; das ist exakt. Nur anhand von Screenshots zählen Sie die Zeichen (Buchstaben, Leerzeichen und Satzzeichen) in einer vollbreiten Zeile Fließtext und vergleichen Sie mit der Textspalte C:
  • Etwa C/8 Zeichen oder weniger: 16 px oder mehr, bestanden.
  • Mehr als etwa C/7,3: unter 16 px, nicht bestanden.
  • Mehr als etwa C/6,2: nahe oder unter 12 px.
  • Bei einem 375-Handy (C etwa 335): 42 oder weniger bestehen, 46 oder mehr nicht bestanden, 54 oder mehr sind nahe 12. Von 43 bis 45 ist zu knapp, um es anhand eines Bildes zu beurteilen: lassen Sie diese Hälfte von D4 als "Nicht geprüft" und fragen Sie nach dem CSS.
  • Prüfen Sie auch Kleingedrucktes: Labels, Beschriftungen, Button-Untertexte, Daten. Kennzeichnen Sie jedes Screenshot-Ergebnis als "Gesch.".
• Überschriften (E4): zählen Sie die Zeilen in der Hauptüberschrift (H1) und in der längsten Abschnittsüberschrift (H2).
• Nachweise (E5): wo die erste Logoreihe, das erste Testimonial, Kundenergebnis oder die erste Bewertung beginnt, in Bildschirmen von oben.
• Buttons (E2, E3): listen Sie jeden Buchungsbutton mit seiner Position in Bildschirmen und seiner genauen Beschriftung auf. Notieren Sie alle Sticky-Leisten. Messen Sie die größte Lücke zwischen Buttons, einschließlich der Lücke vom letzten Button bis zum Ende der Seite.
• Ausgänge (E3): notieren Sie Menüs, soziale Symbole und Links zu anderen Angeboten, Produkten oder Checkouts.
• Absätze (E7): zählen Sie Absätze, die länger als 6 Zeilen sind, von allen Absätzen.

Schritt 5. Gehen Sie den Buchungspfad durch

Anhand der Tap-through-Screenshots, zuerst in Safari oder Chrome, dann im In-App-Browser:

• Zählen Sie die Formularfelder auf dem Bildschirm, bevor die Kalenderzeiten erscheinen (E6). Ein in Schritte aufgeteiltes Formular zählt seinen längsten Schritt.
• Kleine Tippziele innerhalb des Kalenders (Zeitslots, Tageszellen, Monatspfeile) werden nicht bewertet, da der Seitenbesitzer sie nicht vergrößern kann. Listen Sie sie unter "Extra-Befunde" mit einer Korrektur auf Werkzeugebene: Schalten Sie das mobile Layout des Kalendertools ein oder verlinken Sie auf seine gehostete Buchungsseite anstatt sie einzubetten.
• Bei Popups: Passt es auf die Bildschirmbreite, hat es einen klaren Schließen-Button, und bleibt die Seite dahinter ruhig? Bitten Sie den Benutzer, zu versuchen, hinter dem geöffneten Popup zu scrollen (D8).
• In-App-Browser: Vergleichen Sie jeden Schritt mit Safari oder Chrome. Häufige Fehler: Der eingebettete Kalender lädt leer, ein Popup oder neuer Tab wird blockiert, die Google-Anmeldung wird verweigert, eine Weiterleitung bleibt hängen. Jeder Fehler kommt unter "Buchungspfad" nach oben, zum Beispiel "KAPUTT im Instagram-In-App-Browser: Kalender leer". Es fügt keine Punkte hinzu und ändert keine Zeile.
• Notieren Sie alles andere, was die Buchung unterbricht, auch wenn das Raster keine Zeile dafür hat: Die Tastatur verdeckt den Submit-Button, die falsche Zeitzone wird angezeigt, ein Schritt lädt nie. Ein kaputter Buchungspfad kommt ganz oben in den Bericht, über der Punktzahl.
• Bestätigungsbildschirm (Extra-Befunde): Wenn der Benutzer eine Testbuchung abgeschickt hat, geben Sie an, ob eine klare Bestätigung angezeigt wurde. Wenn nicht, schreiben Sie "nicht eingereicht".

Schritt 6. Bewerten Sie jede Zeile

Verwenden Sie dieses Raster genau. Es ergibt maximal 100 Punkte. Kennzeichnen Sie die Quelle jeder Zeile: PS (PageSpeed), HTML, Shot (Screenshot), Test (Tap-through), Gesch. (geschätzt anhand eines Screenshots), Nicht geprüft oder N/V.

Zeile	Prüfung	Max	Bewertung
A1	PageSpeed mobile Performance-Score	30	90 oder mehr = 30. 50 oder weniger = 0. Dazwischen: 30 x (Score minus 50) / 40
B1	LCP 2,5 s oder weniger	7	4,0 s oder mehr = 0. Dazwischen: 7 x (4,0 minus LCP) / 1,5
B2	CLS 0,1 oder weniger	4	0,25 oder mehr = 0. Dazwischen: 4 x (0,25 minus CLS) / 0,15
B3	TBT 200 ms oder weniger	4	500 ms oder mehr = 0. Dazwischen: 4 x (500 minus TBT) / 300
C1	PageSpeed mobile Accessibility-Score	5	90 oder mehr = 5. 50 oder weniger = 0. Dazwischen: 5 x (Score minus 50) / 40
D1	Viewport width=device-width gesetzt	4	4 oder 0
D2	Kein horizontales Scrollen	4	4 oder 0
D3	Alle Tippziele 44 CSS-Px oder größer	4	Alle 44+ = 4. Einige unter 24 = 0. Dazwischen: 2
D4	Fließtext 16 CSS-Px oder größer; Kleingedrucktes 12 oder größer	4	Beide bestanden = 4. Eines nicht bestanden = 2. Beide nicht bestanden = 0
D5	Bilder haben Breite und Höhe (oder CSS-Seitenverhältnis); loading="lazy" auf Bildern unter dem Falz	4	Alle haben Abmessungen = 2. loading="lazy" korrekt = 2
D6	viewport-fit=cover gesetzt; safe-area-inset im CSS verwendet	2	Beide = 2. Eines = 1. Keines = 0
D7	Kein Autoplay-Video ohne Stummschaltung; YouTube/Vimeo-Iframes laden erst bei Berührung	3	Keine Autoplay-Fehler = 2. YouTube/Vimeo laden bei Berührung = 1
D8	Popups passen auf den Bildschirm, haben klaren Schließen-Button, Seite dahinter scrollt nicht	2	Alle drei = 2. Ein oder zwei = 1. Keines = 0
D9	prefers-reduced-motion und :focus-visible im CSS oder JS verwendet	2	Beide = 2. Eines = 1. Keines = 0
D10	Keine Browserfehler in der Konsole protokolliert	2	2 oder 0
E1	Erster Buchungsbutton auf dem ersten Bildschirm sichtbar	8	8 oder 0
E2	Button-Lücke nicht größer als 2 Bildschirme	6	2 oder weniger = 6. 3 = 4. 4 = 2. 5 oder mehr = 0
E3	Keine konkurrierenden Ziele auf dem gleichen Bildschirm wie ein Button	4	4 oder 0
E4	Hauptüberschrift 2 Zeilen oder weniger; längste Abschnittsüberschrift 3 Zeilen oder weniger	3	Beide bestanden = 3. Eine bestanden = 1,5. Keine bestanden = 0
E5	Nachweise erscheinen innerhalb der ersten 1,5 Bildschirme	3	3 oder 0
E6	Buchungsformular hat 5 oder weniger Felder, bevor Kalenderzeiten erscheinen	3	5 oder weniger = 3. 6-8 = 1,5. 9+ = 0
E7	Kein Absatz länger als 6 Zeilen	2	2 oder 0

Schritt 7. Priorisierte Korrekturliste

Fügen Sie jetzt die Bewertung jedes fehlgeschlagenen Elements zusammen mit seiner geschätzten Punktsteigerung (A1, C1) oder der Priorität aus den geschätzten PageSpeed-Einsparungen (B1-B3) in eine Liste ein. Ordnen Sie sie absteigend nach Punkten oder Einsparungen. Schreiben Sie für jedes Element eine klare Anweisung in natürlicher Sprache, die der Benutzer einem Entwickler oder Seiteneditor geben kann.

Priorität	Aktion	Geschätzte Punktsteigerung (von 100)
1	[Schnellste oder höchste Punktsteigerung]	[Zahl]
2	[Nächstes]	[Zahl]
…	…	…

Treffen Sie für jede Aktion eine der folgenden Aussagen, je nachdem, was zutrifft:

• "Sie können dies selbst über [Einstellungsname] in Ihrem Seiteneditor beheben."
• "Bitten Sie Ihren Entwickler, [spezifische Codeänderung] zu implementieren."
• "Dies ist ein Problem mit [Tool-Name]; wechseln Sie in dessen Einstellungen zu [Lösung]."

Schritt 8. Bericht ausgeben

Geben Sie alles in diesem Format aus:

Ergebnis: [Punktzahl] / 100

Stand: [Datum]
[Erste Seite]: [Link]
[Zweite Seite, falls vorhanden]

Zusammenfassung: [Zwei Sätze darüber, was gut funktioniert und was als nächstes behoben werden sollte, basierend auf den Top-3-Prioritäten. Endet mit einer Frage.]

Zeile	Prüfung	Max	Ergebnis	Nachweis
A1	PageSpeed Performance	30	[Zahl]	PS: [Score]
B1	LCP	7	[Zahl]	PS: [s]
B2	CLS	4	[Zahl]	PS: [Zahl]
B3	TBT	4	[Zahl]	PS: [ms]
C1	Accessibility	5	[Zahl]	PS: [Score]
D1	Viewport device-width	4	[Zahl]	HTML: [vorhanden/fehlt]
D2	Kein horizontales Scrollen	4	[Zahl]	Shot: [kein horizontales Scrollen/horizontales Scrollen vorhanden]
D3	Tippziele 44+ px	4	[Zahl]	Shot: [Beschreibung der kleinsten]
D4	Textgröße 16+ / 12+	4	[Zahl]	Shot/CSS: [Geschätzte Größte]
D5	Bildabmessungen / Lazy Loading	4	[Zahl]	HTML: [Prozentsatz der Bilder mit Abmessungen]
D6	Viewport-fit / Safe Area	2	[Zahl]	HTML/CSS: [vorhanden]
D7	Autoplay / Video bei Berührung	3	[Zahl]	HTML/Test: [Beschreibung]
D8	Popup-Passform	2	[Zahl]	Test: [Beschreibung]
D9	Reduced Motion / Focus	2	[Zahl]	CSS: [vorhanden/fehlt]
D10	Keine Konsolenfehler	2	[Zahl]	PS: [vorhanden/fehlt]
E1	Button auf erstem Bildschirm	8	[Zahl]	Shot: [vorhanden/nicht vorhanden]
E2	Button-Lücke	6	[Zahl]	Shot/Est: [Anzahl der Bildschirme]
E3	Keine konkurrierenden Ziele	4	[Zahl]	Shot/HTML: [Beschreibung]
E4	Überschriften kurz	3	[Zahl]	Shot/Est: [maximale Zeilen]
E5	Nachweise früh	3	[Zahl]	Shot/Est: [Bildschirm der ersten Nachweise]
E6	Formularfelder ≤ 5	3	[Zahl]	Test: [Anzahl]
E7	Keine langen Absätze	2	[Zahl]	Shot/Est: [Anteil der langen]

Nicht geprüft: [Liste der Zeilen, die nicht geprüft werden konnten, und warum]

Extra-Befunde: [Liste der Probleme, die nicht in das Raster passen, mit Korrekturvorschlägen]

Priorisierte Korrekturliste

Priorität	Aktion	Geschätzte Punktsteigerung
1	[Aktion]	[Punkte]
2	[Aktion]	[Punkte]
…	…	…

Buchungspfad: [Status]

[Beschreibung von Problemen oder "Keine Probleme festgestellt"]

Hinweis: Dies ist eine automatisierte Prüfung, die auf den von Ihnen bereitgestellten Daten basiert. Ein Entwickler sollte die Änderungen vor dem Deployment testen. Führen Sie dieses Tool erneut aus, nachdem Sie Änderungen vorgenommen haben, um die Punktsteigerung zu messen.