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

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

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

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

• ההשפעה הגדולה ביותר בעולם האמיתי
• רלוונטיים וניתנים לשימוש ברוב האתרים
• הן מציאותיות לרוב המפתחים להטמיע

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

מהירות התגובה לאינטראקציה באתר (INP)

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

1. כדאי לעשות את זה לעיתים קרובות כדי להפריד בין משימות ארוכות

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

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

Scheduler API מאפשר להוסיף משימות לתור באמצעות מערכת של רמות תעדוף. באופן ספציפי, ה-API scheduler.yield()‎ מפצל משימות ארוכות תוך הבטחה שאפשר לטפל באינטראקציות בלי לוותר על המקום שלהן בתור המשימות.

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

2. הימנעות משימוש ב-JavaScript מיותר

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

עם זאת, זו לא בעיה שלא ניתן לפתור, ויש לך אפשרויות:

• שימוש בתכונות Baseline של פלטפורמת האינטרנט שזמינות באופן נרחב, במקום בהטמעות יתירות שמבוססות על JavaScript.
• כדי למצוא בסקריפטים קוד שלא נמצא בשימוש, אפשר להשתמש בכלי הכיסוי שבכלי הפיתוח ל-Chrome. על ידי צמצום גודל המשאבים הדרושים במהלך ההפעלה, ניתן להבטיח שדפים יוקדשו פחות זמן לניתוח והידור של קוד, ומספקת חוויית משתמש ראשונית חלקה יותר.
• משתמשים בפיצול קוד כדי ליצור חבילה נפרדת לקוד שלא נדרש לעיבוד הראשוני, אבל עדיין ישמש מאוחר יותר.
• אם משתמשים במנהל תגים, צריך לבצע אופטימיזציה של התגים מדי פעם. אפשר להסיר תגים ישנים עם קוד שלא בשימוש כדי לצמצם את טביעת הקוד של JavaScript ב-Tag Manager.

3. הימנעות מעדכוני עיבוד גדולים

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

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

• כדאי לארגן מחדש את הקריאות והכתובות של DOM בקוד JavaScript כדי להימנע מפריסה מאולצת ומרעידת פריסה.
• חשוב לשמור על נפח DOM קטן. יש קורלציה בין גודל ה-DOM לבין עוצמת העבודה על הפריסה. כשהמרת הדפים צריכה לעדכן את הפריסה של DOM גדול מאוד, העבודה הנדרשת כדי לחשב מחדש את הפריסה שלו עשויה לגדול באופן משמעותי.
• שימוש במגבלות CSS כדי ליצור עיבוד גרפי (render) עצל של תוכן DOM שמחוץ למסך. זה לא תמיד פשוט, אבל בידוד אזורים שמכילים פריסות מורכבות יכול למנוע עבודה מיותרת על פריסה ועל עיבוד (רנדור).

Largest Contentful Paint (LCP)

המהירות שבה נטען רכיב התוכן הכי גדול (LCP) הוא המדד הבסיסי של חוויית המשתמש (Core Web Vital) שבו למפתחים הכי קשה לעמוד – 40% מהאתרים בדוח חוויית המשתמש ב-Chrome לא עומדים בסף המומלץ ל-LCP לצורך חוויית משתמש טובה. צוות Chrome ממליץ על הטכניקות הבאות כדרכים היעילות ביותר לשיפור LCP.

1. מוודאים שאפשר למצוא את משאב ה-LCP ממקור ה-HTML ולקבל עדיפות

צוות Chrome שם לב לדברים הבאים בנוגע ל-LCP באינטרנט:

