מהירות אתר: מדריך Core Web Vitals לבעלי עסקים

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

במדריך הזה תמצאו את כל מה שצריך כדי לשפר את מהירות האתר ב-2026: מה גוגל מודדת, איך קוראים את PageSpeed בלי להיבהל, מה מאט אתרי וורדפרס ו-WooCommerce, מה לתקן קודם, צ'קליסט, ופרק טכני שאפשר להעביר כמו שהוא למפתח. ב-Ezweb אנחנו בודקים מהירות בכל אתר שאנחנו בונים, עוד לפני שהוא עולה לאוויר, וזה התהליך שלנו.

בקצרה: מהירות אתר נמדדת היום בעיקר דרך שלושת מדדי Core Web Vitals של גוגל: LCP (טעינת התוכן המרכזי, טוב עד 2.5 שניות), INP (תגובה ללחיצות, טוב עד 200 מילישניות) ו-CLS (יציבות התצוגה, טוב עד 0.1). גוגל משתמשת במדדים האלה במערכות הדירוג, אבל הם לא גוברים על תוכן רלוונטי. מניסיוננו, ברוב אתרי הוורדפרס האיטיים ארבעה צעדים פותרים את עיקר הבעיה: תמונות דחוסות ובגודל נכון, שרת ומטמון טובים, פחות סקריפטים חיצוניים, וטיפול נכון בתמונה הראשית של העמוד.

למה אתר איטי מפסיד לקוחות וכסף?

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

המחקר המצוטט ביותר בנושא הוא "Milliseconds Make Millions" של Deloitte, שבוצע בהזמנת גוגל. לפי סיכום המחקר ב-web.dev, נבדקו 37 אתרי מותגים באירופה ובארצות הברית בסוף 2019. שיפור של 0.1 שנייה במדדי המהירות בנייד היה קשור לעלייה של 8.4% בשיעור ההמרה באתרי קמעונאות, ולעלייה של 9.2% בסכום שהקונים הוציאו.

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

מה הם Core Web Vitals ומה נחשב ציון טוב?

Core Web Vitals הם שלושה מדדים שגוגל הגדירה כדי למדוד איך משתמשים אמיתיים חווים עמוד: כמה מהר מופיע התוכן המרכזי, כמה מהר העמוד מגיב ללחיצה, וכמה הוא יציב בזמן הטעינה.

LCP: מהירות הטעינה

LCP (Largest Contentful Paint) הוא הזמן עד שהאלמנט הגדול ביותר בחלק הנראה של המסך מוצג, בדרך כלל תמונת הבאנר, תמונת המוצר או כותרת גדולה. זה הרגע שבו הגולש מרגיש שהעמוד "נטען".

INP: התגובה ללחיצות

INP (Interaction to Next Paint) מודד כמה זמן עובר מלחיצה, הקשה או הקלדה ועד שהמסך מגיב, לאורך כל הביקור. INP החליף את FID כמדד ליבה ב-12 במרץ 2024, ולכן מדריכים שעדיין מדברים על FID כבר לא מעודכנים. INP גבוה מרגיש כמו כפתור "הוספה לסל" שלא קורה כלום כשלוחצים עליו.

CLS: יציבות התצוגה

CLS (Cumulative Layout Shift) מודד כמה התוכן "קופץ" בזמן הטעינה. אם הטקסט ירד פתאום כי נטען באנר מעליו, או שלחצתם על הכפתור הלא נכון כי הוא זז, זה CLS.

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

מדד	מה הוא מודד	טוב	דורש שיפור	גרוע
LCP	טעינת התוכן המרכזי	עד 2.5 שניות	עד 4 שניות	מעל 4 שניות
INP	תגובה לפעולות הגולש	עד 200 מילישניות	עד 500 מילישניות	מעל 500 מילישניות
CLS	יציבות התצוגה	עד 0.1	עד 0.25	מעל 0.25

פרט שרבים מפספסים: הציון לא מחושב לפי ביקור ממוצע. לפי התיעוד של PageSpeed Insights, נלקח האחוזון ה-75, כלומר לפחות 75% מהביקורים צריכים לעמוד ביעד. העמוד עובר את ההערכה רק אם שלושת המדדים בטווח הטוב, והמדידה נעשית בנפרד לנייד ולמחשב.

האם מהירות אתר משפיעה על הדירוג בגוגל ובמנועי AI?

