ביטול הורדות מיותרות

איליה גריגוריק

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

• תמיד כללתם את המשאב X בדפים שלכם, אבל האם עלות ההורדה וההצגה שלו מתקזזת עם הערך שהוא מספק למשתמש? האם אפשר למדוד ולהוכיח את הערך שלו?
• האם המשאב (במיוחד אם זה משאב של צד שלישי) מניב ביצועים עקביים? האם המשאב הזה נמצא בנתיב הקריטי או שהוא צריך להיות קיים? אם המשאב נמצא בנתיב הקריטי, האם הוא מהווה נקודת כשל באתר? כלומר, אם המשאב לא זמין, האם הוא משפיע על הביצועים ועל חוויית המשתמש בדפים?
• האם המשאב הזה צריך הסכם רמת שירות או שיש לו הסכם רמת שירות? האם המשאב הזה פועל בהתאם לשיטות המומלצות לשיפור הביצועים: דחיסה, שמירה במטמון וכו'?

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

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

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

ההשפעות על מדדי הליבה לבדיקת חוויית המשתמש באתר

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

Largest Contentful Paint (LCP)

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

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

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

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

Cumulative Layout Shift (CLS)

כל משאב שנטען עשוי להשפיע על Cumulative Layout Shift (CLS) של הדף, במיוחד אם ההורדה לא הסתיימה עד למועד הצביעה הראשונית. לגבי תמונות, יש להימנע מציון CLS שכולל שיטות כמו הגדרת מאפיינים מפורשים. לגבי גופנים, ניהול של טעינת גופנים והתאמת גופנים פוטנציאלית יכול לצמצם את השינויים במהלך תקופת ההחלפה של גופן אינטרנט. ב-JavaScript, יכול להיות שהוא מנהל את האופן שבו הסקריפט מבצע שינויים ב-DOM כך ששינויי הפריסה יצטמצמו לכמות סבירה.

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

מאינטראקציה ועד הצבע הבא (INP) והשהיית קלט ראשון (FID)

Interaction to Next Paint (INP) ועיכוב לאחר קלט ראשון (FID) הם מדדים שמודדים את הרספונסיביות לקלט של המשתמשים. מדד INP מתוכנן להחליף את FID בתור מדד ליבה לבדיקת חוויית המשתמש באתר במרץ 2024, אבל אסטרטגיות אופטימיזציה של FID בדרך כלל חלות גם על INP. בנוסף, בדרך כלל קשה יותר לבצע אופטימיזציה של INP מאשר FID, מכיוון שהוא עוקב אחר זמן האחזור המלא של האינטראקציה עבור כל האינטראקציות בדף, לא רק את ההשהיה בקלט של האינטראקציה הראשונה כפי שמודדים FID.

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

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

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

סיכום

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

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

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