• לפי היוזמה Web Almanac לשנת 2022 בארכיון של HTTP, ב-72% מהדפים לנייד רכיב ה-LCP שלהם מופיע בתמונה.
• ניתוח של נתונים ממשתמשים אמיתיים ב-Chrome מראה שברוב המקורות שבהם ההוצאה של LCP נמוכה פחות מ-10% מזמן ה-LCP של 75 ימים בהורדה של תמונת ה-LCP.
• בקרב הדפים עם מדד LCP נמוך, הטעינה של תמונות LCP מצד הלקוח מתעכבת ב-1,290 אלפיות השנייה באחוזון ה-75 – כלומר יותר ממחצית מהתקציב כדי לספק חוויית שימוש מהירה.
• מתוך הדפים שבהם רכיב ה-LCP היה תמונה, ב-39% מהתמונות האלה היו כתובות URL מקור שלא היו ניתנות לגילוי בתגובת ה-HTML הראשונית (למשל <img src="..."> או <link rel="preload" href="...">), כדי לאפשר לסורק הטעינה מראש של הדפדפן לגלות אותן בהקדם האפשרי.
• לפי נתוני Web Almanac, רק 0.03% מהדפים שעומדים בדרישות השתמשו במאפיין ה-HTML fetchpriority כדי לתת עדיפות גבוהה יותר למשאבים – כולל משאבים שיכולים לשפר את LCP של דף במאמץ יחסית קטן.

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

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

אם רכיב ה-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 עם עדיפות גבוהה:

• מוסיפים את המאפיין fetchpriority="high" לתג <img> או <link rel="preload"> של התמונה ל-LCP. כך ניתן להגדיל את העדיפות של משאב התמונה כדי שהוא יוכל להתחיל לטעון מוקדם יותר.
• מסירים את המאפיין loading="lazy" מהתג <img> של התמונה של LCP. כך אפשר למנוע את עיכוב הטעינה שנגרם כתוצאה מהאישור שהתמונה מופיעה בחלון התצוגה או בסמוך אליו.
• כשאפשר, כדאי לדחות את השימוש במשאבים לא חיוניים. העברת המשאבים האלה לסוף המסמך, טעינה איטית של תמונות או פריטי iframe, או טעינה שלהם באופן אסינכרוני באמצעות JavaScript, יעזרו לפנות מקום למשאבים חשובים יותר, כמו התמונה של LCP, כדי שהם ייטענו מהר יותר.

2. כדאי לנסות להגיע לניווטים מיידיים

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

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

אפשר לשחזר דפים שביקרת בהם בעבר באמצעות מטמון לדף הקודם/הבא (bfcache). כדי להשתמש בה, צריך לוודא שהדפים עומדים בקריטריונים לזכאות לשמירה במטמון לדף הקודם/הבא. סיבות נפוצות לכך שדפים לא מתאימים לשמירה במטמון לדף הקודם/הבא היא שהם מוצגים עם הוראות שמירה במטמון של no-store או שיש בהם unload פונקציות event listener.

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

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

3. שימוש ב-CDN כדי לבצע אופטימיזציה של זמן אחזור הבקשה הראשונה (TTFB)

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

הזמן הזה נקרא Time to First Byte (TTFB). הדרכים הטובות ביותר לצמצם את זמן אחזור הבקשה הראשונית הן:

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

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

רשתות CDN יכולות גם להציג מסמכי HTML ולשמור אותם במטמון, אבל לפי תקן Web Almanac, רק 29% מהבקשות למסמכי HTML נשלחו מ-CDN. המשמעות היא שיש הזדמנות משמעותית לאתרים לחסוך עוד יותר.

הנה כמה טיפים להגדרת רשתות CDN:

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

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

Cumulative Layout Shift (CLS)

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

1. להגדיר גדלים מפורשים לכל תוכן שנטען מהדף

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

הדרך הטובה ביותר לתקן שינויים בפריסה שנגרמים על ידי תמונות ללא הגדרת גודל היא להגדיר באופן מפורש את המאפיינים width ו-height או את מאפייני ה-CSS המקבילים שלהם. ב-72% מהדפים יש לפחות תמונה אחת לא בגודל. ללא הגדרת גודל מפורשת, הגובה הראשוני של התמונות האלה הוא 0px, וזה עלול לגרום לשינויים בפריסה כשהתמונות האלה נטענות והדפדפן מגלה את המימדים שלהן. זוהי הזדמנות עצומה לאינטרנט הקולקטיבי, והיא מחייבת פחות מאמץ מאשר חלק מההמלצות האחרות שמפורטות במדריך הזה.