כן, אבל כגורם אחד מתוך רבים, ולא כגורם שמנצח תוכן רלוונטי. גוגל כותבת בתיעוד על חוויית עמוד ש-Core Web Vitals משמשים את מערכות הדירוג שלה, אבל שאין "אות אחד" של חוויית עמוד, ושהחיפוש תמיד ישאף להציג את התוכן הרלוונטי ביותר, גם אם חוויית העמוד שלו פחות טובה.

מה זה אומר בפועל בגוגל

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

מה לגבי AI Overviews ו-ChatGPT?

בעמוד על תכונות AI בחיפוש גוגל כותבת שאין דרישות נוספות כדי להופיע ב-AI Overviews או ב-AI Mode: העמוד צריך להיות מאונדקס וזכאי להופיע בחיפוש עם קטע תקציר. ברשימת ההמלצות שם מופיעה גם חוויית עמוד טובה. מה שטוב לחיפוש הרגיל טוב גם לתשובות ה-AI של גוגל.

במנועים אחרים, השאלה החשובה היא פחות שניות ויותר מבנה. מחקר של Vercel ו-MERJ מדצמבר 2024 מצא שאף אחד מסורקי ה-AI הגדולים, ובהם GPTBot של OpenAI, ClaudeBot של Anthropic ו-PerplexityBot, לא הריץ JavaScript באותה תקופה. תוכן שמופיע רק אחרי שסקריפט רץ, כמו ביקורות מווידג'ט חיצוני, עלול לא להיקרא. וורדפרס מייצר את ה-HTML בשרת, ולכן התוכן הבסיסי שלו כן נקרא. לא מצאנו בתיעוד הרשמי של OpenAI או של Perplexity ספי מהירות לסורקים, אז היזהרו ממי שמבטיח "ציון שמכניס ל-ChatGPT". על כל זה בהרחבה במדריך GEO שלנו.

איך בודקים מהירות אתר נכון?

בודקים בשלושה כלים חינמיים של גוגל, תמיד בנייד קודם ובכמה עמודים, לא רק בעמוד הבית. אבל קודם, הבחנה אחת שחוסכת הרבה בלבול.

נתוני שטח מול נתוני מעבדה: למה PageSpeed מראה שני ציונים

נתוני שטח (Field data) הם מדידות של משתמשי כרום אמיתיים שביקרו באתר, מתוך מאגר של גוגל שנקרא CrUX (Chrome User Experience Report). נתוני מעבדה (Lab data) הם סימולציה של טעינה אחת, שהכלי Lighthouse מריץ בתנאים קבועים. ב-PageSpeed Insights נתוני השטח מסכמים את 28 הימים האחרונים, ואילו הציון מ-0 עד 100 שכולם מצלמים מגיע מהמעבדה.

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

סדר הבדיקה שאנחנו עובדים לפיו

PageSpeed Insights: הכניסו את כתובת העמוד ב-pagespeed.web.dev, בחרו "נייד" והסתכלו קודם על החלק העליון: האם העמוד עובר את הערכת Core Web Vitals. רק אחר כך גללו לאבחון.
Search Console: בדוח Core Web Vitals תראו קבוצות של כתובות עם חוויה דומה, מסווגות לגרוע, דורש שיפור וטוב. טפלו קודם בגרועות. אחרי תיקון, לחיצה על אימות פותחת מעקב של 28 יום.
Chrome DevTools: לחצו F12 בכרום ועברו ללשונית Performance. תראו מדידה חיה של LCP ו-CLS, ו-INP כשתלחצו על משהו. הפעילו האטת מעבד ורשת כדי לדמות טלפון ממוצע.
בדקו את העמודים שמכניסים כסף: עמוד הבית, עמוד שירות מרכזי, קטגוריה, מוצר, סל וקופה, ודפי הנחיתה של הקמפיינים.
תעדו נקודת פתיחה: רשמו את הערכים לפני כל שינוי, כדי להוכיח שהתיקון עבד.

למה האתר איטי? הגורמים הנפוצים בוורדפרס ו-WooCommerce

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

בוני עמודים כבדים ותוספים שנטענים בכל עמוד

Elementor, Divi ו-WPBakery נוחים לעריכה, אבל מוסיפים קבצי CSS ו-JavaScript ושכבות של אלמנטים עוטפים. DOM הוא מבנה הרכיבים שהדפדפן בונה מתוך ה-HTML. עמוד עם עמודות בתוך עמודות ואנימציות בכל אזור מייצר DOM ענק, שהדפדפן מחשב מחדש בכל אינטראקציה, וזה פוגע ב-INP. גם מספר התוספים חשוב פחות ממה שכל אחד טוען: תוסף טפסים שמוסיף קבצים לכל עמוד, כשיש טופס רק בעמוד צור קשר, הוא דוגמה קלאסית.

