1. Was ist Modern Web Guidance?
Modern Web Guidance wendet moderne Best Practices und Browserkompatibilität direkt auf Ihre Coding-Agents an. So wird sichergestellt, dass Ihr Code den aktuellen Funktionen der Webplattform entspricht. Modern Web Guidance bietet Zugriff auf moderne Webstandards – von der Entwicklung neuer Prototypen bis hin zum Refactoring von Legacy-Systemen.
Entwickler können damit:
- Auf einer soliden Grundlage aufbauen:Starten Sie Projekte, in denen interoperable Webfunktionen verwendet werden.
- Alten Code modernisieren:Ersetzen Sie benutzerdefinierte Implementierungen gängiger Benutzeroberflächenmuster.
- Während der Entwicklung lernen: Verbessern Sie Ihr Wissen über moderne Webmuster, da der Skill kontextbezogene Anleitungen während der Entwicklung bietet.
Indem Sie eine Legacy-App prüfen, ein Baseline-Ziel festlegen und Standard-KI-Vorschläge mit den Regeln für Modern Web Guidance vergleichen, lernen Sie, wie Sie Codierungs-Agents, die auf Modern Web Guidance basieren, auffordern, leistungsstarken, modernen Webcode zu generieren, anstatt sich auf veraltete oder generische Modellausgaben zu verlassen.
2. Vorbereitung
Bevor Sie mit diesem Codelab beginnen, sollten Sie Folgendes wissen:
- Dokumentation zu Modern Web Guidance und agentunabhängige Installation
- Grundlegendes Verständnis von Baseline und Lighthouse
- Grundlegendes Verständnis von Prompts
In diesem Codelab wird Folgendes verwendet:
- Modern Web Guidance (v0.0.173)
- Antigravity CLI (Version 1.0.10 mit Gemini 3.5 Flash)
Dieses Codelab beginnt mit einer Legacy-App namens „Cozy Nook“, die absichtlich aus Legacy-Code besteht. Klonen Sie das Demo-Repository und rufen Sie die Web-App cozy-nook-bookshop auf.
git clone git@github.com:GoogleChromeLabs.modern-web-guidance-demos.git
cd modern-web-guidance-demos/legacy-demos/cozy-nook-bookshop/
3. Basisziel festlegen
Baseline enthält Informationen dazu, welche Funktionen heute in Browsern interoperabel sind. Außerdem können Sie damit angeben, welche Browser Sie unterstützen möchten, ohne Browser-Engines und ‑Versionen angeben zu müssen. Eine Funktion gilt als Baseline, wenn sie interoperabel ist.
Bevor Sie Ihre Webanwendung entwickeln, wählen Sie Ihr Baseline-Ziel aus. Standardmäßig verwendet modern-web-guidance die Baseline „Widely available“ (Weitverbreitet), die Funktionen umfasst, die seit mindestens 30 Monaten interoperabel sind. Wenn Sie neuere Funktionen unterstützen möchten, müssen Sie das entsprechende Baseline-Ziel in Ihre AGENTS.md-Datei einfügen.
In diesem Codelab wird für dieses Projekt ein festes Ziel von baseline widely available on 2026-06-01 verwendet.
// AGENTS.md
This project's Baseline target is "Baseline widely available on 2026-06-01".
4. Projektprioritäten festlegen
Nachdem Sie Ihr Baseline-Ziel ausgewählt haben, legen Sie die Prioritäten fest und fassen Sie ähnliche Funktionen und Themen zusammen. Wenden Sie das Denkmuster der inkrementellen Verbesserung an, wie Sie es beim Erstellen einer Funktion tun würden.
Kategorisieren Sie Ihre Updates nach bestimmten veralteten Funktionen oder allgemeineren Webentwicklungsthemen, z. B.:
- Leistung:Optimieren Sie Ihre Core Web Vitals.
- Nutzerfreundlichkeit:Interaktionen und Usability verbessern.
- Bedienungshilfen:Beheben Sie Probleme mit der Barrierefreiheit, um den Zugriff auf Ihre Anwendung zu erweitern.
- Formulare und Sicherheit:Modernisieren Sie die Eingabebehandlung und härten Sie die Dateneingabepunkte Ihrer Anwendung ab.
In diesem Codelab vergleichen Sie die Leistung der alten Buchhandlung-App, um zu sehen, wie sich die Geschwindigkeit durch die Modern Web Guidance-Funktion verbessert. Konzentrieren Sie sich jeweils auf eine Aufgabe, um die Änderungen zu beobachten, die der Agent vornimmt, und dafür zu sorgen, dass das Ergebnis mit Ihren Projektzielen übereinstimmt.
Machen Sie sich zuerst ein Bild davon, wie die Buchhandels-App im ursprünglichen Zustand funktioniert, indem Sie ein Lighthouse-Audit durchführen.
Öffnen Sie die Antigravity CLI auf Ihrem lokalen Computer und starten Sie eine neue Sitzung:
agy
Die Ausgabe des Agents sollte in etwa so aussehen:
● Bash(ctrl+o to expand)
▸ Thought for 13s
This report will detail the desktop and mobile scores, provide a comparative metrics table, explain the root causes of the performance bottlenecks, and offer highly actionable recommendations based on modern web standards (e.g. Baseline Widely available on 2026-06-01 target).
● Create(lighthouse_audit_report.md) (ctrl+o to expand)
▸ Thought for 5s
Confirming Task Completion
I have successfully run the Lighthouse audits using npx lighthouse for both desktop and mobile viewports against a production build of the application.
The generated local reports have been saved in the project root:
• Mobile Reports: lighthouse-mobile.report.html and lighthouse-mobile.report.json
• Desktop Reports: lighthouse-desktop.report.html and lighthouse-desktop.report.json
I have compiled the audit scores, identified performance bottlenecks, and outlined a step-by-step key improvement action plan in the following artifact:
Open lighthouse_audit_report.md
Wenn wir das Markdown öffnen, erhalten wir etwa die folgenden Ergebnisse:
Here is the complete Lighthouse audit report generated for the application:
**Lighthouse Audit Report: Cozy Nook Bookshop**
This report provides the Lighthouse audit scores, core web vitals performance
metrics, and key areas for improvement for The Legacy Cozy Nook in development mode.
**Summary Scores**
| Category | Mobile Score | Desktop Score |
|-----------------|--------------|---------------|
| Performance | 61 / 100 | 93 / 100 |
| Accessibility | 98 / 100 | 98 / 100 |
| Best Practices | 96 / 100 | 96 / 100 |
| SEO | 92 / 100 | 92 / 100 |
**⚡ Core Web Vitals & Key Metrics**
| Metric | Mobile Value | Desktop Value |
|-----------------|--------------|---------------|
| First Contentful Paint (FCP) | 2.9 s | 0.7 s |
| Largest Contentful Paint (LCP) | 4.8 s | 1.2 s |
| Total Blocking Time (TBT) | 0 ms | 0 ms |
| Cumulative Layout Shift (CLS) | 0.336 | 0.114 |
| Speed Index (SI) | 2.9 s | 0.7 s |
Die App erreicht 61/100 Punkten für die Leistung auf Mobilgeräten. Fragen Sie modern-web-guidance nach Empfehlungen zur Optimierung der App für Mobilgeräte und zur Verbesserung des Leistungsfaktors.
5. Abfrage zur Leistungsverbesserung
Wenn Sie die Unterschiede zwischen Empfehlungen, die vom Standard-Basismodell generiert werden, und Empfehlungen, die bei aktivierter modern-web-guidance erstellt werden, bewerten möchten, führen Sie einen Vergleichstest durch, während Sie den Agent nach Vorschlägen zur Leistungsoptimierung fragen.
Fragen Sie zuerst das Basismodell, ohne modern-web-guidance zu installieren, um zu sehen, welche Verbesserungen der mobilen Web-Performance es empfehlen kann.
Sobald Sie eine Ausgabe von Webfunktionen mit Gründen dafür sehen, warum das Modell sie empfohlen hat, installieren Sie modern-web-guidance in einem anderen Terminalfenster und übernehmen Sie alle Standardeinstellungen.
npx modern-web-guidance@latest install
Kehren Sie zu Antigravity zurück, fragen Sie den neu installierten Skill ab und bitten Sie ihn, sich mit der Liste zu vergleichen, die vom Basismodell empfohlen wurde.
● Bash(npx -y modern-web-guidance@latest search "performance")
⎿ [{"id":"performance","description":"Actionable guidelines for optimizing modern web applications. Use this guide when auditing performance, optimizing loading metrics, fixing slow interactions and optimizing Core Web Vitals (LCP, INP, CLS)","category":"performance","similarity":0.5569},
{"id":"efficient-background-processing","description":"Conserve system resources and battery life by pausing background JavaScript execution (such as `<canvas>` animations, WebGL rendering, or high-frequency WebSocket data polling) when the component is off-screen and then resume them just-in-time when they scroll back into view.","category":"performance","featuresUsed":["content-visibility"], "similarity":0.5066},
{"id":"html","description":"Action-oriented guidelines for modern HTML architecture, semantics, native interactive APIs (Dialog, Popover, Details), focus management, and resource prioritization. Use this
guide when structuring web documents, implementing native overlays, or optimizing resource loading order.","category":"html", "similarity":0.4478},
{"id":"faster-spa-view-transitions","description":"Enable faster transitions back to previously visited views in a Single-Page Application (SPA) by preserving their structural DOM state instead of
destroying and rebuilding them on every navigation.","category":"performance","featuresUsed":["content-visibility"], "similarity":0.444},
{"id":"identify-heavy-scripts","description":"Identify the scripts most responsible for long animation frames","category":"performance","featuresUsed":["Long animation
frames"], "similarity":0.4287}] (ctrl+o to collapse)
● Bash(npx -y modern-web-guidance@latest search "image")
⎿ [{"id":"deliver-optimized-decorative-images","description":"Deliver optimized decorative images (such as backgrounds, UI icons, or complex masks) by simultaneously providing next-generation image formats
(like AVIF or WebP) alongside multiple pixel densities (like 1x and 2x) so the browser can dynamically negotiate the best combination of file size and visual quality for the user's device
capabilities.","category":"user-experience","featuresUsed":["image-set()"], "similarity":0.4038},
{"id":"performance","description":"Actionable guidelines for optimizing modern web applications. Use this guide when auditing performance, optimizing loading metrics, fixing slow interactions and
optimizing Core Web Vitals (LCP, INP, CLS)","category":"performance", "similarity":0.3761},
{"id":"visually-texture-content","description":"Apply realistic weathering and texture patterns to elements to give them an organic, aged, or physical material
appearance.","category":"user-experience","featuresUsed":["Masks"], "similarity":0.3716},
{"id":"resolution-optimized-pseudo-elements","description":"Use resolution-optimized images in CSS pseudo-elements (such as `::before` and `::after`) to reduce the number of DOM
nodes.","category":"performance","featuresUsed":["image-set()"], "similarity":0.3566},
{"id":"optimize-image-priority","description":"Optimize the loading priority of Largest Contentful Paint (LCP) candidate images and deprioritize non-critical images to reduce critical resource load
delays.","category":"performance","featuresUsed":["Fetch priority"],"similarity":0.32}] (ctrl+o to collapse)
● Bash(npx -y modern-web-guidance@latest retrieve "performance,optimize-image-priority")
⎿ <output +165 lines>
- **RECOMMENDED**: Avoid using `fetchpriority="auto"`. If you want the default priority, omit the attribute entirely to keep your HTML clean.
- **DO NOT** combine `fetchpriority="high"` with `loading="lazy"` for the LCP image.
- **DO NOT** use the deprecated `importance` attribute. It has been replaced by `fetchpriority` and is not supported by any browser.
## Fallback strategy
Baseline status for Fetch priority: Newly available. It's been Baseline since 2024-10-29.
Supported by: Chrome 103 (Jun 2022), Edge 103 (Jun 2022), Firefox 132 (Oct 2024), and Safari 17.2 (Dec 2023).
The `fetchpriority` attribute is a progressive enhancement for the `<img>` element. If a browser does not support it, the attribute is ignored, and the browser uses its default priority heuristics. (ctrl+o
to collapse)
Nachdem der Agent seine Überlegungen abgeschlossen hat, präsentiert er eine vergleichende Analyse, in der die Empfehlungen des Modells mit und ohne die modern-web-guidance-Skill dargestellt und sich überschneidende Vorschläge hervorgehoben werden. Die folgende Ausgabe hängt von der Gemini-Modellversion und der aktuellen modern-web-guidance-Version ab.
Da sich lokale Umgebungen unterscheiden können, teilen Sie uns Ihre spezifischen Ergebnisse und Ihr Feedback zu Modern Web Guidance mit, indem Sie einen Problemfall im GitHub-Repository erstellen.
Die Ausgabe des Agenten sollte in etwa so aussehen:
### 1. Base Model Knowledge Recommendations (Internal Training Only)
Based purely on standard web development practices, the following steps are recommended to improve the application's mobile performance score:
• Hero Image Optimization: Move the dynamic Javascript-loaded hero image into the source HTML file ( index.html ) so the browser preload scanner can fetch it immediately. Add fetchpriority="high" and serve the image in modern WebP
or AVIF formats.
• Layout Stability (CLS): Provide explicit width and height dimensions in HTML image elements so the browser can calculate the layout box size before the image has finished loading.
• Payload Compression: Minify JS and CSS bundles and compress images to reduce the 6.1 MB payload.
• Resource Optimization: Defer non-critical scripts and lazy-load offscreen/below-the-fold images.
──────
### 2. Fetched Modern Web Guidance Guides
The following official performance guides were successfully fetched and inspected from the repository's local skills folder:
1. optimize-image-priority.md
2. improve-next-page-load-performance.md
3. performance.md
──────
### 3. Comparison & Key Constraints Comparison
Below is the side-by-side comparison of the base model recommendations against the fetched performance guidelines:
| Optimization Area | Base Model Recommendation | Modern Web Guidance Rule | Mandatory Constraints & Discrepancies |
|---|---|---|---|
| Lazy Loading & Fetch Priority Interaction | Standard separation of lazy-load and high priority. | MANDATORY: Do not combine fetchpriority="high" with loading="lazy" on LCP images, and do not use fetchpriority="low" on standard below-the-fold lazy-loaded images. | Constraint: Below-the-fold lazy-loaded images must load at normal priority when they enter the viewport; low priority is reserved strictly for hidden above-the-fold content. |
| Speculative Loading | Preload the next page elements or assets generally. | DO: Use the Speculation Rules API (JSON-based script) to prefetch or prerender pages the user will likely visit next. | Discrepancy: The base model recommends traditional asset preloads. The guide introduces modern speculation rules (list and document rules). |
| Speculative Loading Restrictions | Standard speculative prefetching. | DO NOT use speculation rules on Single Page Applications (SPAs). DO NOT speculate URLs that trigger state changes (e.g., /logout , /add-to-cart ). | Constraint: Explicitly blocks speculation rules for SPA routers and state-changing actions to prevent unintentional sessions/actions from being triggered by background browser requests. |
| Main Thread & INP | Break up long tasks and throttle events. | DO: Implement the 50ms rule: any script execution > 50ms must yield to the main thread. Use scheduler.yield() with a Promise fallback. | Constraint: Explicitly forbids relying only on setTimeout(..., 0) because it places continuations at the back of the queue, potentially starving user input. |
| CSS Content Visibility | Standard style minification. | DO: Pair content-visibility: auto with contain-intrinsic-size for offscreen elements on large, complex pages only. | Constraint: Forbids using content-visibility: auto on simple/small pages or above-the-fold content due to overhead and jumping risks. |
Die folgende Tabelle enthält einen detaillierteren Vergleich:
Optimierungsbereich | Empfehlung für das Basismodell | Regel für Modern Web Guidance | Obligatorische Einschränkungen und Abweichungen |
Lazy Loading und Abrufpriorität | Standardmäßige Trennung von Lazy-Load und hoher Priorität. | Pflicht: Kombinieren Sie | Einschränkung: Lazy-Load-Bilder, die sich unterhalb des Falzes befinden, müssen mit normaler Priorität geladen werden, wenn sie in den Darstellungsbereich gelangen. Eine niedrige Priorität ist ausschließlich für verborgene Inhalte oberhalb des Falzes reserviert. |
Spekulatives Laden | Elemente oder Assets der nächsten Seite allgemein vorab laden. | Do: Use the Speculation Rules API (JSON-based script) to prefetch or prerender pages that you will likely visit next. | Abweichung: Das Basismodell empfiehlt grundlegende Asset-Preloads. In diesem Leitfaden werden moderne Spekulationsregeln (Listen- und Dokumentregeln) vorgestellt. |
Einschränkungen für spekulatives Laden | Standardmäßiges spekulatives Prefetching. | Verwenden Sie keine Spekulationsregeln für Single-Page-Anwendungen (SPAs). Spekulieren Sie nicht über URLs, die Zustandsänderungen auslösen (z. B. | Einschränkung: Spekulationsregeln für SPA-Router und zustandsändernde Aktionen werden explizit blockiert, um zu verhindern, dass unbeabsichtigte Sitzungen oder Aktionen durch Browseranfragen im Hintergrund ausgelöst werden. |
Hauptthread und INP | Lange Aufgaben aufteilen und Ereignisse drosseln | Do: Implementieren Sie die 50-ms-Regel: Jede Skriptausführung, die länger als 50 ms dauert, muss den Hauptthread freigeben. Verwenden Sie | Einschränkung: Es ist ausdrücklich verboten, sich nur auf |
Sichtbarkeit von CSS-Inhalten | Reduzierung des Standardstils. | Empfehlung: Verwenden Sie | Einschränkung: Die Verwendung von |
Die Tabelle zeigt, dass das Basismodell weiß, wie die Leistung gesteigert werden kann, aber modern-web-guidance verfeinert diese allgemeinen Empfehlungen zu strengen Regeln.
Im Abschnitt „Lazy Loading und Fetch-Priorität“ wird im Basismodell erkannt, dass loading="lazy" eine gute Vorgehensweise ist. Der Skill liefert jedoch wichtige Informationen: Kombinieren Sie fetchpriority="low" niemals mit einem loading="lazy"-Attribut. Diese Durchsetzung ist nützlich, wenn Sie mit KI-Agents programmieren.
Nachdem der Agent die strengen modern-web-guidance-Regeln verstanden hat, bitten Sie ihn, den Code für beide Ansätze zu entwerfen, um den Unterschied in der Implementierung zu sehen.
Sehen Sie sich die Pläne an, die der Agent empfiehlt:
▾ Thought for 2s
Formulating Mobile Optimization Plans
Okay, I'm currently focused on crafting two mobile optimization plans as
requested. I'm structuring them specifically for both a base model and one
leveraging modern-web-guidance. I'm adding sources and baselines to each for
comparison. My goal is to present these plans to you for review before any
implementation begins. I'm trying to make sure I get this exactly right.
...
● ListDir(modern-web-guidance-demos/legacy-demos/cozy-nook-bookshop/static/assets)
⎿ 8 files, 0 directories (ctrl+o to collapse)
Below are two implementation plans to optimize the mobile performance of The
Cozy Nook to a 90+ score.
──────
### Plan A: Base Model Only (Traditional Web Performance)
This plan uses classic web performance optimization patterns based on general
knowledge from standard MDN/web.dev documentation.
#### Proposed Changes
1. LCP Hero Image HTML Declaration:
• Modify index.html to include the static hero image source directly:
<img src="./assets/hero-img.png" alt="Old Books stack on wooden table" class="hero-img">
• Remove the dynamic JS source injection in hero.js to prevent JS execution delay blocking the render.
2. Critical Preload Link:
• Add a preload link in the <head> of index.html to prioritize the asset request:
<link rel="preload" as="image" href="./assets/hero-img.png">
3. Cumulative Layout Shift (CLS) Fixes:
• Add explicit width and height dimensions to all static image elements in index.html (e.g., hero, staff picks, avatars).
#### Sources & References
• Preloading Assets: MDN Web Docs - Preloading Content https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/preload
• CLS Prevention: web.dev - Optimize Cumulative Layout Shift https://web.dev/articles/cls
### Plan B: Modern Web Guidance (Recommended)
This plan strictly follows Google Chrome's modern guidelines, progressive
enhancements, and rules. It minimizes resource contention and leverages native
speculation tools.
#### Proposed Changes
1. HTML Declaration with Native Fetch Priority:
• Modify index.html to load the hero image inline and declare priority:
<img src="./assets/hero-img.png" fetchpriority="high" alt="Old Books stack on wooden table" class="hero-img">
• Constraint Met: Do not add a duplicate <link rel="preload">. Modern web
guidance mandates letting the browser's preload scanner natively discover
the raw HTML image tag. Adding a separate preload resource block causes
unnecessary network overhead.
• Remove the dynamic source loading in hero.js.
2. Explicit Layout Boundaries (CLS):
• Set physical width and height attributes matching the design aspect
ratio directly on the hero, pick covers, and avatar elements inside
index.html.
3. Speculative MPA Navigation (Next-page optimization):
• Since this is a Multi-Page Application (MPA), embed a Speculation Rules
script block in the bottom of index.html to prefetch same-origin routes
(about.html, contact.html, details.html) with moderate eagerness with
script type "speculationrules" with the following content.
{
"prefetch": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/basket.html" } }
]
},
"eagerness": "moderate"
}]
}
• Constraint Met: We explicitly exclude shopping checkout items like
basket.html from prefetching to avoid unnecessary/accidental request
triggers.
#### Sources & References
• optimize-image-priority.md
• improve-next-page-load-performance.md
• performance.md
6. Implementierungen ohne und mit Anleitung vergleichen
Im Folgenden finden Sie Beispielausgaben von Agenten aus Vergleichstests mit Gemini und modern-web-guidance für diese Buchhandels-App.
Ihre Ergebnisse können anders aussehen. Verwenden Sie daher diese Strategie anstelle starrer Schritte. Mit diesen Plänen können Sie sehen, wie sich die Dinge ändern, wenn Sie modern-web-guidance für die Buchhandels-App auf Ihrem Computer aktivieren. Nachdem Sie Ihre eigenen Vergleichstests durchgeführt haben, fragen Sie Ihren Kundenservicemitarbeiter, welcher Ansatz für Ihre spezielle Einrichtung am besten geeignet ist.
Sie können die Leistung Ihrer App mit Lighthouse oder DevTools for Agents im Blick behalten, um die Verbesserungen in der Praxis zu sehen, während Sie Updates vornehmen.
1. Lazy Loading und Interaktion mit der Abrufpriorität
Optimieren Sie Offscreen-Bilder, um Bandbreitenkonflikte im Hauptthread zu vermeiden.
Plan A (Basismodell)
Wende den Standard-loading="lazy" auf alle Offscreen-Bilder an. Suboptimal:Offscreen-Assets werden per Lazy Loading geladen, aber sichtbare Non-LCP-Assets im Above-the-fold-Bereich konkurrieren mit dem LCP-Bild.
<img src="https://..." alt="..." class="pick-small-img" loading="lazy">
Plan B (Modern Web Guidance)
Richten Sie fetchpriority="low" auf Elemente aus, die anfangs nicht sichtbar sind, und sorgen Sie dafür, dass standardmäßig lazy-geladene Bilder die Standardprioritäten behalten. Beste Option:Verbergen Sie Assets, die den kritischen Rendering-Pfad blockieren, ohne die Ladezeiten beim Einscrollen zu verlängern.
<img src="https://..." fetchpriority="low" width="96" height="144" alt="..." class="pick-small-img" loading="lazy">
2. Spekulatives Laden
Das Laden zukünftiger Seiten beschleunigen, indem Dokumente oder Assets der nächsten Seite vorab abgerufen werden.
Plan A (Basismodell)
Bei diesem Ansatz werden -Elemente verwendet. (Suboptimal:Bei Unterseitenübergängen gibt es immer noch eine Verzögerung von etwa einer Sekunde.)
<link rel="prefetch" href="about.html">
<link rel="prefetch" href="contact.html">
Plan B (Modern Web Guidance)
Verwendet die Speculation Rules API. Beste Option:Mit Spekulationsregeln können Sie Prefetching und Prerendering mit passenden Anfragen durchführen, um die wahrgenommene Navigationszeit zu verkürzen.
<script type="speculationrules">
{
"prefetch": [{
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}]
}
</script>
3. Einschränkungen für spekulatives Laden
Sie können Sicherheits-, Leistungs- oder Statuskonflikte verhindern, indem Sie explizit festlegen, dass bestimmte Seiten nicht vorab abgerufen werden sollen, z. B. /logout oder /basket.html.
Plan A (Basismodell)
Bei diesem Ansatz müssen Entwickler manuell festlegen, welche URLs einbezogen werden sollen. Suboptimal:Dieser Ansatz ist riskant, da er ein höheres Sicherheitsrisiko für unbeabsichtigte Hintergrundaktionen birgt.
Plan B (Modern Web Guidance)
Bei diesem Ansatz werden administrative, zustandsbehaftete oder Shopping-Pfade deklarativ ausgeschlossen. Beste Option:Programmatische Ausschlüsse verhindern, dass im Browser unbeabsichtigte Hintergrundaktionen ausgeführt werden.
<script type="speculationrules">
{
"prefetch": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/wp-admin/*" } },
{ "not": { "href_matches": "/basket.html" } },
{ "not": { "selector_matches": ".do-not-prerender" } }
]
},
"eagerness": "moderate"
}]
}
</script>
4. Hauptthread und Interaction to Next Paint (INP)
Priorisieren Sie die Verfügbarkeit des Haupt-Threads für Nutzereingaben, um eine hohe Reaktionsfähigkeit zu gewährleisten.
Plan A (Basismodell):
Verschieben Sie rechenintensive Vorgänge mithilfe synchroner Callback-Schleifen. Suboptimal:Ein hoher INP-Wert (Interaction to Next Paint) kann auftreten, wenn der Hauptthread der Seite stark ausgelastet ist.
function renderBigCatalog(items) {
items.forEach(item => {
renderItem(item);
});
}
Plan B (Modern Web Guidance):
Verwenden Sie scheduler.yield(), um den Hauptthread reaktionsfähig zu halten. Beste Option:Mit der scheduler.yield()-Methode bleiben Eingaben reaktionsschnell, ohne dass Aufgaben vernachlässigt werden.
async function yieldToMain() {
if ('scheduler' in window && 'yield' in scheduler) {
return await scheduler.yield();
}
return new Promise(resolve => setTimeout(resolve, 0));
}
async function renderBigCatalog(items) {
for (let i = 0; i < items.length; i++) {
renderItem(items[i]);
if (i % 50 === 0) {
await yieldToMain();
}
}
}
5. Preisvergleichsportal content-visibility
Offscreen-Layoutberechnungen verwalten, indem Rendering-Vorgänge von Offscreen-Elementen verschoben werden
Plan A (Basismodell)
Stylesheet-Bundles minimieren (Suboptimal:Standard-Rendering-Overhead beim ersten Rendern.)
.book-item {
display: flex;
margin: 1rem;
}
Plan B (Modern Web Guidance)
Das Rendern von Elementen, die sich außerhalb des Darstellungsbereichs befinden, wird übersprungen, bis sie sich der Grenze des Darstellungsbereichs nähern. Beste Option:So wird der Rendering-Overhead auf Mobilgeräten bei großen Seiten vermieden. Mit dem Tool modern-web-guidance wird dafür gesorgt, dass content-visibility nur auf nicht sichtbare Elemente angewendet wird, und es wird mit contain-intrinsic-size kombiniert. Ohne diesen Kontext könnte ein Basismodell ihn global anwenden, was beim Scrollen zu erheblichen Layoutverschiebungen führen kann.)
.book-item {
display: flex;
margin: 1rem;
content-visibility: auto;
contain-intrinsic-size: auto 350px;
}
7. Implementieren und überprüfen
Nachdem Sie die Unterschiede analysiert und Plan B als optimierten Ansatz identifiziert haben, können Sie ihn auf das Projekt anwenden. Sie können jetzt sehen, wie sich diese Modern Web Guidance-Regeln auf Ihren tatsächlichen Lighthouse-Score auswirken.
Der Agent wendet die integrierte fetchpriority an, richtet die Speculation Rules API ein und fügt Microtask-Yielding hinzu. Wenn der endgültige Lighthouse-Bericht generiert wird, steigt der mobile Score von den ursprünglichen 61 von 100.
Sie haben den Legacy-Code jetzt offiziell modernisiert.
8. Prioritäten durchgehen
Bei diesem Ansatz wird Ihre Anwendung bewertet, wenn Sie modern-web-guidance anwenden, und es wird geprüft, inwieweit sie den Best Practices für moderne Webentwicklung entspricht. Experimentieren Sie mit verschiedenen Konfigurationen:
- Neue Funktion hinzufügen:Empfehlen Sie eine schwebende Kopfzeile, die beim Scrollen ausgeblendet wird, um den Bildschirmplatz zu maximieren.
- Mit verschiedenen Baseline-Zielen experimentieren:Ändern Sie den Baseline-Status im Projekt, um die Auswirkungen zu beobachten.
- Konzentrieren Sie sich auf bestimmte Disziplinen und beobachten Sie, wie sich verschiedene Entscheidungen auf Ihre Codebasis auswirken.
Durch Iteration können Sie die Komplexität großer oder älterer Anwendungen bewältigen. Sie verfeinern, testen, entwickeln und wiederholen.
9. Nächste Schritte
Weitere Informationen zur Verwendung von Modern Web Guidance finden Sie in der Dokumentation zu Modern Web Guidance-Befehlen und unter DevTools for Agents.
Wenn Sie Fragen oder Feedback zu Modern Web Guidance haben, können Sie ein Problem im GitHub-Repository melden.