אוסף של השיטות המומלצות שחברי צוות המפתחים ב-Chrome קבעו כדרכים היעילות ביותר לשפר את הביצועים של מדדי הליבה לבדיקת חוויית המשתמש באתר בשנת 2023.
במהלך השנים הפנינו ב-Google הרבה המלצות למפתחי אתרים לשיפור הביצועים.
כל אחת מההמלצות האלה, בנפרד, עשויה לשפר את הביצועים של אתרים רבים, אבל מגוון ההמלצות המלא הוא בהחלט מסובך, ולמעשה, אין דרך שבה אדם אחד או אתר יוכלו לעקוב אחר כולן.
אם ביצועי האינטרנט הם לא העבודה שלכם, זה כנראה לא מובן מאליו להמלצות שצפויות להשפיע באופן החיובי הגדול ביותר על האתר. לדוגמה, אולי קראתם שהטמעה של CSS קריטי יכולה לשפר את ביצועי הטעינה, ויכול להיות ששמעתם גם שחשוב לבצע אופטימיזציה של התמונות. אבל אם אין לכם זמן לעבוד על שני הנושאים האלה, איך תחליטו באיזה מהם לבחור?
בצוות Chrome, השקענו את השנה האחרונה בניסיון לענות על השאלה הזו: מהן ההמלצות החשובות ביותר שאנחנו יכולים לתת למפתחים, שיעזרו להם לשפר את הביצועים עבור המשתמשים?
כדי לענות בצורה נכונה על השאלה הזו, עלינו להביא בחשבון לא רק את החוזק הטכני של כל המלצה נתונה, אלא גם גורמים אנושיים וארגוניים שמשפיעים על הסבירות שמפתחים יוכלו בפועל לאמץ את ההמלצות האלה. במילים אחרות, להמלצות מסוימות יכולה להיות השפעה עצומה על תיאוריה, אבל למעשה רק למעט מאוד אתרים יהיה את הזמן או המשאבים הדרושים ליישם אותן. באופן דומה, חלק מההמלצות הן קריטיות, אך רוב האתרים כבר פועלים בהתאם לשיטות האלה.
בקצרה, רצינו שרשימת ההמלצות המובילות לשיפור הביצועים באינטרנט תתמקד ב:
- להמלצות שלדעתנו תהיה ההשפעה הגדולה ביותר בעולם האמיתי
- המלצות רלוונטיות ורלוונטיות לרוב האתרים
- המלצות מציאותיות לרוב המפתחים
במהלך השנה האחרונה הקדשנו זמן רב לבדיקת המבחר המלא של ההמלצות לשיפור הביצועים שאנחנו נותנים, והערכה של כל אחת מהן (איכותית וכמותית) לפי שלושת הקריטריונים שלמעלה.
בפוסט הזה מפורטות ההמלצות המובילות שלנו לשיפור הביצועים של כל אחד מהמדדים של מדדי הליבה לבדיקת חוויית המשתמש באתר. אם אין לכם ניסיון בעבודה באינטרנט, או אם אתם מנסים להחליט מה יספק לכם את התמורה הגדולה ביותר להוצאה שלכם, אנחנו סבורים שהמלצות אלה הן המקום הטוב ביותר להתחיל.
Largest Contentful Paint (LCP)
קבוצת ההמלצות הראשונה שלנו היא עבור המאפיין LCP (המהירות שבה נטען רכיב התוכן הכי גדול), שהוא מדד של ביצועי הטעינה. מתוך שלושת המדדים של מדדי ליבה לבדיקת חוויית המשתמש באתר, מדד ה-LCP הוא המדד שהכי מתקשים לראות אתרים. רק כחצי מכל האתרים באינטרנט עומדים בסף המומלץ – אז נתחיל מהדוח.
מוודאים שמשאב ה-LCP ניתן לגילוי במקור ה-HTML
על פי אלמנט האינטרנט לשנת 2022 של ארכיון HTTP, ב-72% מהדפים לנייד יש תמונה כרכיב LCP. המשמעות היא שברוב האתרים כדי לבצע אופטימיזציה של ה-LCP, צריך לוודא שהתמונות האלה יכולות להיטען במהירות.
מה שלא יהיה ברור למפתחים רבים הוא שהזמן שלוקח לטעון תמונה הוא רק חלק אחד מהאתגר. חלק קריטי נוסף הוא הזמן לפני תחילת הטעינה של תמונה. לפי נתוני ארכיון HTTP, זה בעצם המקום שבו אתרים רבים נופלים.
למעשה, מבין הדפים שבהם אלמנט ה-LCP היה תמונה, ל-39% מהתמונות האלה היו כתובות URL של המקור שלא לא ניתן היה לגלות מהמקור של מסמך ה-HTML. במילים אחרות, כתובות ה-URL האלה לא נמצאו במאפייני HTML רגילים (כמו <img src="..."> או <link rel="preload" href="...">), מה שהיה מאפשר לדפדפן לגלות אותן במהירות ולהתחיל לטעון אותן מיד.
אם דף צריך להמתין עד שקובצי CSS או JavaScript יעברו הורדה מלאה, ניתוח ועיבוד של התמונה לפני שאפשר אפילו להתחיל להיטען, ייתכן שכבר מאוחר מדי.
ככלל, אם רכיב ה-LCP הוא תמונה, כתובת ה-URL של התמונה צריכה תמיד להיות גלויה ממקור ה-HTML. הנה כמה טיפים שמאפשרים זאת:
טוענים את התמונה באמצעות אלמנט
<img>עם המאפייןsrcאוsrcset. אין להשתמש במאפיינים לא סטנדרטיים כמוdata-srcשעיבודם ב-JavaScript צריך להתבצע, כי הנתונים האלה תמיד יהיו איטיים יותר. 9% מהדפים מסתירים את תמונת ה-LCP מאחוריdata-src.להעדיף עיבוד בצד השרת (SSR) על פני עיבוד בצד הלקוח (CSR) כי SSR מרמז שהסימון המלא של הדף (כולל התמונה) נמצא במקור ה-HTML. פתרונות CSR מחייבים הרצת JavaScript לפני שניתן לאתר את התמונה.
אם צריך להפנות לתמונה שלך מקובץ CSS או JS חיצוני, עדיין אפשר לכלול אותה במקור ה-HTML באמצעות תג
<link rel="preload">. חשוב לזכור שסורק הטעינה מראש של הדפדפן לא יכול למצוא תמונות שמפנות לסגנונות מוטבעים. לכן, גם אם הן נמצאות במקור ה-HTML, יכול להיות שהן ייחסמו בזמן הטעינה של משאבים אחרים, כך שטעינה מראש יכולה לעזור במקרים כאלה.
כדי לעזור לכם להבין אם יש בעיות ביכולת הגילוי בתמונת ה-LCP, מערכת Lighthouse תפרסם ביקורת חדשה בגרסה 10.0 (הצפויה בינואר 2023).
הקפדה על כך שניתן למצוא את משאב ה-LCP ממקור ה-HTML יכולה להוביל לשיפורים שניתנים למדידה, וגם הזדמנויות נוספות לתעדף את המשאב – ההמלצה הבאה שלנו.
מוודאים שמשאב ה-LCP מקבל עדיפות
כדי לוודא שניתן יהיה לגלות את משאב ה-LCP ממקור ה-HTML, היא צריכה להיות פעולה קריטית ראשונה כדי להבטיח שמשאב ה-LCP יוכל להיטען בשלב מוקדם. עם זאת, עוד שלב חשוב הוא להבטיח שהטעינה של המשאב הזה תהיה מתועדפת ולא תופיע בתור אחרי מספר משאבים אחרים ופחות חשובים.
לדוגמה, גם אם תמונת ה-LCP קיימת במקור ה-HTML באמצעות תג <img> רגיל, אם הדף כולל תריסר תגי <script> ב-<head> של המסמך לפני תג <img> הזה, יכול להיות שיעבור קצת זמן עד שמשאב התמונה יתחיל להיטען.
הדרך הקלה ביותר לפתור את הבעיה הזו היא לרמוז לדפדפן לגבי המשאבים בעלי העדיפות הגבוהה ביותר. לשם כך, מגדירים את המאפיין fetchpriority="high" החדש בתג <img> או <link> שטוען את תמונת ה-LCP. פעולה זו מורה לדפדפן לטעון אותו מוקדם יותר, במקום להמתין להשלמת הסקריפטים.
לפי Almanac אינטרנט, רק 0.03% מהדפים הכשירים מנצלים את ה-API החדש, ומשמעות הדבר היא שלרוב האתרים באינטרנט יש הזדמנויות רבות לשפר את ה-LCP תוך עבודה מועטה. המאפיין fetchpriority נתמך בשלב זה רק בדפדפנים המבוססים על Chromium, אך ה-API הזה הוא שיפור הדרגתי שדפדפנים אחרים פשוט מתעלמים ממנו, ולכן אנחנו ממליצים מאוד למפתחים להשתמש בו עכשיו.
בדפדפנים שאינם Chromium, הדרך היחידה לוודא שמשאב ה-LCP יקבל עדיפות על פני משאבים אחרים, היא להפנות אליו בשלב מוקדם יותר במסמך. אם נשתמש שוב בדוגמה של אתר עם הרבה תגי <script> ב-<head> של המסמך, אם רצית לוודא שמשאב ה-LCP מקבל עדיפות על פני משאבי הסקריפט האלה, אפשר להוסיף תג <link rel="preload"> לפני כל אחד מהסקריפטים האלה. לחלופין, ניתן להעביר את הסקריפטים האלה מתחת ל<img> בהמשך ה-<body>. זה אמנם עובד, אבל הוא פחות ארגונומי מהשימוש ב-fetchpriority, כך שאנחנו מקווים שתמיכה בדפדפנים אחרים תהיה זמינה בקרוב.
היבט קריטי נוסף של תעדוף משאב ה-LCP הוא לוודא שלא עושים משהו שגורם לעדיפות של משאב ה-LCP, כמו הוספת המאפיין loading="lazy". כיום, ב-10% מהדפים מוגדר הערך loading="lazy" כתמונת LCP. היזהרו מפתרונות לאופטימיזציה של תמונות, שמחילים התנהגות של טעינה עצלה על כל התמונות באופן חסר הבחנה. אם הן מאפשרות לעקוף את ההתנהגות הזו, יש להקפיד להשתמש בה בתמונת ה-LCP. אם אינכם בטוחים איזו תמונה תהיה ה-LCP, נסו להשתמש בהיוריסטיקה כדי לבחור מועמד סביר.
דחיית משאבים לא קריטיים היא דרך נוספת לשפר ביעילות את העדיפות היחסית של משאב ה-LCP. לדוגמה, אפשר לדחות בצורה בטוחה סקריפטים שלא מפעילים את ממשק המשתמש (כמו סקריפטים של Analytics או ווידג'טים של רשתות חברתיות) עד שהאירוע load יופעל. כך ניתן להבטיח שהם לא יתחרו במשאבים קריטיים אחרים (כמו משאב LCP) על רוחב הפס ברשת.
לסיכום, כדאי לפעול לפי השיטות המומלצות הבאות כדי להבטיח שמשאב ה-LCP נטען מוקדם ובעדיפות גבוהה:
- מוסיפים את
fetchpriority="high"לתג<img>של תמונת ה-LCP. אם משאב ה-LCP נטען באמצעות תג<link rel="preload">, אל דאגה, כי אפשר גם להגדיר אתfetchpriority="high"על ידיו! - אף פעם לא להגדיר את
loading="lazy"בתג<img>של תמונת ה-LCP. פעולה זו תקטין את העדיפות של התמונה ותעכב את הטעינה שלה. - מומלץ לעכב משאבים לא קריטיים כשאפשר. ניתן להעביר אותם לסוף המסמך באמצעות טעינה מדורגת מקומית עבור תמונות או מסגרות iframe, או לטעון אותם באופן אסינכרוני באמצעות JavaScript.
השתמש ב-CDFB כדי לבצע אופטימיזציה של מסמכים ומשאבים
שתי ההמלצות הקודמות התמקדו בשאלה אם משאב ה-LCP יתגלה בשלב מוקדם ויתעדף, כדי שהוא יוכל להתחיל להיטען מיד. החלק האחרון בפתרון החידה הוא לוודא שגם התגובה הראשונית למסמך תגיע מהר ככל האפשר.
הדפדפן לא יכול להתחיל לטעון משאבי משנה כלשהם לפני שהוא מקבל את הבייט הראשון של התגובה הראשונית של מסמך ה-HTML, וככל שזה יקרה, כך כל השאר יתחיל מהר יותר.
זמן זה נקרא Time to First Byte (TTFB), והדרך הטובה ביותר להפחית את TTFB היא:
- מומלץ להציג את התוכן שלכם קרוב ככל האפשר מבחינה גיאוגרפית למשתמשים
- שומרים את התוכן שהתבקש לאחרונה כדי שניתן יהיה להציג אותו שוב במהירות.
הדרך הטובה ביותר לעשות את שני הדברים האלה היא להשתמש ב-CDN. רשתות CDN מחלקות את המשאבים שלך לשרתי קצה, שמפוזרים ברחבי העולם, וכך מגבילה את המרחק שהמשאבים האלה צריכים לעבור דרך הרשת למשתמשים שלך. ל-CDN יש בדרך כלל גם בקרות שמירה במטמון ברמת פירוט גבוהה, שניתן להתאים אישית ולבצע אופטימיזציה בהתאם לצורכי האתר שלכם.
מפתחים רבים מכירים את השימוש ב-CDN כדי לארח נכסים סטטיים, אבל רשתות CDN יכולות להציג ולשמור במטמון גם מסמכי HTML, אפילו כאלה שנוצרים באופן דינמי.
לפי Almanac האינטרנט, רק 29% מהבקשות למסמכי HTML הוגשו מ-CDN, כך שלאתרים יש הזדמנות משמעותית לטעון לחיסכון נוסף.
כמה טיפים להגדרת CDNs:
- כדאי לשקול להאריך את משך הזמן לשמירת תוכן (לדוגמה, האם זה באמת קריטי שהתוכן יהיה תמיד עדכני? או שזה יכול להיות כמה דקות לא פעיל?).
- כדאי אולי אפילו לשמור תוכן במטמון ללא הגבלת זמן, ולאחר מכן למחוק באופן סופי את המטמון אם וכאשר תבצעו עדכון.
- בדקו אם אפשר להעביר לוגיקה דינמית שרצה כרגע בשרת המקור אל הקצה (תכונה של רוב רשתות ה-CDN המודרניות).
באופן כללי, בכל פעם שאפשר להציג תוכן ישירות מהקצה העליון (כדי להימנע מנסיעה לשרת המקורי), התוצאה היא ביצועים מנצחים. גם במקרים שבהם צריך לבצע את כל המסלול עד חזרה לשרת המקור, בדרך כלל מתבצעת אופטימיזציה של רשתות CDN כדי לעשות זאת מהר יותר, כך שזה מנצח בכל מקרה.
Cumulative Layout Shift (CLS)
הקבוצה הבאה של המלצות היא Cumulative Layout Shift (CLS), שהיא מדד ליציבות החזותית בדפי אינטרנט. מדד CLS השתפר באופן משמעותי באינטרנט מאז 2020, אבל כרבע מהאתרים עדיין לא עומדים בסף המומלץ, כך שיש עדיין הזדמנות גדולה לאתרים רבים לשפר את חוויית המשתמש.
הגדרת גדלים של תוכן בוטה בכל תוכן שנטען מהדף
שינויי פריסה בדרך כלל מתרחשים כשתוכן קיים עובר אחרי שהטעינה של תוכן אחר מסתיימת. לכן, הדרך העיקרית לצמצם את התופעה הזו היא לשריין מראש את כל השטחים הנדרשים.
הדרך הישירה ביותר לתקן שינויים בפריסה שנגרמו בגלל תמונות לא בגודל מותאם היא להגדיר באופן מפורש את מאפייני width ו-height (או מאפייני CSS מקבילים). עם זאת, לפי ארכיון HTTP, ב-72% מהדפים יש לפחות תמונה אחת לא בגודל. בלי גודל מפורש, דפדפנים יגדירו בהתחלה גובה ברירת מחדל של 0px, ועשוי לגרום לשינוי משמעותי בפריסה כשהמערכת תיטען בסופו של דבר והמידות יתגלו. הן מייצגות הזדמנות אדירה לאינטרנט הקולקטיבי, וההזדמנות הזו דורשת הרבה פחות מאמץ מאשר חלק מההמלצות האחרות שמתוארות במאמר הזה.
חשוב גם לזכור שתמונות הן לא הגורמים היחידים שמוסיפים ל-CLS. הסיבה לשינויים בפריסה יכולה להיות תוכן אחר שבדרך כלל נטען לאחר עיבוד ראשוני של הדף, כולל מודעות של צד שלישי או סרטונים מוטמעים. בעזרת הנכס aspect-ratio אפשר להילחם בתופעה הזו. זוהי תכונת CSS חדשה יחסית שמאפשרת למפתחים לספק באופן מפורש יחס גובה-רוחב לתמונות, כמו גם לרכיבים שאינם תמונות. כך תהיה לך אפשרות להגדיר width דינמי (לדוגמה, על סמך גודל המסך) ולהגדיר לדפדפן באופן אוטומטי את הגובה המתאים, באופן דומה לאופן הפעולה של תמונות עם מידות.
לפעמים לא ניתן לדעת מה הגודל המדויק של תוכן דינמי, מאחר שהוא דינמי, מטבעו. עם זאת, גם אם לא ידוע לך מה הגודל המדויק, עדיין אפשר לבצע פעולות להפחתת החומרה של התנודות בפריסה. הגדרת min-height הגיונית כמעט תמיד טובה יותר מאשר מתן אפשרות לדפדפן להשתמש בגובה ברירת המחדל של 0px עבור רכיב ריק. השימוש ב-min-height הוא בדרך כלל פתרון קל, כי הוא עדיין מאפשר למאגר להגיע לגובה הסופי של התוכן במקרה הצורך. זה פשוט הפחית את כמות הצמיחה הזו מכמות מלאה לרמה שעשויה להיות נסבלת יותר.
מוודאים שהדפים עומדים בדרישות לשמירה במטמון לדף הקודם/הבא
דפדפנים משתמשים במנגנון ניווט שנקרא מטמון לדף הקודם/הבא (או בקיצור bfcache) כדי לטעון דף באופן מיידי מהיסטוריית הדפדפן ישירות מתמונת מצב של הזיכרון.
המטמון לדף הקודם/הבא הוא אופטימיזציה משמעותית של ביצועים ברמת הדפדפן, והוא מבטל לחלוטין את השינויים בפריסה במהלך טעינת הדף. מצב כזה באתרים רבים הוא המקור לרוב נתוני ה-CLS. ההכנסה של bfcache גרמה לשיפור הגדול ביותר ב-CLS שראיתם בשנת 2022.
למרות זאת, מספר משמעותי של אתרים לא עומדים בדרישות לשימוש במטמון לדף הקודם/הבא, ולכן אתם לא יכולים לפספס את הזכייה הזו בביצועי אתרים חינמיים במספר גדול של ניווטים. מומלץ לוודא שהדפים שלך כשירים, אלא אם הדף טוען מידע רגיש שאינך רוצה לשחזר מהזיכרון.
בעלי אתרים צריכים לבדוק שהדפים שלהם עומדים בדרישות לשימוש במטמון לדף הקודם/הבא ופועלים לגבי כל סיבה לכך. ל-Chrome כבר יש כלי לבדיקת bfcache ב-DevTools והשנה אנחנו מתכננים לשפר את הכלים כאן בעזרת ביקורת חדשה של Lighthouse שמבצעת בדיקה דומה וממשק API שימדוד את השימוש הזה בשטח.
כללנו את bfcache בקטע ה-CLS, אבל מכיוון שהבחנו בשיפורים הגדולים ביותר עד כה, אבל המטמון בדרך כלל גם ישפר גם מדדים אחרים של מדדי ליבה לבדיקת חוויית המשתמש באתר. זהו אחד ממספר הניווטים המיידיים הזמינים לשיפור משמעותי של הניווטים בדף.
יש להימנע מאנימציות או מעברים שמשתמשים במאפייני CSS שגורמים לפריסה
מקור נפוץ נוסף לשינויים בפריסה הוא כשאלמנטים מונפשים. לדוגמה, באנרים של קובצי cookie או מודעות באנר אחרות של התראות שמוצגות מתחת לחלק העליון או התחתון תורמות בדרך כלל ל-CLS. הדבר בעייתי במיוחד כאשר מודעות הבאנר האלה מעבירות תוכן אחר הצידה, אבל גם אם הן לא לעשות זאת, האנימציה שלהן עדיין עלולה להשפיע על ה-CLS.
אמנם אי אפשר לקשר באופן חד-משמעי בין נתוני ארכיון HTTP בין אנימציות לשינויי פריסה, אבל הנתונים מראים שדפים עם אנימציה של כל מאפיין CSS שיכול להשפיע על הפריסה, יש סיכוי נמוך ב-15% לערך CLS 'טוב' מאשר לדפים באופן כללי. נכסים מסוימים משויכים לנתוני CLS גרועים יותר מאחרים. לדוגמה, בדפים עם אנימציה של margin או עם רוחב border יש CLS 'חלש' כמעט פי שניים מהקצב הכולל של דפים מוערכים כדפים נמוכים.
העובדה הזו לא מפתיעה, כי בכל פעם שמעבירים נכס CSS או אנימציה כל נכס CSS שגורם לפריסה, התוצאה תהיה שינויים בפריסה. אם התנודות בפריסה לא התרחשו בטווח של 500 אלפיות השנייה מאינטראקציה של המשתמש, הן ישפיעו על ה-CLS.
מה שעשוי להפתיע מפתחים מסוימים הוא שזה נכון גם במקרים שבהם המרכיב נלקח מחוץ לזרימת המסמך הרגילה. לדוגמה, רכיבים ממוקמים במיקום מוחלט שיש בהם אנימציה של top או left יגרמו לתנודות בפריסה, גם אם הם לא גורמים לדחיפה של תוכן אחר. עם זאת, אם במקום ליצור אנימציה ב-top או ב-left, תופעל אנימציה ב-transform:translateX() או ב-transform:translateY(), הדפדפן לא יעדכן את פריסת הדף ולא יגרום לשינויי פריסה.
העדפת אנימציה של מאפייני CSS שניתן לעדכן ב-thread של הרכיב הקומפוזבילי של הדפדפן היא כבר שיטה מומלצת לשיפור הביצועים, כי היא מעבירה את הנתונים ל-GPU ולמחוץ ל-thread הראשי. בנוסף לכך שזוהי שיטה מומלצת לשיפור הביצועים באופן כללי, היא יכולה גם לעזור לשפר את ה-CLS.
ככלל, אין ליצור אנימציה או להעביר מאפייני CSS כלשהם שמחייבים את הדפדפן לעדכן את פריסת הדף, אלא אם אתם עושים זאת בתגובה להקשה של משתמש או ללחיצה על מקש (אבל לא hover). וכשאפשר, כדאי להעדיף מעברים ואנימציות באמצעות מאפיין ה-CSS transform.
בביקורת של Lighthouse יש להימנע מאנימציות לא מורכבות, שתוצג אזהרה כשבדף מתבצעת אנימציה של מאפייני CSS שעשויים להיות איטיים.
First Input Delay (FID)
קבוצת ההמלצות האחרונה שלנו היא בנוגע להשהיה לאחר קלט ראשון (FID). זהו מדד של מידת התגובה של הדף לאינטראקציות של משתמשים. רוב האתרים באינטרנט משיגים כרגע דירוג גבוה ב-FID, אבל תיעדנו את החסרונות של מדד FID בעבר, ואנחנו סבורים שעדיין יש לאתרים הזדמנויות רבות לשפר את הרספונסיביות הכוללת לאינטראקציות של משתמשים.
המדד החדש שלנו, Interaction to Next Paint (INP) הוא תחליף אפשרי ל-FID, וכל ההמלצות הבאות רלוונטיות באותה מידה ל-FID ול-INP. מכיוון שאתרים ב-INP מניבים ביצועים פחות טובים ב-INP, במיוחד בניידים, אנחנו ממליצים למפתחים לשקול ברצינות את ההמלצות האלה למהירות תגובה, למרות שנתוני FID 'טובים'.
איך להימנע ממשימות ארוכות או לפצל אותן
משימות הן כל סוג של עבודה נפרדת שהדפדפן מבצע. המשימות כוללות עיבוד, פריסה, ניתוח, הידור וביצוע של סקריפטים. כשמשימות הופכות למשימות ארוכות, כלומר 50 אלפיות השנייה או יותר, הן חוסמות את ה-thread הראשי להגיב במהירות לקלט של משתמשים.
לפי אלמנאק האינטרנט, יש הרבה ראיות שרומזות על כך שמפתחים יכולים לעשות יותר כדי להימנע ממשימות ארוכות או לבטל אותן. אומנם פיצול של משימות ארוכות לא דורש הרבה מאמץ כמו המלצות אחרות במאמר הזה, אבל זה פחות מאמץ מטכניקות אחרות שלא מוצגות במאמר הזה.
כדאי תמיד לשאוף לבצע כמה שפחות עבודה ב-JavaScript, אבל ניתן לשפר את ה-thread הראשי לא מעט, על ידי פיצול משימות ארוכות לפעולות קטנות יותר. כדי לעשות זאת, לעבור ל-thread הראשי לעיתים קרובות כדי שעדכוני העיבוד ואינטראקציות אחרות של המשתמשים יתבצעו מהר יותר.
אפשרות אחרת היא להשתמש בממשקי API כמו isInputPending ו-Scheduler API. isInputPending היא פונקציה שמחזירה ערך בוליאני שמציין אם קלט משתמש נמצא בהמתנה. אם מחזירים את הערך true, אפשר לתלות את ה-thread הראשי כדי שהוא יוכל לטפל בקלט של המשתמש שבהמתנה.
ה-Scheduler API הוא גישה מתקדמת יותר, שמאפשרת לתזמן את העבודה לפי מערכת סדרי עדיפויות שמביאות בחשבון אם העבודה מתבצעת גלויה למשתמש או מבוססת על רקע.
כשמפצלים משימות ארוכות, לדפדפן יש יותר הזדמנויות להתאים לעבודה חשובה וגלויה למשתמשים, כמו התמודדות עם אינטראקציות ועדכוני רינדור.
יש להימנע מ-JavaScript מיותר
אין ספק: אתרים שולחים יותר JavaScript מאי פעם, ונראה שהמגמה לא עומדת להשתנות בזמן הקרוב. כשאתם שולחים יותר מדי JavaScript, אתם יוצרים סביבה שבה משימות מתחרות על תשומת הלב של ה-thread הראשי. זה בהחלט יכול להשפיע על הרספונסיביות של האתר, במיוחד בתקופת ההפעלה הקריטית.
עם זאת, בעיה זו אינה פתרת את הבעיה. יש כמה אפשרויות:
- אפשר להשתמש בכלי הכיסוי בכלים למפתחים ב-Chrome כדי למצוא קוד שלא נמצא בשימוש במשאבי האתר. הקטנת המשאבים שתזדקקו להם במהלך ההפעלה תחסוך לכם זמן בניתוח ובהכנה של הקוד, וכך תשפרו את חוויית המשתמש הראשונית.
- לפעמים קוד שלא נמצא בשימוש באמצעות כלי הכיסוי מסומן כ-'unused' כי הוא לא הופעל במהלך ההפעלה, אבל הוא עדיין נחוץ לפונקציונליות מסוימת בעתיד. זהו קוד שאפשר להעביר לחבילה נפרדת באמצעות פיצול קוד.
- אם אתם משתמשים במנהל תגים, חשוב לבדוק מדי פעם את התגים כדי לוודא שהם עברו אופטימיזציה, וגם אם הם עדיין בשימוש. ניתן למחוק תגים ישנים יותר עם קוד שלא נמצא בשימוש כדי להפוך את ה-JavaScript של מנהל התגים לקטן ויעיל יותר.
יש להימנע מעדכוני רינדור גדולים
JavaScript אינו הדבר היחיד שיכול להשפיע על הרספונסיביות של האתר שלך. עיבוד נתונים הוא סוג של עבודה יקרה כשלעצמה – וכשמתבצעים עדכוני רינדור גדולים, הוא עלול להפריע ליכולת של האתר להגיב לקלט של משתמשים.
לא מדובר בתהליך פשוט לביצוע אופטימיזציה של רינדור, ובדרך כלל הדבר תלוי במה שאתם מנסים להשיג. עם זאת, יש כמה דברים שאפשר לעשות כדי לוודא שעדכוני העיבוד יהיו סבירים, ושלא ייכללו במשימות ארוכות:
- הימנעו משימוש ב-
requestAnimationFrame()לעבודה שאינה חזותית.requestAnimationFrame()קריאות מטופלות בשלב הרינדור של לולאת האירוע, ואם מתבצעת עבודה רבה מדי בשלב הזה, עדכוני העיבוד עשויים להתעכב. חשוב שכל הפעולות שתבצעו ב-requestAnimationFrame()יישמרו אך ורק למשימות שכוללות עיבוד של עדכונים. - להקפיד שה-DOM יהיה קטן. יש התאמה בין גודל ה-DOM לבין העוצמה של עבודת הפריסה. כאשר כלי הרינדור חייב לעדכן את הפריסה של DOM גדול מאוד, העבודה הנדרשת לחישוב מחדש של הפריסה שלו עשויה לגדול באופן משמעותי.
- משתמשים בבלימה של CSS. גבולות ה-CSS מבוססים על המאפיין
containשל CSS, שמספק לדפדפן הוראות לביצוע עבודת הפריסה עבור מאגר התגים שבו מוגדר נכסcontain, כולל אפילו בידוד היקף הפריסה והעיבוד לרמה הבסיסית (root) ב-DOM. זה לא תמיד תהליך קל, אבל באמצעות בידוד של אזורים שמכילים פריסות מורכבות תוכלו להימנע מביצוע פעולות פריסה ועיבוד שאינן נחוצות.
סיכום
שיפור הביצועים של דפים יכול להיראות כמו משימה מרתיעה, במיוחד בהתחשב בכך שיש באינטרנט מספר גדול של הנחיות שצריך להתייחס אליהן. עם זאת, כשמתמקדים בהמלצות האלה, אפשר לגשת לבעיה עם המיקוד והמטרה, וכדאי לנסות להניע את גורמי הפגיעה במדדי הליבה לבדיקת חוויית המשתמש באתר.
ההמלצות שכאן הן בהחלט לא ממצות, אבל אנחנו מאמינים – על סמך ניתוח קפדני של מצב האינטרנט – ההמלצות האלה הן הדרכים היעילות ביותר שאתרים יכולים לשפר את הביצועים של מדדי הליבה לבדיקת חוויית המשתמש באתר בשנת 2023.
אם תרצו מעבר להמלצות המפורטות כאן, עיינו במדריכי האופטימיזציה הבאים:
שתהיה שנה חדשה, ואינטרנט מהיר יותר לכולם! אפשר לאתרים שלך לפעול במהירות עבור המשתמשים בכל הדרכים החשובות ביותר.
צילום: Devin Avery