תמונות לא מותאמות

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

אחסון שיתופי זול

באחסון שיתופי זול האתר חולק שרת עם אתרים רבים, ולפעמים אין מטמון ברמת השרת. התוצאה היא TTFB גבוה. TTFB (Time to First Byte) הוא הזמן עד שהשרת מתחיל להחזיר תשובה, ושום אופטימיזציה בדפדפן לא מפצה על שרת שעונה רק אחרי שנייה וחצי.

סקריפטים חוסמים, צ'אט ווידג'טים שיווקיים

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

פונטים

פונט עברי מעוצב הוא חלק מהמותג, אבל כל משקל (רגיל, מודגש, דק) הוא קובץ נפרד. שלושה פונטים בארבעה משקלים, משרת חיצוני, מעכבים את הטקסט ולפעמים גורמים לו לקפוץ כשהפונט מתחלף.

בעיות ייחודיות ל-WooCommerce

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

מה לתקן קודם? טבלת עדיפויות לשיפור מהירות אתר וורדפרס

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

הבעיה	איך מזהים	הפתרון	מאמץ	השפעה צפויה
תמונה ראשית כבדה	LCP breakdown או Improve image delivery מצביעים על תמונה גדולה	WebP או AVIF, הקטנה לגודל התצוגה, fetchpriority="high"	נמוך	גבוהה על LCP
תמונת ה-LCP בטעינה עצלה	אזהרה ב-LCP request discovery, או loading="lazy" על הבאנר	הסרת הטעינה העצלה מהתמונה הראשית בלבד	נמוך	גבוהה על LCP
שרת איטי	Document request latency, או TTFB מעל 800 מילישניות בנתוני השטח	מטמון עמודים, CDN, PHP עדכני, אחסון טוב יותר	בינוני	גבוהה על כל המדדים
תמונות בלי מידות	Layout shift culprits, תוכן שקופץ	width ו-height לכל תמונה ו-iframe	נמוך	גבוהה על CLS
קבצים חוסמי רינדור	Render blocking requests	defer או async לסקריפטים, צמצום CSS	בינוני	בינונית עד גבוהה
צ'אט, פיקסלים ווידג'טים	3rd parties, דומיינים חיצוניים רבים בלשונית Network	הסרת מה שלא בשימוש, טעינה אחרי אינטראקציה, תמונה במקום סרטון או מפה	נמוך עד בינוני	גבוהה על INP
פונטים	Font display, קבצי פונט רבים	אחסון מקומי ב-WOFF2, פחות משקלים, preload לפונט הראשי	נמוך	בינונית
DOM ענק מבונה עמודים	Optimize DOM size	פישוט המבנה, הסרת עטיפות, לפעמים בנייה מחדש	גבוה	בינונית עד גבוהה על INP
תוספים מיותרים	התוסף Query Monitor מראה מה כל תוסף טוען	השבתה, החלפה, או טעינה רק בעמודים הרלוונטיים	בינוני	בינונית
מסד נתונים מנופח	ניהול, סל וחיפוש איטיים	ניקוי גרסאות, נתונים זמניים וספאם, מעבר ל-HPOS	נמוך עד בינוני	בינונית, בעיקר על TTFB
גרסת PHP ישנה	כלי "בריאות האתר" (Site Health) בוורדפרס	שדרוג לגרסה נתמכת אחרי בדיקה בסביבת בדיקות	נמוך	בינונית

צ'קליסט מהירות אתר

העמודים המרכזיים עוברים את הערכת Core Web Vitals בנייד.
כל התמונות ב-WebP או AVIF, בגודל שמתאים לתצוגה, עם width ו-height.
התמונה הראשית לא בטעינה עצלה ומסומנת ב-fetchpriority="high", והתמונות שמתחת לקו הגלילה כן בטעינה עצלה.
מטמון עמודים פעיל, והסל, הקופה ו"החשבון שלי" מוחרגים ממנו.
צ'אט ופיקסלים נטענים רק אחרי אינטראקציה או אחרי שהעמוד נטען.
לא יותר משני פונטים, רק במשקלים שבשימוש, עם font-display מוגדר.
אין תוספים כבויים שנשכחו או כפולים, למשל שני תוספי מטמון.
גרסת PHP נתמכת, וגם וורדפרס, התבנית והתוספים מעודכנים.
אחרי כל עדכון גדול או תוסף חדש, בודקים שוב.

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

