המשאב המהיר ביותר והאופטימי ביותר הוא משאב שלא נשלח. כדאי להסיר מהאפליקציה משאבים מיותרים. מומלץ לבדוק את ההנחות המשתמעות והמפורשות עם הצוות, ולחזור אליהן מדי פעם. הנה כמה דוגמאות:
- תמיד כללתם את המשאב X בדפים שלכם, אבל האם העלות של ההורדה וההצגה שלו משתלמת בהתאם לערך שהוא מספק למשתמש? האם אתם יכולים למדוד את הערך שלה ולהוכיח אותו?
- האם המשאב (במיוחד אם מדובר במשאב של צד שלישי) מספק ביצועים עקביים? האם המשאב הזה נמצא בנתיב הקריטי, או שהוא צריך להיות שם? אם המשאב נמצא בנתיב הקריטי, האם הוא יכול להיות נקודת כשל יחידה באתר? כלומר, אם המשאב לא זמין, האם הוא משפיע על הביצועים ועל חוויית המשתמש בדפים?
- האם למשאב הזה יש הסכם רמת שירות (SLA) או שהוא צריך אחד? האם המשאב הזה עומד בשיטות המומלצות לשיפור הביצועים: דחיסה, אחסון במטמון וכו'?
לעיתים קרובות מדי, דפים מכילים משאבים מיותרים, או גרוע מכך, משאבים שמפריעים לביצועים של הדף בלי לספק ערך רב למבקר או לאתר שבו הם מתארחים. הכלל הזה חל באופן שווה על משאבים ווידג'טים מאינטראקציה ישירה (First-Party) ועל משאבים ווידג'טים של צד שלישי:
- באתר א' החליטו להציג קרוסלה של תמונות בדף הבית כדי לאפשר למבקרים לראות תצוגה מקדימה של כמה תמונות בלחיצה מהירה. כל התמונות נטענות כשהדף נטען, והמשתמש עובר בין התמונות.
- שאלה: האם מדדת כמה משתמשים צופים בכמה תמונות בקרוסלה? יכול להיות שאתם צוברים עלויות גבוהות על ידי הורדת משאבים שרוב המבקרים אף פעם לא צופים בהם.
- באתר ב' החליטו להתקין ווידג'ט של צד שלישי כדי להציג תוכן קשור, לשפר את המעורבות ברשתות החברתיות או לספק שירות אחר.
- שאלה: האם עקבתם אחרי מספר המבקרים שמשתמשים בווידג'ט או אחרי הקליקים על התוכן שהווידג'ט מספק? האם ההתעניינות שהווידג'ט הזה יוצר מספיקה כדי להצדיק את העלויות הנלוות שלו? בנוסף, האם יש לך אפשרות להשתמש בשיטת טעינה כדי לוודא שהסקריפט לא נטען עד שהוא נחוץ?
כדי לקבוע אם להפסיק הורדות מיותרות, לרוב צריך לחשוב הרבה ולבצע מדידות. כדי לקבל את התוצאות הטובות ביותר, מומלץ לבדוק מדי פעם את כל הנכסים בדפים ולענות שוב על השאלות האלה לגבי כל נכס.
ההשפעה על מדדי הליבה לבדיקת חוויית המשתמש באתר
Google השיקה את היוזמה של מדדי הליבה לבדיקת חוויית המשתמש באתר כדי לספק קבוצה של מדדים שמשקפים את חוויית המשתמשים בזמן השימוש באינטרנט. יש הרבה שיטות אופטימיזציה ל-Core Web Vitals, אבל שאלה לגבי טעינת משאב מסוים בדף עשויה להאיר לכם נתיב לשיפור המדדים האלה באתר. בהמשך מפורטות כמה דוגמאות – שמקובצות לפי כל אחד מהמדדים הבסיסיים של חוויית המשתמש – שכדאי לכם לשקול. זו רשימה חלקית של דוגמאות (יש הרבה יותר דוגמאות!), אבל כדאי לקרוא אותה כדי לקבל השראה.
Largest Contentful Paint (LCP)
המדד Largest Contentful Paint (LCP) מודד את הזמן שבו נטען התוכן הגדול ביותר (לדוגמה, תמונה ראשית או כותרת). הוא נחשב למדד חשוב של תפיסת המשתמש, שמעניק למשתמש את התחושה שהאתר נטען במהירות.
באופן כללי, הורדה של פחות משאבים מובילה לכך שרוחב הפס של המשתמש יוקצה לפחות משאבים, ועשויה להוביל לשיפור במדד LCP. דוגמה קלאסית היא טעינה איטית (lazy loading), שבה תמונות מחוץ לאזור התצוגה במהלך טעינת הדף לא יורדו עד שהדפדפן יקבע שיש סיכוי גבוה יותר שהמשתמש יראה אותן. אם יש לכם גלריה גדולה של תמונות ממוזערות, למשל 50 תמונות, טעינת נתונים באיטרציות נמוכות של כל התמונות מלבד 10 התמונות הראשונות מאפשרת לדפדפן לנצל ביעילות רבה יותר את רוחב הפס הזמין לו, והתמונות הראשונות שהמשתמש יראה ייטענו מהר יותר.
עם זאת, לא מדובר רק בטעינת פחות תמונות. בדפדפן יש תוכנית פנימית לקביעת תעדוף, שמחליטה כמה רוחב פס צריך להקצות לכל משאב. עם זאת, גם עם כל המשאבים האלה – במיוחד אלה שהורדתם בעדיפות גבוהה – יש סיכוי שהם יגרמו לכך שהמשאב התלוי של רכיב LCP פוטנציאלי לא ייטען. זה נכון במיוחד בחיבור איטי לרשת. המשאב התלוי יכול להיות קובץ תמונה שמייצג את רכיב ה-LCP של הדף, אבל הוא יכול להיות גם משאב של גופן אינטרנט שהדפדפן צריך כדי להציג צומת טקסט שעשוי להיחשב כרכיב ה-LCP של הדף.
אם האתר שלכם מכיל הרבה טקסט, יכול להיות שרכיב ה-LCP של הדף הוא צומת טקסט. יש הרבה אסטרטגיות טעינה ואופטימיזציה טובות של גופנים, אבל כדאי לשקול אם גופן מערכת מספיק לצרכים של האתר שלכם, כדי שרכיבי LCP שהם צמתים של טקסט יוכלו להיטען ללא תלות במשאב של גופן אינטרנט, ולהופיע כמעט מיד אחרי שה-CSS וה-HTML מגיעים מהשרת.
Cumulative Layout Shift (CLS)
כל משאב שאתם טוענים יכול להשפיע על מידת התזוזות המצטברות בפריסת הדף (CLS), במיוחד אם ההורדה שלו לא הושלמה עד לזמן הצביעה הראשונית. כדי להימנע מ-CLS בתמונות, צריך להשתמש בשיטות כמו הגדרת מידות מפורשות. לגבי גופנים, ניהול טעינת הגופן והתאמת גופן חלופי פוטנציאלי יכולים לצמצם את השינויים במהלך תקופת ההחלפה של גופן האינטרנט. ב-JavaScript, אפשר לנהל את האופן שבו הסקריפט מנהל את ה-DOM כדי לצמצם את השינויים בפריסה למידה מקובלת.
כל משאב שתורם ל-CLS של דף דורש עבודה מסוימת כדי להבטיח שהפריסה של הדף יציבה מספיק. כשבודקים אם צריך משאב ספציפי או לא, לא רק שמקצרים את זמני הטעינה של הדפים, אלא גם מפחיתים את המאמץ הקוגניטיבי הנדרש לשמירה על יציבות הפריסה. כך לא רק חוויית המשתמש תהיה פחות מתסכלת, אלא גם חוויית הפיתוח תהיה פחות מתסכלת, כי יהיה לכם יותר זמן להשיג מטרות אחרות בפרויקטים שלכם.
מהירות התגובה לאינטראקציה באתר (INP)
המדד מהירות התגובה לאינטראקציה באתר (INP) מודד את רמת הרספונסיביות של הדף לקלט של משתמשים במהלך כל תקופת החיים שלו. ה-INP של דף יכול להיות מושפע מאוד מקטע ה-JavaScript שהוא טוען, כי קטע ה-JavaScript הוא זה שמניע את רוב האינטראקטיביות שאנשים חווים באינטרנט. באופן ספציפי, כמות משאבי הסקריפטים שהורדתם במהלך טעינת הדף יכולה להפעיל עבודה שעלולה להיות יקרה שקשורה לבדיקה והדרכה של סקריפטים. ככל שפחות JavaScript תטעינו במהלך ההפעלה, כך הדפדפן יצטרך לבצע פחות עבודה בנקודה הקריטית הזו בחוויית השימוש בדף, שבה המשתמשים עשויים לנסות ליצור איתו אינטראקציה.
יש אמנם אסטרטגיות להקטנת הגודל של משאבי JavaScript שהורדתם במהלך ההפעלה – כמו פיצול קוד וריצה של קוד ללא פונקציות לא נחוצות (tree shaking) – אבל כדאי לבדוק את החבילות שבהן אתם משתמשים בפרויקטים כדי לראות אם הן בכלל נחוצות. לדוגמה, ל-lodash יש שיטות רבות שעדיין שימושיות היום, אבל היא מגיעה עם שיטות שהדפדפן מספק מראש, כמו פונקציות ספציפיות ל-Array למיפוי, להפחתה ולסינון, ועוד רבות.
שיפור הדרגתי הוא גם גישה שימושית ל-JavaScript, כי הוא מאפשר להציג למשתמשים חוויה בסיסית (אבל עדיין פונקציונלית) שאפשר להוסיף אליה תכונות למשתמשים עם מכשירים חזקים יותר וחיבורי רשת מהירים יותר. בין שאתם פועלים לפי העיקרון של שיפור הדרגתי ובין שלא, הנקודה נשארת: כל משאב JavaScript שאפשר להימנע מהורדה שלו יכול להוביל לחוויה שמגיבה מהר יותר לאינטראקציות של המשתמשים, וזה היבט חיוני של ביצועי האתר.
סיכום
בדיקת האתר לאיתור הורדות מיותרות היא רק היבט אחד במתן חוויית משתמש מהירה, אבל היא היבט שיכול להשפיע מאוד. לסיכום:
- ניהול מלאי הנכסים שלכם ושל צדדים שלישיים בדפים שלכם.
- מודדים את הביצועים של כל נכס: הערך שלו והביצועים הטכניים שלו.
- לבדוק אם המשאבים מספקים ערך מספיק.
- הסבר על ההשפעה של הורדות מיותרות על מדדי הליבה לבדיקת חוויית המשתמש באתר ועל מדדים תומכים.
כשמבצעים אופטימיזציה של יעילות התוכן באופן הזה, לא רק שמשפרים את הביצועים הכוללים, אלא גם מוודאים שלא מבזבזים את רוחב הפס של המשתמשים, ויש גם סיכוי לשפר מדדים שמתמקדים במשתמשים ולספק חוויית משתמש טובה יותר.