Core Web Vitals באלמנטור: למה כולם נכשלים, ואיך אנחנו עוברים 90+ במובייל

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

אנחנו מהנדסים אתרים שעוברים את הסף של Google במובייל, על אלמנטור פרו, בלי לשכתב את האתר מאפס. המאמר הזה הוא בדיוק מה שאנחנו עושים — לפי הסדר, עם המספרים.

קודם כל: מה Google בעצם מודד

לפני שנוגעים בקוד, צריך להבין שיש שני עולמות נפרדים ורוב האנשים מבלבלים ביניהם:

• Lab Data — הסימולציה שרצה ב-PageSpeed Insights או ב-Lighthouse. זה מה שנותן לך את "הציון" הצבעוני מ-0 עד 100. זה כלי אבחון, לא מדד דירוג.
• Field Data (CrUX) — נתונים אמיתיים ממשתמשי Chrome אמיתיים שגלשו באתר שלך ב-28 הימים האחרונים. זה מה ש-Google משתמש בו כאות דירוג.

שלושת המדדים שמרכיבים את Core Web Vitals, והספים הרשמיים של Google למעבר:

• LCP (Largest Contentful Paint) — מתי נצבע האלמנט הגדול ביותר במסך הראשון. יעד: מתחת ל-2.5 שניות.
• INP (Interaction to Next Paint) — כמה זמן לוקח לדף להגיב לאינטראקציה. החליף רשמית את FID במרץ 2024. יעד: מתחת ל-200ms.
• CLS (Cumulative Layout Shift) — כמה הפריסה "קופצת" תוך כדי טעינה. יעד: מתחת ל-0.1.

שים לב: הסף נמדד ב-אחוזון ה-75 של המשתמשים. כלומר גם אם 70% מהגולשים שלך מקבלים חוויה מצוינת — אתה עדיין נכשל. זה מדד שנבנה במכוון סביב המשתמש הגרוע, לא הממוצע.

ציון 100 במחשב עם אתר שנתקע במובייל הוא לא הישג. זו הונאה עצמית מעוצבת יפה.— RAMS Studio

מה באמת הורג ביצועים באלמנטור

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

1. עודף DOM — המחלה המובנית של Page Builders

כל Section באלמנטור עוטף Container, שעוטף Column, שעוטף Widget Wrapper, שעוטף את התוכן. ארבע שכבות DIV כדי להציג כותרת אחת. דף נחיתה "פשוט" באלמנטור מגיע בקלות ל-2,000+ אלמנטים ב-DOM. הדפדפן צריך לחשב Layout ו-Paint לכל אחד מהם.

הפתרון הראשון והחשוב ביותר: Flexbox Containers במקום Sections/Columns. זה לא עניין של טעם — זה חותך בין 30% ל-50% מעומק ה-DOM. באתרים שאנחנו בונים מאפס, Sections לא קיימים. נקודה.

2. Render-Blocking CSS בהיקף אבסורדי

אלמנטור, בברירת מחדל, טוען את כל קובצי ה-CSS שלו לכל הווידג'טים — גם לאלה שלא בשימוש בדף הנוכחי. תוסיף לזה Font Awesome (גם אם השתמשת באייקון אחד), את eicons, ואת קובץ ה-CSS של התבנית, ואתה בקלות ב-400KB של CSS חוסם רינדור לפני שהמשתמש ראה פיקסל אחד.

3. jQuery ו-Swiper שנטענים בכל דף

אלמנטור עדיין נשען על jQuery. ספריית Swiper (הקרוסלות) נטענת גם בדפים שאין בהם קרוסלה. זה JavaScript שצריך להוריד, לפרסר ולהריץ — וכל מילישנייה של פרסור ב-Main Thread נזקפת ישירות לחובת ה-INP שלך.

4. תמונות שלא הותאמו

הקלאסיקה. תמונת Hero ברוחב 2400px נטענת במכשיר שהוויופורט שלו 390px. WordPress אמנם מייצר srcset, אבל רק אם התמונה הועלתה נכון — ובמסך Hero שמוגדר כ-Background Image ב-CSS, אין srcset בכלל. הדפדפן מוריד את המקור המלא.

5. תוספים מצטברים

כל תוסף מוסיף בממוצע קובץ CSS אחד ו-JS אחד לכל דף. עשרים תוספים = ארבעים בקשות HTTP נוספות. זה לא ליניארי — זה מצטבר לחנק של Main Thread.

LCP: הקרב על 2.5 שניות

ב-95% מאתרי האלמנטור שבדקנו, אלמנט ה-LCP הוא אותו אלמנט: תמונת הרקע של ה-Hero, או כותרת ה-H1. ברגע שאתה יודע את זה, הטיפול הופך כירורגי.

מה שאנחנו עושים, לפי סדר העדיפות:

1. מוציאים את ה-Hero מ-Lazy Load. תוספי אופטימיזציה מחילים lazy loading גורף. על תמונת ה-Hero זה אסון — אתה מוסיף מחזור רינדור שלם לפני שהתמונה בכלל מתחילה לרדת. בכל אתר שלנו יש חוק: התמונה הראשונה בדף לעולם לא lazy.
2. Preload מפורש. <link rel="preload" as="image" fetchpriority="high"> על תמונת ה-LCP. ב-Hero של Background Image זה קריטי, כי הדפדפן מגלה את התמונה רק אחרי שפרסר את כל ה-CSS.
3. WebP או AVIF, בגדלים נכונים. המרה ל-WebP חותכת 25-35% מהמשקל בלי הבדל ויזואלי. תמונת Hero במובייל לא צריכה לעבור 150KB.
4. Self-Hosting לפונטים + font-display: swap. פונטים עבריים כמו Heebo ו-Assistant שנטענים מ-Google Fonts יוצרים חיבור חיצוני נוסף (DNS + TLS Handshake) — 200-400ms שנזרקים לפח. אנחנו מארחים מקומית, בפורמט woff2, ומגדירים preload על המשקל היחיד שמופיע ב-Hero.
5. מכבים את Inline Font Icons ומסירים את Font Awesome כשהוא לא בשימוש אמיתי.

CLS: המדד היחיד שאפשר לאפס לחלוטין

LCP ו-INP תלויים ברשת, בשרת ובמכשיר של המשתמש. CLS תלוי רק בך. זה מדד שאפשר להביא ל-0.00 בעבודה נקייה — וכשאנחנו מקבלים אתר עם CLS של 0.4, זה תמיד אחד מארבעת אלה:

• תמונות בלי מימדים מוצהרים. אם אין width ו-height ב-HTML (או aspect-ratio ב-CSS), הדפדפן לא יודע כמה מקום לשריין — והתוכן קופץ כשהתמונה נוחתת.
• Sticky Header שנכנס לתוקף אחרי טעינת ה-JS. אלמנטור מוסיף את מחלקת ה-sticky דינמית. בלי padding-top מוגדר מראש על ה-body, כל הדף מזנק מעלה.
• אנימציות Entrance על אלמנטים מעל הקיפול. Fade-In-Up על ה-Hero מייצר Layout Shift ישיר. אנחנו פשוט לא משתמשים באנימציות כניסה מעל הקיפול — ומתחת לקיפול משתמשים רק ב-transform ו-opacity, שרצים ב-Compositor ולא נוגעים ב-Layout.
• החלפת פונט (FOUT). כשפונט המערכת מוחלף ב-Heebo, רוחב התווים משתנה והטקסט מסדר את עצמו מחדש. הפתרון: preload על הפונט הקריטי, ו-size-adjust בהגדרת ה-fallback.

מה עשינו באתר שלנו

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

שלב א' — ניקוי. מיפינו כל תוסף מול הערך שהוא מספק. שבעה תוספים ירדו. זה לבדו הוריד 180KB של JS ו-CSS מכל דף.

שלב ב' — המרה ל-Containers. כל ה-Sections הישנים הוחלפו ב-Flex Containers. עומק ה-DOM בדף הבית ירד מ-1,900 אלמנטים לאזור ה-1,100.

שלב ג' — CSS גלובלי במקום Elementor UI. במקום להגדיר ריווח, טיפוגרפיה ואפקטים בכל ווידג'ט בנפרד (מה שמייצר CSS מוטבע ייחודי לכל אלמנט), הגדרנו מערכת CSS גלובלית עם משתנים. פחות קוד, יותר עקביות, ותחזוקה שלא דורשת לפתוח את העורך.

שלב ד' — שכבת ביצועים. Object Cache, Page Cache, Critical CSS מוטבע, דחיית JS לא-קריטי, ו-CDN. חשוב: הפעלנו כל שכבה בנפרד ומדדנו. ההבדל בין "הפעלנו הכל בבת אחת ומשהו נשבר" לבין "אנחנו יודעים בדיוק מה עשה מה" הוא כל ההבדל.

שלב ה' — מדידה בשטח, לא במעבדה. חיברנו מעקב CWV אמיתי והמתנו 28 יום לנתוני CrUX. Lighthouse סימן ירוק הרבה לפני שהשדה סימן ירוק. השדה הוא זה שקובע.

שלוש טעויות שחוזרות אצל כולם

מרדף אחרי 100. ההבדל בין 92 ל-98 הוא שעות עבודה שלא מזיזות שקל בהכנסות. ההבדל בין 40 ל-85 הוא שינוי בשיעור הנטישה. תדע איפה עקומת התשואה נשברת.

בדיקה רק בדסקטופ. Google מדרג לפי אינדקס Mobile-First. אם לא בדקת מובייל, לא בדקת.

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

ביצועים הם לא תוסף שמתקינים בסוף. הם החלטת עיצוב שמקבלים בהתחלה.— RAMS Studio

שורה תחתונה

אלמנטור לא מונע ממך להגיע ל-90+ במובייל. מה שמונע זה תהליך בנייה שלא לקח ביצועים בחשבון — ואז ניסיון לתקן את זה בדיעבד עם תוסף. הפתרון הוא סדר פעולות: DOM רזה, CSS קריטי בלבד, JS נדחה, תמונות מותאמות, ומדידה בשדה ולא במעבדה.

אתר מהיר הוא לא פרויקט טכני. הוא החלטה עסקית — כי כל שנייה של המתנה היא גולש שלא יראה את מה שיש לך להציע.