המשאב המהיר ביותר שעבר אופטימיזציה הוא משאב שלא נשלח. יש להסיר מהאפליקציה משאבים לא נחוצים. מומלץ לבדוק עם הצוות את ההנחות המרומזות והמפורשות, ולחזור אליהן באופן קבוע. הנה כמה דוגמאות:
- תמיד כללתם את משאב X בדפים שלכם, אבל האם עלות ההורדה וההצגה שלו מתקזזת עם הערך שהוא נותן למשתמש? האם אתם יכולים למדוד ולהוכיח את הערך שלו?
- האם המשאב (במיוחד אם זה משאב של צד שלישי) מספק ביצועים עקביים? המשאב הזה נמצא בנתיב הקריטי או חייב להיות קיים? אם המשאב נמצא בנתיב הקריטי, האם הוא יכול להיות נקודת כשל באתר? כלומר, אם המשאב לא זמין, האם הוא משפיע על הביצועים ועל חוויית המשתמש בדפים?
- האם המשאב הזה צריך הסכם רמת שירות או שיש לו הסכם רמת שירות? האם המשאב הזה פועל לפי השיטות המומלצות לביצועים: דחיסת נתונים, שמירה במטמון וכו'?
לעיתים קרובות מדי, דפים מכילים משאבים מיותרים, או גרוע יותר, שפוגעים בביצועי הדפים בלי לספק ערך רב למבקר או לאתר שבו הם מתארחים. הדבר נכון לגבי ווידג'טים ומשאבים של צד ראשון ושל צד שלישי באופן שווה:
- באתר א' החליטו להציג קרוסלת תמונות בדף הבית כדי לאפשר למבקרים לראות תצוגה מקדימה של כמה תמונות בלחיצה מהירה. כל התמונות נטענות כשהדף נטען, והמשתמש מתקדם בין התמונות.
- שאלה: האם מדדתם כמה משתמשים צופים בכמה תמונות בקרוסלה? יכול להיות שאתם צוברים תקורה גבוהה כתוצאה מהורדת משאבים שרוב המבקרים אף פעם לא צופים בהם.
- באתר ב' החליטו להתקין ווידג'ט של צד שלישי כדי להציג תוכן קשור, לשפר את המעורבות ברשתות החברתיות או לספק שירות אחר.
- שאלה: האם עקבתם אחרי כמה מבקרים משתמשים בווידג'ט או לוחצים על התוכן שהווידג'ט מספק? האם המעורבות שהווידג'ט הזה יוצר מספיקה כדי להצדיק את התקורה שלו? בנוסף, האם ניתן להשתמש באסטרטגיית טעינה כדי להבטיח הסקריפט לא ייטען עד שהוא נחוץ?
כדי להחליט אם להסיר הורדות מיותרות, בדרך כלל נדרשת הרבה חשיבה ומדידה בקפידה. לקבלת התוצאות הטובות ביותר, כדאי לערוך מדי פעם מלאי שטחי פרסום ולבדוק את השאלות האלה לגבי כל אחד מהנכסים בדפים שלכם.
ההשפעות על מדדי הליבה לבדיקת חוויית המשתמש באתר
Google השיקה את הבסיס למדדי הליבה לבדיקת חוויית המשתמש באתר כדי לספק טווח מדדים שמשקפים את החוויה של המשתמשים באינטרנט. יש הרבה אסטרטגיות אופטימיזציה למדדי הליבה לבדיקת חוויית המשתמש באתר, אבל השאלה אם לטעון משאב מסוים בדף יכולה לעזור לכם לשפר את המדדים האלה באתר. בהמשך מפורטות כמה דוגמאות - כשהן מקובצות לפי כל מדד של ליבה לבדיקת חוויית המשתמש באתר - שחשוב להביא בחשבון. זו אינה רשימה מלאה של דוגמאות (ויש הרבה מהן!), אבל קריאתן עשויה לתת לכם חומר למחשבה.
Largest Contentful Paint (LCP)
המדד המהירות שבה נטען רכיב התוכן הכי גדול (LCP) מודד מתי נטען התוכן הגדול ביותר (למשל תמונה ראשית (Hero) או כותרת. היא נחשבת למדד תפיסתי חשוב שמעניק למשתמש את הרושם שאתר נטען במהירות.
באופן כללי, המשמעות של הורדה של פחות משאבים היא שרוחב הפס שיש למשתמש יוקצה לפחות משאבים, והדבר עשוי להוביל לשיפור ב-LCP. דוגמה קלאסית היא טעינה מדורגת, שבה לא תתבצע הורדה של תמונות שנמצאות מחוץ לאזור התצוגה בזמן טעינת הדף עד שהדפדפן יקבע שיש סיכוי גבוה יותר שהמשתמש יראה אותן. אם יש לכם גלריה גדולה של תמונות ממוזערות, למשל 50 תמונות, בטעינה הדרגתית של כולן מלבד עשרת המובילים, הדפדפן יכול לנצל בצורה יעילה יותר את רוחב הפס שזמין לו, והתמונות הראשונות שהמשתמש יראה ייטענו מהר יותר.
עם זאת, לא מדובר רק בטעינה של פחות תמונות, בהכרח. לדפדפן יש סכמה פנימית לתעדוף שקובעת כמה רוחב פס כל משאב צריך לקבל. עם זאת, גם באמצעות כל המשאבים האלה – במיוחד אלה שהורדו בעדיפות גבוהה – יש פוטנציאל לשלול מהמשאב התלוי של רכיב LCP פוטנציאלי. הדבר נכון במיוחד בחיבורי רשת איטיים. משאב תלוי זה יכול להיות קובץ תמונה שמייצג את רכיב ה-LCP של הדף, אבל הוא יכול להיות גם משאב של גופן אינטרנט שהדפדפן צריך לעבד צומת טקסט, שייקבע כרכיב ה-LCP של הדף.
אם יש הרבה טקסט באתר, יכול להיות שרכיב ה-LCP של דף מסוים הוא צומת של טקסט. יש הרבה אסטרטגיות טובות לטעינת גופנים ולאופטימיזציה, אבל רצוי לשקול אם גופן של מערכת מתאים לצרכים של האתר שלכם. כדי שרכיבי LCP שהם צומתי טקסט יוכלו להיטען ללא תלות במשאב של גופן אינטרנט, הם יופיעו כמעט מיד כשה-CSS וה-HTML מגיעים מהשרת.
Cumulative Layout Shift (CLS)
לכל משאב שטוענים יש פוטנציאל להשפיע על שינוי הפריסה המצטברת (CLS) של הדף, במיוחד אם ההורדה לא הסתיימה עד שעת העיבוד הראשונית. לגבי תמונות, אין לכלול ב-CLS פעולות כמו הגדרת מאפיינים מפורשים. במקרה של גופנים, ניהול של טעינת הגופנים ואפשרות להתאמת גופנים חלופיים יכול לצמצם את השינויים במהלך תקופת ההחלפה של גופן אינטרנט. עבור JavaScript, ייתכן שהוא מנהל את האופן שבו הסקריפט מטפל ב-DOM כך ששינויים בפריסה יצומצמו לכמות מקובלת.
כדי לוודא שפריסת הדף יציבה מספיק, צריך להשקיע הרבה מאמצים בכל משאב שתורם ל-CLS בדף. כששואלים אם אתם זקוקים למשאב מסוים או לא, אתם לא רק מזרזים את טעינת הדפים, אלא גם מפחיתים את המאמץ הקוגניטיבי שדרוש לשמירה על יציבות הפריסה. כתוצאה מכך, חוויית המשתמש לא תהיה פחות מתסכלת, אלא גם חוויה פחות מתסכלת למפתחים, מכיוון שיהיה לכם יותר זמן להשיג יעדים אחרים בפרויקטים שלכם.
אינטראקציה עד הצבע הבא (INP)
המדד Interaction to Next Paint (INP) מודד את הרספונסיביות לקלט של משתמשים לאורך כל החיים של הדף. ה-INP של דף יכול להיות מושפע במידה רבה מ-JavaScript שהוא נטען, כיוון ש-JavaScript הוא הגורם שמוביל לרוב האינטראקטיביות במהלך חוויית השימוש באינטרנט. באופן ספציפי, כמות משאבי הסקריפט שהורדתם במהלך טעינת הדף עשויה להוביל לעבודה שעלולה להיות יקרה שכרוכה בהערכה והידור של סקריפטים. ככל שטוענים פחות JavaScript במהלך ההפעלה, כך הדפדפן צריך לבצע פחות עבודה בנקודה הקריטית הזו בדף, שבה המשתמשים עשויים לנסות ליצור איתו אינטראקציה.
יש אסטרטגיות להקטנת הגודל של משאבי ה-JavaScript שאתם מורידים במהלך ההפעלה – כמו פיצול קוד ורעידת עצים – אבל כדאי לבדוק את החבילות שבהן אתם משתמשים בפרויקטים כדי לראות אם הן נחוצות בכלל. לדוגמה, ל-lodash יש הרבה שיטות שעדיין שימושיות היום, אבל נשלחות עם שיטות שהדפדפן מספק חדשות, כמו פונקציות ספציפיות ל-Array
למיפוי, הפחתה וסינון, ולהרבה אחרות.
שיפור מתקדם הוא גם גישה שימושית ל-JavaScript, כי הוא מאפשר לכם לספק חוויית שימוש בסיסית (אבל עדיין פעילה) למשתמשים שתוכלו להוסיף לה למשתמשים עם מכשירים חזקים יותר וחיבורי רשת מהירים יותר. גם אם אתם פועלים לפי העיקרון של שיפור הדרגתי וגם אם לא, הנקודה נשארה: כל משאב JavaScript שניתן להימנע מהורדה עשוי להוביל לחוויה שמגיבה מהר יותר לאינטראקציות של משתמשים, שהיא היבט חיוני של ביצועי האינטרנט.
סיכום
בדיקת האתר לאיתור הורדות מיותרות היא רק אחד מההיבט אחד לגבי מתן חוויית משתמש מהירה, אבל יש לכך פוטנציאל להשפעה גדולה. לסיכום:
- יצירת מלאי שטחי פרסום של הנכסים שלך ושל נכסי צד שלישי בדפים שלך.
- מודדים את הביצועים של כל נכס: הערך והביצועים הטכניים שלו.
- בודקים אם המשאבים מניבים ערך מספיק.
- להבין את ההשפעה של הורדות מיותרות על מדדי הליבה לבדיקת חוויית המשתמש באתר ועל מדדים תומכים.
על ידי אופטימיזציה של יעילות התוכן באופן הזה, אתם לא רק משפרים את הביצועים הכוללים, אתם גם מקפידים לא לבזבז את רוחב הפס של המשתמשים, אלא גם יכולים לשפר את המדדים שמתמקדים במשתמש ולספק חוויית משתמש טובה יותר.