כנראה שהרגשתם את זה עוד לפני שידעתם איך קוראים לתופעה. אתם הולכים ללחוץ על כפתור בדף, ובדיוק כשהאצבע נוגעת במסך, מודעה נטענת מעליו ודוחפת את הכל למטה. אתם מוצאים את עצמכם לוחצים על הדבר הלא נכון. הקפיצה המעצבנת הזו נקראת Cumulative Layout Shift, או CLS, וזה אחד משלושת ה-Core Web Vitals שאיכות האחסון משפיעה עליהם באופן ישיר.
רוב האנשים מתייחסים ל-CLS כאל בעיה שקשורה רק לצד הלקוח: CSS גרוע, חוסר במימדי תמונה, מיקום מודעות רשלני. כל זה נכון. אבל יש כאן גם סיפור שקשור לשכבת האחסון, וזה סיפור שכמעט אף אחד לא מספר.
מה בעצם Cumulative Layout Shift מודד
ה-CLS מודד כמה תוכן גלוי זז באופן בלתי צפוי בזמן טעינת הדף. גוגל מחשבת את זה על ידי הכפלה של שבר ההשפעה (כמה מהמסך הנראה זז) בשבר המרחק (כמה רחוק זה זז). מוסיפים את כל התזוזות הבלתי צפויות שקורות במהלך חיי הדף, ומקבלים את הציון.
- טוב: מתחת ל-0.1
- דורש שיפור: 0.1 עד 0.25
- גרוע: מעל 0.25
כל דבר מעל 0.1 מספיק בולט כדי להרגיז משתמשים אמיתיים, וגוגל מתייחסת לזה כאל גורם דירוג במסגרת של Core Web Vitals באחסון וחוויית הדף.
החשודים הרגילים (סיבות מצד הלקוח)
לפני שנעבור לאחסון, בואו נכסה את הקלאסיקות, כי הן עדיין אחראיות לרוב בעיות ה-CLS:
- תמונות וסרטונים בלי מימדי width ו-height מפורשים
- מודעות, embeds ו-iframes שמוזרקים בלי מקום שמור מראש
- גופנים מהאינטרנט שמתחלפים מאוחר וגורמים לטקסט לזוז (FOIT/FOUT)
- תוכן שמוזרק דינמית מעל תוכן קיים, כמו באנרים של עוגיות או פסי פרסום
לתקן את זה פשוט. תמיד קבעו מימדים למדיה:
<img src="hero.jpg" width="1200" height="600" alt="Product photo">או השתמשו בגישת ה-CSS המודרנית עם aspect-ratio, כך שהדפדפן שומר מקום עוד לפני שהתמונה בכלל נטענת:
img { aspect-ratio: 16 / 9; width: 100%; height: auto; }איפה סביבת האחסון שלכם נכנסת לתמונה
הנה החלק שמפתיע אנשים: שרת איטי או לא עקבי לא רק מעכב את הדף שלכם, הוא גם יוצר באופן פעיל יותר הזדמנויות לתזוזות בפריסה.
זמן תגובה איטי מרחיב את חלון התזוזה
CLS לא נמדד ברגע אחד, הוא מצטבר לאורך כל תהליך הטעינה. ככל שהשרת שלכם לוקח יותר זמן להגיב, כך גדל החלון שבו גופנים, תמונות וסקריפטים של צד שלישי יכולים להיכנס בהדרגה ולהזיז דברים. שרת עם TTFB של 200 מילישניות נותן לדף שלכם רצף טעינה הרבה יותר צפוי מאשר שרת שנמצא סביב 1.2 שניות. כיסינו את הקשר הזה בעומק רב יותר במאמר למה זמן התגובה הראשוני שלכם עולה לכם בהמרות.
זמני תגובה לא עקביים יוצרים רינדור בלתי צפוי
הנקודה הזו עדינה. אם זמן התגובה של השרת שלכם משתנה בצורה קיצונית בין בקשה לבקשה (נניח 150 מילישניות בטעינה אחת ו-900 מילישניות בטעינה הבאה בגלל תחרות על משאבים בשרת משותף עמוס), ה-CSS הקריטי והגופנים שלכם מגיעים בנקודות זמן שונות ביחס ל-HTML. חלק מהמבקרים מקבלים רינדור נקי. אחרים מקבלים דף שמתרנדר מוקדם, ואז קופץ כשגיליון הסגנונות סוף סוף מגיע. סוג כזה של שונות הוא סימפטום קלאסי של בעיות "שכן רועש" באחסון משותף או באחסון שנמכר יתר על המידה.
מטמון בצד השרת ואספקה יציבה
כשדפים מוגשים ממטמון מהיר ועקבי במקום להיבנות מחדש מאפס בכל בקשה, המשאבים מגיעים בסדר הרבה יותר צפוי. העקביות הזו חשובה ל-CLS יותר משאנשים חושבים. אם אתם מריצים אתר מבוסס מסד נתונים, שילוב של מטמון דפים עם מטמון אובייקטים כמו Redis מחליק את חוסר היציבות במהירות שבה ה-HTML שלכם מורכב מלכתחילה, מה שמשמר את כל ציר הזמן של הרינדור יציב. כתבנו מדריך מלא על הגדרת מטמון Redis בלי לשבור שום דבר אם אתם רוצים להעמיק.
איפה השרת ממוקם גיאוגרפית
מרחק מוסיף השהיה, והשהיה מוסיפה חוסר יציבות. מבקר שנמצא במרחק של 10,000 קילומטרים מהשרת שלכם צפוי לחוות טעינת משאבים מושהית יותר ממבקר שנמצא במרחק 150 קילומטרים, וההשהיה הזו יכולה להיות ארוכה בדיוק מספיק כדי שאלמנט שגורם לתזוזת פריסה ייטען אחרי הציור הראשוני. זו עוד סיבה לכך שמיקום האחסון משפיע על זמן התגובה של השרת יותר משאנשים מניחים.
תיקונים מעשיים שמשלבים את שתי השכבות
1. טענו מראש את אלמנט התוכן הגדול ביותר
אם אתם יודעים מה האלמנט של ה-Largest Contentful Paint שלכם (בדרך כלל תמונת hero או כותרת), טענו אותו מראש כדי שלא יתחרה עם משאבים אחרים על רוחב פס:
<link rel="preload" as="image" href="hero.jpg">ב-WordPress בפרט, כלים שנבנו לניהול LCP ו-preload יכולים לעשות את זה אוטומטית בלי שתצטרכו לערוך ידנית כותרות בכל תבנית.
2. שמרו מקום עבור מודעות ו-embeds
קבעו min-height למכולות מודעות עוד לפני שסקריפט המודעה בכלל רץ. זה לבד מבטל חלק גדול מה-CLS באתרי תוכן ובלוגים.
3. השתמשו ב-font-display: swap בזהירות
זה מונע טקסט בלתי נראה אבל יכול לגרום לזזה כשהגופן האמיתי נטען. שלבו את זה עם טעינה מראש של גופנים כדי לצמצם את הפער:
<link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin>4. השיגו שליטה על זמן התגובה של השרת
הריצו כמה בדיקות עם WebPageTest או פאנל הביצועים של Chrome DevTools והסתכלו במיוחד על הפער בין תחילת הניווט לציור הראשון. אם הפער הזה לא עקבי לאורך טעינות חוזרות, הבעיה כנראה לא ב-CSS שלכם בכלל, אלא בתחרות על משאבים בשרת עצמו. בתשתית שלנו, אנחנו שומרים על משאבים מבודדים לכל חשבון כדי שעלייה בתנועה של אתר אחד לא תשבש את עקביות התגובה של אתר אחר, מה שמשמר את ציר הזמן של הרינדור (וגם את ציוני ה-CLS) צפוי.
מדידה ומעקב אחר ההתקדמות שלכם
השתמשו ב-PageSpeed Insights של Chrome או בדוח Core Web Vitals ב-Search Console כדי לקבל נתוני שדה ממבקרים אמיתיים. לבדיקות מבוקרות, Lighthouse ב-DevTools נותן לכם נתוני מעבדה שאפשר להשוות לפני ואחרי כל תיקון. עקבו אחרי CLS יחד עם TTFB ו-LCP, כי כפי שהראינו במאמר הזה, הם לעיתים רחוקות בלתי תלויים זה בזה.
לסיכום
Cumulative Layout Shift נראה כמו בעיית CSS על פני השטח, אבל התזמון של כל דבר שזז נקבע על ידי המהירות והעקביות שבה השרת שלכם מספק את הדף. תקנו קודם את הבעיות הברורות בצד הלקוח: מימדי תמונה, טעינת גופנים, מקום שמור למודעות. אחר כך תבדקו את השונות ב-TTFB ואת הגדרות המטמון שלכם, כי שרת לא יציב משאיר פחות מקום לכל תיקון אחר לעבוד.
