החלה של טעינה מיידית עם תבנית PRPL

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

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

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

בדיקת הדף באמצעות Lighthouse

מריצים את Lighthouse כדי לזהות הזדמנויות לשיפור בהתאם לשיטות PRPL:

  1. מקישים על 'Control+Shift+J' (או על 'Command+Option+J' ב-Mac) כדי לפתוח את כלי הפיתוח.
  2. לוחצים על הכרטיסייה Lighthouse.
  3. מסמנים את התיבות ביצועים ואפליקציה מתקדמת לאינטרנט.
  4. לוחצים על הרצת ביקורות כדי ליצור דוח.

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

טעינה מראש של משאבים קריטיים

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

Lighthouse: ביקורת של בקשות מפתח לטעינה מראש

טעינה מראש היא בקשת אחזור מצהירה שמורה לדפדפן לבקש משאב שלא ניתן לגלות אותו בדרך אחרת על ידי סורק הטעינה מראש של הדפדפן, כמו תמונה שנכס background-image מפנה אליה. כדי לטעון מראש משאבים שהתגלו מאוחר, מוסיפים תג <link> עם rel="preload" לחלק העליון של מסמך ה-HTML:

<link rel="preload" as="image" href="hero-image.jpg">

הוספה של הוראת <link rel="preload"> תפעיל בקשה למשאב הזה ותאחסן אותו במטמון. לאחר מכן הדפדפן יוכל לאחזר את המידע בעת הצורך.

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

עיבוד המסלול הראשוני בהקדם האפשרי

מערכת Lighthouse מספקת אזהרה אם יש משאבים שמתעכבים בהצגת התמונה הראשונית (FP), כלומר הרגע שבו האתר מעבד פיקסלים ומציג אותם במסך:

Lighthouse: ביקורת להסרת משאבים שחוסמים את העיבוד

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

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

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

בקשות או תשובות מה-service worker

אחסון נכסים במטמון מראש

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

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

טעינה מדורגת

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

Lighthouse: יש לו ביקורת עצומה של עומסי נתונים (payloads) ברשת

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

Lighthouse: בדיקת זמן האתחול של JavaScript

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

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

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

Lighthouse: בדיקה של עיכוב טעינה של תמונות שלא מופיעות מיד במסך

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

השלבים הבאים

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

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

בקישור הבא אפשר לקרוא מידע נוסף על דפוסי PRPL.