עיבוד מראש של דפים ב-Chrome לניווט מיידי בדפים

Barry Pollard

פורסם: 2 בדצמבר 2022, עודכן לאחרונה: 22 בינואר 2026

צוות Chrome החזיר את הטעינה המקדימה המלאה של דפים עתידיים שסביר להניח שמשתמש ינווט אליהם.

היסטוריה קצרה של טרום-עיבוד

בעבר, Chrome תמך ברמז המשאב <link rel="prerender" href="/next-page">, אבל הוא לא נתמך באופן נרחב מחוץ ל-Chrome, והוא לא היה API מאוד מפורט.

הוצאנו משימוש את העיבוד מראש הקודם באמצעות הרמז rel=prerender לקישור, ועברנו לשימוש בשליפה מראש ללא מצב. במקום לעבד מראש את הדף באופן מלא או להפעיל JavaScript, המערכת שולפת מראש את המשאבים שדרושים לדף העתידי. השליפה מראש ללא שמירת מצב עוזרת לשפר את ביצועי הדף על ידי שיפור טעינת המשאבים, אבל היא לא תספק טעינת דף מיידית כמו עיבוד מראש מלא.

צוות Chrome החזיר עכשיו את הרינדור המקדים המלא ל-Chrome. כדי למנוע סיבוכים בשימוש הקיים ולאפשר הרחבה עתידית של טרום-העיבוד, מנגנון הטרום-העיבוד החדש הזה לא ישתמש בתחביר <link rel="prerender"...>, שעדיין קיים עבור NoState Prefetch, במטרה להוציא אותו משימוש בשלב מסוים בעתיד.

איך מתבצע עיבוד מראש של דף?

יש ארבע דרכים לבצע טרום-עיבוד של דף, וכולן נועדו לזרז את הניווטים:

1. כשמקלידים כתובת URL בסרגל הכתובות של Chrome (שנקרא גם "התיבה הרב-תכליתית"), ‏ Chrome עשוי לבצע טעינה מראש של הדף באופן אוטומטי, אם הוא בטוח במידה רבה שתבקרו בדף הזה, על סמך היסטוריית הגלישה הקודמת שלכם.
2. כשמשתמשים בסרגל הסימניות, יכול להיות ש-Chrome יבצע באופן אוטומטי טרום-עיבוד של הדף כשמעבירים את מצביע העכבר מעל אחד מכפתורי הסימניות.
3. כשמקלידים מונח חיפוש בסרגל הכתובות של Chrome, יכול להיות ש-Chrome יבצע באופן אוטומטי טרום-עיבוד של דף תוצאות החיפוש, אם מנוע החיפוש יורה לו לעשות זאת.
4. אתרים יכולים להשתמש ב-Speculation Rules API כדי להגדיר באופן אוטומטי ל-Chrome אילו דפים להציג מראש. התכונה הזו מחליפה את הפעולה ש<link rel="prerender"...> ביצעה בעבר, ומאפשרת לאתרים לבצע עיבוד מראש של דף באופן יזום על סמך כללי ספקולציה בדף. התגים האלה יכולים להיות קיימים בדפים באופן סטטי, או להיות מוזרקים באופן דינמי על ידי JavaScript לפי שיקול דעתו של בעל הדף.

בכל אחד מהמקרים האלה, עיבוד מראש מתבצע כאילו הדף נפתח בכרטיסיית רקע בלתי נראית, ואז הוא 'מופעל' על ידי החלפת הכרטיסייה שבחזית בדף שעבר עיבוד מראש. אם דף מופעל לפני שהוא עבר רינדור מראש באופן מלא, המצב הנוכחי שלו הוא 'העברה לחזית' והוא ממשיך להיטען, כך שעדיין אפשר לקבל יתרון משמעותי.

הדף שעבר עיבוד מראש נפתח במצב מוסתר, ולכן מספר ממשקי API שגורמים להתנהגויות פולשניות (לדוגמה, הנחיות) לא מופעלים במצב הזה, אלא מופעלים רק כשהדף מופעל. במקרים נדירים שבהם עדיין אי אפשר לעשות זאת, העיבוד מראש מבוטל. צוות Chrome עובד על חשיפת סיבות לביטול טרום-רנדור כ-API, וגם על שיפור היכולות של DevTools כדי להקל על זיהוי של מקרים חריגים כאלה.

ההשפעה של טרום-העיבוד

טרום-עיבוד מאפשר טעינה כמעט מיידית של הדף, כמו שרואים בסרטון הבא:

אתר הדוגמה הוא כבר אתר מהיר, אבל גם במקרה כזה אפשר לראות איך הרינדור המקדים משפר את חוויית המשתמש. לכן, יכולה להיות לכך גם השפעה ישירה על המדדים המרכזיים של ביצועי האתר, עם LCP קרוב לאפס, CLS מופחת (כי כל CLS של טעינה מתרחש לפני התצוגה הראשונית) ו-INP משופר (כי הטעינה אמורה להסתיים לפני שהמשתמש מבצע אינטראקציה).

גם אם דף מופעל לפני שהוא נטען במלואו, התחלה מוקדמת של טעינת הדף אמורה לשפר את חוויית הטעינה. כשמפעילים קישור בזמן שהעיבוד מראש עדיין מתבצע, הדף שעבר עיבוד מראש יעבור למסגרת הראשית וימשיך להיטען.

עם זאת, הרינדור המקדים משתמש בזיכרון נוסף וברוחב פס נוסף ברשת. חשוב להיזהר שלא להשתמש ביותר מדי טכניקות של טרום-עיבוד, כי זה עלול לבזבז משאבים של המשתמשים. עיבוד מראש מתבצע רק כשיש סבירות גבוהה שהמשתמש ינווט לדף.

בקטע מדידת הביצועים מוסבר איך למדוד את ההשפעה בפועל על הביצועים בניתוח הנתונים.

הצגת החיזויים בסרגל הכתובות של Chrome

במקרה השימוש הראשון, אפשר לראות את התחזיות של Chrome לגבי כתובות URL בדף chrome://predictors:

קווים ירוקים מציינים שיש מספיק ביטחון כדי להפעיל טרום-עיבוד. בדוגמה הזו, הקלדת האות s נותנת רמת סבירות סבירה (צהוב), אבל אחרי שמקלידים sh, ל-Chrome יש מספיק נתונים כדי להניח שכמעט תמיד עוברים אל https://sheets.google.com.

צילום המסך הזה נעשה בהתקנה חדשה יחסית של Chrome, והסינון בו הוא של תחזיות עם רמת מהימנות אפס. אבל אם תצפו בתחזיות שלכם, סביר להניח שתראו הרבה יותר רשומות, ואולי תצטרכו להקליד יותר תווים כדי להגיע לרמת מהימנות גבוהה מספיק.

התחזיות האלה גם מניעות את האפשרויות המוצעות בסרגל הכתובות, שאולי שמתם לב אליהן:

‫Chrome יעדכן באופן רציף את התחזיות שלו על סמך ההקלדה והבחירות שלכם.

• אם רמת הביטחון גבוהה מ-30% (מוצגת בצבע ענבר), Chrome מתחבר מראש לדומיין באופן יזום, אבל לא מבצע טרום-עיבוד של הדף.
• אם רמת הביטחון גבוהה מ-50% (מוצגת בירוק), Chrome יבצע טרום-עיבוד של כתובת ה-URL.

Speculation Rules API

באפשרות prerender של Speculation Rules API, מפתחי אתרים יכולים להוסיף הוראות JSON לדפים שלהם כדי ליידע את הדפדפן לגבי כתובות ה-URL שצריך לבצע להן prerender.

רשימת כתובות URL

כללי ספקולציות יכולים להתבסס על רשימות של כתובות URL:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

כללים לגבי מסמכים

כללי ספקולציה יכולים להיות גם 'כללים של מסמך' באמצעות התחביר where. התכונה הזו מציעה קישורים שנמצאו במסמך על סמך בוררי href (בהתבסס על URL Pattern API) או בוררי CSS:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"href_matches": "/wp-admin"}},
        { "not": {"href_matches": "/*\\?*(^|&)add-to-cart=*"}},
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel~=nofollow]"}}
      ]
    }
  }]
}
</script>

התלהבות

ההגדרה eagerness משמשת לציון המועד שבו ההשערות צריכות לפעול, וזה שימושי במיוחד לכללי מסמכים:

• ‫conservative: המפרט הזה מתייחס למיקום של מצביע או למגע.
• ‫moderate: במחשב, הפעולה הזו מבצעת ספקולציות אם מחזיקים את מצביע העכבר מעל קישור למשך 200 מילי-שניות (או באירוע pointerdown אם הוא מתרחש מוקדם יותר, ובנייד שבו אין אירוע hover). בנייד, החל מאוגוסט 2025, אנחנו נסתמך על היוריסטיקה מורכבת של אזור התצוגה. היוריסטיקות מורכבות של אזור התצוגה מופעלות 500 אלפיות השנייה אחרי שהמשתמש הפסיק לגלול, עבור תגי עוגן שנמצאים בטווח של 30% מהמרחק האנכי מהמצביע הקודם למטה, כאשר תגי העוגן גדולים לפחות פי 0.5 מתג העוגן הגדול ביותר באזור התצוגה. כפי שמתואר במסמך הזה.
• ‫eager: בעבר, ההתנהגות של התכונה הזו הייתה זהה לזו של immediate, אבל היא השתנתה החל מגרסה Chrome 143. במחשב, אם מחזיקים את מצביע העכבר מעל קישור למשך 10 אלפיות השנייה, מתבצעות ספקולציות. בנייד, החל מינואר 2026, נעבור לשימוש באוריסטיקה פשוטה של אזור התצוגה. היוריסטיקות פשוטות של אזור התצוגה מופעלות 50 אלפיות השנייה אחרי שהעוגן נכנס לאזור התצוגה.
• ‫immediate: הערך הזה משמש לספקולציה מוקדמת ככל האפשר, כלומר ברגע שמתגלים כללי הספקולציה.

ערך ברירת המחדל של eagerness לכללי list הוא immediate. אפשר להשתמש באפשרויות eager, moderate ו-conservative כדי להגביל את כללי list לכתובות URL שמשתמש מקיים איתן אינטראקציה ברשימה ספציפית. עם זאת, במקרים רבים, document כללים עם תנאי where מתאים עשויים להיות מתאימים יותר.

ערך ברירת המחדל של eagerness לכללי document הוא conservative. מסמך יכול לכלול הרבה כתובות URL, ולכן צריך להשתמש ב-immediate בזהירות כשמגדירים כללי document (אפשר לעיין גם בקטע ההגבלות ב-Chrome בהמשך).

ההגדרה eagerness שבה כדאי להשתמש תלויה באתר שלכם. באתר סטטי קל משקל, יכול להיות שאין עלות גבוהה לניחוש מוקדם יותר, והוא יכול להועיל למשתמשים. באתרים עם ארכיטקטורות מורכבות יותר ומטענים כבדים יותר של דפים, כדאי להפחית את הבזבוז על ידי צמצום התדירות של הניחושים עד שתקבלו אותות חיוביים יותר לגבי כוונת המשתמשים.

האפשרות moderate היא פשרה, ואתרים רבים יכולים להפיק תועלת מכלל הניחוש הבא, שיבצע טרום-עיבוד של קישור כשמחזיקים את מצביע העכבר מעל הקישור למשך 200 מילישניות או באירוע pointerdown כהטמעה בסיסית – אך עוצמתית – של כללי ניחוש:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "href_matches": "/*"
    },
    "eagerness": "moderate"
  }]
}
</script>

שליפה מראש (prefetch)

אפשר להשתמש בכללי ספקולציה גם רק לשליפה מראש של דפים, בלי לבצע עיבוד מראש מלא. לרוב, זה יכול להיות צעד ראשון טוב בדרך לטרום-עיבוד:

<script type="speculationrules">
{
  "prefetch": [
    {
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

Prender until script

צוות Chrome עובד גם על הוספת prerender_until_script ל-Speculation Rules API (ראו: באג בהטמעה). זה יהיה שלב בין השליפה מראש (prefetch) לבין הטרום-עיבוד (prerender), והשימוש בו יהיה דומה:

<script type="speculationrules">
{
  "prerender_until_script": [
    {
      "urls": ["next.html", "next2.html"]
    }
  ]
}
</script>

בדומה ל-NoState prefetch, הפקודה הזו תבצע אחזור מראש של מסמך ה-HTML וגם של משאבי המשנה שזמינים ב-HTML. אבל הוא ימשיך מעבר לכך ויתחיל גם לבצע טרום-עיבוד של הדף, ויפסיק כשהוא ייתקל בסקריפט הראשון.

המשמעות היא שבדפים ללא JavaScript, או עם JavaScript רק בכותרת התחתונה, אפשר לבצע מראש כמעט את כל העיבוד המקדים של הדף. דפים עם סקריפטים בתג <head> לא יוכלו לעבור טרום-עיבוד, אבל עדיין ייהנו מאחזור משאבי המשנה.

כך אפשר להימנע מהסיכונים של תופעות לוואי לא רצויות כתוצאה מהרצת JavaScript, אבל עדיין ליהנות משיפור משמעותי יותר בביצועים מאשר רק prefetch.

מגבלות ב-Chrome

ב-Chrome יש מגבלות כדי למנוע שימוש יתר ב-Speculation Rules API:

ההגדרות moderate ו-conservative – שתלויות באינטראקציה של המשתמש – פועלות בשיטת נכנס ראשון, יוצא ראשון (FIFO): אחרי שמגיעים למגבלה, ספקולציה חדשה תגרום לביטול הספקולציה הכי ישנה ולהחלפתה בספקולציה החדשה יותר, כדי לחסוך בזיכרון. אפשר להפעיל מחדש ניחוש שבוטל – למשל, על ידי ריחוף מעל הקישור הזה שוב – וכתוצאה מכך כתובת ה-URL הזו תנוחש מחדש, והניחוש הכי ישן יידחק החוצה. במקרה כזה, ההשערה הקודמת תאחסן במטמון את כל המשאבים שניתנים לאחסון במטמון במטמון ה-HTTP של כתובת ה-URL הזו, ולכן ההשערה הבאה תהיה זולה יותר. לכן הגדרנו את המגבלה לסף הנמוך של 2. כללים של רשימה סטטית לא מופעלים על ידי פעולת משתמש, ולכן יש להם מגבלה גבוהה יותר, כי הדפדפן לא יכול לדעת אילו כללים נדרשים ומתי הם נדרשים.

גם המגבלות immediate ו-eager הן דינמיות, כך שהסרה של רכיב סקריפט של כתובת URL list תיצור קיבולת על ידי ביטול הניחושים שהוסרו.

‫Chrome גם ימנע שימוש בהשערות בתנאים מסוימים, כולל:

• Save-Data.
• חיסכון באנרגיה כשהוא מופעל ורמת הטעינה של הסוללה נמוכה.
• מגבלות זיכרון.
• כשההגדרה 'טעינה מראש של דפים' מושבתת (היא מושבתת גם באופן מפורש על ידי תוספי Chrome כמו uBlock Origin).
• דפים שנפתחו בכרטיסיות ברקע.

בנוסף, Chrome לא מעבד iframe ממקורות שונים בדפים שעברו עיבוד מראש עד להפעלה.

כל התנאים האלה נועדו לצמצם את ההשפעה של ספקולציות מוגזמות במקרים שבהם הן עלולות לפגוע במשתמשים.

איך כוללים כללי ספקולציות בדף

אפשר לכלול כללי ניחוש באופן סטטי ב-HTML של הדף או להוסיף אותם באופן דינמי לדף באמצעות JavaScript:

• כללי ניחוש שנוספו באופן סטטי: לדוגמה, אתר חדשות או בלוג יכולים לבצע טרום-עיבוד של המאמר החדש ביותר, אם זה לרוב היעד הבא של חלק גדול מהמשתמשים. לחלופין, אפשר להשתמש בכללי מסמך עם moderate או conservative כדי לנחש את הפעולות של המשתמשים בזמן שהם מבצעים אינטראקציה עם קישורים.
• כללי ניחוש שמוכנסים באופן דינמי: יכול להיות שהם מבוססים על לוגיקה של אפליקציה, מותאמים אישית למשתמש או מבוססים על היוריסטיקה אחרת.

אם אתם מעדיפים הוספה דינמית על סמך פעולות כמו ריחוף מעל קישור או לחיצה על קישור – כמו שספריות רבות עשו בעבר עם <link rel=prefetch> – מומלץ לעיין בכללי המסמך, כי הם מאפשרים לדפדפן לטפל ברבים מהתרחישים שלכם.

אפשר להוסיף כללי ספקולציה ב-<head> או ב-<body> של המסגרת הראשית. לא מתבצעת פעולה לפי כללי טעינה מראש ב-subframes, וכללי טעינה מראש בדפים שעברו טרום-עיבוד מופעלים רק אחרי שהדף מופעל.

כותרת ה-HTTP‏ Speculation-Rules

אפשר גם להעביר כללים לניחוש מראש באמצעות כותרת HTTP של Speculation-Rules, במקום לכלול אותם ישירות ב-HTML של המסמך. כך קל יותר לפרוס את המסמכים באמצעות רשתות CDN בלי לשנות את התוכן שלהם.

כותרת ה-HTTP‏ Speculation-Rules מוחזרת עם המסמך, ומפנה למיקום של קובץ JSON שמכיל את כללי הניחוש:

Speculation-Rules: "/speculationrules.json"

למשאב הזה צריך להיות סוג ה-MIME הנכון, ואם הוא משאב חוצה מקורות, הוא צריך לעבור בדיקת CORS.

Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *

אם רוצים להשתמש בכתובות URL יחסיות, כדאי לכלול את המפתח "relative_to": "document" בכללי הניחוש. אחרת, כתובות URL יחסיות יהיו יחסיות לכתובת ה-URL של קובץ ה-JSON של כללי הניחוש. האפשרות הזו יכולה להיות שימושית במיוחד אם אתם צריכים לבחור חלק מהקישורים מאותו מקור או את כולם.

שדה התג של כללי ספקולציות

אפשר גם להוסיף 'תגים' בתחביר JSON של כללי הניחוש ברמה הכוללת לכל כללי הניחוש בקבוצת כללים:

{
  "tag": "my-rules",
  "prefetch": [
    "urls": ["next.html"]
  ],
  "prerender": [
    "urls": ["next2.html"]
  ],
}

או ברמת הכלל הספציפי:

{
  "prefetch": [
    "urls": ["next.html"],
    "tag": "my-prefetch-rules"
  ],
  "prerender": [
    "urls": ["next2.html"],
    "tag": "my-prerender-rules"
  ],
}

התג הזה משתקף בכותרת ה-HTTP ‏Sec-Speculation-Tags, שאפשר להשתמש בה כדי לסנן כללי ניחוש בשרת. כותרת ה-HTTP‏ Sec-Speculation-Tags יכולה לכלול כמה תגים אם הספקולציה מכוסה על ידי כמה כללים, כמו בדוגמה הבאה:

Sec-Speculation-Tags: null
Sec-Speculation-Tags: null, "cdn-prefetch"
Sec-Speculation-Tags: "my-prefetch-rules"
Sec-Speculation-Tags: "my-prefetch-rules", "my-rules", "cdn-prefetch"

חלק מרשתות ה-CDN מוסיפות כללי ניחוש באופן אוטומטי, אבל חוסמות ניחושים בדפים שלא נשמרו במטמון של שרת קצה, כדי שהתכונה הזו לא תגרום לשימוש מוגבר בשרת המקור. התגים מאפשרים להם לזהות השערות שהופעלו על ידי קבוצת הכללים שמוגדרת כברירת מחדל, אבל עדיין מאפשרים לכל כלל שנוסף על ידי האתר לעבור למקור.

תגי ערכת הכללים מוצגים גם בכלי הפיתוח ל-Chrome.

השדה Speculation rules target_hint

כללי הניחוש יכולים לכלול גם שדה target_hint, שמכיל שם או מילת מפתח תקפים של הקשר גלישה שמציינים איפה הדף מצפה שהתוכן שעבר טרום-עיבוד יופעל:

<script type=speculationrules>
{
  "prerender": [{
    "target_hint": "_blank",
    "urls": ["next.html"]
  }]
}
</script>

ההערה הזו מאפשרת לטפל בספקולציות של טרום-עיבוד עבור קישורי target="_blank":

<a target="_blank" href="next.html">Open this link in a new tab</a>

בשלב הזה, רק "target_hint": "_blank" ו-"target_hint": "_self" (ברירת המחדל אם לא מצוין אחרת) נתמכים ב-Chrome, ורק עבור prerender – לא נתמך prefetch.

התג target_hint נדרש רק לכללי ספקולציה של urls, כי בכללי מסמך הערך של target ידוע מהקישור עצמו.

כללי ספקולציות ו-SPA

כללי ספקולציה נתמכים רק בניווטים בדפים מלאים שמנוהלים על ידי הדפדפן, ולא באפליקציות של דף יחיד (SPA) או בדפים של מעטפת אפליקציה. בארכיטקטורות האלה לא מתבצעות אחזור של מסמכים, אלא אחזור של נתונים או דפים באמצעות API או אחזור חלקי שלהם. הנתונים או הדפים האלה מעובדים ומוצגים בדף הנוכחי. האפליקציה יכולה לבצע אחזור מראש של הנתונים שנדרשים למה שנקרא "מעברים רכים", מחוץ לכללי הניחוש, אבל היא לא יכולה לבצע עיבוד מראש שלהם.

אפשר להשתמש בכללי ספקולציה כדי לבצע עיבוד מראש של האפליקציה עצמה מדף קודם. כך אפשר לקזז חלק מהעלויות הנוספות של טעינה ראשונית שיש לחלק מאתרי ה-SPA. עם זאת, אי אפשר לבצע רינדור מראש של שינויים במסלול בתוך האפליקציה.

ניפוי באגים של כללי ספקולציות

בפוסט הייעודי בנושא ניפוי באגים בכללי ניחוש מוסבר על התכונות החדשות בכלי הפיתוח של Chrome שעוזרות לצפות ב-API החדש הזה ולנפות בו באגים.

כמה כללי ספקולציות

אפשר גם להוסיף כמה כללי ניחוש לאותו דף, והם יצורפו לכללים הקיימים. לכן, כל הדרכים השונות הבאות יובילו לטרום-רנדור של one.html ושל two.html:

רשימת כתובות URL:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html", "two.html"]
    }
  ]
}
</script>