מה להעביר למפתח? המדריך הטכני

את הפרק הזה אפשר להעביר כמו שהוא למי שמתחזק את האתר, לפי המדד שרוצים לשפר.

שיפור LCP

זהו את אלמנט ה-LCP בכל תבנית עמוד, ופרקו אותו לארבעה חלקים: TTFB, השהיית טעינה, משך טעינה והשהיית רינדור, כפי שמפורט במדריך של web.dev.
ודאו שתמונת ה-LCP נמצאת ב-HTML הראשוני כתגית img, ולא כרקע ב-CSS או כתמונה שמוזרקת ב-JavaScript. אם אין ברירה, הוסיפו preload עם fetchpriority="high".
לעולם אל תגדירו loading="lazy" לתמונת ה-LCP. לפי אותו מדריך, זה תמיד יוצר עיכוב מיותר. תבניות ותוספים רבים מחילים טעינה עצלה על כל התמונות, כולל הראשונה.
fetchpriority="high" רק לתמונת ה-LCP, לא ליותר מאחת או שתיים בעמוד.
תמונות רספונסיביות עם srcset ו-sizes, ב-AVIF או WebP. וורדפרס תומכת ב-AVIF מגרסה 6.5, אם ספריית התמונות בשרת תומכת בו (בודקים בכלי בריאות האתר, תחת Media Handling).
הורדת TTFB: מטמון עמודים מלא, CDN, ובחנויות גם object cache כמו Redis.

שיפור CLS ופונטים

width ו-height, או aspect-ratio, לכל img, video ו-iframe.
מקום שמור מראש לבאנר העוגיות, לפס המבצעים ולמודעות.
לא להכניס תוכן מעל תוכן קיים אחרי הטעינה.
פונטים: WOFF2 מאוחסן מקומית, subset לעברית ולאנגלית אם הרישיון מאפשר, preload רק לפונט הראשי, ו-font-display: swap, או optional כשחשוב יותר למנוע קפיצות.

שיפור INP

לפצל משימות JavaScript ארוכות, ולתת לדפדפן לצייר תגובה לפני עבודה לא דחופה.
defer לכל סקריפט שלא נדרש לתצוגה הראשונה, וטעינת צ'אט ופיקסלים אחרי האינטראקציה הראשונה.
לצמצם את ה-DOM: פחות עטיפות, פחות אלמנטים מוסתרים במגה-מניו, בלי עותקים נפרדים לנייד ולמחשב.
לבדוק במיוחד את הפעולות הכבדות בחנות: הוספה לסל, מסננים ובחירת וריאציה.

שרת, וורדפרס ומסד נתונים

PHP בגרסה נתמכת (וורדפרס ממליצה כיום על 8.3 ומעלה), HTTP/2 או HTTP/3, ודחיסת Brotli או Gzip.
מטמון עמודים, עם החרגה של הסל, הקופה, "החשבון שלי" וכל עמוד אישי.
ניקוי והגבלה של גרסאות עמודים, מחיקת transients שפג תוקפם, ספאם וטבלאות של תוספים שהוסרו, ובדיקת הנתונים שנטענים אוטומטית מ-wp_options.

דוגמה: איך מאבחנים חנות WooCommerce איטית?

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

נניח חנות WooCommerce לציוד קמפינג בבאר שבע. הבעלים מתלוננים שהקמפיין בגוגל מביא קליקים אבל מעט רכישות מהנייד. בדיקת דף מוצר ב-PageSpeed Insights בנייד מראה בנתוני השטח: LCP של 4.6 שניות (גרוע), INP של 380 מילישניות ו-CLS של 0.18 (שניהם דורשים שיפור). העמוד לא עובר את ההערכה.

מה האבחון מגלה

LCP: אלמנט ה-LCP הוא תמונת המוצר, PNG ברוחב 2,400 פיקסלים במשקל של כ-1.8 מגה-בייט, ותוסף טעינה עצלה מחיל עליה lazy. ה-TTFB עומד על כ-1.4 שניות: אחסון שיתופי בלי מטמון עמודים.
INP: בכל עמוד נטענים צ'אט, שני פיקסלים, כלי הקלטת גולשים ותוסף סינון, גם בעמודים בלי מסנן. המגה-מניו של בונה העמודים מכיל מאות קישורים מוסתרים, ועוד עותק לנייד.
CLS: באנר העוגיות נדחף מלמעלה, כוכבי הביקורות נטענים מווידג'ט חיצוני ודוחפים את המחיר, והטקסט משנה גודל כשהפונט נטען.

