לאורך השנים, קהילת האינטרנט צברה ידע רב בנושא אופטימיזציה של ביצועי האתר. כל אופטימיזציה יכולה לשפר את הביצועים של הרבה אתרים, אבל אם תנסו לבצע את כולן בבת אחת, יכול להיות שתרגישו מוצפים. למעשה, רק חלק מהן רלוונטיות לכל אתר נתון.
אם אתם לא מומחים לביצועי אתרים, סביר להניח שלא ברור לכם אילו פעולות אופטימיזציה ישפיעו בצורה המשמעותית ביותר על האתר שלכם. סביר להניח שלא יהיה לכם זמן לבצע את כולן, לכן חשוב לשאול את עצמכם אילו פעולות אופטימיזציה הכי יעזרו לכם לשפר את הביצועים של המשתמשים?
האמת על אופטימיזציות של ביצועים היא שאי אפשר לשפוט אותן רק על סמך היתרונות הטכניים שלהן. חשוב גם להביא בחשבון את הגורמים האנושיים והארגוניים שמשפיעים על הסבירות שתצליחו להטמיע אופטימיזציה מסוימת. חלק משיפורי הביצועים עשויים להשפיע בצורה משמעותית על האתר, אבל בפועל, למפתחים מעטים יהיה זמן או משאבים להטמיע אותם. לעומת זאת, יכול להיות שיש שיטות מומלצות שמשפיעות מאוד על הביצועים וכבר כמעט כולם פועלים לפיהן. במדריך הזה מפורטות פעולות אופטימיזציה של ביצועי האתר ש:
- הכי הרבה השפעה בעולם האמיתי
- רלוונטיים וניתנים לשימוש ברוב האתרים
- הן מציאותיות לרוב המפתחים להטמיע
בסך הכול, אלה הדרכים הכי ריאליסטיות ויעילות לשיפור המדדים של Core Web Vitals. אם זו הפעם הראשונה שאתם עובדים עם ביצועי אתרים, או אם אתם עדיין לא בטוחים מה יניב לכם את החזר ה-ROI הגבוה ביותר, זה המקום הטוב ביותר להתחיל בו.
מהירות התגובה לאינטראקציה באתר (INP)
מדד מהירות התגובה לאינטראקציה באתר (INP) הוא המדד החדש ביותר של Core Web Vitals, והוא מציע כמה מהאפשרויות הגדולות ביותר לשיפור. עם זאת, בגלל שמספר האתרים שעומדים בסף לחוויית משתמש 'טובה' נמוך בהרבה בהשוואה לקודם שהוסר משימוש, יכול להיות שאתם נמנים על המפתחים הרבים שמלמדים את עצמם איך לבצע אופטימיזציה של תגובתיות האינטראקציה בפעם הראשונה. כדאי להתחיל עם השיטות הבאות, שחשוב להכיר כדי לשפר את הביצועים של INP ביעילות הגבוהה ביותר.
1. כדאי להשתמש ב-Yield לעיתים קרובות כדי לפצל משימות ארוכות
משימות הן כל פעולה נפרדת שהדפדפן מבצע, כולל רינדור, פריסה, ניתוח, הידור או הפעלה של סקריפטים. אם משך המשימה חורג מ-50 אלפיות שנייה, היא הופכת למשימה ארוכה. משימות ארוכות הן בעייתיות כי הן עלולות למנוע מהשרשור הראשי להגיב במהירות לאינטראקציות של משתמשים.
תמיד כדאי לנסות לבצע כמה שפחות עבודה ב-JavaScript, אבל אפשר לעזור לתהליך הראשי על ידי פירוקה של משימות ארוכות. כדי לעשות זאת, צריך להעביר את השליטה לשרשור הראשי לעיתים קרובות, כדי שעדכוני הרינדור ואינטראקציות אחרות של משתמשים יוכלו להתרחש מוקדם יותר.
Scheduler API מאפשר להוסיף משימות לתור באמצעות מערכת של רמות תעדוף. באופן ספציפי, ה-API scheduler.yield() מפצל משימות ארוכות תוך הבטחה שאפשר לטפל באינטראקציות בלי לוותר על המקום שלהן בתור המשימות.
כשמחלקים משימות ארוכות, הדפדפן מקבל יותר הזדמנויות לבצע משימות קריטיות שמונעות ממשתמשים להשתמש בדפדפן.
2. הימנעות משימוש ב-JavaScript מיותר
האתרים כוללים יותר קוד JavaScript מאי פעם, ונראה שהמגמה הזו לא משתנה. כששולחים יותר מדי JavaScript, יוצרים סביבה שבה משימות מתחרות על תשומת הלב של השרשור הראשי. הדבר עשוי להשפיע על מהירות התגובה של האתר, במיוחד בתקופה הקריטית של ההפעלה.
עם זאת, זו לא בעיה שלא ניתן לפתור, ויש לך אפשרויות:
- שימוש בתכונות Baseline של פלטפורמת האינטרנט שזמינות באופן נרחב, במקום בהטמעות יתירות שמבוססות על JavaScript.
- אתם יכולים להשתמש בכלי הכיסוי ב-Chrome DevTools כדי למצוא קוד שלא נמצא בשימוש בסקריפטים שלכם. אם תקטינו את נפח המשאבים הנדרשים במהלך ההפעלה, תוכלו להבטיח שהדפים יקדישו פחות זמן לניתוח ולקמפלור של הקוד, וכך לספק חוויית משתמש ראשונית חלקה יותר.
- משתמשים בפיצול קוד כדי ליצור חבילה נפרדת לקוד שלא נדרש לעיבוד הראשוני, אבל עדיין ישמש מאוחר יותר.
- אם אתם משתמשים במנהל תגים, כדאי לבצע אופטימיזציה של התגים מדי פעם. אפשר להסיר תגים ישנים עם קוד שלא בשימוש כדי לצמצם את טביעת הקוד של 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 באינטרנט:
- לפי 2024 Web Almanac של HTTP Archive, 73% מהדפים לנייד מכילים תמונה כרכיב LCP.
- ניתוח של נתוני משתמשים אמיתיים מ-Chrome מראה שרוב המקורות עם זמן LCP נמוך מבזבזים פחות מ-10% מזמן ה-LCP החציוני החמישי (p75) בהורדת תמונת ה-LCP.
- בדפים עם זמן LCP ארוך, זמן הטעינה של תמונות ה-LCP שלהם בצד הלקוח מתעכב ב-1,290 אלפיות השנייה ב-75% מהדפים – יותר ממחצית התקציב לחוויה מהירה.
- מתוך הדפים שבהם רכיב ה-LCP היה תמונה, ל-35% מהתמונות האלה היו כתובות URL של מקור שלא ניתן היה למצוא בתגובה הראשונית של ה-HTML (כמו
<img src="...">
או<link rel="preload" href="...">
), מה שמאפשר לסורק הטעינה המקדימה של הדפדפן לגלות אותן בהקדם האפשרי. - לפי נתוני Web Almanac, 15% מהדפים שעומדים בדרישות השתמשו במאפיין ה-HTML
fetchpriority
כדי לתת עדיפות גבוהה יותר למשאבים – כולל משאבים שיכולים לשפר את ה-LCP של דף מסוים במאמץ יחסית קטן.
הנתונים הסטטיסטיים האלה ממחישים למפתחים שיש להם הזדמנות גדולה לצמצם גם את העיכוב בטעינה של המשאבים וגם את משך הטעינה של המשאבים בתמונות LCP.
אם הבעיה היא עיכוב בטעינת המשאבים, חשוב לזכור שיכול להיות שכבר מאוחר מדי להשיג LCP טוב אם הדף צריך להמתין לטעינת CSS או JavaScript במלואה לפני שהתמונות יכולות אפילו להתחיל להיטען. בנוסף, אפשר לקצר את משך הזמן של טעינה של משאב תמונה מסוג LCP על ידי שינוי סדר העדיפויות שלה כך שתקבל יותר רוחב פס, וכך תיטען מהר יותר באמצעות מאפיין ה-HTML fetchpriority
.
אם רכיב ה-LCP הוא תמונה, כתובת ה-URL של התמונה צריכה להיות גלויה בתגובה של ה-HTML כדי לצמצם את עיכוב הטעינה של המשאב. ריכזנו כאן כמה טיפים שיעזרו לכם לעשות זאת:
- טעינה של התמונה באמצעות רכיב
<img>
עם המאפייןsrc
אוsrcset
. אין להשתמש במאפיינים לא סטנדרטיים כמוdata-src
שדורשים JavaScript כדי לבצע עיבוד, כי תהליך כזה תמיד יהיה איטי יותר. ב-7% מהדפים, התמונה של רכיב ה-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) מאפשר לשחזר דפים שביקרתם בהם בעבר. כדי להשתמש בה, עליכם לוודא שהדפים עומדים בקריטריונים לזכאות של bfcache. סיבות נפוצות לכך שדפים לא עומדים בדרישות לשימוש ב-bfcache הן שהם מוצגים עם הנחיות מטמון של no-store
או שיש להם מאזינים לאירועים של unload
.
שחזור דפים שעברו עיבוד מלא משפר לא רק את ביצועי הטעינה, אלא גם את יציבות הפריסה. מידע נוסף על bfcache ועל מידת היעילות שלו בשיפור מדד CLS זמין בקטע מוודאים שהדפים עומדים בדרישות לשימוש ב-bfcache.
Browser Support
עיבוד מראש של הדף הבא שאליו המשתמש נכנס היא דרך יעילה נוספת לשיפור משמעותי של ביצועי LCP, והיא מתאפשרת באמצעות Speculation Rules API. עם זאת, כדי ליהנות מהיתרונות האלה, חשוב לוודא שהדפים הנכונים עוברים עיבוד מראש. השערות שגויות מבזבזות משאבים גם בשרת וגם בלקוח, ויכולות לפגוע בביצועים. לכן, ככל שאתם פחות בטוחים איזה יהיה הדף הבא, כך עליכם להיות שמרנים יותר ביצירת הרינדור מראש שלו. אם אתם לא בטוחים, נתוני ניתוח הנתונים יכולים לעזור לכם לבצע רינדור מראש של דפים עם הסבירות הגבוהה ביותר לביקור בהם בשלב הבא.
3. שימוש ב-CDN כדי לבצע אופטימיזציה של זמן אחזור הבקשה הראשונה (TTFB)
ההמלצה הקודמת התמקדה בניווטים מיידיים, שמספקים למשתמשים את חוויית השימוש הטובה ביותר. עם זאת, יכולים להיות מצבים שבהם שיטות bfcache וטעינה ספקולטיבית לא רלוונטיות. נניח שמשתמש עוקב אחרי קישור ממקורות שונים לאתר שלכם, שבו התגובה הראשונית של מסמך ה-HTML חוסמת למעשה את LCP. הדפדפן לא יכול להתחיל לטעון משאבי משנה עד שהוא מקבל את הבייט הראשון בתגובה. ככל שהדבר יקרה מוקדם יותר, כך כל השאר יוכל להתחיל לקרות.
הזמן הזה נקרא זמן עד בייט ראשון (TTFB). הדרכים הטובות ביותר לצמצם את זמן אחזור הבקשה הראשונית הן:
- כדאי להציג את התוכן שלכם קרוב ככל האפשר מבחינה גיאוגרפית למשתמשים שלכם.
- לשמור את התוכן הזה במטמון כדי שניתן יהיה להציג אותו במהירות אם הוא יתבקש שוב בעתיד הקרוב.
הדרך הטובה ביותר לעשות את שני הדברים האלה היא להשתמש ב-CDN. רשתות CDN מפיצות את המשאבים שלכם לשרתים קצה ברחבי העולם, וכך מגבילות את המרחק שהמשאבים האלה צריכים לעבור בחיבור הפיזי למשתמשים. בדרך כלל, פלטפורמות CDN כוללות גם אמצעי בקרה מפורטים על אחסון במטמון, שניתן לשנות בהתאם לצרכים של האתר.
רשתות CDN יכולות גם להציג ולשמור במטמון מסמכי HTML, אבל לפי נתוני Web Almanac, רק 33% מהבקשות למסמכי HTML הוצגו מ-CDN. המשמעות היא שיש הזדמנות משמעותית לאתרים לחסוך עוד יותר.
ריכזנו כאן כמה טיפים להגדרת CDN:
- שמירת מסמכי HTML סטטיים במטמון גם לזמן קצר. לדוגמה, האם חשוב שהתוכן תמיד יהיה עדכני? או שאפשר להשתמש בנתונים שתקפים רק לכמה דקות?
- כדאי לבדוק אם אפשר להעביר לקצה את הלוגיקה הדינמית שפועלת בשרת המקור. זוהי תכונה של רוב רשתות ה-CDN המודרניות.
בכל פעם שאפשר להציג תוכן ישירות מהקצה ולהימנע מנסיעה לשרת המקור, יש שיפור בביצועים. גם במקרים שבהם צריך לעבור את כל הדרך עד למקור, בדרך כלל רשתות ה-CDN מותאמות לביצוע הפעולה הזו מהר יותר, כך שזו תהיה תוצאה טובה בכל מקרה.
Cumulative Layout Shift (CLS)
מדד יציבות חזותית (CLS) הוא מדד של היציבות החזותית של דף אינטרנט. מדד CLS הוא המדד שבו רוב האתרים נוטים להציג ביצועים טובים, אבל כ-רבע מהם עדיין לא עומדים בסף המומלץ, כך שעדיין יש הזדמנות גדולה לשפר את חוויית המשתמש באתרים רבים.
1. להגדיר גדלים מפורשים לכל תוכן שנטען מהדף
שינויים בפריסה מתרחשים בדרך כלל כשתוכן קיים זז אחרי שתוכן אחר מסיים להיטען. הדרך העיקרית לשיפור ה-CLS היא להזמין מראש את כל המקום הנדרש, ככל האפשר.
הדרך הטובה ביותר לתקן שינויים בפריסה שנגרמים על ידי תמונות ללא הגדרת גודל היא להגדיר באופן מפורש את המאפיינים width
ו-height
או את מאפייני ה-CSS המקבילים שלהם. ב66% מהדפים יש לפחות תמונה אחת ללא שינוי גודל. ללא הגדרת גודל מפורשת, הגובה הראשוני של התמונות האלה הוא 0px
, וזה עלול לגרום לשינויים בפריסה כשהתמונות האלה נטענות והדפדפן מגלה את המימדים שלהן. זוהי הזדמנות עצומה לאינטרנט הקולקטיבי, והיא מחייבת פחות מאמץ מאשר חלק מההמלצות האחרות שמפורטות במדריך הזה.
תמונות הן לא הגורם היחיד שמשפיע על CLS. שינויים בפריסת הדף יכולים להיגרם בגלל תוכן אחר שנטען בדרך כלל אחרי הרינדור הראשוני של הדף, כולל מודעות של צד שלישי או סרטונים מוטמעים. הנכס aspect-ratio
יכול לעזור לכם בכך. זוהי תכונה בסיסית שזמינה באופן נרחב ב-CSS שמאפשרת למפתחים להגדיר באופן מפורש יחס גובה-רוחב בתמונות וגם באלמנטים שאינם תמונות. כך תוכלו להגדיר width
דינמי (למשל, על סמך גודל המסך) ולאפשר לדפדפן לחשב באופן אוטומטי את הגובה המתאים, בדומה לאופן שבו הוא עושה זאת בתמונות עם מידות.
עם זאת, לא תמיד אפשר לדעת מהו הגודל המדויק של תוכן דינמי. גם אם לא ידוע לכם מהו הגודל המדויק, עדיין תוכלו לצמצם את חומרת השינויים בפריסת האתר. כמעט תמיד עדיף להגדיר ערך הגיוני ל-min-height
מאשר לאפשר לדפדפן להשתמש בגובה ברירת המחדל של 0px
לרכיב ריק. בדרך כלל, גם שימוש ב-min-height
הוא פתרון פשוט, כי הוא עדיין מאפשר לקונטיינר לגדול לגובה התוכן הסופי אם יש צורך – הוא רק מפחית את מידת הגדילה הזו לרמה שאפשר לסבול, בתקווה.
2. מוודאים שהדפים עומדים בדרישות לשמירה במטמון לדף הקודם/הבא
כפי שצוין למעלה במדריך, המטמון לדף הקודם/הבא (bfcache) טוען באופן מיידי דף מוקדם או מאוחר יותר בהיסטוריית הדפדפן באמצעות קובץ snapshot של הזיכרון. המטמון לדף הקודם/הבא הוא אופטימיזציה משמעותית של הביצועים ברמת הדפדפן שמשפרת את מדד LCP, אבל הוא גם מבטל לחלוטין את השינויים בפריסה. למעשה, השקת bfcache בשנת 2022 הייתה אחראית לשיפור הגדול ביותר ב-CLS שראינו באותה שנה.
למרות זאת, מספר משמעותי של אתרים לא עומדים בדרישות לשימוש ב-bfcache, ולכן הם לא נהנים מהיתרון בחינם הזה לשיפור ביצועי האתר. אם הדף לא טוען מידע רגיש שאתם לא רוצים לשחזר מהזיכרון, עליכם לוודא שהדפים שלכם עומדים בדרישות לשימוש ב-bfcache.
בעלי אתרים צריכים לבדוק אם הדפים עומדים בדרישות לשימוש ב-bfcache ולתקן את הסיבות לכך שהם לא עומדים בדרישות. ב-Chrome יש בודק bfcache בכלי הפיתוח, ואפשר גם להשתמש ב-Not Restored Reasons API כדי לזהות בשטח את הסיבות לכך שהמודעות לא עומדות בדרישות.
3. מומלץ להימנע משימוש באנימציות ובמעברים שמשתמשים במאפייני CSS שמשפיעים על הפריסה
עוד סיבה נפוצה לשינויים בפריסה היא כשיש אנימציה לרכיבים. לדוגמה, מודעות באנר של קובצי cookie או מודעות באנר אחרות של התראות שנכנסות מלמעלה או מלמטה תורמות לערך CLS לעיתים קרובות. הבעיה הזו חמורה במיוחד כשבאנרים כאלה דוחפים תוכן אחר, אבל גם אם הם לא, אנימציה שלהם עדיין יכולה להשפיע על CLS.
הנתונים של HTTP Archive לא מאפשרים לקשר באופן חד-משמעי בין אנימציות לתנודות בפריסה, אבל הנתונים מראים שבדפים שבהם יש אנימציה של מאפיין CSS שיכול להשפיע על הפריסה, יש סיכוי נמוך ב-15% לקבלת CLS 'טוב' בהשוואה לדפים באופן כללי. יש נכסים שמשויכים ל-CLS נמוך יותר מאחרים. לדוגמה, בדפים עם אנימציה של רוחב margin
או border
, הערך של CLS הוא 'גרוע' בשיעור כמעט כפול מהשיעור שבו דפים באופן כללי נחשבים ל'גרועים'.
זה לא מפתיע, כי בכל פעם שמבצעים מעבר או אנימציה של כל נכס CSS שמשפיע על הפריסה, התוצאה היא שינויים בפריסה. אם השינויים בפריסה האלה לא מתרחשים תוך 500 אלפיות השנייה ממועד האינטראקציה של המשתמש, הם ישפיעו על מדד CLS.
יכול להיות שחלק מהמפתחים יתפלצו לגלות שזה נכון גם במקרים שבהם הרכיב מועבר מחוץ לתהליך הרגיל של המסמך. לדוגמה, אלמנטים שממוקמים באופן מוחלט ומפעילים אנימציה של top
או left
גורמים לשינויים בפריסה, גם אם הם לא דוחפים תוכן אחר. עם זאת, אם במקום להוסיף אנימציה ל-top
או ל-left
, מוסיפים אנימציה ל-transform:translateX()
או ל-transform:translateY()
, הדפדפן לא יתעדכן את פריסת הדף, וכך מונעים שינויים בפריסת הדף.
העדפת אנימציה של מאפייני CSS שאפשר לעדכן בשרשור המאגר של הדפדפן היא שיטה מומלצת לשיפור הביצועים כבר זמן רב, כי היא מעבירה את העבודה הזו מהשרשור הראשי ל-GPU. בנוסף לכך שזוהי שיטה מומלצת באופן כללי לשיפור הביצועים, היא גם יכולה לעזור לשפר את מדד CLS.
ככלל, לעולם אל תוסיפו אנימציה או מעברים למאפייני CSS שמחייבים את הדפדפן לעדכן את פריסת הדף, אלא אם אתם עושים זאת בתגובה להקשה של משתמש או ללחיצה על מקש (אבל לא hover
). כשהדבר אפשרי, עדיף להשתמש במעברים ובאנימציות באמצעות המאפיין transform
ב-CSS.
בבדיקה של Lighthouse אין להשתמש באנימציות ללא הרכבת שכבות מוצגת אזהרה כשדף מציג אנימציה של מאפייני CSS שעשויים להאט את הדף.
סיכום
שיפור ביצועי הדפים יכול להיראות כמו משימה מרתיעה, במיוחד בהתחשב בכמות העצומה של ההנחיות באינטרנט שצריך להביא בחשבון. עם זאת, אם תתמקדו ברשימה הקצרה הזו של השיטות המומלצות היעילות ביותר, תוכלו לגשת לבעיה עם כוונה מחודשת, ובתקווה לשפר את מדדי חוויית המשתמש הבסיסיים (Core Web Vitals) של האתר.
אם אתם רוצים להרחיב את האופטימיזציה מעבר לשיטות שמפורטות כאן, תוכלו לקרוא את המדריכים הבאים כדי לקבל מידע נוסף:
נספח: יומן שינויים
כאן נעקוב אחרי שינויים משמעותיים במסמך הזה כדי להסביר מתי ולמה ההמלצות המובילות השתנו.
אוקטובר 2024
עדכון ל-2024:
- INP
- החלפנו את המדד הזה מ-FID ל-INP בהתאם להשקת המדד INP כמדד ליבה לבדיקת חוויית המשתמש באתר, והפכנו אותו למדד המוביל ברשימה.
- שינינו את ההמלצה שלנו להשתמש ב-API של
isInputPending
כחלק מפיצול משימות ארוכות. מידע נוסף על השיקולים שלנו זמין במאמר אופטימיזציה של משימות ארוכות.
- LCP
- שילבנו את ההמלצות לגבי ניראות והמלצות לגבי תעדוף לרשימה אחת.
- הוספנו המלצה חדשה שמטרתה לעודד ניווטים מיידיים.
ינואר 2023
זוהי הרשימה הראשונית של ההמלצות:
- LCP
- מוודאים שאפשר למצוא את משאב ה-LCP ממקור ה-HTML
- מוודאים שהמשאב של LCP מקבל עדיפות
- שימוש ב-CDN כדי לבצע אופטימיזציה של זמן אחזור הבקשה הראשון (TTFB) של מסמכים ומשאבים
- CLS
- להגדיר גדלים מפורשים לכל תוכן שנטען מהדף
- מוודאים שהדפים עומדים בדרישות לשמירה במטמון לדף הקודם/הבא
- מומלץ להימנע משימוש באנימציות ובמעברים שמשתמשים במאפייני CSS שמשפיעים על הפריסה
- FID
- הימנעות ממשימות ארוכות או פיצול שלהן
- הימנעות משימוש ב-JavaScript מיותר
- הימנעות מעדכוני עיבוד גדולים
אפשר גם לצפות במצגת של Google I/O 2023 כדי לקבל סיכום בסרטון.