אופטימיזציה של CLS ב-1C-Bitrix: היכן האתר מאבד יציבות
היסט פריסה מצטבר ב-Bitrix כמעט תמיד מורכב ממספר מקורות חוזרים, וכל אחד מהם נראה בקוד. באנרים וסליידרים שמאותחלים לאחר טעינת התוכן הראשי תופסים גובה אפס עד לרגע החלפת התמונה — כל הבלוק שמתחת מייד זז למטה.
גופנים מותאמים אישית ללא font-display תקין יוצרים הבזק החלפה: הטקסט מצויר תחילה בגופן מערכת עם מטריקות שונות, ולאחר הטעינה מחדש מחושב מחדש ודוחף את האלמנטים הסמוכים.
בלוקים פרסומיים ופרומושניים שמוטמעים דרך קומפוננטות עם פלט מושהה מתנהגים באותו אופן: הקונטיינר מופיע ריק, ומתמלא רק לאחר הרינדור הראשון. קומפוננטות דינמיות — סל קניות, בלוק התחברות, פאנלים קופצים — בעת הידרציה משנות את הגובה של ה-DOM שכבר עובד, וגם זה נכנס להיסט המצטבר.
קטגוריה נפרדת — תמונות קטלוג ללא מידות מפורשות: הדפדפן אינו יודע את הפרופורציות לפני טעינת הקובץ ומשריין גובה שגוי.
חוסר היציבות של הממשק פוגע בדברים מדידים לחלוטין. המשתמש מפספס כפתור שזז ברגע הלחיצה — גדל שיעור הפעולות השגויות והניסיונות החוזרים. מנועי חיפוש מתייחסים להיסט הפריסה כאות לאיכות העמוד, ולכן הדירוגים יורדים גם עם תוכן ומהירות טובים.
במובייל, שבו המסך צר והבלוקים בו רבים יותר, האפקט מתגבר: באנר אחד שלא שוריין כראוי גורר אחריו את כל המסך הראשון.
מפרקים כיצד זה נסגר: מביקורת של היסטים אמיתיים בעמודים חיים ועד תיקונים בתבניות הקומפוננטות והגדרת טעינה מושהית כך שהמקום לתוכן ישוריין מראש.
מה נותנת פריסה יציבה: האפקט במספרים
יציבות הממשק מפסיקה להיות משאלה מופשטת כשמתרגמים אותה למדד היסט. הכלים מודדים עד כמה חזק האלמנטים זזים ברגע הטעינה, והמספר הזה מתואם ישירות לאופן שבו המבקר מתנהג: קפיצות חדות של באנרים, גופנים ובלוקים נתפסות כ"אתר שבור", והאדם עוזב לפני שהוא מספיק לקרוא את ההצעה.
בפועל, לאחר קיבוע גדלי הקונטיינרים, המדדים הטיפוגרפיים והמקום לבלוקים דינמיים, מדד ההיסט יורד מ-0,25–0,4 לערכים מתחת ל-0,1 — זהו הסף שבו התזוזות כבר אינן מפריעות לאינטראקציה.
השימור בעמודים המרכזיים עולה ב-10–20%, כי המבקר לא מאבד את מיקום הלחיצה: הכפתור והטופס נשארים במקום שבו הוא ראה אותם.
אפקט נפרד הוא ההמרה. כשהאלמנט לא "בורח" מתחת לסמן, שיעור הלחיצות השגויות והניסיונות החוזרים יורד, והפעולה הרצויה מבוצעת בניסיון הראשון. זה מורגש בטפסי בקשות ובעגלת הקניות, שבהם קודם לכן חלק מהמשתמשים פספסו את הכפתור הנכון.
גם העומס על התמיכה יורד: פניות טיפוסיות כמו "אני לא מצליח ללחוץ", "הכול קופץ בטלפון" נעלמות, כי הסיבה לא הייתה במכשיר של הלקוח, אלא בפריסה לא יציבה. נבחן כיצד זה נסגר ברמת התבניות וההגדרות.
גישות לתיקון היסטים: השוואת אפשרויות
היסט נוצר במקום שבו הדפדפן לומד על הבלוק רק לאחר הרינדור הראשון: באנר נטען, גופן הגיע, ווידג'ט ביקורות הוכנס — וכל התוכן שמתחת זינק למטה.
מדד CLS אינו סופר את עצם השינוי, אלא את מכפלת חלק המסך שהוסט במרחק ההיסט, ולכן בלוק גדול אחד במסך הראשון פוגע במדד חזק יותר מעשרה תיקונים קטנים בתחתית. להלן ארבע גישות אשר בפרויקטים של 1C-Bitrix מכסות מחלקות שונות של סיבות.
השוואת שיטות
| גישה | מתי מתאימה | מגבלות |
|---|---|---|
| שריון מקום | באנרים, כרטיסי קטלוג, בלוקים בגובה ידוע | נדרשים פרופורציות מדויקות; בפריסה אדפטיבית הגובה נקבע באמצעות יחס גובה-רוחב |
| טעינה מוקדמת של משאבים | גופנים, לוגו, תמונת המסך הראשון | עוזר רק כאשר כתובת המשאב יציבה; בהחלפה דרך סקריפט האפקט אובד |
| רינדור מושהה | ווידג'טים, צ'אטים, בלוקי המלצות, הטמעות צד שלישי | דורש מכולה משוריינת, אחרת ההיסט פשוט עובר למטה |
| תיקון תבניות | רכיבים עם פלט דינמי, מטמון, lazy-load בתבניות | יקר יותר במשאבי עבודה, אך מסיר את הסיבה ולא את התוצאה |
בפועל השיטות משולבות: תחילה משוריין מקום למדיה ולווידג'טים, לאחר מכן נטענים מראש משאבים קריטיים, ובלוקים כבדים של צד שלישי מועברים לרינדור מושהה. תיקון תבניות ידני מחובר נקודתית — במקום שבו הרכיב מחזיר סימון שונה במטמון חם ובמטמון קר.
מה נותן כל שלב
שריון מקום מסיר את עיקר ההיסטים במסך הראשון ואינו דורש כתיבה מחדש של לוגיקת הרכיבים. טעינה מוקדמת מקצרת את החלון שבו הגופן או הלוגו מחליפים בלוק שכבר רונדר. רינדור מושהה מבודד הטמעות צד שלישי שאיננו שולטים בהן. תיקון תבניות סוגר את השארית — היסטים שאינם נתפסים באף אחת משלוש השיטות הראשונות.
סדר היישום תלוי בכך אילו בלוקים תורמים למדד: תחילה נוטלים מדידות לפי עמודים, לאחר מכן בוחרים שיטה לכל קבוצת סיבות.
כיצד אנו מיישמים אופטימיזציה של CLS: שלבי העבודה
אופטימיזציה של CLS אינה "לתקן כמה תמונות", אלא רצף שבו כל שלב נשען על המדידה של השלב הקודם. איננו נוגעים בקוד הפריסה עד שאיננו רואים את מקורות התזוזה האמיתיים בעמודים וברזולוציות ספציפיים: הסיבות במחשב ובמובייל כמעט תמיד שונות.
- ביקורת פריסה. משרטטים מפה של תבניות ורכיבים: היכן התוכן נטען באופן אסינכרוני, היכן בלוקים מוכנסים באמצעות סקריפטים, אילו באנרים ווידג'טים שומרים מקום ואילו לא. בנפרד בוחנים עמודים עם מסננים דינמיים וסל קניות.
- מדידת מדדים. קובעים את ערך הבסיס של CLS לפי קבוצות עמודים — דף הבית, קטלוג, כרטיס מוצר, השלמת הזמנה. המדידות נעשות בתנאי טעינה אמיתיים, ולא על מטמון ריק, אחרת התמונה מעוותת.
- איתור הסיבות. משווים את התזוזות לרכיבים ספציפיים: תמונות ללא פרופורציות מוגדרות, גופנים עם החלפה, בלוקים של המלצות שנטענים באיחור, באנרים קופצים. הסיבה נרשמת עם שיוך לתבנית, ולא "איפשהו בעמוד".
- הגדרת תבניות. שומרים מקום למדיה ול�بلוקים פרסומיים, מגדירים פרופורציות למכולות, מעבירים סגנונות קריטיים לרינדור הראשון, מייצבים את טעינת הגופנים והמקטעים הדינמיים. התיקונים מבוצעים בתבניות הרכיבים, כדי שיורשו לכל העמודים במדור.
- בדיקת התוצאה. חוזרים על המדידה לפי אותן קבוצות עמודים ותרחישים. משווים לפני/אחרי, בודקים שהתיקונים לא שברו את הרספונסיביות ולא הרעו מדדי טעינה אחרים.
- תיעוד. מעבירים רשימה של תבניות ששונו, כללים לסימון מדיה וצ'ק-ליסט למנהלי תוכן — כדי שבאנר או בלוק חדש לא יחזירו את התזוזות בחזרה.
סדר פעולות כזה נותן תוצאה צפויה: התזוזה נעלמת לא בעמוד אחד, אלא בכל התבנית, ונשארת ניתנת לניהול בעת תיקוני תוכן עתידיים.
מה הלקוח מקבל לאחר אופטימיזציה של CLS
לאחר עבודות ה-CLS אצל הלקוח נשאר לא "הפך למהיר יותר", אלא סט שלם של ארטיפקטים, שמהם רואים בדיוק מה השתנה ואיך לשמור על כך בהמשך. להלן — מה שאנחנו מוסרים בסיום.
- תבניות ורכיבים מתוקנים. התיקונים בוצעו בקוד המקור, ולא מעליו: לתמונות ולסרטונים הוגדרו מידות מפורשות, עבור באנרים וסליידרים הוקצו מכולות, הגופנים חוברו כך שלא יגרמו לציור מחדש של הטקסט. כל שינוי מקושר למקום ספציפי בעמוד.
- קונפיגורציות והגדרות תצוגה. מטמון רכיבים, טעינה נדחית של בלוקים מתחת למסך הראשון, סדר חיבור הסגנונות — מקובעים בהגדרות, כדי שהתיקונים לא יאבדו בעדכון התוכן הבא.
- דוח מדידות. צילומי מדדים לפני ואחרי לפי תבניות מרכזיות: דף הבית, כרטיס מוצר, קטלוג, טפסים. ניתן לראות אילו אלמנטים יצרו את התזוזה ובכמה היא ירדה.
- רשימת סיבות אופייניות לתזוזה. רשימה קצרה לעורכים: הוספת תמונה ללא מידות, באנר ללא גובה מוקצה, ווידג'ט צד שלישי בזרימה. כדי שחומרים חדשים לא יחזירו את הבעיה.
- נהלי תמיכה. מה בודקים בכל שחרור ועדכון תוכן, אילו מדדים נשמרים בטווח התקין, מי אחראי לבדיקה לפני פרסום.
- תיעוד התבניות. היכן במבנה נמצאים הבלוקים הקריטיים, אילו מאפיינים הם חובה, ומה אסור לשנות ללא בנייה מחדש של הפריסה.
- צ'ק-ליסט קבלה. מעבר על העמודים לפני מסירה: מידות, הקצאת מקום, גופנים, בלוקים מוטמעים — כדי שהתוצאה תאושר על ידי מדידה, ולא לפי העין.
סט כזה מאפשר לצוות הלקוח לבדוק באופן עצמאי עמודים חדשים ולא לחזור למצב ההתחלתי כעבור חודש. תארו את המשימה — נחזור עם הערכה ותוכנית לפי התבנית שלכם.
מקרה בוחן: איך הסרנו את קפיצות הפריסה בפורטל
הפורטל של הלקוח — אתר ארגוני על 1C-Bitrix עם קטלוג, אזור אישי וטופס בקשה בכל עמוד. הבעיה באה לידי ביטוי במובייל: בעת הטעינה הבאנר זינק, כרטיסי המוצרים זזו מטה, וכפתור "השאר בקשה" חמק מתחת לאצבע.
מדד ה-CLS נשמר בסביבות 0.34 בעוד הסף של "טוב" הוא עד 0.1 — המשתמשים פספסו את הכפתורים ועזבו.
מה היה לפני
מקורות התזוזה העיקריים: תמונות הקטלוג והבאנרים הוצגו ללא פרופורציות קבועות, ולכן הדפדפן לא ידע את מידותיהם לפני הטעינה. הגופנים חוברו ללא שריון מקום למטריקות, ובגלל זה הטקסט צויר מחדש לאחר ההחלפה. בלוק ההמלצות וההתראה הקופצת על קובצי Cookie הוכנסו לזרימה כבר לאחר הציור — התוכן שמתחתיהם זז מטה.
מה שינינו
הגדרנו לקונטיינרים של התמונות והבאנרים פרופורציות מפורשות באמצעות CSS, כדי שהמקום יושריין לפני טעינת הקבצים. לגופנים הגדרנו מטריקות של גופן חלופי — ההחלפה הפסיקה להזיז שורות.
התראת ה-Cookie ובלוק ההמלצות הוצאנו מהזרימה לשכבות קבועות, ואת ההכנסות הדינמיות בקטלוג העברנו לשריון גובה הקונטיינר.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| CLS (מובייל) | 0.34 | 0.06 |
| CLS (דסקטופ) | 0.18 | 0.04 |
| שיעור הפספוסים ב-CTA | גבוה | בודדים |
| עומק הצפייה | בסיסי | עלייה |
יציבות הפריסה חזרה לאזור ה"ירוק", וההמרה של טופס הבקשה עלתה — המשתמשים הפסיקו ללחוץ על הכפתור הלא נכון.
הלקוח, ראש תחום: "קפיצות הפריסה עצבנו גם אותנו וגם את המבקרים. אחרי התיקונים העמודים הפסיקו לרעוד, והבקשות זרמו בצורה אחידה יותר — העבודה עם הטופס כבר לא מבלבלת".
במה שונה CLS ממדדי יציבות אחרים?
CLS מודד לא מהירות, אלא יציבות הפריסה: עד כמה חזק האלמנטים זזים ברגע הטעינה. מדדי הזמן — LCP ו-INP — עונים על השאלה "כמה מהר", ואילו CLS עונה על "כמה צפוי".
המשתמש יכול לקבל את הדף בשברירי שנייה, אבל אם באנר, גופן או בלוק המלצות הזיז את הטקסט למטה בדיוק ברגע הלחיצה, הוא יפגע באצבע במקום הלא נכון. בדיוק את סוג התקלות הזה CLS תופס.
מבחינה טכנית המדד מחושב כסכום ההזזות של אלמנטים נראים לעין, משוקללים לפי שטח ולפי מרחק ההיסט, לאורך כל חיי הדף. הזזה שמתרחשת במילישניות הראשונות, לפני הופעת התוכן, אינה נענשת — הדפדפן מחשיב אותה כצפויה.
מה שכן נענש הוא מה שהמשתמש כבר רואה והתחיל לקרוא: טעינה נוספת של גופן ווב, שבגללה הטקסט קופץ לגופן אחר, הכנסה של בלוק פרסומי ללא גובה שמור מראש, "קפיצה" של כפתור בזמן טעינת אייקונים.
ההבדל המרכזי ממדדי המהירות הוא בטבע הבעיה. LCP ו-INP משתפרים באמצעות האצה: מטמון, דחיסה, סדרי עדיפויות בטעינה.
CLS כמעט תמיד נרפא לא באמצעות מהירות, אלא באמצעות משמעת בפריסה: מידות מפורשות לתמונות ול�บลוקים מוטמעים, font-display וטעינה מוקדמת של גופנים, שמירת מקום להכנסות דינמיות.
ב-1C-Bitrix זה בולט במיוחד: קומפוננטות ותבניות מכניסות תוכן באופן אסינכרוני לעיתים קרובות, ובלי מכולות קבועות הדף "נושם" בכל טעינה נוספת.
מבחינת התפיסה ההבדל עקרוני. דף איטי אך יציב מעצבן בהמתנה, ואילו דף מהיר אך "מקפץ" — בתחושת חוסר אמינות: המשתמש לא נותן אמון בממשק ועוזב, עוד לפני שהבין שהוא היה מהיר. לכן CLS מוערך בנפרד מהמהירות ומתוקן בשיטות נפרדות — על כך בהמשך.
ספקות טכניים נפוצים לגבי אופטימיזציה של CLS
לפני שמתחילים חשוב להפריד בין שני סוגים של הזזות: אלו שנוצרות על ידי הסימון (תמונות ובאנרים ללא מידות שמורות, גופנים עם החלפת סגנון, בלוקים שמצוירים על ידי סקריפט), ואלו שמגיעים מרכיבים דינמיים. הראשונים מתוקנים בתבנית ובסגנונות, השניים — בהגדרת פלט מושהה ומטמון שרת. בביטריקס לרוב מפריעים דווקא השניים: הרכיב מחזיר תוכן לאחר הטעינה, והמקום עבורו אינו שמור.
תאימות עם התבנית הנוכחית נבדקת לפני התיקונים: מבצעים מדידה לפי תבניות העמודים המרכזיות, מתעדים אילו בלוקים תורמים להזזה, ורק לאחר מכן נוגעים בסימון. אם האתר על מטמון מורכב, התיקונים מבוצעים כך שלא לשבור את המטמון ולא לאלץ את העמוד להיבנות מחדש בכל בקשה.
התיקונים ישפיעו על מדדים אחרים — מהירות טעינה, ציור?
שמירת מקום עבור תמונות ובלוקים בדרך כלל משפרת גם את שאר המדדים: הדפדפן מבין מוקדם יותר את מבנה העמוד ואינו בונה אותו מחדש. הסיכון הפוך — אם לשמור יותר מדי מקום, ייווצרו אזורים ריקים.
לכן את המידות לוקחים מהפרופורציות האמיתיות של התוכן, ולא «לפי העין», ובודקים בנפרד בפריסה לנייד ולמחשב שולחני.
כמה זמן לוקחת העבודה והאם אפשר לעשות בשלבים?
תחילה מתבצעת מדידה וניתוח הסיבות, לאחר מכן תיקונים בבלוקים ה«כבדים» ביותר, ואז מדידה חוזרת והשלמת השאר. שלביות כאן מועילה: כבר לאחר הגל הראשון של התיקונים עיקר ההזזה נעלם, ואת השאר אפשר לסגור מבלי לעצור את האתר. לוחות הזמנים המדויקים תלויים במספר התבניות והבלוקים הדינמיים — אותם מחשבים לאחר הניתוח.
מה עם התמיכה לאחר האופטימיזציה?
המדד יכול «לזוז» לאחר עדכון התבנית, הוספת באנר חדש או החלפת ספק הווידג'טים. לכן במסירה נכלל צ'ק-ליסט קצר עבור מנהל התוכן והמפתח: אילו מאפיינים חובה בתמונות, כיצד להוסיף בלוקים מבלי ליצור הזזה. במסגרת הליווי אנו חוזרים למדידה לאחר שינויים משמעותיים בפריסה.
נדון במשימה שלכם לייצוב הפריסה
יציבות הפריסה היא דבר שנראה רק במכשירים אמיתיים ובתעבורה אמיתית. תארו היכן בדיוק התוכן "קופץ": בכרטיס מוצר, ברשימת חדשות, בעמוד עם בלוקים דינמיים או בעת טעינת באנרים. ככל שהסימפטום ספציפי יותר — כך נזהה בצורה מדויקת יותר את מקור ההיסט ולא נעבור על הכול באופן אקראי.
כדי לחזור עם הערכה ותוכנית עבודה, מועיל לנו להבין את ההקשר:
- אילו תבניות ורכיבים מעורבים בעמודים הבעייתיים;
- כיצד מוצגים תמונות ומדיה — האם מידות המיכלים מוגדרות מראש;
- האם יש בלוקים הנטענים באופן דינמי, באנרים, אלמנטים קופצים;
- כיצד מתנהגת הפריסה במכשירים ניידים ובחיבור איטי;
- אילו מדדים אתם כבר אוספים ובאילו תנאים;
- האם יש מגבלות זמנים לשחרור התיקונים לפרודקשן;
- מי מצד הלקוח מקבל את התוצאה ובודק את היציבות.
לפי נתוני פתיחה אלה נבנה תוכנית: היכן מספיק לקבע מידות מיכלים, היכן יהיה צורך לעבד מחדש את סדר הצגת הרכיבים, והיכן — לבחון מחדש את לוגיקת הטעינה. ההערכה תהיה קשורה לעמודים ולתבניות ספציפיים, ולא ל"נ�Optimizציה של הכול" מופשטת.
תארו את המשימה שלכם — נחזור עם הערכה ותוכנית עבודה לייצוב הפריסה.