Was macht Motion-Analytics?
Bewegungsqualität ist messbar. „Fühlt sich flüssig an“ und „sieht aus wie die Referenz“ sind Behauptungen; dieses Skill macht daraus Zahlen, die Du nächste Woche wiederholen kannst.
Zwei Aufgaben:
- Performance: Wie lange jedes Bild dauert, wie schwer die Seite ist und wie sich die Seite anpasst, wenn das Gerät langsam ist. Anleitung: references/performance.md. Werkzeug: scripts/frame-meter.js.
- Referenzbewertung: Wie nah eine Seite an einer Referenz oder ihrem eigenen Designziel ist, fair beurteilt. Anleitung: references/reference-grading.md. Werkzeug: scripts/compare-sheet.mjs.
Schnellstart
Framedauer auf einer beliebigen Seite messen
Füge den Meter ein und öffne die Seite mit ?meter:
<script src="frame-meter.js" defer></script>
Eine kleine Anzeige zeigt p50, p95 und eine vorgeschlagene Qualitätsstufe an, und die Konsole protokolliert alle fünf Sekunden eine Zusammenfassung. Von der Konsole aus kannst Du auch Folgendes ausführen:
frameMeter.start(); // eine saubere Messung beginnen
// ...durch die Seite scrollen, die Hauptinteraktion verwenden...
frameMeter.report(); // { frames, p50, p95, p99, max, fps, longFrames, jank, suggest }
Messe auf dem langsamsten Gerät, das Dir wichtig ist, nicht auf Deinem Arbeitsplatzrechner. Scrolle während der Messung durch die gesamte Seite und verwende die Hauptinteraktion, da Leerlaufbilder die teuren Momente verbergen.
Ein Side-by-Side-Blatt erstellen
node scripts/compare-sheet.mjs ./shots/unsere ./shots/referenz ./vergleich --labels "Unsere,Referenz"
Paart Bilder mit demselben Dateinamen, schreibt compare.html (immer) und compare.png (wenn sharp installiert ist). Gib das Blatt an die Prüfer weiter, wie im Bewertungsleitfaden beschrieben.
Die Zahlen, die zählen
| Messwert | Ziel | Warum |
|---|---|---|
| Framedauer p95 | 16,7 ms oder weniger auf dem Zielgerät (60 Hz) | p95 ist das, was Menschen fühlen; der Median verbirgt Ruckler |
| Framedauer p50 | Deutlich unter p95 | Ein großer Abstand bedeutet Spitzen: Uploads, GC, Shader-Kompilierung |
| Lange Frames (über 50 ms) | 0 während des Scrollens | Jeder einzelne ist ein sichtbarer Ruckler |
| Seitengewicht beim ersten Bildschirm | Unter 3 MB | Erster Eindruck bei mobilen Daten |
| Gesamte Seite | Unter 10 MB | Ladezeit, Datenkosten, Akku |
| Largest Contentful Paint | Unter 2,5 s | Ein zusammengesetztes Standbild anzeigen, bevor schwere Assets eintreffen |
| Cumulative Layout Shift | Unter 0,1 | Canvas- und Videoboxen müssen ihren Platz reservieren |
| Interaction to Next Paint | Unter 200 ms | Schwere Render-Loops dürfen die Eingabe nicht blockieren |
Details, Budgets pro Asset-Typ und eine funktionierende Qualitätsleiter finden sich in references/performance.md.
Arbeitsablauf
- Baseline. Lade die Seite mit
?meter, scrolle zweimal von oben nach unten, verwende die Hauptinteraktion, lies dannframeMeter.report(). Notiere Gerät, Browser, Viewport und die Zahlen. - Finde den teuren Abschnitt. Wiederhole pro Abschnitt mit
frameMeter.start()am Abschnitt undreport()danach. Der schlechteste p95 ist der Ort, an dem gearbeitet werden muss. - Behebe die Ursache. Meistens einer von: Gerätepixelverhältnis zu hoch, ein Pass mit voller Auflösung, zu viele Draw Calls, eine Textur, die mitten im Scrollen hochgeladen wird, ein Shader, der beim ersten Anzeigen kompiliert wird, oder Rendern im verborgenen Zustand. Siehe die Fehlerbehebungstabelle im Performance-Leitfaden.
- Füge die Leiter hinzu. Selbst eine schnelle Seite braucht einen Weg nach unten auf einem schwachen Telefon. Verwende das Snippet der rollierenden Leiter: Stufe runter bei p95 über 22 ms, Stufe rauf bei p95 unter 12 ms.
- Messe auf die gleiche Weise erneut. Gleiches Gerät, gleicher Pfad, gleiche Dauer. Berichte vorher und nachher.
- Bewerte gegen das Ziel. Wenn die Seite ein Design oder ein Referenzbild nachbildet, erstelle Vier-Moment-Blätter und wende die Drei-Prüfer-Methode in references/reference-grading.md an.
Berichtsformat
Seite: <Name> Gerät: <Modell, Browser> Viewport: <B x H, DPR>
Pfad: Vollbild-Scroll x2 + Hauptinteraktion, 60 s
Vorher: p50 9,8 ms, p95 31,2 ms, lange Frames 6, Gewicht 14,1 MB
Nachher: p50 7,1 ms, p95 15,9 ms, lange Frames 0, Gewicht 8,7 MB
Änderungen: DPR-Obergrenze 1,5 auf Telefonen, Bloom bei halber Auflösung, Helden-Texturen in WebP 2048, Shader im Loader vorcompiliert
Leiter: Stufen 0 bis 3, stabilisiert sich auf Stufe 3 auf dem Desktop, Stufe 2 auf dem Testtelefon
Regeln
- Berichte p95, nicht die durchschnittliche FPS. Ein Durchschnitt von 58 fps kann einen Ruckler pro Sekunde verbergen.
- Eine Geräteklasse pro Zahl. Mische niemals eine Laptop-Messung mit einer Telefon-Messung in einer Behauptung.
- Gleicher Pfad jedes Mal. Messungen sind nur vergleichbar, wenn Scrollpfad, Interaktion und Dauer übereinstimmen.
- Messe auch den kalten Start. Der erste Aufruf compiliert Shader und lädt Texturen hoch. Dort leben lange Frames.
- Bewerte mit Beweisen. Ein „nahe“-Urteil benötigt Blätter bei abgeglichenen Momenten und Prüfer, die die Seite nicht gebaut haben.
Verwandtes
- Bewertungsraster und blockierende QA-Prüfungen: ../motion-review/SKILL.md.
- Handwerks-Workflow und Technikbibliothek: ../motioncraft-builder/SKILL.md.