ביצועי Web ו-Core Web Vitals: איך לשפר מהירות ודירוג בגוגל
מהירות האתר שלכם משפיעה ישירות על הדירוג בגוגל, על שיעורי ההמרה ועל חוויית המשתמש. גוגל הפכו את Core Web Vitals לגורם דירוג רשמי עוד ב-2021, ומאז המשמעות ברורה: אתר איטי נדחק למטה בתוצאות החיפוש. ב-SysTech אנחנו עובדים עם עשרות לקוחות על אופטימיזציית ביצועים, ובמאמר הזה נשתף את הידע המעשי שצברנו.
מה זה Core Web Vitals ולמה זה חשוב
Core Web Vitals הם שלושה מדדים שגוגל מודדים בכל אתר, והם משקפים את חוויית המשתמש האמיתית. לא מדובר במספרים תיאורטיים אלא בנתונים שנאספים מדפדפנים של משתמשים אמיתיים דרך Chrome User Experience Report (CrUX).
הסיבה שגוגל בחרו דווקא בשלושת המדדים האלה היא שהם מכסים שלוש תחושות שונות: כמה זמן לוקח לראות תוכן משמעותי, כמה האתר מגיב לאינטראקציה, וכמה יציב הפריסה הוויזואלית. כשאחד מהם לא תקין, המשתמשים מרגישים את זה מיד.
שלושת המדדים שחייבים להכיר
LCP (Largest Contentful Paint)
LCP מודד את הזמן שלוקח לאלמנט התוכן הגדול ביותר להיטען ולהופיע על המסך. בדרך כלל מדובר בתמונה ראשית, כותרת גדולה או בלוק טקסט מרכזי. הסף שגוגל מגדירים כטוב הוא עד 2.5 שניות.
למה זה קריטי? כי LCP הוא הרושם הראשוני. אם משתמש נכנס לאתר ורואה מסך ריק במשך 4 שניות, הוא פשוט הולך. מחקרים מראים שכל שנייה נוספת ב-LCP מורידה את שיעור ההמרה ב-7% בממוצע.
גורמים שפוגעים ב-LCP:
– תמונות כבדות שלא עברו אופטימיזציה
– פונטים שחוסמים את הרינדור
– זמן תגובה ארוך של השרת (TTFB)
– JavaScript שחוסם את ה-render path
– CSS לא יעיל שמעכב הצגת תוכן
INP (Interaction to Next Paint)
INP החליף את FID (First Input Delay) במרץ 2024 כמדד רשמי. ההבדל המרכזי: FID מדד רק את ההשהיה של האינטראקציה הראשונה, בעוד INP מודד את כל האינטראקציות לאורך חיי הדף ולוקח את הערך הגרוע ביותר (בערך). הסף הטוב הוא עד 200 מילישניות.
מה שהופך את INP למאתגר יותר מ-FID זה שאי אפשר לברוח ממנו. FID היה קל יחסית לתקן כי הוא מדד רק את הקליק הראשון. INP תופס גם את הכפתור שנלחץ אחרי שהדף כבר טעון, גם את הסקרול, גם את פתיחת התפריט. כל אינטראקציה שגורמת ל-paint חדש נמדדת.
גורמים שפוגעים ב-INP:
– JavaScript כבד שרץ על ה-main thread
– Event handlers לא יעילים
– רינדור מורכב של DOM גדול
– Third-party scripts שחוסמים את ה-thread
– חישובים סינכרוניים כבדים
CLS (Cumulative Layout Shift)
CLS מודד כמה אלמנטים זזים על המסך בצורה לא צפויה. כולם מכירים את התחושה הזו: אתם עומדים ללחוץ על כפתור, ופתאום באנר נטען מלמעלה והכל זז. הסף הטוב הוא עד 0.1.
CLS הוא אולי המדד הכי מתסכל מבחינת המשתמש כי הוא גורם לטעויות בלחיצה ולתחושה של אתר לא מקצועי. גם מבחינת SEO, גוגל רואים CLS גבוה כסימן לחוויית משתמש גרועה.
גורמים שפוגעים ב-CLS:
– תמונות וסרטונים בלי מידות מוגדרות (width/height)
– פרסומות שנטענות דינמית
– פונטים שגורמים ל-FOUT (Flash of Unstyled Text)
– תוכן שנטען דינמית ודוחף תוכן קיים
– אנימציות שמשנות את ה-layout
כלי מדידה שאנחנו משתמשים בהם
Google Lighthouse
Lighthouse הוא הכלי הבסיסי שמגיע מובנה ב-Chrome DevTools. הוא מריץ ביקורת סינתטית על הדף ונותן ציון מ-0 עד 100 עם המלצות מפורטות לשיפור. חשוב לזכור ש-Lighthouse מריץ בדיקה מסביבה מבוקרת, אז הציונים לא תמיד משקפים את מה שמשתמשים אמיתיים חווים.
אנחנו ממליצים להריץ Lighthouse במצב Incognito כדי למנוע התערבות של תוספים, ולהריץ לפחות 3 פעמים ולקחת את הממוצע כי יש שונות בין הרצות.
PageSpeed Insights
PageSpeed Insights משלב בין נתוני Lighthouse (סינתטיים) לבין נתוני CrUX (נתוני שטח אמיתיים). זה הכלי שנותן את התמונה המלאה ביותר. אם יש מספיק תעבורה לאתר, הוא יציג נתוני Core Web Vitals ממשתמשים אמיתיים חלוקים לפי מובייל ודסקטופ.
Chrome UX Report (CrUX)
CrUX הוא מאגר הנתונים של גוגל שאוסף ביצועים ממשתמשי Chrome אמיתיים. אפשר לגשת אליו דרך BigQuery, דרך CrUX API, או דרך הדשבורד ב-Looker Studio. זה המקור שגוגל עצמם משתמשים בו לדירוג, אז זה הנתון הכי חשוב.
Web Vitals Extension
תוסף Chrome שמציג את ה-Core Web Vitals בזמן אמת בזמן גלישה. שימושי בעיקר לפיתוח ולבדיקות מהירות.
טכניקות אופטימיזציה מעשיות
אופטימיזציית תמונות
תמונות הן בדרך כלל הגורם מספר אחת ל-LCP איטי. הנה מה שעובד:
שימוש בפורמט WebP או AVIF במקום JPEG/PNG מקטין את גודל הקובץ ב-30%-50% בלי פגיעה באיכות נראית. ב-Next.js יש לנו את קומפוננטת Image שעושה את זה אוטומטית, כולל lazy loading ו-responsive sizes.
הגדרת מידות width ו-height לכל תמונה מונעת CLS. הדפדפן צריך לדעת כמה מקום לשמור לתמונה עוד לפני שהיא נטענת. ב-React עם Next.js Image component זה מתנהל אוטומטית.
Preload לתמונת ה-hero: אם יש תמונה גדולה בחלק העליון של הדף, שימוש ב-<link rel="preload"> יכול לקצר את ה-LCP משמעותית כי הדפדפן מתחיל להוריד אותה מוקדם יותר.
Code Splitting ו-Tree Shaking
אחת הטעויות הנפוצות שאנחנו רואים בפרויקטי פיתוח תוכנה היא bundle יחיד ענק שמכיל את כל הקוד של האפליקציה. המשתמש צריך להוריד, לפרסר ולהריץ את כל ה-JavaScript עוד לפני שהוא רואה משהו על המסך.
Code splitting מחלק את הקוד לחלקים קטנים יותר שנטענים לפי הצורך. ב-Next.js זה קורה אוטומטית ברמת הדפים, אבל בתוך דף אפשר להשתמש ב-dynamic() או ב-React.lazy לטעינה עצלה של קומפוננטות כבדות.
Tree shaking מסיר קוד שלא נמצא בשימוש מה-bundle הסופי. חשוב לוודא שה-imports מדויקים ולא מייבאים ספריות שלמות כשצריך רק פונקציה אחת.
// לא מומלץ - מייבא את כל הספרייה
import _ from 'lodash';
// מומלץ - מייבא רק מה שצריך
import debounce from 'lodash/debounce';
אסטרטגיות Caching
Caching נכון יכול לחסוך טעינות מיותרות ולשפר דרמטית את ה-LCP ואת חוויית החזרה לאתר.
Cache-Control headers צריכים להיות מוגדרים נכון לכל סוג משאב. קבצי static כמו תמונות, פונטים ו-JS bundles עם hash בשם הקובץ יכולים לקבל cache ארוך של שנה. קבצי HTML צריכים cache קצר או אפילו no-cache כדי שמשתמשים תמיד יקבלו את הגרסה העדכנית.
Service Workers מאפשרים caching מתקדם ברמת האפליקציה. אפשר ליצור אסטרטגיות שונות כמו cache-first לאסטים סטטיים ו-network-first לתוכן דינמי. ב-Next.js עם אפליקציות SaaS אנחנו מיישמים את זה בקביעות.
CDN ותשתית
שימוש ב-CDN מקצר את הזמן שלוקח למשאבים להגיע למשתמש כי הם מוגשים מנקודה גיאוגרפית קרובה. ב-SysTech אנחנו עובדים עם Google Cloud CDN שמשתלב טבעי עם Cloud Run ועם שאר תשתיות GCP.
Cloud CDN של גוגל נותן כמה יתרונות ברורים: הוא מתחבר לרשת ה-edge הגלובלית של גוגל, תומך ב-HTTP/3 ו-QUIC, ומאפשר invalidation מהיר של cache כשמעדכנים תוכן.
הנה כמה טיפים לאופטימיזציית CDN:
– הגדרת cache rules לפי סוג תוכן
– שימוש ב-compression (Brotli עדיף על gzip)
– הפעלת HTTP/2 Server Push למשאבים קריטיים
– מעקב אחרי cache hit ratio ואופטימיזציה שלו
אופטימיזציית Server-Side Rendering
ב-Next.js יש לנו כמה אפשרויות לרינדור שמשפיעות ישירות על ביצועים:
SSG (Static Site Generation) מייצר HTML סטטי בזמן build. זה הכי מהיר כי אין חישוב בזמן ריצה. מתאים לדפים שהתוכן שלהם לא משתנה בתדירות גבוהה.
ISR (Incremental Static Regeneration) משלב בין SSG לבין תוכן דינמי. הדף מוגש מ-cache ומתעדכן ברקע לפי revalidation time שמגדירים. זה הפתרון שאנחנו ממליצים לרוב האתרים.
SSR (Server-Side Rendering) מייצר HTML לכל בקשה. איטי יותר אבל מתאים לדפים עם תוכן מותאם אישית למשתמש. כשעובדים עם SSR על Cloud Run חשוב להגדיר minimum instances כדי למנוע cold starts.
אופטימיזציית CSS
CSS שלא מנוהל נכון יכול לחסום את כל הרינדור של הדף. כמה טכניקות שעובדות:
Critical CSS: חילוץ ה-CSS שנדרש לחלק העליון של הדף (above the fold) והטמעה שלו inline ב-HTML. שאר ה-CSS נטען באופן אסינכרוני. ב-Next.js עם CSS Modules או styled-components זה מתנהל בצורה יעילה.
הסרת CSS שלא בשימוש באמצעות כלים כמו PurgeCSS. אתרים רבים נושאים CSS של ספריות שלמות כשהם משתמשים רק בחלק קטן.
אופטימיזציית פונטים
פונטים יכולים לגרום גם ל-LCP איטי וגם ל-CLS. הגישה המומלצת:
שימוש ב-font-display: swap כדי שטקסט יוצג מיד עם פונט חלופי עד שהפונט המבוקש נטען. שימוש ב-preconnect ל-Google Fonts או טעינה עצמית של הפונטים. ב-Next.js 13+ יש מודול next/font שמטפל בזה אוטומטית ומונע CLS.
ההשפעה על דירוג SEO
גוגל הודיעו מפורשות ש-Core Web Vitals הם גורם דירוג. אבל חשוב לשמור על פרופורציה: הם גורם אחד מתוך הרבה. תוכן איכותי ורלוונטי עדיין חשוב יותר. עם זאת, כשתוכן מתחרה שווה באיכותו, ביצועי האתר יכולים להיות ההבדל בין עמוד 1 לעמוד 2.
נתונים שאנחנו רואים אצל לקוחות:
– שיפור LCP מ-4 שניות ל-2 שניות הוביל לעלייה של 15% בתעבורה אורגנית תוך חודשיים
– תיקון בעיות CLS שיפר את שיעור ההמרה ב-12%
– אתר e-commerce שעבר אופטימיזציה מלאה ראה עלייה של 23% בהכנסות
מעבר ל-SEO, ביצועים טובים משפיעים על מדדים עסקיים ישירים. שיעורי נטישה יורדים, זמן שהייה באתר עולה, ושיעורי המרה משתפרים. אמזון פרסמו שכל 100 מילישניות של השהיה עולות להם 1% במכירות.
תהליך אופטימיזציה שלב אחרי שלב
ככה נראה תהליך אופטימיזציית ביצועים שאנחנו מריצים ב-SysTech:
-
מדידת מצב קיים: הרצת Lighthouse ובדיקת נתוני CrUX. תיעוד כל המדדים כקו בסיס.
-
זיהוי צווארי בקבוק: שימוש ב-Performance tab ב-Chrome DevTools לזיהוי מה בדיוק מאט את הדף. לפעמים זו תמונה אחת גדולה, לפעמים זה script של צד שלישי.
-
תיעדוף לפי השפעה: לא כל שיפור שווה. אנחנו מתחילים מהדברים שישפרו הכי הרבה עם הכי פחות מאמץ.
-
ביצוע שיפורים: עבודה על תמונות, code splitting, caching, CDN, ואופטימיזציות נוספות לפי הממצאים.
-
מדידה חוזרת: בדיקה שהשיפורים עבדו ולא גרמו לרגרסיות. מעקב אחרי נתוני CrUX לאורך זמן.
-
מוניטורינג שוטף: הגדרת התראות לירידה בביצועים כדי לתפוס בעיות חדשות מהר.
שאלות נפוצות
מה ההבדל בין FID ל-INP?
FID מדד רק את ההשהיה של האינטראקציה הראשונה עם הדף, כלומר הזמן עד שהדפדפן התחיל לעבד את הקליק הראשון. INP מדד את כל האינטראקציות לאורך כל חיי הדף ומחזיר את הערך שמייצג את ה-percentile ה-98 מביניהן. INP הוא מדד מחמיר יותר ומשקף טוב יותר את החוויה האמיתית. גוגל עברו רשמית ל-INP במרץ 2024.
כמה זמן לוקח לראות שיפור בדירוג אחרי אופטימיזציית ביצועים?
גוגל אוספים נתוני CrUX על בסיס 28 יום מתגלגלים. אז שיפור שעשיתם היום ייקח לפחות חודש עד שישתקף בנתוני השטח, ולאחר מכן עוד זמן עד שגוגל יעדכנו את הדירוג. בפועל, אנחנו רואים שינויים בדירוג תוך 2-3 חודשים מרגע השיפור הטכני.
האם Core Web Vitals חשובים יותר מתוכן?
לא. תוכן איכותי ורלוונטי עדיין הגורם החשוב ביותר לדירוג. Core Web Vitals הם גורם משני שמשפיע בעיקר כשיש תחרות על אותן מילות מפתח בין אתרים עם תוכן דומה באיכותו. אבל אתר עם תוכן מצוין וביצועים גרועים עדיין ידורג גבוה יותר מאתר עם תוכן חלש וביצועים מעולים.
איך בודקים Core Web Vitals של אתר מתחרה?
אפשר להשתמש ב-PageSpeed Insights ולהזין את כתובת האתר המתחרה. אם יש לו מספיק תעבורה מ-Chrome, תראו את נתוני ה-CrUX שלו. אפשר גם להשתמש ב-CrUX API או בדשבורד ה-CrUX ב-Looker Studio להשוואה מפורטת. כלי נוסף שימושי הוא Chrome UX Report שנגיש דרך BigQuery ומאפשר ניתוח היסטורי.
מה עדיף, SSR או SSG לביצועים?
SSG כמעט תמיד מהיר יותר כי ה-HTML מוכן מראש ומוגש ישירות מ-CDN בלי שום חישוב בזמן ריצה. SSR דורש עיבוד בשרת לכל בקשה, מה שמוסיף latency. אם התוכן לא צריך להיות מותאם אישית לכל משתמש, עדיף SSG או ISR. ב-Next.js אנחנו משתמשים ב-ISR כברירת מחדל ועוברים ל-SSR רק כשיש צורך אמיתי.
סיכום
ביצועי Web ו-Core Web Vitals הם לא רק עניין טכני. הם משפיעים ישירות על הדירוג בגוגל, על חוויית המשתמש ועל ההכנסות. שיפור ביצועים דורש מומחיות טכנית, כלים נכונים ותהליך מסודר של מדידה, שיפור ומעקב.
ב-SysTech אנחנו מתמחים בפיתוח אפליקציות web מהירות עם React ו-Next.js על תשתית GCP, כולל אופטימיזציית ביצועים מקצה לקצה. מ-2015 אנחנו עוזרים לחברות ישראליות לבנות מוצרים דיגיטליים שעובדים מהר ומדורגים גבוה.
רוצים לשפר את ביצועי האתר שלכם? צרו איתנו קשר ונעשה ביקורת ביצועים ראשונית בלי עלות.