כמה סקריפטים של speculationrules:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    }
  ]
}
</script>
<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

כמה רשימות בתוך קבוצה אחת של speculationrules

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    },
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

התמיכה של No-Vary-Search

כשמבצעים אחזור מראש או עיבוד מראש של דף, יכול להיות שפרמטרים מסוימים של כתובת URL (שנקראים טכנית פרמטרים של חיפוש) לא חשובים לדף שמועבר בפועל על ידי השרת, ומשמשים רק ל-JavaScript בצד הלקוח.

לדוגמה, מערכת Google Analytics משתמשת בפרמטרים של UTM למדידת קמפיינים, אבל בדרך כלל לא מציגה דפים שונים מהשרת. המשמעות היא שגם page1.html?utm_content=123 וגם page1.html?utm_content=456 יציגו את אותו דף מהשרת, כך שאפשר לעשות שימוש חוזר באותו דף מהמטמון.

באופן דומה, אפליקציות עשויות להשתמש בפרמטרים אחרים של כתובות URL שמטופלים רק בצד הלקוח.

ההצעה No-Vary-Search מאפשרת לשרת לציין פרמטרים שלא גורמים להבדל במשאב שמועבר, ולכן מאפשרת לדפדפן לעשות שימוש חוזר בגרסאות של מסמך שנשמרו במטמון בעבר, ששונות רק בפרמטרים האלה. התכונה הזו נתמכת ב-Chrome (ובדפדפנים שמבוססים על Chromium) לניחושים של ניווט גם לגבי אחזור מראש וגם לגבי טרום-עיבוד.

