זהו אוסף של השיטות המומלצות שחברי הצוות של Chrome DevRel סבורים שהן הדרכים היעילות ביותר לשיפור הביצועים של מדדי הליבה לבדיקת חוויית המשתמש באתר בשנת 2023.
לאורך השנים, הענקנו ב-Google המלצות רבות למפתחי אתרים בנושא שיפור הביצועים.
כל אחת מההמלצות האלה, בנפרד, עשויה לשפר את הביצועים של אתרים רבים, אבל ההמלצות המלאות הן אולי מוצדקות, ולמעשה, אין אדם או אתר שיכולים ליישם את כולן.
אלא אם אתם משתמשים בביצועי אתרים, זה כנראה לא מובן מאליו לאילו המלצות תהיה ההשפעה החיובית הגדולה ביותר על האתר שלכם. לדוגמה, ייתכן שקראתם שהטמעת CSS קריטי יכולה לשפר את ביצועי הטעינה, וייתכן ששמעתם גם שחשוב לבצע אופטימיזציה של התמונות. אבל, אם אין לכם זמן לעבוד על שני הדברים, איך תחליטו במה לבחור?
בצוות Chrome, השקענו את השנה האחרונה בניסיון לענות על השאלה הבאה: מהן ההמלצות החשובות ביותר שנוכל לתת למפתחים כדי לעזור להם לשפר את הביצועים של המשתמשים שלהם?
כדי לענות בצורה הולמת על השאלה הזו, עלינו להביא בחשבון לא רק את היתרונות הטכניים של כל המלצה, אלא גם את הגורמים האנושיים והארגוניים שמשפיעים על הסבירות שמפתחים יוכלו ליישם את ההמלצות האלה. במילים אחרות, בתיאוריה ייתכן שלהמלצות מסוימות תהיה השפעה עצומה, אבל בפועל, למעט מאוד אתרים יש את הזמן או המשאבים הדרושים כדי ליישם אותן. גם חלק מההמלצות הן קריטיות, אבל רוב האתרים כבר פועלים לפי השיטות האלה.
בקצרה, רצינו להתמקד ברשימת ההמלצות המובילות בנוגע לביצועים באינטרנט:
- המלצות שאנחנו סבורים שיהיו להן ההשפעה הגדולה ביותר בעולם האמיתי
- המלצות רלוונטיות ורלוונטיות לרוב האתרים
- המלצות ריאליסטיות לרוב המפתחים
בשנה האחרונה השקענו זמן רב בבדיקה של כל ההמלצות לשיפור הביצועים שאנחנו מגישים, ובהערכה של כל אחת מהן (גם כמותית וגם איכותית) מול שלושת הקריטריונים שלמעלה.
בפוסט הזה מפורטות ההמלצות המובילות שלנו לשיפור הביצועים של כל אחד ממדדי Core Web Vitals. אם זו הפעם הראשונה שאתם משתמשים בביצועים באינטרנט, או אם ניסיתם להחליט מה יניב את התמורה הכי גבוהה על כספכם, אנחנו חושבים שההמלצות האלה הן המקום הכי טוב להתחיל בו.
Largest Contentful Paint (LCP)
קבוצת ההמלצות הראשונה שלנו היא מדד המהירות שבה נטען רכיב התוכן הכי גדול (LCP), שהוא מדד של ביצועי הטעינה. מתוך שלושת מדדי הליבה לבדיקת חוויית המשתמש באתר, LCP הוא המדד שהכי הרבה אתרים מתקשים איתו – רק כמחצית מכל האתרים באינטרנט כיום עומדים בסף המומלץ. לכן, שנתחיל?
מוודאים שאפשר למצוא את משאב ה-LCP ממקור ה-HTML
לפי אלמנית האינטרנט לשנת 2022 של HTTP Archive, 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. הפעולה הזו מורה לדפדפן לטעון אותו מוקדם יותר, במקום להמתין עד שהסקריפטים האלה יושלמו.
לפי אלמן, רק 0.03% מהדפים הכשירים מנצלים את היתרונות של ה-API החדש הזה. המשמעות היא שלרוב האתרים באינטרנט יש הרבה הזדמנויות לשפר את ה-LCP עם מעט מאוד עבודה. המאפיין fetchpriority נתמך בשלב זה רק בדפדפנים המבוססים על Chromium, אבל ה-API הזה הוא שיפור הדרגתי שדפדפנים אחרים פשוט מתעלמים ממנו, ולכן אנחנו ממליצים מאוד למפתחים להשתמש בו עכשיו.
בדפדפנים שאינם Chromium, הדרך היחידה לוודא שמשאב ה-LCP יקבל עדיפות על פני משאבים אחרים הוא להפנות אליו מוקדם יותר במסמך. נשתמש שוב בדוגמה של אתר עם הרבה תגי <script> ב<head> של המסמך. כדי לוודא שמשאב ה-LCP יקבל עדיפות גבוהה יותר במשאבי הסקריפט האלה, אפשר להוסיף תג <link rel="preload"> לפני כל אחד מהסקריפטים האלה. לחלופין, אפשר להעביר את הסקריפטים אל מתחת ל-<img> בהמשך <body>. השיטה הזו אמנם פועלת, אבל היא פחות ארגונומית בהשוואה לשימוש ב-fetchpriority, לכן אנחנו מקווים שבקרוב נוסיף תמיכה בדפדפנים אחרים.
היבט קריטי נוסף של מתן עדיפות למשאב 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.
שימוש ב-CDN לביצוע אופטימיזציה שלTTFB מסמכים ומשאבים
שתי ההמלצות הקודמות התמקדו בכך שמשאב ה-LCP יאותר בשלב מוקדם, והתקבל עדיפות גבוהה אליו כדי שניתן יהיה להתחיל להיטען באופן מיידי. החלק האחרון בפאזל הזה הוא לוודא שהמסמך הראשוני יגיע בהקדם האפשרי.
הדפדפן לא יכול להתחיל לטעון משאבי משנה לפני שהוא מקבל את הבייט הראשון של התגובה הראשונית של מסמך ה-HTML. ככל שזה יקרה, כל השאר יתחיל מוקדם יותר.
הזמן הזה נקרא Time to First Byte (TTFB), והדרך הטובה ביותר להפחית את המצב הזה היא:
- חשוב להציג את התוכן במיקום קרוב ככל האפשר למשתמשים.
- אפשר לשמור את התוכן הזה במטמון כדי שניתן יהיה להציג שוב במהירות את התוכן שביקשת לאחרונה.
הדרך הטובה ביותר לעשות את שני הדברים האלה היא להשתמש ב-CDN. רשתות CDN מפיץות את המשאבים לשרתי קצה, שמפוזרים ברחבי העולם, וכך מגבילים את המרחק של המשאבים האלה לעבור דרך הכבלים למשתמשים שלכם. לרשתות CDN יש בדרך כלל גם אמצעי בקרה פרטניים לשמירה במטמון שניתן להתאים אישית ולבצע להם אופטימיזציה לפי צורכי האתר.
מפתחים רבים מכירים את השימוש ב-CDN לאירוח נכסים סטטיים, אבל רשתות CDN יכולות להציג ולשמור מסמכי HTML במטמון, גם כאלה שנוצרים באופן דינמי.
לפי אלמנך באינטרנט, רק 29% מהבקשות למסמכי HTML נשלחו מ-CDN, כלומר יש הזדמנות משמעותית לאתרים ליהנות מחיסכון נוסף.
לפניכם כמה טיפים להגדרת רשתות CDN:
- כדאי לשקול להאריך את משך הזמן שבו התוכן נשמר במטמון (לדוגמה, האם בפועל חשוב שהתוכן יהיה תמיד עדכני? או שאולי הערוץ לא פעיל במשך כמה דקות?).
- כדאי אולי אפילו לשמור תוכן במטמון ללא הגבלת זמן, ולאחר מכן למחוק את המטמון באופן סופי אם מבצעים עדכון.
- כדאי לבדוק אם אפשר להעביר לוגיקה דינמית שפועלת כרגע בשרת המקור לקצה (תכונה של רשתות ה-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 שלהם נמצא. ההשקה של המטמון לדף הקודם/הבא גרמה לשיפור הגדול ביותר ב-CLS שראינו בשנת 2022.
למרות זאת, מספר משמעותי של אתרים לא עומדים בדרישות לשמירה במטמון לדף הקודם/הבא, ולכן הם מחמיצים את הזכייה החינמית הזו בביצועים באינטרנט במספר משמעותי של ניווטים. אם הדף לא טוען מידע רגיש שאתם לא רוצים שישוחזר מהזיכרון, כדאי לוודא שהדפים עומדים בדרישות.
בעלי אתרים צריכים לבדוק שהדפים שלהם מתאימים לשמירה במטמון לדף הקודם/הבא ולעבוד על כל סיבה לכך. ב-Chrome כבר יש בודק של bfcache בכלי הפיתוח, והשנה אנחנו מתכננים לשפר את הכלי בכלי הזה באמצעות בדיקה חדשה של Lighthouse שמבצעת בדיקה דומה וממשק API כדי למדוד זאת בשטח.
כללנו את המטמון לדף הקודם/הבא בקטע CLS, אבל זיהינו את העלייה הגדולה ביותר כאן עד עכשיו, אבל המטמון לדף הקודם/הבא ישפר באופן כללי גם מדדים אחרים של Core Web Vitals. זהו אחד ממספר הניווטים המיידיים שזמינים לשיפור משמעותי של הניווט בדפים.
מומלץ להימנע מאנימציות או מעברים המשתמשים במאפייני CSS שיוצרים פריסה
מקור נפוץ נוסף לשינויי פריסה הוא מצב שבו רכיבים מכילים אנימציה. לדוגמה, באנרים של קובצי Cookie או באנרים אחרים של התראות שזזים למעלה או למטה הם לרוב תורמים ל-CLS. הבעיה הזו בעייתית במיוחד כשמודעות הבאנר האלה מפריעות לתוכן אחר, אבל גם אם הן לא עושות את זה, האנימציה שלהן עדיין עלולה להשפיע על CLS.
לא ניתן לקשר באופן חד-משמעי בין נתוני ארכיון HTTP לבין שינויים בפריסה, אבל הנתונים מראים שדפים שכוללים אנימציה לכל נכס CSS שיכול להשפיע על הפריסה שלהם הם בעלי סבירות נמוכה ב-15% שהדירוג שלהם יהיה 'טוב'. CLS לעומת דפים באופן כללי. נכסים מסוימים משויכים לרמת CLS נמוכה יותר בהשוואה לנכסים אחרים. למשל, לדפים מונפשים ברוחב של margin או border יש 'גרוע' שיעור ה-CLS כמעט כפול משיעור הכולל של דפים שנבדקים כדפים גרועים.
זה אולי לא מפתיע, כי כל פעם שאתם מעבירים או מוסיפים אנימציה לכל נכס CSS שגורם לפריסה, הדבר יגרום לשינויים בפריסה. אם שינויי הפריסה לא יתבצעו תוך 500 אלפיות השנייה מהאינטראקציה של המשתמש, הם ישפיעו על ה-CLS.
מה שיפתיע חלק מהמפתחים הוא שהמצב הזה נכון גם במקרים שבהם הרכיב צולם מחוץ לזרימת המסמך הרגילה. לדוגמה, רכיבים שנמצאים במיקום מוחלט ושיש בהם אנימציה ל-top או ל-left יגרמו לשינויים בפריסה, גם אם הם לא דוחפים תוכן אחר. עם זאת, אם במקום להוסיף אנימציה ל-top או ל-left מוסיפים אנימציה ל-transform:translateX() או ל-transform:translateY(), הדפדפן לא יעדכן את פריסת הדף ולכן לא יהיו שינויים בפריסה.
אנימציה של מאפייני CSS שאפשר לעדכן בשרשור הקומפוזבילי של הדפדפן היא שיטה מומלצת לביצועים, כי היא מעבירה את העבודה ל-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 בהשוואה ל-FID, במיוחד בניידים, אנחנו ממליצים למפתחים לשקול ברצינות את המלצות הרספונסיביות האלה, למרות העובדה מזהה FID.
איך להימנע ממשימות ארוכות או לפצל אותן
'משימות' הן כל עבודה נפרדת שהדפדפן עושה. המשימות כוללות עיבוד, פריסה, ניתוח, הידור וביצוע של סקריפטים. כשמשימות הופכות למשימות ארוכות – כלומר 50 אלפיות השנייה או יותר – הן חוסמות את היכולת של ה-thread הראשי להגיב במהירות לקלט של המשתמשים.
לפי אלמן האינטרנט, יש שפע של הוכחות לכך שמפתחים יכולים לעשות יותר כדי להימנע ממשימות ארוכות או לפרק אותן. חלוקת משימות ארוכות עשויה להיות מאמץ לא פשוט כמו המלצות אחרות במאמר הזה, אבל המאמץ יהיה קטן יותר מטכניקות אחרות שלא מוצעות במאמר הזה.
מומלץ תמיד להשקיע כמה שפחות בעבודה ב-JavaScript, אבל אפשר לעזור ל-thread הראשי לא מעט על ידי פיצול של משימות ארוכות למשימות קטנות יותר. תוכלו לעשות זאת על ידי מעבר ל-thread הראשי לעיתים קרובות, כדי שעדכוני הרינדור ואינטראקציות אחרות של המשתמשים יתרחשו מהר יותר.
אפשרות אחרת היא להשתמש בממשקי API כמו isInputPending ו-Scheduler API. isInputPending הוא פונקציה שמחזירה ערך בוליאני שמציין אם הקלט של המשתמש נמצא בהמתנה. אם הפונקציה מחזירה true, אפשר לעבור ל-thread הראשי כדי לטפל בקלט של המשתמשים שממתינים לאישור.
ה-Scheduler API הוא גישה מתקדמת יותר, שמאפשרת לתזמן את העבודה על סמך מערכת עדיפויות שלוקחת בחשבון אם העבודה שנעשתה גלויה למשתמשים או מוצגת ברקע.
חלוקת משימות ארוכות מעניקה לדפדפן יותר הזדמנויות להתאים לעבודה חשובה שנראית למשתמש, כמו התמודדות עם אינטראקציות ועדכוני עיבוד אחרים.
נמנעים משימוש ב-JavaScript מיותר
אין ספק: אתרים שולחים יותר JavaScript מבעבר, ולא נראה שהמגמה תשתנה בקרוב. כשאתם שולחים יותר מדי JavaScript, אתם יוצרים סביבה שבה המשימות מתחרות על תשומת הלב של ה-thread הראשי. בהחלט יכולה להיות לכך השפעה על מידת הרספונסיביות של האתר, במיוחד בתקופה הזו של ההפעלה ההכרחית.
עם זאת, זו לא בעיה שלא ניתן לפתור. יש לכם כמה אפשרויות:
- כדי למצוא קוד שלא נמצא בשימוש במשאבים של האתר, אפשר להשתמש בכלי הכיסוי שבכלי הפיתוח ל-Chrome. על ידי צמצום גודל המשאבים הדרושים לכם במהלך ההפעלה, תוכלו להבטיח שהאתר שלכם משקיע פחות זמן בניתוח והידור של קוד, דבר שיוביל לחוויית משתמש ראשונית חלקה יותר.
- לפעמים הקוד שלא נמצא בשימוש בכלי הכיסוי מסומן כ'לא בשימוש'. מכיוון שהיא לא בוצעה במהלך ההפעלה, אבל עדיין תידרש פונקציונליות מסוימת בעתיד. זהו קוד שניתן להעביר לחבילה נפרדת באמצעות פיצול קוד.
- אם אתם משתמשים ב-Tag Manager, כדאי לבדוק מדי פעם את התגים כדי לוודא שהם עברו אופטימיזציה, גם אם הם עדיין נמצאים בשימוש. כדי ש-JavaScript של מנהל התגים יהיה קטן ויעיל יותר, אפשר למחוק תגים ישנים יותר שלא נמצאים בשימוש.
נמנעים מעדכוני רינדור גדולים
JavaScript הוא לא הדבר היחיד שיכול להשפיע על הרספונסיביות של האתר. רינדור יכול להיות סוג של עבודה יקרה בפני עצמו, וכשמתבצעים עדכוני רינדור גדולים, הם עלולים להפריע ליכולת של האתר שלכם להגיב לקלט של משתמשים.
אופטימיזציה של עבודת הרינדור היא לא תהליך פשוט, ובדרך כלל היא תלויה במה שרוצים להשיג. למרות זאת, יש כמה דברים שאפשר לעשות כדי לוודא שעדכוני העיבוד יהיו סבירים, ולא יתפרסו על משימות ארוכות:
- מומלץ להימנע משימוש ב-
requestAnimationFrame()לעבודה שאינה ויזואלית. קריאותrequestAnimationFrame()מטופלות בשלב הרינדור של לולאת האירוע, ואם מתבצעת יותר מדי עבודה בשלב הזה, יכול להיות עיכוב בעדכוני הרינדור. חשוב שכל העבודה שמבצעים ב-requestAnimationFrame()תישמר אך ורק למשימות של עיבוד עדכונים. - חשוב להקפיד שגודל ה-DOM יהיה קטן. גודל ה-DOM ואינטנסיביות של פעולת הפריסה קשורים זה לזה. כשהרינדור צריך לעדכן את הפריסה עבור DOM גדול מאוד, העבודה הנדרשת לחישוב מחדש של הפריסה שלו יכולה להתארך באופן משמעותי.
- משתמשים בהכללת CSS. בלימת ה-CSS מסתמכת על המאפיין
containשל CSS, שמספק לדפדפן הוראות לביצוע פעולות פריסה בקונטיינר שבו מוגדר המאפייןcontain, כולל בידוד של היקף הפריסה והרינדור ברמה הבסיסית (root) ב-DOM. זה לא תמיד תהליך קל, אבל אם מבודדים אזורים שמכילים פריסות מורכבות, אפשר להימנע מביצוע עבודות פריסה ועיבוד שלא נחוצות.
סיכום
שיפור הביצועים של דפים יכול להיראות כמו משימה מרתיעה, במיוחד לאור העובדה שיש באינטרנט כמות גדולה של הנחיות שצריך לשקול. עם זאת, על ידי התמקדות בהמלצות האלה תוכלו לגשת לבעיה בצורה ממוקדת ומטרה, בתקווה שהיא תתייחס לשיפור במדדי הליבה לבדיקת חוויית המשתמש באתר.
ההמלצות שמפורטות כאן הן לא ממצות, אבל אנחנו מאמינים – על סמך ניתוח קפדני של מצב האינטרנט, ההמלצות האלה הן הדרכים האפקטיביות ביותר לשפר את הביצועים של מדדי הליבה לבדיקת חוויית המשתמש באתר בשנת 2023.
אם רוצים לקבל מידע נוסף מעבר להמלצות המפורטות כאן, עיינו במדריכים הבאים לאופטימיזציה:
שנה חדשה בפתח, ואינטרנט מהיר יותר לכולם! לאפשר לאתרים שלכם לפעול במהירות רבה עבור המשתמשים בכל הדרכים החשובות ביותר.
צילום: Devin Avery