מדוע Core Web Vitals קריטיים לקידום אורגני טכני?
PageSpeed 34/100 בנייד. Search Console מציג אדום בכל דפי הקטגוריות. מתחרה עם אתר ישן יותר עוקף אותך בדירוג למרות תוכן חלש יותר. ביצועים טכניים הפכו לגורם דירוג ישיר — והפער בין "מקובל" ל"מהיר" עולה במקומות. יש לנו ניסיון של למעלה מ-8 שנים בקידום אורגני טכני ואופטימיזציית ביצועים, השלמנו יותר מ-150 פרויקטים במסחר אלקטרוני, SaaS ואתרים ארגוניים. עבור חנות מסחר אלקטרוני טיפוסית בגודל בינוני עם 50 אלף ביקורים חודשיים, תיקון Core Web Vitals מירוד לטוב הגדיל את התנועה האורגנית ב-35% תוך שלושה חודשים, והוסיף הכנסה חודשית מוערכת של 12,000 דולר.
Core Web Vitals: מה באמת משפיע על דירוגים
גוגל משתמשת בשלושה מדדים כאותות דירוג (Page Experience): Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), Interaction to Next Paint (INP, החליף את FID בעדכון האלגוריתם האחרון). לפי התיעוד של גוגל ל-Page Experience, עמידה בספים אלה יכולה להפחית את שיעור הנטישה בעד 24% בהשוואה לדפים שנכשלים בהם.
LCP: למה 8 שניות זה לא בעיית תמונה
LCP מודד את זמן העיבוד של האלמנט הגדול ביותר הנראה לעין. טוב <2.5 שניות, ירוד >4 שניות.
מקרה אמיתי: חנות בגדים מקוונת, LCP 7.8 שניות בנייד. תמונת Hero במשקל 4.2MB בפורמט JPEG ללא srcset, נטענה דרך CSS background-image (לא srcset). הבעיה: הדפדפן לא יכול לטעון מראש תמונות רקע של CSS דרך background-image, ו-4.2MB בחיבור נייד איטי.
פתרון:
- מעבר ל-
<img>עם<link rel="preload">ו-<img> - המרה ל-WebP, הוספת srcset: 800w לנייד, 1400w לשולחן עבודה
-
fetchpriority="high"ב-loading="eager" - הסרת סקריפטים חוסמי רינדור מעל ה-Hero עם
srcset
תוצאה: LCP 7.8 שניות → 1.9 שניות ללא שינוי באחסון או CDN. זה פי 4 מהר יותר — יתרון תחרותי בדירוג החיפוש.
אם LCP הוא בלוק טקסט: הבעיה עשויה להיות TTFB, CSS/JS חוסמי רינדור, או גופני אינטרנט עם 800w.
CLS: מה גורם לשינויי פריסה ואיך לעצור אותם
CLS מודד שינוי פריסה מצטבר. טוב <0.1, ירוד >0.25. באנר הנחה שמופיע אחרי שנייה אחת ומזיז את כל התוכן למטה גורם ל-CLS של 0.35.
מקורות:
- תמונות ללא מידות.
1400wללא width/height — הדפדפן לא שומר מקום. תיקון: width/height מפורשים או<link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)">ב-CSS. - בלוקי פרסומות ווידג'טים — Google Ads, צ'אט, הסכמת עוגיות. שמירת מקום דרך
<head>או טעינה לפני התוכן הראשי. - גופני אינטרנט.
deferעםfont-display: blockממזער CLS. - תוכן דינמי — הוספת placeholder עם מידות.
| תרחיש טיפוסי | CLS לפני | CLS אחרי | התיקון העיקרי |
|---|---|---|---|
| באנר הנחה ללא min-height | 0.42 | 0.02 | min-height: 300px |
| תמונות מאמר ללא מאפיינים | 0.18 | 0.01 | width/height + aspect-ratio |
| וידג'ט צ'אט שנטען אחרי 3 שניות | 0.35 | 0.05 | position: fixed עם שוליים שמורים |
INP: למה הממשק קופא ל-500 אלפיות שנייה
INP מודד את עיכוב התגובה לכל אינטראקציה של משתמש. טוב <200 אלפיות שנייה, ירוד >500 אלפיות שנייה. INP של 680 אלפיות שנייה אומר שהמשתמש לוחץ על כפתור סינון ומחכה חצי שנייה.
הסיבה העיקרית: חסימת ה-main thread. חבילת JavaScript של 2.1MB מנותחת ומופעלת באופן סינכרוני, ומונעת עיבוד אירועים.
אבחון: Chrome DevTools → Performance → interact → חיפוש Long Tasks (>50 אלפיות שנייה). אשמים טיפוסיים:
- עיבוד רשימה גדולה ללא requestIdleCallback או requestAnimationFrame
- מאזיני אירועים כבדים ללא debounce/throttle
- setState סינכרוני ב-React הגורם ל-render מלא
- סקריפטים של צד שלישי על ה-main thread
פתרונות: פיצול קוד באמצעות dynamic import, העברת עומס ל-Web Workers, React.memo + useMemo, Scheduler API.
איך נתונים מובנים ו-Schema.org משפרים את הנראות בחיפוש?
נתונים מובנים באמצעות JSON-LD אינם גורם דירוג ישיר, אבל הם מאפשרים rich snippets (דירוגי כוכבים, מחירים, תאריך פרסום), ומגדילים את שיעור ההקלקות (CTR) ב-20–30%. עבור מסחר אלקטרוני, סימון נכון יכול להוביל לעוד 25% הקלקות בהשוואה לתוצאות רגילות — זה 3,000–5,000 דולר נוספים בהכנסה חודשית לחנות מקוונת בגודל בינוני.
סוגי סימון לפי תרחיש:
- מסחר אלקטרוני: Product עם offers (מחיר, זמינות, מטבע), aggregateRating, brand. BreadcrumbList, ItemList.
- מאמרים: Article או BlogPosting עם author, datePublished, dateModified, image. Organization ו-WebSite.
- עסק מקומי: LocalBusiness עם address, telephone, openingHours, geo.
- שאלות נפוצות: FAQPage עם mainEntity — שאלות מופיעות כבלוק מתפתח.
ולידציה: Google Rich Results Test, Schema Markup Validator. טעות נפוצה: ציון מחיר ללא priceCurrency — הסימון מתעלם.
איך לבצע ביקורת קידום אורגני טכני
יכולת סריקה. robots.txt חוסם דפים נחוצים או לא חוסם דפי שירות. כתובות Canonical שגויות — כפילויות עם פרמטרי UTM. Sitemap מכיל דפי noindex. כלים כמו Screaming Frog או Sitebulb מראים זאת תוך שעה.
Core Web Vitals בקנה מידה. Google Search Console → Core Web Vitals → הסתכלות על קבוצות כתובות (תבנית מוצר, תבנית קטגוריה, בלוג). הבעיה בדרך כלל מערכתית.
JavaScript SEO. גוגל מרנדרת JS עם עיכוב. עבור תוכן קריטי, SSR או SSG הם חובה. בדיקה דרך Search Console → Inspect URL → View Crawled Page.
קישורים פנימיים. דפים יתומים מאבדים PageRank. קישורים שבורים (404) הם אות איכות.
טעויות נפוצות ביישום Schema.org: ציון מחיר ללא priceCurrency, ratingValue ללא reviewCount, מספר Product באותו דף ללא ItemList, JSON-LD ב-GTM — רינדור בצד השרת עדיף.
איך נראה תהליך האופטימיזציה?
| שלב | מה כולל | משך |
|---|---|---|
| ביקורת | סריקה, ניתוח Core Web Vitals, ביקורת Schema, דוח עדיפויות | 1–2 שבועות |
| אופטימיזציה של תבנית אחת | LCP, CLS, INP, הטמעת SSR/SSG, הגדרת preload | 2–4 שבועות |
| אופטימיזציה טכנית מלאה | כל התבניות, פיצול קוד, Web Workers, ניטור CI | 4–10 שבועות |
| הטמעת Schema.org | יצירת JSON-LD, ולידציה, בדיקת rich snippets | 1–3 שבועות |
אילו תוצרים אתה מקבל?
- תיעוד: דוח הבעיות שנמצאו, מפת דרכים עם עדיפויות, לוחות זמנים לכל שלב.
- גישה: הגדרת ניטור (SpeedCurve, Sentry, Search Console), מסירת דשבורד.
- הדרכה: שיחה או שתיים לסקירת טעויות טיפוסיות עבור הצוות שלך.
- תמיכה: ליווי חודשי לאחר העלייה לאוויר — בדיקות מדדים, תיקוני רגרסיה.
כמה מקומות אפשר להחזיר דרך קידום אורגני טכני?
יש לנו 5+ שנים בשוק ו-150+ פרויקטים שהושלמו. לדוגמה: פלטפורמת SaaS עם 200 אלף ביקורים חודשיים הייתה עם LCP 6.2 שניות, CLS 0.45, INP 600 אלפיות שנייה. לאחר האופטימיזציה, LCP ירד ל-1.8 שניות, CLS ל-0.02, ו-INP ל-180 אלפיות שנייה. התנועה האורגנית גדלה ב-40% תוך חודשיים, ויצרה הכנסה חודשית נוספת של 18,000 דולר מהרשמות לניסיון.
צור קשר — נעריך את הפרויקט שלך תוך יומיים ונראה את פוטנציאל השיפור. בקש ביקורת וקבל רשימת בדיקה אישית של 15 נקודות עם צעדים מעשיים.