Core Web Vitals לוורדפרס — LCP, INP ו-CLS בשפה של בעלי אתרים
שלושת המדדים שגוגל מודדת בפועל, מה גורם לכל אחד להיכשל באתר וורדפרס, ואיך לתקן — כולל INP שהחליף את FID.
אביר
אחראי מידע ותוכן
תוכן עניינים11 פרקים
גוגל מודדת חוויית משתמש בשלושה מספרים. הם משפיעים על הדירוג, והם נמדדים ממבקרים אמיתיים — לא מסימולציה.
הבעיה היא שרוב ההסברים עליהם כתובים למפתחים. המדריך הזה מסביר מה כל מדד אומר, מה שובר אותו דווקא באתרי וורדפרס, ומה עושים.
שלושת המדדים
| מדד | מה נמדד | טוב | דורש שיפור | גרוע |
|---|---|---|---|---|
| LCP | מתי נטען האלמנט הגדול ביותר | ≤ 2.5 שנ׳ | 2.5–4.0 | > 4.0 |
| INP | כמה מהר הדף מגיב לאינטראקציה | ≤ 200ms | 200–500 | > 500 |
| CLS | כמה הדף "קופץ" בזמן טעינה | ≤ 0.1 | 0.1–0.25 | > 0.25 |
חשוב: גוגל מודדת את האחוזון ה-75. כלומר, 75% מהמבקרים חייבים לקבל תוצאה טובה. ממוצע יפה עם זנב גרוע — נכשל.
LCP — Largest Contentful Paint
מה זה
הזמן עד שהאלמנט הגדול ביותר בחלק הנראה של המסך הופיע. באתר וורדפרס זו כמעט תמיד תמונת הכותרת, או גוש הטקסט הראשי.
זהו המדד שמייצג "מתי הדף נראה טעון" מבחינת המבקר.
ממה הוא מורכב
LCP הוא סכום של ארבעה שלבים, ורובם קורים לפני שהדפדפן ראה את התמונה:
- TTFB — עד שהבייט הראשון חזר
- עיכוב טעינת המשאב — עד שהדפדפן גילה את התמונה והתחיל להוריד
- זמן ההורדה של התמונה
- זמן הרינדור
באתרים רבים שלב 1 ו-2 יחד הם 70% מה-LCP. לכן דחיסת התמונה לבדה כמעט לא מזיזה את המחט.
מה שובר אותו בוורדפרס
TTFB גבוה. אם השרת מחזיר את ה-HTML אחרי 900ms, ה-LCP לא יהיה מתחת ל-1.5 שניות בשום מצב. מטמון דפים הוא התיקון היחיד שמשנה כאן סדר גודל.
טעינה עצלה על התמונה הראשית. זו הטעות הנפוצה ביותר. תוסף אופטימיזציה מחיל loading="lazy" על כל התמונות, כולל זו שבראש הדף — והדפדפן דוחה בכוונה את הטעינה של המדד שנמדד.
<img src="hero.webp" fetchpriority="high" decoding="async" width="1200" height="630" alt="...">התמונה הראשית צריכה fetchpriority="high", ובלי loading="lazy".
גופנים חוסמים. טקסט שמחכה לגופן חיצוני לא מצויר. font-display: swap מציג אותו מיד בגופן חלופי.
קרוסלה בראש הדף. רוב הסליידרים טוענים JavaScript כבד לפני שמציגים משהו. סליידר בראש דף הוא כמעט תמיד LCP גרוע.
איך מתקנים
- מטמון דפים — מוריד TTFB דרמטית
fetchpriority="high"על התמונה הראשית, בלי lazy- פורמט WebP/AVIF בגודל הנכון
preloadלגופנים קריטיים,font-display: swap- הימנעו מסליידר בראש הדף
INP — Interaction to Next Paint
מה זה
INP החליף את FID במרץ 2024, והוא מחמיר בהרבה. FID מדד רק את העיכוב הראשון — כמה זמן עבר עד שהדפדפן התחיל לטפל באינטראקציה הראשונה. INP מודד את כל האינטראקציות לאורך הביקור, ולוקח את הגרועה שבהן.
הוא מודד את המסלול המלא: מהלחיצה, דרך הרצת ה-JavaScript, ועד שהמסך צויר מחדש.
למה אתרים שעברו FID נכשלים ב-INP
FID היה סלחני. אתר יכול היה להגיב מהר ללחיצה הראשונה ואז להיתקע בכל השאר. INP חושף בדיוק את זה.
מה שובר אותו בוורדפרס
עודף תוספים שמריצים JavaScript. כל תוסף שמוסיף מאזין אירועים מוסיף עבודה לחוט הראשי. עשרים תוספים = עשרים ספריות שמתחרות עליו.
משימות ארוכות (Long Tasks). כל פעולת JavaScript מעל 50ms חוסמת את הדפדפן. בזמן הזה לחיצות פשוט לא נענות.
בוני דפים. Elementor, WPBakery ודומיהם טוענים מנועי רינדור בצד הלקוח. הם נוחים ויקרים ב-INP.
סקריפטים של צד שלישי. צ׳אט, פיקסלים, מפות, וידג׳טים. כל אחד מהם רץ על אותו חוט.
איך מתקנים
- הסירו תוספים שאינם בשימוש. ההשפעה הגדולה ביותר.
- דחו סקריפטים לא-קריטיים ל-
defer, או טענו אותם רק באינטראקציה ראשונה. - טענו צ׳אט ומפות רק כשצריך — למשל בלחיצה, לא בטעינת הדף.
- פצלו משימות ארוכות — אם יש קוד מותאם,
requestIdleCallbackאו פיצול לחלקים. - בדקו אילו תוספים טוענים נכסים בכל דף גם כשאינם רלוונטיים.
CLS — Cumulative Layout Shift
מה זה
כמה תוכן "קופץ" בזמן שהדף נטען. אם התחלתם לקרוא והטקסט זז — זה CLS. אם התכוונתם ללחוץ על כפתור ובאנר נדחף פנימה והזיז אותו — זה CLS, וזו גם הקלקה בטעות.
זהו המדד הכי קל לתקן והכי מוזנח.
מה שובר אותו בוורדפרס
תמונות בלי מידות. הדפדפן לא יודע כמה מקום לשריין, ומקצה אפס. כשהתמונה מגיעה, כל מה שמתחתיה נדחף למטה. תמיד ציינו width ו-height.
מודעות ובאנרים שנטענים אחרי התוכן. שריינו מקום בעיצוב מראש.
גופן שמחליף גופן. אם החלופה והגופן הסופי במידות שונות, הטקסט זז ברגע ההחלפה. size-adjust ב-@font-face מצמצם את זה.
באנר קוקיז או הודעה שנדחפת לראש הדף. אם היא דוחפת תוכן במקום לצוף מעליו — זה CLS. שימו לב שזו סיבה טובה לתת לבאנר position: fixed ולא לדחוף את המסמך.
תוכן שנטען דינמית מעל תוכן קיים. תמיד הוסיפו למטה, או שריינו מקום.
איך מתקנים
widthו-heightעל כל תמונה ווידאו- מקום שמור מראש לכל אלמנט שנטען מאוחר
font-display: swapיחד עםsize-adjust- באנרים צפים, לא דוחפים
שלושת המדדים ביחד — למה אתר יכול לעבור אחד ולהיכשל באחר
המדדים אינם מודדים את אותו דבר, ולעיתים הם מושכים לכיוונים מנוגדים.
דוגמה מוכרת: כדי לשפר LCP מפצלים את ה-CSS ומזריקים את הקריטי ישירות לדף. זה מזרז את הציור הראשון — ומגדיל את ה-HTML, מה שמאט מעט את ה-TTFB. שיפור באחד, החמרה קלה באחר.
דוגמה שנייה: כדי לשפר INP דוחים סקריפטים. אבל אם דחיתם סקריפט שאחראי על פריסת אלמנט בראש הדף, הוא ייטען מאוחר, ידחוף תוכן — וה-CLS יקפוץ.
המסקנה המעשית: אל תתקנו מדד אחד בבידוד. אחרי כל שינוי, מדדו את שלושתם.
מה קורה לדירוג בפועל
שווה להיות מדויקים כאן, כי הנושא מלווה בהגזמות משני הכיוונים.
Core Web Vitals הם גורם דירוג אמיתי אך משני. הם לא יעלו תוכן בינוני מעל תוכן מצוין. מה שהם כן עושים הוא להכריע בין תוצאות שוות בערך — וברוב תחומי התחרות, זה בדיוק המצב.
ההשפעה הגדולה יותר היא עקיפה ולא נוגעת לאלגוריתם כלל: אתר איטי מאבד מבקרים לפני שהם ראו אותו. שיעורי נטישה עולים בחדות ככל שזמן הטעינה גדל, וכל מבקר שנוטש הוא המרה שלא קרתה — בלי קשר למיקום בתוצאות.
סדר העדיפויות הנכון: תוכן טוב קודם, ביצועים אחריו. אתר מהיר עם תוכן דל לא ידורג.
מקרה בוחן: מה באמת קורה באתר טיפוסי
אתר תדמית עסקי על אחסון שיתופי, לפני טיפול:
| מדד | ערך | מצב |
|---|---|---|
| TTFB | 940ms | גרוע |
| LCP | 4.1 שנ׳ | נכשל |
| INP | 340ms | דורש שיפור |
| CLS | 0.28 | נכשל |
הסיבות, לפי סדר התרומה: אין מטמון דפים; תמונת הכותרת היא JPEG של 2.4MB עם loading="lazy"; אין width ו-height על אף תמונה; שלושה סקריפטים של צד שלישי נטענים בראש המסמך.
אחרי טיפול בארבעת הדברים האלה בלבד:
| מדד | ערך | מצב |
|---|---|---|
| TTFB | 180ms | טוב |
| LCP | 1.6 שנ׳ | עובר |
| INP | 190ms | עובר |
| CLS | 0.04 | עובר |
שימו לב שלא נגענו בתבנית, לא החלפנו בונה דפים ולא שכתבנו קוד. ארבעה תיקונים, שלושתם מהרשימה שלמעלה.
איך למדוד נכון
Search Console → Core Web Vitals — נתוני אמת ממבקרים אמיתיים. זה מה שקובע.
PageSpeed Insights — מציג גם שדה וגם מעבדה. הסתכלו על החלק העליון (שדה), לא רק על הציון.
Chrome DevTools → Performance — לאיתור משימות ארוכות ששוברות INP.
מלכודת נפוצה: נתוני השדה מתעדכנים על בסיס חלון של 28 יום. תיקנתם היום — התוצאה תתייצב רק בעוד מספר שבועות. אל תסיקו שהתיקון לא עבד.
למה הנתונים בכלים שונים לא מסכימים
שאלה שחוזרת: PageSpeed נותן 92, GTmetrix נותן 68, ו-Search Console אומר שהאתר נכשל. מי צודק?
כולם, כי הם מודדים דברים שונים. PageSpeed מריץ סימולציה על מכשיר נייד בינוני; GTmetrix בודק ממיקום שאתם בוחרים, לרוב על שולחני; Search Console מדווח על מבקרים אמיתיים שלכם, ב-28 הימים האחרונים.
מה שקובע לדירוג הוא Search Console בלבד. השאר הם כלי אבחון — שימושיים כדי להבין למה משהו איטי, לא כדי לדעת האם.
סדר עדיפויות מעשי
- תקנו LCP קודם — הוא המושפע ביותר מהתשתית ומשפיע על התחושה הכללית
- CLS אחר כך — התיקונים זולים והתוצאה מיידית
- INP אחרון — הכי מורכב, ודורש בדרך כלל החלטות על תוספים
הקשר לאחסון
LCP תלוי ב-TTFB, ו-TTFB תלוי בשרת. אתר על אחסון עמוס מתחיל את המרוץ עם חוב של שנייה.
זו הסיבה שאופטימיזציית מהירות שמתחילה מהתוספים ולא מהתשתית נעצרת מהר. חבילות אחסון הוורדפרס שלנו כוללות מטמון ברמת השרת ו-NVMe, מה שמטפל בשלב הראשון של LCP לפני שנגעתם בקוד.
נכתב על ידי אביר, אחראי מידע ותוכן ב-CloudX. מקור רשמי למדדים: web.dev/vitals.