בכללי ניחוש אפשר להשתמש ב-expects_no_vary_search כדי לציין איפה צפויה לחזור כותרת HTTP‏ No-Vary-Search. כך תוכלו למנוע הורדות מיותרות לפני שהתשובות מוצגות.

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products"],
    "expects_no_vary_search": "params=(\"id\")"
  }]
}
</script>

<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>

בדוגמה הזו, ה-HTML הראשוני של הדף /products זהה לשני מזהי המוצרים 123 ו-124. עם זאת, התוכן של הדף משתנה בסופו של דבר על סמך עיבוד בצד הלקוח באמצעות JavaScript כדי לאחזר נתוני מוצרים באמצעות פרמטר החיפוש id. לכן אנחנו מבצעים אחזור מראש של כתובת ה-URL הזו, והיא אמורה להחזיר כותרת HTTP‏ No-Vary-Search שמראה שאפשר להשתמש בדף לכל פרמטר חיפוש id.

עם זאת, אם המשתמש ילחץ על אחד מהקישורים לפני שהטעינה מראש תושלם, יכול להיות שהדפדפן לא יקבל את הדף /products. במקרה הזה, הדפדפן לא יודע אם הוא יכיל את כותרת ה-HTTP‏ No-Vary-Search. לאחר מכן, הדפדפן צריך להחליט אם לאחזר את הקישור שוב או להמתין לסיום האחזור המקדים כדי לבדוק אם הוא מכיל כותרת HTTP‏ No-Vary-Search. ההגדרה expects_no_vary_search מאפשרת לדפדפן לדעת שתגובת הדף צפויה להכיל כותרת HTTP No-Vary-Search, ולהמתין עד לסיום האחזור המקדים.

אפשר גם להוסיף כמה פרמטרים ל-expects_no_vary_search ולהפריד ביניהם ברווח (כי No-Vary-Search היא כותרת HTTP מובנית):

    "expects_no_vary_search": "params=(\"param1\" \"param2\" \"param3\")"

הגבלות על כללי ספקולציות ושיפורים עתידיים

כללי הספקולציה מוגבלים לדפים שנפתחים באותה כרטיסייה, אבל אנחנו פועלים לצמצום ההגבלה הזו.

