שיפור הביצועים של טעינת הדף הבא

תכונות באינטרנט: כללי ספקולציות

אחת הדרכים הכי יעילות לשפר את ביצועי טעינת הדף למשתמשים שגולשים באתר היא להתחיל לטעון את הדף הבא שהם עומדים לבקר בו לפני שהם מבקרים בו. אפשר לעשות את זה באמצעות טכניקה שנקראת "טעינה מראש" בעזרת Speculation Rules API.

איך זה עובד

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

הכללים יכולים להיות רשימה של כתובות URL בתוך הקוד עם מפתח urls (שנקראת כלל רשימה), או עם מפתח where שמכיל קבוצה של סלקטורים ב-CSS ו-href שמשמשים למציאת קישורים בדף (שנקראת כלל document).

הכללים יכולים לכלול גם מאפיין eagerness אופציונלי שמציין מתי צריך לאחזר מראש או לרנדר מראש את הדף. אפשר להגדיר את המאפיין eagerness לערכים immediate,‏ eager,‏ moderate או conservative. immediate מנחש בהקדם האפשרי, בעוד שהאחרים ממתינים לאותות מהמשתמש, כמו העברת העכבר מעל הקישור לפרק זמן קצר, לפרק זמן ארוך יותר או התחלת לחיצה על הדף, בהתאמה.

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

מתי כדאי להשתמש בו

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

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

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

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

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

איך להשתמש בעמודה

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

אפשר גם להשתמש ב-tag, ברמה הגלובלית או על בסיס כלל. כשהתג הזה מוגדר, הוא נכלל בכותרת Sec-Speculation-Tags ומאפשר לזהות בצד השרת אילו השערות הועלו.

דוגמה לכלל פשוט של רשימת כתובות URL לאחזור מראש של כתובות URL מוגדרות מראש

<script type="speculationrules">
  {
    "tag": "product-page-speculations",
    "prefetch": [
      {
        "urls": ["/product/1", "/product/2", "/product/3"]
      }
    ]
  }
</script>
<script type="speculationrules">
  {
    "tag": "all-links-speculations",
    "prerender": [{
      "where": { "href_matches": "/*" }
    }]
  }
</script>
<script type="speculationrules">
  {
    "tag": "speculations-with-exclusions",
    "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>

דוגמה לקבוצת כללים מעורבת

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

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

שיטות מומלצות

  • מומלץ להשתמש בכללי ספקולציות כדי לבצע שליפה מראש ורינדור מראש של דפים שהמשתמשים צפויים לבקר בהם בהמשך.
  • מומלץ להשתמש בכללי ספקולציה באתרים סטטיים, שבהם התוכן לא צפוי להשתנות לעיתים קרובות, ושהדפים שלהם זולים יותר להפקה – במיוחד אם הם נשמרים במטמון בקצה.
  • כדאי להקפיד יותר כשמשתמשים בכללי ספקולציה בדפים דינמיים, שבהם יש סיכוי גבוה יותר שהתוכן ישתנה לעיתים קרובות, עלול להיות לא עדכני, ועלות ההפקה של הדפים גבוהה יותר.
  • מומלץ להעדיף כללי מסמכים על פני כללי רשימות, כי הם גמישים יותר, מאפשרים לשתף את אותו כלל בכמה דפים, וניתן להשתמש בהם כדי לאחזר מראש ולעבד מראש דפים שלא ידועים מראש.
  • כדאי לשקול את היתרונות והחסרונות של אחזור מראש ורינדור מראש, ולבחור את האפשרות המתאימה לתרחיש לדוגמה שלכם. רינדור מראש יקר יותר מאחזור מראש ויכול לגרום ליותר תופעות לוואי לא מכוונות באפליקציות מורכבות שמציגות מצב דינמי, אבל הוא מספק חוויית משתמש טובה יותר. אם אתם לא בטוחים, כדאי לשאול את המפתח מה הוא מעדיף.
  • מומלץ לשקול את היתרונות והחסרונות של רמות ה-eagerness השונות, ולבחור את הרמה שמתאימה לתרחיש לדוגמה שלכם. השערה נלהבת יותר מספקת חוויית משתמש טובה יותר, אבל היא משתמשת ביותר משאבים ויכולה לגרום ליותר תופעות לוואי לא מכוונות באפליקציות מורכבות שמציגות מצב דינמי. אם אתם לא בטוחים, תשאלו את המפתח מה הוא מעדיף.
  • אל תשתמשו יותר מדי בכללי הטעינה מראש, למשל כדי לטעון מראש כל קישור בדף. בדפדפנים יש מגבלות (2 השערות להשערות לא נלהבות). צריך להשתמש ב-immediate רק למספר קטן מאוד של קישורים.
  • אל תבצעו טעינה מראש של כתובות URL שסביר להניח שיגרמו לשינויים במצב, כמו /logout או /add-to-cart, והחריגו אותן באופן מפורש מכללי הטעינה מראש אם סביר להניח שהן ייכללו בכללי המסמך.
  • אל תשתמשו בכללי ספקולציה באפליקציות דף יחיד (SPA). כללי הספקולציה מיועדים לאפליקציות עם כמה דפים (MPA), שבהן הדפדפן מנווט למסמך חדש בכל ניווט. באפליקציות SPA, הדפדפן לא מנווט למסמך חדש בכל ניווט, ולכן כללי ההשערה לא יפעלו כצפוי.

תמיכה בדפדפנים ושיטות חלופיות

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