אם פתחתם את דוח Core Web Vitals ב-Google Search Console וראיתם כתמים אדומים, הגעתם למקום הנכון. שלושת המדדים האלה, LCP, CLS ו-INP, הם הדרך שבה גוגל מודדת את חוויית המשתמש בפועל באתר שלכם, והם משפיעים גם על הדירוג. במאמר הזה נסביר מה כל מדד מודד, איך לקרוא את המספרים נכון, ואיך מתקנים כל אחד מהם בוורדפרס בצורה מסודרת.

מה זה Core Web Vitals ולמה זה חשוב

Core Web Vitals הם שלושה מדדים שגוגל הגדירה כדי לכמת את חוויית הטעינה והאינטראקטיביות של דף אינטרנט. הם חלק מאות הדירוג של "חוויית עמוד" (Page Experience), כלומר הם לא הגורם היחיד לדירוג, אבל הם כן משפיעים, ובעיקר משפיעים על שיעור הנטישה: דף איטי או "קופצני" מאבד מבקרים עוד לפני שהם רואים את התוכן.

שלושת המדדים הם:

  1. LCP (Largest Contentful Paint) - מהירות הטעינה של האלמנט הגדול ביותר בדף.
  2. CLS (Cumulative Layout Shift) - יציבות חזותית, כמה הדף "קופץ" בזמן הטעינה.
  3. INP (Interaction to Next Paint) - תגובתיות, כמה מהר הדף מגיב לאינטראקציה של המשתמש.

ב-מרץ 2024 גוגל החליפה את המדד הישן FID במדד INP, שמודד תגובתיות בצורה מקיפה יותר. אם אתם עדיין מסתכלים על FID, זה מידע מיושן.

איך מודדים נכון (Field Data מול Lab Data)

לפני שמתקנים, חשוב להבין שיש שני סוגי נתונים, וזו אחת הסיבות הנפוצות לבלבול:

  • Field Data (נתוני שטח) - נתונים אמיתיים שנאספו ממשתמשים אמיתיים (מבסיס הנתונים CrUX). זה מה שגוגל משתמשת בו בפועל בדוח Search Console, והוא נמדד באחוזון ה-75 של המבקרים. כלומר, המדד "עובר" רק אם 75% מהביקורים היו בטווח הטוב.
  • Lab Data (נתוני מעבדה) - בדיקה חד-פעמית מסביבה מבוקרת, כמו Lighthouse או הציון של PageSpeed Insights. שימושי לאיתור בעיות, אבל לא משקף בהכרח את החוויה האמיתית.

הכלים העיקריים: PageSpeed Insights (מציג גם שטח וגם מעבדה), Search Console (דוח Core Web Vitals ברמת האתר) ו-Lighthouse בכלי המפתחים של הדפדפן. הכלל המנחה: תקנו לפי נתוני השטח, אבל אבחנו את הסיבות עם נתוני המעבדה.

תיקון LCP - הטעינה איטית

הסף: LCP נחשב טוב עד 2.5 שניות, דורש שיפור בין 2.5 ל-4 שניות, וגרוע מעל 4 שניות.

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

  • תמונות כבדות ולא דחוסות. דחסו והמירו תמונות לפורמט WebP, והגדירו width ו-height מפורשים. תמונת ה-hero לא צריכה להיות "lazy load", להפך, כדאי לתת לה עדיפות טעינה.
  • זמן תגובת שרת איטי (TTFB). אחסון משותף זול, היעדר caching ברמת השרת או תוסף כבד יכולים להאט את הבייט הראשון. caching ברמת עמוד (כמו WP Rocket או LiteSpeed Cache) ו-CDN משפרים זאת משמעותית.
  • CSS ו-JavaScript חוסמי-רינדור. קבצים שנטענים לפני התוכן מעכבים את ה-LCP. דחיית סקריפטים לא קריטיים והקטנת ה-CSS עוזרים.

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

תיקון CLS - הדף קופץ

הסף: CLS נחשב טוב עד 0.1, דורש שיפור בין 0.1 ל-0.25, וגרוע מעל 0.25.

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

  • תמונות בלי מימדים. בלי width ו-height הדפדפן לא יודע כמה מקום לשמור, והתוכן קופץ כשהתמונה נטענת. הגדרת מימדים פותרת את רוב המקרים.
  • גופנים שנטענים מאוחר (FOIT/FOUT). טעינת גופן שמחליפה גופן ברירת מחדל מזיזה טקסט. שימוש ב-font-display: swap עם גופן רזרבי בגודל דומה מצמצם זאת.
  • תוכן מוזרק דינמית. באנרים, הודעות קוקיז, פרסומות ו-embeds שנדחפים מעל התוכן. הקצו להם מקום קבוע מראש.

תיקון INP - האתר מגיב לאט

הסף: INP נחשב טוב עד 200 מילישניות, דורש שיפור בין 200 ל-500, וגרוע מעל 500 מילישניות.

INP מודד כמה זמן עובר מרגע שמשתמש מבצע אינטראקציה (לחיצה, הקלדה, נגיעה) ועד שהדף מגיב חזותית. בוורדפרס האשם המרכזי כמעט תמיד הוא עומס JavaScript: יותר מדי תוספים שמריצים סקריפטים, builders כבדים, וסקריפטים של צד-שלישי (צ'אטים, פיקסלים, אנליטיקס).

הכיוונים לטיפול:

  1. הפחתת תוספים מיותרים. כל תוסף שמוסיף JS לפרונט מגדיל את העומס. בדקו מה באמת בשימוש.
  2. דחייה ופיצול של סקריפטים. טעינת JS לא קריטי בעיכוב או בעת אינטראקציה במקום בטעינה הראשונית.
  3. ריסון סקריפטים של צד-שלישי. הם רצים ב-thread הראשי וחוסמים תגובתיות. טענו אותם בעצלות במידת האפשר.

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

למה זה לא נגמר בתיקון חד-פעמי

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

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

שאלות נפוצות

האם ציון 100 ב-PageSpeed Insights הכרחי? לא. הציון הוא נתון מעבדה. מה שקובע לדירוג הוא נתוני השטח (Field Data) שעוברים את הסף ב-LCP, CLS ו-INP. ציון 90 עם נתוני שטח ירוקים עדיף על ציון 100 עם נתוני שטח אדומים.

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

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

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

רוצים שמישהו יבדוק למה הדוח שלכם אדום ויתקן בלי לשבור את האתר? דברו איתנו ב-OCW ונעשה בדיקת ביצועים ונבנה תוכנית תיקון ל-LCP, CLS ו-INP.