כברירת מחדל, ההשערות מוגבלות לדפים מאותו מקור. ניחוש של דפים חוצי-מקורות באותו אתר (לדוגמה, https://a.example.com יכול לבצע טרום-עיבוד של דף ב-https://b.example.com). כדי להשתמש בתכונה הזו, הדף המשוער (https://b.example.com בדוגמה הזו) צריך להביע הסכמה על ידי הכללת כותרת HTTP ‏Supports-Loading-Mode: credentialed-prerender, אחרת Chrome יבטל את הניחוש.

יכול להיות שגרסאות עתידיות גם יאפשרו עיבוד מראש של דפים ממקורות שונים שלא נמצאים באותו אתר, כל עוד לא קיימים קובצי Cookie בדף שעבר עיבוד מראש והדף שעבר עיבוד מראש מביע הסכמה באמצעות כותרת HTTP דומה Supports-Loading-Mode: uncredentialed-prerender.

כללי הניחוש כבר תומכים באחזור מראש של נתונים ממקורות שונים, אבל שוב, רק אם אין קובצי Cookie לדומיין ממקור שונה. אם קיימים קובצי Cookie מהביקור הקודם של המשתמש באתר, לא יתבצע ניחוש והשגיאה תוצג בכלי הפיתוח.

בהתחשב במגבלות הנוכחיות, דפוס אחד שיכול לשפר את חוויית המשתמשים שלכם גם בקישורים פנימיים וגם בקישורים חיצוניים, איפה שאפשר, הוא לבצע עיבוד מראש של כתובות URL מאותו מקור ולנסות לאחזר מראש כתובות URL ממקורות שונים:

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": { "href_matches": "/*" },
        "eagerness": "moderate"
      }
    ],
    "prefetch": [
      {
        "where": { "not": { "href_matches": "/*" } },
        "eagerness": "moderate"
      }
    ]
  }
</script>

ההגבלה למניעת ספקולציות ממקורות שונים לגבי קישורים ממקורות שונים נדרשת לצורך אבטחה. השיטה הזו משפרת את <link rel="prefetch"> עבור יעדים חוצי-מקורות, שגם לא ישלחו קובצי Cookie אבל עדיין ינסו לבצע אחזור מראש – מה שיגרום לאחזור מראש מיותר שצריך לשלוח מחדש, או גרוע מכך, לטעינה של הדף הלא נכון.

תמיכה ב-API לזיהוי כללי ספקולציות

אפשר לזהות תמיכה ב-Speculation Rules API באמצעות בדיקות HTML רגילות:

if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  console.log('Your browser supports the Speculation Rules API.');
}

הוספה דינמית של כללי ניחוש באמצעות JavaScript

דוגמה להוספת prerender כלל ניחוש באמצעות JavaScript:

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specRules = {
    prerender: [
      {
        urls: ['/next.html'],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('added speculation rules to: next.html');
  document.body.append(specScript);
}

בדף הדגמה של עיבוד מראש אפשר לראות הדגמה של עיבוד מראש באמצעות Speculation Rules API, עם הוספה של JavaScript.

הוספה של רכיב <script type = "speculationrules"> ישירות ל-DOM באמצעות innerHTML לא תרשום את כללי הניחוש מטעמי אבטחה, ולכן צריך להוסיף אותו כמו שמוצג למעלה. עם זאת, תוכן שמוכנס באופן דינמי באמצעות innerHTML שמכיל קישורים חדשים, יזוהה על ידי הכללים הקיימים בדף.

באופן דומה, עריכה ישירה של החלונית Elements ב-Chrome DevTools כדי להוסיף את הרכיב <script type = "speculationrules"> לא רושמת את כללי הניחוש, ובמקום זאת צריך להפעיל את הסקריפט מהמסוף כדי להוסיף את הכללים ל-DOM.

הוספת כללי ניחוש באמצעות כלי לניהול תגים

כדי להוסיף כללי ניחוש באמצעות כלי לניהול תגים כמו Google Tag Manager‏ (GTM), צריך להוסיף אותם באמצעות JavaScript, ולא להוסיף את הרכיב <script type = "speculationrules"> ישירות דרך GTM. הסיבות לכך הן אותן סיבות שצוינו קודם:

הערה: בדוגמה הזו נעשה שימוש ב-var כי GTM לא תומך ב-const.

ביטול כללי ספקולציות

הסרה של כללי ספקולציה תגרום לביטול העיבוד מראש. עם זאת, עד שזה יקרה, סביר להניח שכבר יבוזבזו משאבים על הפעלת הטרום-עיבוד, ולכן מומלץ לא להשתמש בטרום-עיבוד אם יש סיכוי שתצטרכו לבטל אותו. מצד שני, אפשר לעשות שימוש חוזר במשאבים שנשמרו במטמון, כך שביטולים לא בהכרח ירדו לטמיון ויכול להיות שהם עדיין יועילו לניווטים ולספקולציות עתידיות.

אפשר גם לבטל השערות באמצעות כותרת ה-HTTP‏ Clear-Site-Data עם ההנחיות prefetchCache ו-prerenderCache.

האפשרות הזו יכולה להיות שימושית כשהמצב משתנה בשרת. לדוגמה, כשקוראים ל-API של 'הוספה לסל' או ל-API של התחברות או יציאה מהחשבון.

באופן אידיאלי, עדכוני המצב האלה יועברו לדפים שעברו עיבוד מראש באמצעות ממשקי API כמו Broadcast Channel API, אבל אם זה לא אפשרי, או עד שהלוגיקה הזו תיושם, יכול להיות שיהיה קל יותר לבטל את הניחוש.

כללי ספקולציה ומדיניות אבטחת תוכן

מכיוון שכללי הניחוש משתמשים ברכיב <script>, גם אם הם מכילים רק JSON, צריך לכלול אותם ב-script-src Content-Security-Policy אם האתר משתמש בזה – באמצעות hash או nonce.

אפשר להוסיף inline-speculation-rules חדש ל-script-src כדי לתמוך ברכיבי <script type="speculationrules"> שמוחדרים מסקריפטים עם גיבוב או עם ערך חד-פעמי. ההגדרה הזו לא תומכת בכללים שכלולים ב-HTML הראשוני, ולכן צריך להחדיר כללים באמצעות JavaScript לאתרים שמשתמשים ב-CSP מחמיר.

זיהוי והשבתה של טרום-עיבוד

טרום-עיבוד בדרך כלל משפר את חוויית המשתמשים, כי הוא מאפשר עיבוד מהיר של הדף – לעיתים קרובות באופן מיידי. הדבר מועיל גם למשתמש וגם לבעל האתר, כי דפים שעברו טרום-עיבוד מאפשרים חוויית משתמש טובה יותר, שאולי קשה להשיג בדרך אחרת.

עם זאת, יכול להיות שיהיו מקרים שבהם לא תרצו שהדפים יעברו רינדור מראש, למשל כשהמצב של הדפים משתנה – על סמך הבקשה הראשונית או על סמך JavaScript שמופעל בדף.

הפעלה והשבתה של טרום-עיבוד ב-Chrome

הטעינה מראש מופעלת רק למשתמשי Chrome שההגדרה 'טעינה מראש של דפים' מופעלת אצלם ב-chrome://settings/performance/. בנוסף, הרינדור מראש מושבת גם במכשירים עם זיכרון נמוך, או אם מערכת ההפעלה נמצאת במצב חיסכון בנתונים או במצב חיסכון באנרגיה. מידע נוסף זמין בקטע ההגבלות ב-Chrome.

זיהוי והשבתה של טרום-עיבוד בצד השרת

דפים שעברו עיבוד מראש יישלחו עם כותרת ה-HTTP‏ Sec-Purpose:

Sec-Purpose: prefetch;prerender

בדפים שבוצעה להם שליפה מראש באמצעות Speculation Rules API, הכותרת הזו תוגדר לערך prefetch בלבד:

Sec-Purpose: prefetch

השרתים יכולים להגיב על סמך הכותרת הזו כדי לרשום בקשות ספקולטיביות ביומן, להחזיר תוכן שונה או למנוע טרום-עיבוד. אם מוחזר קוד תגובה סופי שלא מציין הצלחה – כלומר, לא בטווח 200-299 אחרי הפניות אוטומטיות – הדף לא יעבור עיבוד מראש וכל דף שבוצע לו אחזור מראש יימחק. חשוב גם לציין שתגובות 204 ו-205 לא תקפות גם לטרום-עיבוד, אבל הן תקפות לאחזור מראש.

אם אתם לא רוצים שדף מסוים יעבור טרום-עיבוד, הדרך הכי טובה לוודא שזה לא יקרה היא להחזיר קוד תגובה שאינו 2XX (למשל 503). עם זאת, כדי לספק את חוויית השימוש הטובה ביותר, מומלץ לאפשר טרום-עיבוד, אבל לדחות כל פעולה שצריכה לקרות רק כשהדף מוצג בפועל, באמצעות JavaScript.

זיהוי טרום-עיבוד ב-JavaScript

‫API‏ document.prerendering יחזיר true בזמן שהדף עובר עיבוד מראש. דפים יכולים להשתמש בזה כדי למנוע פעילויות מסוימות במהלך הטרום-רנדור, או לדחות אותן עד שהדף מופעל בפועל.

אחרי שמפעילים מסמך שעבר עיבוד מראש, הערך של PerformanceNavigationTiming's activationStart מוגדר גם הוא לזמן שאינו אפס, שמייצג את הזמן שחלף בין תחילת העיבוד מראש לבין ההפעלה בפועל של המסמך.

אפשר להשתמש בפונקציה הבאה כדי לבדוק אם מתבצע טרום עיבוד של דפים או אם הדפים עברו טרום עיבוד:

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
  );
}

הדרך הכי קלה לבדוק אם דף עבר טרום-עיבוד (מלא או חלקי) היא לפתוח את כלי הפיתוח אחרי שהדף מופעל ולהקליד performance.getEntriesByType('navigation')[0].activationStart במסוף. אם מוחזר ערך שאינו אפס, אתם יודעים שהדף עבר טרום-עיבוד:

כשהמשתמש מפעיל את הדף על ידי צפייה בו, האירוע prerenderingchange מופעל ב-document. לאחר מכן אפשר להשתמש באירוע הזה כדי להפעיל פעילויות שהיו מופעלות כברירת מחדל בטעינת הדף, אבל אתם רוצים להשהות אותן עד שהמשתמש יצפה בדף בפועל.

באמצעות ממשקי ה-API האלה, קוד JavaScript של ממשק הקצה יכול לזהות דפים שעברו עיבוד מראש ולפעול בהתאם.

ההשפעה על ניתוח הנתונים

מערכת Analytics משמשת למדידת השימוש באתר. לדוגמה, אפשר להשתמש ב-Google Analytics כדי למדוד צפיות בדפים ואירועים. אפשרות נוספת היא למדוד את מדדי הביצועים של הדפים באמצעות מעקב אחר משתמשים אמיתיים (RUM).

צריך לבצע טרום-עיבוד של דפים רק כשיש סבירות גבוהה שהמשתמש יטען את הדף. לכן, האפשרויות של טעינה מראש בסרגל הכתובות של Chrome מתרחשות רק כשיש סיכוי גבוה מאוד (יותר מ-80% מהזמן).

עם זאת – במיוחד כשמשתמשים ב-Speculation Rules API – יכול להיות שלדפים שעברו טרום-עיבוד תהיה השפעה על ניתוח הנתונים, ובעלי האתרים יצטרכו להוסיף קוד נוסף כדי להפעיל את ניתוח הנתונים רק עבור דפים שעברו טרום-עיבוד כשהם מופעלים, כי לא כל ספקי ניתוח הנתונים עושים את זה כברירת מחדל.

אפשר להשיג את זה באמצעות Promise שממתין לאירוע prerenderingchange אם המסמך עובר טרום-עיבוד, או שמבצע פעולה באופן מיידי אם הוא מוצג כרגע:

// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

גישה חלופית היא להשהות את פעילויות הניתוח עד שהדף מוצג בפעם הראשונה. כך אפשר לטפל גם במקרה של טרום-עיבוד וגם במקרים שבהם כרטיסיות נפתחות ברקע (לדוגמה, באמצעות לחיצה ימנית ובחירה באפשרות 'פתיחה בכרטיסייה חדשה'):

// Set up a promise for when the page is first made visible
const whenFirstVisible = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenFirstVisible;
  // Initialise your analytics
}

initAnalytics();

יכול להיות שזה הגיוני לניתוח נתונים ולתרחישי שימוש דומים, אבל במקרים אחרים יכול להיות שתרצו לטעון יותר תוכן, ולכן כדאי להשתמש בתגים document.prerendering ו-prerenderingchange כדי לטרגט באופן ספציפי דפים שעוברים טרום-עיבוד.

השהיית תוכן אחר במהלך טרום-הרינדור

אפשר להשתמש באותם ממשקי API שצוינו קודם כדי להשהות תוכן אחר במהלך שלב הטרום-עיבוד. אלה יכולים להיות חלקים ספציפיים של JavaScript או רכיבי סקריפט שלמים שאתם מעדיפים שלא יפעלו במהלך שלב הטרום-עיבוד.

לדוגמה, אם נתון הסקריפט הבא:

<script src="https://example.com/app/script.js" async></script>

אפשר לשנות את זה לרכיב סקריפט שמוכנס באופן דינמי, ומוכנס רק על סמך הפונקציה הקודמת whenActivated:

async function addScript(scriptUrl) {
  await whenActivated;
  const script = document.createElement('script');
  script.src = 'scriptUrl';
  document.body.appendChild(script);
}

addScript('https://example.com/app/script.js');

האפשרות הזו יכולה להיות שימושית כדי לעכב סקריפטים נפרדים שכוללים ניתוח נתונים, או כדי לעבד תוכן על סמך מצב או משתנים אחרים שיכולים להשתנות במהלך הביקור. לדוגמה, יכול להיות שהמלצות, סטטוס התחברות או סמלים של עגלת קניות לא יוצגו כדי לוודא שמוצג המידע העדכני ביותר.

יכול להיות שהמצב הזה יקרה יותר פעמים כשמשתמשים בטכניקת טרום-העיבוד, אבל התנאים האלה מתקיימים גם לגבי דפים שנטענים בכרטיסיות ברקע שצוינו קודם (לכן אפשר להשתמש בפונקציה whenFirstVisible במקום בפונקציה whenActivated).

במקרים רבים, מומלץ לבדוק את הסטטוס גם בשינויים כלליים ב-visibilitychange – לדוגמה, כשחוזרים לדף שהיה ברקע, צריך לעדכן את מוני עגלת הקניות במספר הפריטים העדכני בעגלה. לכן, זו לא בעיה שקשורה ספציפית לטרום-עיבוד, אלא טרום-עיבוד רק הופך בעיה קיימת לברורה יותר.

אחת הדרכים שבהן Chrome מצמצם את הצורך בהוספת תגי עטיפה לסקריפטים או לפונקציות באופן ידני היא השהיה של ממשקי API מסוימים, כפי שצוין קודם. בנוסף, לא מתבצע רינדור של iframe של צד שלישי, ולכן רק תוכן שמוצג מעל ה-iframe הזה צריך להיות מושהה באופן ידני.

למדוד ביצועים

כדי למדוד מדדי ביצועים, מערכת הניתוח צריכה לקחת בחשבון אם עדיף למדוד אותם על סמך זמן ההפעלה ולא על סמך זמן טעינת הדף שדווח על ידי ממשקי API של הדפדפן.

המדדים הבסיסיים של חוויית המשתמש נמדדים על ידי Chrome באמצעות הדוח לגבי חוויית המשתמש ב-Chrome, והם נועדו למדוד את חוויית המשתמש. לכן המדדים האלה נמדדים על סמך זמן ההפעלה. לדוגמה, שימוש בטכניקה הזו יכול להוביל לערך LCP של 0 שניות, ולכן זו דרך מצוינת לשפר את המדדים הבסיסיים של חוויית המשתמש.

החל מגרסה 3.1.0, הספרייה web-vitals עודכנה כדי לטפל בניווטים שעברו טרום-עיבוד באותו אופן שבו Chrome מודד את מדדי הליבה של חוויית השימוש באתר. בנוסף, בגרסה הזו, אם הדף עבר טרום-עיבוד מלא או חלקי, המערכת מסמנת את הניווטים שעברו טרום-עיבוד במדדים האלה באמצעות מאפיין Metric.navigationType.

מדידת טרום-עיבוד

כדי לראות אם דף מסוים עבר טרום-עיבוד, אפשר לחפש רשומה של PerformanceNavigationTiming עם ערך שונה מאפס activationStart. אחר כך אפשר לרשום את זה ביומן באמצעות מאפיין מותאם אישית, או בדרך דומה כשרושמים ביומן את הצפיות בדף, למשל באמצעות הפונקציה pagePrerendered שמתוארת למעלה:

// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');

כך תוכלו לראות בניתוח הנתונים כמה ניווטים עברו טרום-עיבוד בהשוואה לסוגים אחרים של ניווטים, וגם תוכלו לקשר בין מדדי ביצועים או מדדים עסקיים שונים לבין סוגי הניווטים האלה. דפים שנטענים מהר יותר משמחים את המשתמשים, ולעיתים קרובות יש לכך השפעה אמיתית על מדדים עסקיים, כפי שאפשר לראות במחקרים שלנו.

כשאתם מודדים את ההשפעה העסקית של טרום-עיבוד דפים לניווטים מיידיים, אתם יכולים להחליט אם כדאי להשקיע יותר מאמץ בשימוש בטכנולוגיה הזו כדי לאפשר טרום-עיבוד של יותר ניווטים, או לבדוק למה הדפים לא עוברים טרום-עיבוד.

מדידת שיעורי ההצלחה

בנוסף למדידת ההשפעה של דפים שנכנסים אליהם אחרי טרום-עיבוד, חשוב גם למדוד דפים שעברו טרום-עיבוד ולא נכנסים אליהם בהמשך. יכול להיות שאתם מבצעים יותר מדי טרום-עיבוד, ומשתמשים במשאבים יקרי ערך של המשתמש ללא תועלת רבה.

אפשר למדוד את זה על ידי הפעלת אירוע ניתוח כשמוסיפים כללי ניחוש – אחרי שבודקים אם הדפדפן תומך בטעינה מראש באמצעות HTMLScriptElement.supports('speculationrules') – כדי לציין שהתבקשה טעינה מראש. (הערה: רק כי נשלחה בקשה לעיבוד מראש, לא אומר שהעיבוד מראש התחיל או הסתיים. כמו שצוין קודם, עיבוד מראש הוא רמז לדפדפן, והוא יכול לבחור לא לעבד מראש דפים על סמך הגדרות המשתמש, השימוש הנוכחי בזיכרון או היוריסטיקות אחרות).

אחר כך תוכלו להשוות בין מספר האירועים האלה לבין מספר הצפיות בדפים שבוצעו בפועל לפני הרינדור. אפשרות אחרת היא להפעיל אירוע נוסף בהפעלה, אם זה יקל על ההשוואה.

אפשר להעריך את 'שיעור ההצלחה של ההיט' על סמך ההבדל בין שני הנתונים האלה. בדפים שבהם אתם משתמשים ב-Speculation Rules API כדי לבצע טרום-עיבוד של הדפים, אתם יכולים לשנות את הכללים בהתאם כדי לשמור על שיעור פגיעה גבוה, וכך לשמור על האיזון בין שימוש במשאבי המשתמשים כדי לעזור להם לבין שימוש מיותר במשאבים.

חשוב לדעת שחלק מהטעינה מראש עשוי להתבצע בגלל טעינה מראש של סרגל הכתובות, ולא רק בגלל כללי הניחוש שלכם. אם רוצים להבדיל בין הניווטים האלה, אפשר לבדוק את document.referrer (שיהיה ריק בניווטים בסרגל הכתובות, כולל ניווטים בסרגל הכתובות שעברו טרום-עיבוד).

חשוב לבדוק גם דפים שלא מתבצע בהם טרום-רנדור, כי יכול להיות שהדפים האלה לא עומדים בדרישות לטרום-רנדור, גם לא מסרגל הכתובות. יכול להיות שאתם לא נהנים מהשיפור הזה בביצועים. צוות Chrome מתכנן להוסיף כלי בדיקה נוספים כדי לבדוק את הזכאות לטרום-עיבוד, אולי בדומה לכלי הבדיקה של bfcache, וגם להוסיף API כדי להסביר למה טרום-עיבוד נכשל.

ההשפעה על תוספים

בפוסט הייעודי בנושא תוספים ל-Chrome: הרחבת ה-API לתמיכה בניווט מיידי מפורטים שיקולים נוספים שיוצרי תוספים צריכים לקחת בחשבון לגבי דפים שעברו טרום-עיבוד.

משוב

צוות Chrome מפתח באופן פעיל את התכונה 'טרום-עיבוד', ויש תוכניות רבות להרחבת היקף התכונות שזמינות בגרסה 108 של Chrome. נשמח לקבל משוב על מאגר GitHub או על השימוש בכלי למעקב אחר בעיות. אנחנו מצפים לשמוע על מחקרי מקרה של ה-API החדש והמעניין הזה ולשתף אותם.

קישורים רלוונטיים

• ‫Speculation Rules Codelab
• ניפוי באגים בכללי ספקולציות
• חדש: NoState Prefetch
• מפרט של Speculation Rules API
• מאגר GitHub של ניחוש ניווט
• תוספים ל-Chrome: הרחבת ה-API לתמיכה בניווט מיידי

תודות

תמונה ממוזערת מאת Marc-Olivier Jodoin ב-Unsplash