1. מה זה Modern Web Guidance?
Modern Web Guidance מיישם שיטות מומלצות מודרניות ותאימות לדפדפן ישירות בסוכני התכנות שלכם. הכישורים האלה מבטיחים שהקוד שלכם יתאים ליכולות הנוכחיות של פלטפורמת האינטרנט. מפיתוח אבות טיפוס חדשים ועד לשינוי מבנה של מערכות מדור קודם, Modern Web Guidance מספק גישה לסטנדרטים מודרניים של האינטרנט.
מפתחים יכולים להשתמש בו כדי:
- בונים על בסיס מוצק: מתחילים פרויקטים שמשתמשים בתכונות אינטרנט שניתנות להפעלה הדדית.
- עדכון קוד מדור קודם: החלפת הטמעות מותאמות אישית של דפוסים נפוצים בממשק המשתמש.
- לומדים תוך כדי פיתוח: המיומנות מספקת הנחיות בהתאם להקשר במהלך הפיתוח, וכך משפרת את הידע שלכם לגבי דפוסי אינטרנט מודרניים.
בעזרת ביקורת על אפליקציה מדור קודם, הגדרת יעד Baseline והשוואה בין הצעות AI רגילות לבין כללי Modern Web Guidance, תוכלו ללמוד איך להנחות סוכני תכנות משופרים של Modern Web Guidance ליצור קוד מודרני לאינטרנט עם ביצועים גבוהים, במקום להסתמך על פלט של מודלים מיושנים או גנריים.
2. דרישות מוקדמות
לפני שמתחילים את ה-codelab הזה, חשוב לוודא שיש לכם את הידע הבא:
- חומרי עזר שקשורים ל-Modern Web Guidance והתקנה שלא תלויה בסוכן
- הבנה בסיסית של Baseline ו-Lighthouse
- הבנה בסיסית של הנחיות
ב-codelab הזה נעשה שימוש ברכיבים הבאים:
- Modern Web Guidance (v0.0.173)
- Antigravity CLI (גרסה 1.0.10 עם Gemini 3.5 Flash)
ב-Codelab הזה נתחיל עם אפליקציית Cozy Nook מדור קודם, שמורכבת בכוונה מקוד מדור קודם. משכפלים את מאגר ההדגמה ועוברים לאפליקציית האינטרנט cozy-nook-bookshop.
git clone git@github.com:GoogleChromeLabs.modern-web-guidance-demos.git
cd modern-web-guidance-demos/legacy-demos/cozy-nook-bookshop/
3. הגדרת יעד בסיסי
Baseline מספק מידע על התכונות שניתן להשתמש בהן בדפדפנים היום. הוא גם מאפשר לציין אילו דפדפנים רוצים לתמוך בהם, בלי לציין מנועי דפדפן וגרסאות. תכונה נחשבת ל-Baseline אם היא ניתנת להפעלה הדדית.
לפני שמפתחים את אפליקציית האינטרנט, בוחרים את יעד הבסיס. כברירת מחדל, modern-web-guidance משתמש ב-Baseline Widely available, שכולל תכונות שניתן להשתמש בהן באופן הדדי לפחות 30 חודשים. אם אתם צריכים לתמוך בתכונות חדשות יותר, תצטרכו לכלול את יעד הבסיס המתאים בקובץ AGENTS.md.
בשיעור Codelab הזה, הפרויקט משתמש ביעד קבוע של baseline widely available on 2026-06-01.
// AGENTS.md
This project's Baseline target is "Baseline widely available on 2026-06-01".
4. זיהוי סדרי העדיפויות בפרויקט
אחרי שבוחרים את יעד הבסיס, מגדירים את סדר העדיפויות ומקבצים תכונות ונושאים קשורים. כדאי לאמץ את המודל המנטלי של שיפור מצטבר, כמו כשבונים תכונה.
אפשר לסווג את העדכונים לפי תכונות ספציפיות שיצאו משימוש או לפי תחומים רחבים יותר בפיתוח אתרים, לדוגמה:
- ביצועים: אופטימיזציה של מדדי ה-Core Web Vitals.
- חוויית משתמש: שיפור האינטראקציות ונוחות השימוש.
- נגישות: כדאי לטפל בבעיות נגישות כדי להרחיב את הגישה לאפליקציה.
- טפסים ואבטחה: מודרניזציה של הטיפול בקלט וחיזוק של נקודות הכניסה לנתונים באפליקציה.
ב-Codelab הזה מתמקדים בהשוואת הביצועים של אפליקציית חנות הספרים מדור קודם כדי לראות איך Modern Web Guidance משפרת את המהירות שלה. כדי לעקוב אחרי השינויים שהסוכן מבצע ולוודא שהתוצאה תואמת ליעדים של הפרויקט, מומלץ להתמקד במשימה אחת בכל פעם.
כדי להתחיל, כדאי לקבל תמונה ברורה של הביצועים של אפליקציית חנות הספרים במצב ההתחלתי שלה באמצעות ביקורת של Lighthouse.
פותחים את Antigravity CLI במחשב המקומי ומתחילים סשן חדש:
agy
הפלט של הסוכן אמור להיראות כך.
● 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
כשפותחים את קובץ ה-Markdown, מקבלים את התוצאות הבאות:
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 |
הציון של האפליקציה הוא 61 מתוך 100 בביצועים בנייד. שליחת שאילתה modern-web-guidance לקבלת המלצות לאופטימיזציה של האפליקציה לנייד ולשיפור ציון הביצועים.
5. שאילתה לשיפור הביצועים
כדי להעריך את ההבדלים בין ההמלצות שנוצרות על ידי מודל הבסיס הרגיל לבין ההמלצות שנוצרות כשהתכונה modern-web-guidance פעילה, אפשר לבצע בדיקת השוואה בזמן שאתם מבקשים מהסוכן הצעות לאופטימיזציה של הביצועים.
קודם כל, בלי להתקין את modern-web-guidance, שולחים שאילתה למודל הבסיסי כדי לראות אילו שיפורים בביצועים של אתר לנייד הוא יכול להמליץ.
אחרי שרואים את הפלט של תכונות האינטרנט עם הסיבות להמלצה של המודל, אפשר להתקין את modern-web-guidance בחלון מסוף אחר ולאשר את כל ברירות המחדל.
npx modern-web-guidance@latest install
חוזרים אל Antigravity, שולחים שאילתה למיומנות שהותקנה זה עתה ומבקשים ממנה להשוות את עצמה לרשימה שהומלצה על ידי מודל הבסיס.
● 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)
אחרי שהסוכן מסיים את תהליך ההסקה, הוא מציג ניתוח השוואתי שכולל את ההמלצות של המודל עם ובלי מיומנות modern-web-guidance, ומדגיש הצעות חופפות. הפלט הבא תלוי בגרסת המודל של Gemini ובגרסה הנוכחית של modern-web-guidance.
יכול להיות שיהיו הבדלים בין סביבות מקומיות שונות, ולכן כדאי לפתוח issue במאגר GitHub כדי לשתף את התוצאות הספציפיות שלכם ומשוב על המדריך בנושא אתרים מודרניים.
הפלט של הסוכן אמור להיראות כך:
### 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. |
הטבלה הבאה מציגה השוואה מפורטת יותר:
אזור האופטימיזציה | המלצה לגבי מודל בסיס | כלל Modern Web Guidance | הגבלות ואי-התאמות חובה |
אינטראקציה בין טעינה מדורגת לבין עדיפות לאחזור | הפרדה רגילה בין טעינה עצלה לבין עדיפות גבוהה. | חובה: אסור לשלב בין | הגבלה: תמונות שנטענות באופן עצלני בחלק הנגלל שמתחת לקו, צריכות להיטען בעדיפות רגילה כשהן נכנסות לאזור התצוגה. עדיפות נמוכה שמורה אך ורק לתוכן מוסתר בחלק העליון והקבוע. |
טעינה מראש | טעינה מראש של אלמנטים או נכסים של הדף הבא באופן כללי. | מומלץ: להשתמש ב-Speculation Rules API (סקריפט מבוסס-JSON) כדי לבצע שליפה מראש או עיבוד מראש של דפים שסביר שתבקרו בהם בהמשך. | אי התאמה: מודל הבסיס ממליץ על טעינה מראש של נכסים בסיסיים. המדריך מציג כללי ספקולציה מודרניים (כללים לרשימות ולמסמכים). |
הגבלות על טעינה מראש | אחזור מראש ספקולטיבי רגיל. | אל תשתמשו בכללי ניחוש באפליקציות עם דף יחיד (SPA). אל תנחשו כתובות URL שמפעילות שינויים במצב (לדוגמה, | מגבלה: חסימה מפורשת של כללי ספקולציה לנתבי SPA ופעולות שמשנות את המצב, כדי למנוע הפעלה לא מכוונת של סשנים או פעולות כתוצאה מבקשות דפדפן ברקע. |
ה-thread הראשי ו-INP | לפצל משימות ארוכות ולהגביל את מספר האירועים. | מומלץ: להטמיע את כלל 50 אלפיות השנייה: כל הרצת סקריפט שנמשכת יותר מ-50 אלפיות השנייה חייבת להניב לשרשור הראשי. משתמשים ב- | מגבלה: אסור להסתמך רק על |
CSS content visibility | הקטנה של סגנון רגיל. | מומלץ: לשלב בין | הגבלה: אסור להשתמש ב- |
מהטבלה אפשר לראות שהמודל הבסיסי מבין איך לשפר את הביצועים, אבל modern-web-guidance הוא משפר את ההמלצות הכלליות האלה לכללים מחמירים.
בקטע 'אינטראקציה בין טעינה עצלה לבין עדיפות אחזור', מודל הבסיס מזהה ש-loading="lazy" היא שיטה מומלצת, אבל המיומנות מספקת מידע חיוני: אסור לשלב בין fetchpriority="low" לבין מאפיין loading="lazy". האכיפה הזו שימושית כשכותבים קוד באמצעות סוכני AI.
אחרי שהסוכן מבין את הכללים המחמירים של modern-web-guidance, מבקשים ממנו לכתוב טיוטה של הקוד לשתי הגישות כדי לראות את ההבדל בהטמעה.
בודקים את התוכניות שהסוכן ממליץ עליהן:
▾ 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. השוואה בין הטמעות לא מודרכות לבין הטמעות מודרכות
אלה דוגמאות לפלט של סוכן מבדיקות השוואה עם Gemini ועם modern-web-guidance באפליקציה הזו של חנות ספרים.
התוצאות שלכם עשויות להיות שונות, לכן כדאי להשתמש באסטרטגיה הזו ולא לפעול לפי שלבים קבועים. אפשר להשתמש בתוכניות האלה כדי לראות איך הדברים משתנים כשמפעילים את modern-web-guidance באפליקציית חנות הספרים במחשב. אחרי שתסיימו להריץ בדיקות השוואה משלכם, תוכלו לשאול את הנציג איזו גישה מתאימה ביותר להגדרה הספציפית שלכם.
אתם יכולים לעקוב אחרי הביצועים של האפליקציה באמצעות Lighthouse או DevTools for Agents כדי לראות שיפורים בפועל בזמן שאתם מבצעים עדכונים.
1. טעינה מדורגת ואינטראקציה של עדיפות אחזור
כדאי לבצע אופטימיזציה לתמונות שלא מוצגות במסך כדי למנוע תחרות על רוחב הפס של השרשור הראשי.
תוכנית א' (מודל בסיסי)
החלת loading="lazy" רגיל על כל התמונות שלא מוצגות במסך. (לא אופטימלי: טעינה עצלה של נכסים מחוץ למסך, אבל מאפשרים לנכסים גלויים שאינם LCP בחלק העליון של הדף להתחרות עם תמונת ה-LCP).
<img src="https://..." alt="..." class="pick-small-img" loading="lazy">
Plan B (Modern Web Guidance)
כדאי להשתמש ב-fetchpriority="low" כדי לטרגט רכיבים שבהתחלה לא נראים בחלק העליון של הדף, ולוודא שתמונות רגילות שנטענות בטעינה עצלה נשארות בעדיפות ברירת המחדל. (האפשרות הכי טובה: הורדת דירוג של נכסים מוסתרים שחוסמים את נתיב העיבוד הקריטי בלי לפגוע בזמני הטעינה של הגלילה פנימה).
<img src="https://..." fetchpriority="low" width="96" height="144" alt="..." class="pick-small-img" loading="lazy">
2. טעינה מראש
כדי להאיץ את טעינת הדפים בעתיד, אפשר לבצע אחזור מראש של מסמכים או נכסים מהדף הבא.
תוכנית א' (מודל בסיסי)
בגישה הזו נעשה שימוש ברכיבי . (לא אופטימלי: עדיין יש עיכוב של בערך שנייה במעברים בין דפי המשנה).
<link rel="prefetch" href="about.html">
<link rel="prefetch" href="contact.html">
Plan B (Modern Web Guidance)
הדף משתמש ב-Speculation Rules API. (האפשרות המומלצת: כללי ספקולציה מאפשרים לבצע אחזור מראש וטרום-עיבוד עם שאילתות תואמות כדי לקצר את זמן הניווט שנתפס).
<script type="speculationrules">
{
"prefetch": [{
"where": { "href_matches": "/*" },
"eagerness": "moderate"
}]
}
</script>
3. הגבלות על טעינה מראש
כדי למנוע בעיות אבטחה, בעיות בביצועים או בעיות במצב, אפשר לחסום במפורש טעינה מראש של דפים מסוימים, למשל /logout או /basket.html.
תוכנית א' (מודל בסיסי)
בגישה הזו, המפתחים צריכים לנהל באופן ידני את כתובות ה-URL שרוצים לכלול. (לא אופטימלי: הגישה הזו מסוכנת כי היא יוצרת סיכון אבטחה גבוה יותר לפעולות רקע לא מכוונות).
Plan B (Modern Web Guidance)
הגישה הזו מאפשרת להחריג באופן הצהרתי נתיבים אדמיניסטרטיביים, נתיבים עם מצב או נתיבי שופינג. (האפשרות הכי טובה: החרגות פרוגרמטיות מונעות מהדפדפן לבצע פעולות לא מכוונות ברקע).
<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. ה-thread הראשי ומהירות התגובה לאינטראקציה באתר (INP)
כדי לשמור על רמת היענות גבוהה, חשוב לתת עדיפות לזמינות של השרשור הראשי לקלט של משתמשים.
תוכנית א' (מודל בסיסי):
דחיית חישובים כבדים באמצעות לולאות של קריאות חוזרות סינכרוניות. (לא אופטימלי: יכול להיות שתחוו מהירות תגובה לאינטראקציה באתר (INP) גבוהה אם השרשור הראשי של הדף עמוס.)
function renderBigCatalog(items) {
items.forEach(item => {
renderItem(item);
});
}
תוכנית ב' (Modern Web Guidance):
כדי שהשרשור הראשי ימשיך להגיב, משתמשים ב-scheduler.yield() כדי להעביר את השליטה לשרשור הראשי. (האפשרות הכי טובה: שיטת scheduler.yield() עוזרת לשמור על תגובתיות של הקלט בלי שייווצר מצב של הרעבת משימות).
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. CSS content-visibility
אפשר לנהל את חישובי הפריסה של רכיבים שלא מוצגים במסך על ידי דחיית פעולות העיבוד של רכיבים כאלה.
תוכנית א' (מודל בסיסי)
מצמצמים את חבילות הגיליונות הדינמיים (stylesheet). (Suboptimal: Standard rendering overhead on initial paint.)
.book-item {
display: flex;
margin: 1rem;
}
Plan B (Modern Web Guidance)
דילוג על צביעת אלמנטים מחוץ למסך עד שהם מתקרבים לגבולות אזור התצוגה. (האפשרות הכי טובה: מונעת תקורה של עיבוד בנייד בדפים גדולים. הכלי modern-web-guidance מוודא שהמאפיין content-visibility יוחל רק על רכיבים שלא מוצגים במסך, ומשייך אותו למאפיין contain-intrinsic-size. בלי ההקשר הזה, מודל בסיסי עשוי להחיל אותו באופן גלובלי, מה שעלול לגרום לשינויים משמעותיים בפריסה במהלך הגלילה).
.book-item {
display: flex;
margin: 1rem;
content-visibility: auto;
contain-intrinsic-size: auto 350px;
}
7. הטמעה ואימות
אחרי שמנתחים את ההבדלים ומזהים שתוכנית ב' היא הגישה האופטימלית, אפשר להחיל אותה על הפרויקט. עכשיו אפשר לראות איך הכללים האלה של Modern Web Guidance משפיעים על הציון שלכם ב-Lighthouse בעולם האמיתי.
הסוכן מחיל את fetchpriority המובנה, מגדיר את Speculation Rules API ומוסיף את התכונה microtask yielding. כשנוצר דוח Lighthouse הסופי, הציון לנייד עולה מהציון ההתחלתי של 61 מתוך 100.
השלמתם את המודרניזציה של הקוד מדור קודם.
8. שיפורים על סמך סדרי עדיפויות
בגישה הזו, המערכת מעריכה את האפליקציה כשמחילים עליה modern-web-guidance, ובודקת אם היא עומדת בשיטות המומלצות בפיתוח אתרים מודרני. בהמשך, כדאי להתנסות בהגדרות שונות:
- הוספת תכונה חדשה: המלצה על כותרת צפה שמוסתרת בזמן גלילה כדי למקסם את שטח המסך.
- התנסות ביעדי Baseline שונים: משנים את סטטוס ה-Baseline בפרויקט כדי לבחון את ההשפעות.
- התמקדו בתחומים ספציפיים ובדקו איך בחירות שונות משפיעות על בסיס הקוד.
האיטרציה עוזרת לכם להתמודד עם המורכבות של אפליקציות גדולות או מדור קודם, לשפר, לבדוק, לבנות ולחזור על הפעולות האלה.
9. השלבים הבאים
מידע נוסף על השימוש ב-Modern Web Guidance זמין במסמכי התיעוד בנושא פקודות Modern Web Guidance ובמאמר DevTools for Agents.
אם יש לכם שאלות או משוב לגבי Modern Web Guidance, אתם יכולים לפתוח בעיה במאגר GitHub.