תמונות הן לא הגורם היחיד שמשפיע על CLS. שינויים בפריסת הדף עשויים לנבוע מתוכן אחר שנטען בדרך כלל אחרי הרינדור הראשוני של הדף, כולל מודעות של צד שלישי או סרטונים מוטמעים. הנכס aspect-ratio יכול לעזור בכך. זוהי תכונת CSS שזמין לציבור הרחב שמאפשרת למפתחים להגדיר במפורש יחס גובה-רוחב לתמונות ולרכיבים שאינם תמונות. כך תוכלו להגדיר width דינמי (למשל על סמך גודל המסך) ולאפשר לדפדפן לחשב באופן אוטומטי את הגובה המתאים, בדומה לאופן שבו הוא עושה זאת בתמונות עם מידות.

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

2. מוודאים שהדפים עומדים בדרישות לשמירה במטמון לדף הקודם/הבא

כפי שצוין קודם במדריך הזה, המטמון לדף הקודם/הבא (bfcache) טוען באופן מיידי דף מוקדם או מאוחר יותר בהיסטוריית הדפדפן, באמצעות קובץ snapshot של הזיכרון. המטמון לדף הקודם/הבא הוא אופטימיזציה משמעותית של הביצועים ברמת הדפדפן שמשפרת את מדד LCP, אבל הוא גם מבטל לחלוטין את השינויים בפריסה. למעשה, השקת bfcache בשנת 2022 הייתה אחראית לשיפור הגדול ביותר ב-CLS שראינו באותה שנה.

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

בעלי אתרים צריכים לבדוק אם הדפים עומדים בדרישות לשימוש ב-bfcache ולתקן את הבעיות שמונעות את השימוש בו. ב-Chrome יש בודק bfcache בכלי הפיתוח, ואפשר גם להשתמש ב-Not Restored Reasons API כדי לזהות בשטח את הסיבות לכך שהמודעות לא עומדות בדרישות.

3. מומלץ להימנע משימוש באנימציות ובמעברים שמשתמשים במאפייני CSS שמשפיעים על הפריסה

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

אי אפשר לקשר באופן חד-משמעי בין נתוני ארכיון HTTP לבין שינויים בפריסה, אבל הנתונים מראים שלדפים שיש בהם אנימציה לכל נכס CSS שיכול להשפיע על הפריסה יש סיכוי נמוך ב-15% לקבל CLS 'טוב' בהשוואה לדפים בסך הכול. נכסים מסוימים משויכים לרמת CLS נמוכה יותר בהשוואה לנכסים אחרים. לדוגמה, לדפים עם אנימציה ברוחב של margin או border יש CLS 'חלש' כמעט פי שניים משיעור ה-CLS הכולל של דפים שנחשבים גרועים.

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

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

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

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

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

סיכום

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

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

• אופטימיזציה של ה-INP
• אופטימיזציה של LCP
• אופטימיזציה של CLS

נספח: יומן שינויים

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

אוקטובר 2024

עדכון ל-2024:

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

ינואר 2023

זוהי הרשימה הראשונית של ההמלצות:

• LCP
  • מוודאים שאפשר לראות את משאב ה-LCP ממקור ה-HTML
  • קביעת תעדוף של משאב ה-LCP
  • שימוש ב-CDN לביצוע אופטימיזציה שלTTFB מסמכים ומשאבים
• CLS
  • הגדרת גדלים מפורשים לכל תוכן שנטען מהדף
  • מוודאים שהדפים עומדים בדרישות לשמירה במטמון לדף הקודם/הבא
  • מומלץ להימנע מאנימציות ומעברים שמשתמשות במאפייני CSS שיוצרים פריסה
• FID
  • הימנעות ממשימות ארוכות או פיצול שלהן
  • נמנעים משימוש ב-JavaScript מיותר
  • הימנעות מעדכוני עיבוד גדולים

אפשר גם לצפות במצגת Google I/O לשנת 2023 כדי לקבל סיכום של הסרטון.