PRPL הוא ראשי תיבות שמתאר דפוס שמשמש להאצת הטעינה של דפי אינטרנט והפיכתם לאינטראקטיביים:
- טעינה מראש של המשאבים שהתגלו מאוחר.
- מריצים את המסלול הראשוני בהקדם האפשרי.
- שמירה מראש במטמון של שאר הנכסים.
- טעינה איטית של מסלולים אחרים ונכסים לא קריטיים.
במדריך הזה תלמדו איך כל אחת מהשיטות משתלבות זו בזה, אבל עדיין אפשר להשתמש בהן בנפרד כדי להשיג תוצאות ביצועים.
ניתן לבדוק את הדף באמצעות Lighthouse
מריצים את Lighthouse כדי לזהות הזדמנויות לשיפור בהתאם לשיטות PRPL:
- מקישים על 'Control+Shift+J' (או על 'Command+Option+J' ב-Mac) כדי לפתוח את כלי הפיתוח.
- לוחצים על הכרטיסייה Lighthouse.
- מסמנים את התיבות ביצועים ואפליקציה מתקדמת לאינטרנט.
- לוחצים על הרצת ביקורות כדי ליצור דוח.
מידע נוסף זמין במאמר זיהוי הזדמנויות לשיפור הביצועים באמצעות Lighthouse.
טעינה מוקדמת של משאבים קריטיים
אם ניתוח של משאב מסוים ואחזור שלו מתבצעים באיחור, מערכת Lighthouse מציגה את הביקורת הכושלת הבאה:
טעינה מראש היא בקשת אחזור מצהירה שמורה לדפדפן לבקש משאב שלא ניתן לגלות אותו בדרך אחרת על ידי סורק הטעינה מראש של הדפדפן, כמו תמונה שנכס background-image מפנה אליה. כדי לטעון מראש משאבים שהתגלו מאוחר, מוסיפים תג <link> עם rel="preload" לחלק העליון של מסמך ה-HTML:
<link rel="preload" as="image" href="hero-image.jpg">
הוספת הוראה <link rel="preload"> תגרום ליצירת בקשה למשאב הזה ולאחסון שלו במטמון. לאחר מכן הדפדפן יוכל לאחזר אותו לפי הצורך.
למידע נוסף על טעינת משאבים קריטיים מראש, קראו את המדריך טעינה מראש של נכסים קריטיים.
עיבוד המסלול הראשוני בהקדם האפשרי
ב-Lighthouse מוצגת אזהרה אם יש משאבים שמעכבים את המהירות שבה נטען רכיב ראשון, ברגע שבו האתר מעבד פיקסלים למסך:
כדי לשפר את מהירות התגובה הראשונה, ב-Lighthouse מומלץ להטמיע קוד JavaScript קריטי ולדחות את השאר באמצעות async, וכן להטמיע CSS קריטי שבו נעשה שימוש בחלק העליון והקבוע. כך אפשר לשפר את הביצועים על ידי ביטול נסיעות הלוך ושוב לשרת כדי לאחזר נכסים שמונעים את הטעינה.
עם זאת, קשה יותר לתחזק קוד בתוך שורת טקסט מבחינת פיתוח, והדפדפן לא יכול לשמור אותו בנפרד במטמון.
גישה נוספת לשיפור הצגת התוכן הראשון היא רינדור בצד השרת של ה-HTML הראשוני של הדף. כך התוכן מוצג למשתמש באופן מיידי בזמן שהסקריפטים עדיין נשלפים, מנותחים ומבוצעים. עם זאת, הפעולה הזו עלולה להגדיל באופן משמעותי את עומס העבודה של קובץ ה-HTML, וכתוצאה מכך להשפיע לרעה על זמן הטעינה עד לאינטראקטיביות, כלומר הזמן שחולף עד שהאפליקציה הופכת לאינטראקטיבית ויכולה להגיב להזנת נתונים על ידי משתמשים.
אין פתרון אחד נכון כדי לקצר את זמן ה-First Paint באפליקציה, ורק אם היתרונות של שילוב סגנונות ורינדור בצד השרת עולים על החסרונות שלהם באפליקציה, כדאי לכם להשתמש בהם. אפשר להיעזר במקורות המידע הבאים כדי לקבל מידע נוסף על שני המושגים האלה.
נכסים דיגיטליים שנשמרו מראש במטמון
על ידי שימוש כשרת Proxy, עובדי שירות יכולים לאחזר נכסים ישירות מהמטמון במקום מהשרת בביקורים חוזרים. כך המשתמשים יכולים להשתמש באפליקציה גם כשהם אופליין, וגם זמני הטעינה של הדפים קצרים יותר בביקור חוזר.
כדאי להשתמש בספרייה של צד שלישי כדי לפשט את תהליך היצירה של עובד שירות, אלא אם יש לכם דרישות מורכבות יותר לשמירת נתונים במטמון ממה שספרייה יכולה לספק. לדוגמה, Workbox מספק אוסף כלים שמאפשרים ליצור ולתחזק שירות עובד (service worker) כדי לשמור נכסים במטמון. למידע נוסף על קובצי שירות (service worker) ועל מהימנות אופליין, תוכלו לעיין במדריך בנושא קובצי שירות במסלול הלמידה בנושא מהימנות.
טעינה מדורגת
אם שולחים יותר מדי נתונים ברשת, מערכת Lighthouse מציגה ביקורת שנכשלה.
הנתונים האלה כוללים את כל סוגי הנכסים, אבל עומסי עבודה גדולים של JavaScript יקרים במיוחד בגלל הזמן שנדרש לדפדפן כדי לנתח ולעבד אותם. ב-Lighthouse מוצגות גם אזהרה על כך במקרים רלוונטיים.
כדי לשלוח עומס נתונים קטן יותר של JavaScript שמכיל רק את הקוד הנדרש כשמשתמש טוען את האפליקציה בפעם הראשונה, צריך לפצל את החבילה כולה ולטעון באופן איטי קטעים על פי דרישה.
אחרי שמצליחים לפצל את החבילה, כדאי לטעון מראש את הקטעים החשובים יותר (ראו המדריך טעינה מראש של נכסים קריטיים). הטעינה מראש מבטיחה שהדפדפן יאחזר ויוריד יותר משאבים חשובים.
מלבד פיצול וטעינה של מקטעי JavaScript שונים על פי דרישה, Lighthouse ניתן גם לבדוק טעינה מדורגת של תמונות לא קריטיות.
אם אתם טוענים הרבה תמונות בדף האינטרנט, כדאי לדחות את הטעינה של כל התמונות שמתחת לקו החזית או מחוץ לשטח התצוגה של המכשיר כשהדף נטען (ראו שימוש ב-lazysizes כדי לטעון תמונות באיטרציות).
השלבים הבאים
עכשיו, אחרי שהבנתם חלק מהמושגים הבסיסיים שמאחורי התבנית PRPL, תוכלו להמשיך למדריך הבא בקטע הזה כדי לקבל מידע נוסף. חשוב לזכור שלא צריך ליישם את כל השיטות יחד. כל אחד מהמאמצים הבאים יוביל לשיפורים משמעותיים בביצועים.
- טעינה מוקדמת של משאבים קריטיים.
- מריצים את המסלול הראשוני בהקדם האפשרי.
- שמירה מראש במטמון של שאר הנכסים.
- טעינה איטית של מסלולים אחרים ונכסים לא קריטיים.
מידע נוסף על דפוסי PRPL