תוכנית הטיפול, לפי סדר

שבוע ראשון, תיקונים מהירים: המרת תמונות המוצר ל-WebP בגודל התצוגה, הסרת lazy מהתמונה הראשית והוספת fetchpriority="high", מידות לתמונות ומקום שמור לבאנר העוגיות ולכוכבי הביקורות.
שבוע שני, שרת: אחסון עם מטמון ברמת השרת, CDN, PHP עדכני ו-object cache, עם החרגת הסל והקופה.
שבוע שלישי, סקריפטים: הסרת כלי ההקלטה שאיש לא צופה בו, טעינת הצ'אט רק אחרי גלילה או לחיצה, תוסף הסינון רק בדפי קטגוריה, ופישוט המגה-מניו.
שבוע רביעי, מסד נתונים: ניקוי גרסאות ונתונים זמניים, ומעבר ל-HPOS אחרי בדיקה בסביבת בדיקות.
מעקב: בדיקת מעבדה אחרי כל שלב ואימות ב-Search Console. נתוני השטח מתעדכנים בהדרגה, כי הם מסכמים 28 ימים.

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

מתי עדיף לבנות אתר חדש במקום לשפץ?

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

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

אתר שנבנה נכון מראש פותר את רוב השורות בטבלה כבר בשלב הפיתוח. ב-Ezweb כל אתר נבנה בהתאמה אישית, בלי תבניות מוכנות, עם בדיקת מהירות ו-SEO לפני העלייה לאוויר, בין אם זו חנות אינטרנטית ב-WooCommerce ובין אם אתר שנבנה בעזרת AI.

שאלות נפוצות

מה נחשב מהירות אתר טובה ב-2026?

לפי הספים של גוגל, עמוד נחשב מהיר כשה-LCP שלו עד 2.5 שניות, ה-INP עד 200 מילישניות וה-CLS עד 0.1. כדי לעבור, לפחות 75% מהביקורים האמיתיים צריכים לעמוד ביעד בשלושת המדדים, בנפרד לנייד ולמחשב. הציון מ-0 עד 100 של PageSpeed הוא בדיקת מעבדה, שימושית לאבחון, אבל הוא לא מה שקובע אם העמוד עובר.

האם צריך ציון 100 ב-PageSpeed?

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

כמה זמן לוקח לראות שיפור אחרי התיקונים?

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

האם תוסף מטמון לבד יפתור את הבעיה?

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

האם Elementor או בונה עמודים אחר הורסים את מהירות האתר?

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

האם מהירות האתר משפיעה על ההופעה ב-ChatGPT וב-AI Overviews?

ב-AI Overviews של גוגל אין דרישות נוספות מעבר ל-SEO רגיל, וגוגל מונה חוויית עמוד טובה כחלק מהבסיס. לגבי ChatGPT ו-Perplexity לא מצאנו ספי מהירות רשמיים, אבל מחקר של Vercel ו-MERJ מ-2024 מצא שסורקי ה-AI הגדולים לא הריצו JavaScript. לכן חשוב שהתוכן יופיע ב-HTML הראשוני, ושהשרת יענה מהר ובאופן יציב.

סיכום: מהירות היא חלק מהשירות שלכם

מהירות אתר היא לא ציון לתלות על הקיר, אלא חלק מהחוויה שהלקוח מקבל. שלושה מדדים מסכמים אותה: LCP עד 2.5 שניות, INP עד 200 מילישניות ו-CLS עד 0.1, על גולשים אמיתיים. בוורדפרס, רוב השיפור מגיע מתמונות, משרת ומטמון ומצמצום סקריפטים. התחילו מטבלת העדיפויות, תעדו לפני ואחרי, ותנו לנתוני השטח חודש להתעדכן.

רוצים לדעת איפה האתר שלכם עומד? הזמינו בדיקת SEO ומהירות חינם לאתר קיים, בתוקף עד 31.12.2026, ובדקו תוך שניות אם מנועי AI יכולים לקרוא ולצטט אותו בבדיקת המוכנות ל-AI החינמית. ואם עדיף להתחיל מחדש, הכירו את שירות בניית אתרי תדמית שלנו, עם בדיקת מהירות לפני העלייה לאוויר.