לקוחות מתלוננים על מהירות? הנה מה לעשות

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

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

שלב 1: מדדו לפני שאמרתם כלום

לפני שמסבירים לכלום — תמדדו:

Google PageSpeed Insights: נכנסים ל-pagespeed.web.dev → מכניסים URL → מחכים לתוצאות.

מה לחפש:

• ציון Performance (0–100)
• LCP (Largest Contentful Paint)
• TTFB ב-"Server response times"

כלל אצבע:

• ציון מעל 70 + LCP מתחת ל-2.5s = האתר לא באמת איטי, הלקוח מרגיש זמן אחר
• ציון מתחת ל-50 = יש בעיה אמיתית

שלב 2: זיהוי הגורם — שרת או צד-לקוח?

בדקו TTFB: Chrome DevTools (F12) → Network → טענו מחדש → לחצו על הבקשה הראשונה → Timing → "Waiting (TTFB)".

אם TTFB מתחת ל-400ms — קפצו לשלב 4 (צד לקוח).

אם TTFB מעל 400ms — המשיכו לשלב 3.

שלב 3: תיקון TTFB גבוה (בעיות שרת)

בדיקה 1: האם קאשינג מופעל?

ב-WordPress admin → Settings → WP Rocket (אם מותקן) → בדקו שPage Cache מופעל.

ב-Cloudways: Application → Application Management → Varnish → האם מופעל?

כאשר קאשינג כבוי — TTFB יהיה 300–600ms אפילו על שרת טוב, כי כל בקשה מריצה PHP + MySQL. הפעלת קאשינג יורידה TTFB ל-50–200ms.

בדיקה 2: Redis Object Cache

הריצו במסוף:

wp redis status

אם מוצג "Not connected" — חברו Redis.

ב-Kinsta: Redis כלול — רק התקינו את תוסף Redis Object Cache → הפעלה.

ב-Cloudways: Application → Add-Ons → Redis → Enable.

ב-שיתופי/SiteGround: Redis לא זמין. זהו גורם מגביל.

בדיקה 3: PHP version

ב-admin → Tools → Site Health → בדקו גרסת PHP.

• PHP 8.3: מעולה
• PHP 8.1: טוב
• PHP 7.4: מומלץ לשדרג
• PHP 7.x ומטה: שדרגו עכשיו — 30–40% איטי יותר

ב-Cloudways: Application → PHP Settings → PHP version → בחרו 8.3.

שלב 4: תיקונים בצד לקוח

תיקון 1: Lazy Loading לתמונות

ב-WP Rocket: Media → Lazy load images → מופעל?

ידנית:

// ב-functions.php
add_filter('wp_lazy_loading_enabled', '__return_true');

השפעה: תמונות מתחת לfold לא נטענות עד שהגולש מגיע אליהן. מוריד LCP ב-0.5–1.5s באתרים עם הרבה תמונות.

תיקון 2: WebP + דחיסת תמונות

בדקו אם תמונות הן WebP: Chrome DevTools → Network → סננו Images → בדקו Type.

אם הן JPG/PNG ולא WebP:

• התקינו Smush → הפעילו WebP conversion
• וורדפרס 6.1+ כבר תומך WebP מובנית: הגדרות → מדיה

חיסכון טיפוסי: 25–40% בנפח תמונה.

תיקון 3: Elementor Asset Loading

Elementor טוען CSS על כל עמוד גם אם לא בשימוש:

Elementor → Settings → Experiments → Improved Asset Loading → Active

השפעה: מוריד Render-Blocking CSS ב-30–60%.

תיקון 4: Google Fonts מקומי

בדקו שגופנים נטענים מהשרת שלכם ולא מGoogle:

PageSpeed Insights → Opportunities → "Eliminate render-blocking resources" → בדקו אם fonts.googleapis.com מופיע.

אם כן:

1. התקינו תוסף OMGF (חינמי)
2. הוא יוריד את הגופנים לשרת ויחליף את ה-CDN requests

שלב 5: בדיקה שניה + דו"ח ללקוח

אחרי שביצעתם תיקונים:

1. הריצו שוב Google PageSpeed Insights
2. צלמו מסך של הפני ואחרי
3. שלחו ללקוח מייל עם:
   • מה היה: ציון X, LCP X שניות
   • מה עשינו: רשימת פעולות
   • מה יש עכשיו: ציון Y, LCP Y שניות

זה ממחיש ערך ומפחית תלונות עתידיות.

כשהכל לא עוזר — שאלת האחסון

אם ביצעתם הכל וה-TTFB עדיין מעל 600ms — הבעיה היא האחסון.

הצגה ללקוח: "ה-TTFB שלך הוא X ms. זה אומר שהשרת לוקח X ms לענות לפני שהדפדפן מתחיל לטעון כלום. אין אופטימיזציה שתתקן שרת איטי. המעבר ל-[Cloudways/Kinsta] יוריד את זה ל-387ms / 312ms.

עבור אתר עם X מבקרים חודשיים, השיפור הצפוי בהמרות הוא Y% — שמתורגם ל-₪Z חודשי."

אתר שמפסיד ₪500/חודש בגלל אחסון איטי לא צריך שיכנוע — הוא צריך נתונים.