עודכן לאחרונה: · מאת עשהאל דרייר
בקצרה: אתר איטי בקלאודוויז (Cloudways) נובע לרוב מאחת מחמש סיבות: תנועה של בוטים, עמוד או שאילתה כבדים, משימות Cron, קאש שלא עובד, או שרת קטן מדי. מאתרים אותה בסדר קבוע: קודם Monitoring של השרת כדי לראות איזה משאב ואיזו אפליקציה עמוסים, ואז Monitoring של האפליקציה (Traffic, PHP, MySQL) כדי למצוא את הגורם. רק אחרי שהעומס אמיתי ולגיטימי, מגדילים שרת.
⏱ זמן אבחון: 15–45 דקות · רמת קושי: בינוני · נבדק לאחרונה מול התיעוד הרשמי: 06.11.2026
למה אתר נהיה איטי: שתי משפחות של בעיות
הסעיף הזה עוזר להבין אם הבעיה בשרת או מחוץ לו, לפני שמתחילים לחפש.
איטיות בצד השרת היא כשהשרת לוקח הרבה זמן לבנות את העמוד. מודדים אותה ב-TTFB (Time To First Byte), הזמן עד שהבייט הראשון מגיע. כאן נמצאים CPU גבוה, זיכרון שנגמר, שאילתות איטיות ובוטים.
איטיות בצד הדפדפן היא כשהעמוד מגיע מהר אבל לוקח זמן להציג אותו: תמונות כבדות, הרבה JavaScript, פונטים. שרת חזק יותר לא יפתור אותה. לזה יש את המדריך להאצת וורדפרס וההגדרות המתקדמות של Breeze.
איך מבדילים? הריצו בדיקה ב-PageSpeed Insights או בכלי הפיתוח של הדפדפן (לשונית Network) ותסתכלו על זמן התגובה של המסמך הראשי. לפי web.dev, TTFB של עד 0.8 שניות נחשב טוב, ומעל 1.8 שניות נחשב גרוע. אם הוא קרוב ל-1.8 שניות ומעלה באופן קבוע, הבעיה בשרת וזה המדריך בשבילכם.
| סימפטום | סיבה סבירה | איפה בודקים |
|---|---|---|
| כל האתרים בשרת איטיים בבת אחת | משאב שנגמר (CPU או RAM) או בוטים באתר אחד שמעמיס על כולם | Server > Monitoring > Summary |
| רק אתר אחד איטי | תוסף, שאילתה או בוטים באותו אתר | Application > Monitoring > PHP, MySQL, Traffic |
| רק לוח הניהול (wp-admin) איטי | תוספים כבדים, Heartbeat, autoload נפוח | PHP > Slow Pages, Breeze > Heartbeat |
| איטי בשעות קבועות | גיבוי, Cron או סריקה מתוזמנת | Server > Details לאורך 24 שעות, Running Crons |
| שגיאות 502 או 504 לסירוגין | עומס יתר, timeout של PHP או שירות שקרס | Error Logs, Manage Services |
| איטי רק לגולשים בישראל, מהיר מחו"ל | שרת רחוק מישראל | מיקום השרת (ראו בהמשך) |
לפני שמתחילים
- הרשאה לשרת ולאפליקציה בפאנל הניהול.
- כתבו לעצמכם מתי בדיוק האתר היה איטי. בלי חלון זמן, הגרפים לא יעזרו. זכרו שהפאנל מציג זמנים ב-UTC (שעתיים או שלוש פחות משעון ישראל).
- אם עומדים לכבות תוספים או לשנות הגדרות, קחו קודם גיבוי, או בדקו בסביבת Staging.
איך מאבחנים אתר איטי בשישה צעדים?
הסדר חשוב. כל צעד מצמצם את החשודים לצעד הבא, ולא מבזבזים זמן על אופטימיזציה של דבר שלא היה הבעיה.
- זהו את המשאב. פתחו את השרת > Monitoring > Summary. בדקו CPU, RAM ודיסק. לפי קלאודוויז, CPU קבוע מעל 80% הוא עומס אמיתי, וזיכרון פנוי שיורד בקביעות מתחת ל-100MB גורם לקריסות. דיסק מלא גורם לבעיות משלו; ראו דיסק מלא או Inodes גמורים.
- זהו את האתר. באותו מסך פתחו Application Wise Details ובדקו לאיזו אפליקציה יש הכי הרבה CPU ו-Memory.
- זהו את הזמן. בלשונית Details בחרו CPU Consumption לטווח 24 שעות או 7 ימים. עומס קבוע מצביע על תנועה או קוד; קפיצות בשעות קבועות מצביעות על Cron או גיבוי.
- בדקו מי שולח בקשות. באפליקציה החשודה: Monitoring > Analytics > Traffic, לשוניות IP Requests ו-Bot Traffic לטווח העומס.
- בדקו מה איטי. PHP > Slow Pages ו-MySQL > Slow Queries. כל עמוד או שאילתה מעל חמש שניות נרשמים שם.
- תפסו את התהליך בזמן אמת. אם העומס קורה עכשיו, התחברו ב-SSH והריצו
htop, ואז ב-PHP > Running Processes ו-Running Crons.


הסבר מפורט על כל מסך נמצא בשני מדריכי הניטור: ניטור שרת וניטור אפליקציה.
מהן הסיבות הנפוצות ואיך מטפלים בכל אחת?
אחרי האבחון, כנראה שמצאתם את עצמכם באחד המצבים הבאים.
בוטים וסריקות
זו אחת הסיבות הנפוצות ל-CPU גבוה. בוטים של כלי SEO, סורקי AI, ניסיונות התחברות ל-wp-login.php ובקשות ל-xmlrpc.php יכולים לייצר יותר עומס מכל הגולשים האמיתיים.
- ודאו שגישת XMLRPC כבויה. לפי קלאודוויז היא כבויה כברירת מחדל, ואפשר לבדוק בלשונית WordPress תחת Settings של האפליקציה (ראו הצילום למטה). השאירו אותה פעילה רק אם יש שירות שבאמת צריך אותה (למשל Jetpack ישן או אפליקציית מובייל ישנה).
- חומת האש של השרת (Imunify360) כוללת הגנה מפני בוטים ו-DoS. ההגדרות והאפשרויות מוסברות במדריך לחסימת בוטים בקלאודוויז.
- כתובת IP בודדת שתוקפת אפשר לחסום ב-.htaccess או בחומת האש, אבל בוטים מתחלפים בכתובות. הגנה ברמת השרת או ב-CDN יעילה יותר מרדיפה אחרי כתובות.

תוסף, עמוד או שאילתה כבדים
אם Slow Pages מראה עמודים מסוימים, ו-Slow Queries מראה שאילתות באותו זמן, הבעיה בקוד או במסד הנתונים.
- autoload נפוח: וורדפרס טוענת את כל האפשרויות שמסומנות autoload בכל עמוד. באתרים ותיקים הטבלה הזו מתנפחת מתוספים שהוסרו. לפי קלאודוויז, שכבת ה-Object Cache בשרת דוחה אובייקטים מעל 900KB, ואז autoload גדול מדי גורם לוורדפרס לטעון אותו פעמיים. בודקים עם
wp doctor check autoload-options-size(אחרי התקנת חבילת doctor ל-WP-CLI). - תוסף כבד: אם בעמוד מסוים יש שאילתה שחוזרת, שם הטבלה או הפונקציה בדרך כלל מסגירים את התוסף. בדקו ב-יומן השגיאות, ואם צריך, כבו תוספים אחד-אחד בסביבת Staging.
- Object Cache: בחנויות ווקומרס ובאתרים עם משתמשים מחוברים, Object Cache מוריד הרבה שאילתות חוזרות. ראו Object Cache Pro.
Cron ו-WP-Cron
משימות מתוזמנות שרצות לעתים קרובות מדי הן סיבה נפוצה ל-CPU גבוה בשעות קבועות. קלאודוויז ממליצה לרווח משימות Cron לפחות 15 דקות זו מזו. WP-Cron של וורדפרס רץ בכל טעינת עמוד, ובאתר עמוס זה מבוזבז. ההחלפה ב-Cron אמיתי של השרת מוסברת במדריך ל-Cron Jobs ו-WP-Cron.
קאש שלא עובד
אם הקאש עובד, רוב הבקשות של גולשים אנונימיים לא מגיעות ל-PHP בכלל. אם Requested Pages מלא בעמודי בית ופוסטים רגילים, משהו עוקף את הקאש: עוגייה, פרמטר בכתובת, או הגדרה שכובתה. בדקו את Varnish ואת Breeze, ואחרי שינוי נקו את הקאש.
שירות שקרס או נתקע
כש-PHP-FPM, Apache או Nginx נתקעים, האתר מחזיר 502 גם אם המשאבים תקינים. על מקרה נפוץ אחד, OPcache מלא בוורדפרס עם PHP-FPM, קראו במדריך נפרד. ב-Manage Services של השרת אפשר להפעיל מחדש את השירותים ולנקות את Varnish. אם זה חוזר על עצמו, בדקו את Auto Healing Restarts בניטור: שירות שנהרג שוב ושוב בגלל זיכרון מצביע על שרת קטן מדי או על דליפת זיכרון בתוסף. כדי לאתר את התוסף האשם ראו איך מוצאים איזה תוסף מאט את האתר.
השרת רחוק מהגולשים
כשכל הגולשים שלכם בישראל והשרת בצד השני של העולם, כל בקשה עוברת מרחק גדול, וזה מורגש במיוחד בעמודים שלא בקאש. בתל אביב יש מרכזי נתונים של AWS, Google Cloud ו-Vultr, וכולם זמינים בקלאודוויז, ולצדם מיקומים קרובים באירופה. את המחיר בתל אביב רואים בפאנל לפני הקמת השרת. השוואה מלאה נמצאת במדריך מיקומי השרתים. CDN מקצר את המרחק לקבצים סטטיים; ראו חיבור CDN ל-Breeze.
מתי באמת צריך להגדיל שרת
הגדלת שרת היא הפתרון הנכון רק כשהעומס אמיתי. אחרת משלמים יותר על אותה בעיה.
| מצב | מה עושים |
|---|---|
| CPU קבוע מעל 80%, התנועה לגיטימית, הקאש עובד | מגדילים שרת |
| זיכרון פנוי מתחת ל-100MB בקביעות ו-Auto Healing Restarts חוזרים | מגדילים RAM, או מפצלים אתרים לשרת נוסף |
| CPU גבוה ורוב הבקשות מבוטים | חוסמים בוטים קודם, ובודקים שוב אחרי יום |
| CPU גבוה רק בשעות קבועות | מרווחים Cron וגיבויים, לא מגדילים |
| עמוד אחד איטי, השאר מהירים | מתקנים את העמוד או התוסף, לא מגדילים |
ההגדלה עצמה נעשית מהפאנל וכתוב איך במדריך להגדלת שרת. טיפ: אחרי הגדלה, עקבו אחרי הגרפים לפחות יום. אם ה-CPU עלה שוב לאותו מקום, הבעיה לא היתה בגודל.
תקלות שנראות כמו "אתר איטי" אבל הן משהו אחר
- לולאת הפניות או אזהרות HTTPS שגורמות לעמוד להיתקע: Mixed Content ו-Too Many Redirects.
- האתר "נתקע" ואז מציג שגיאת מסד נתונים: Error Establishing a Database Connection.
- העלאת קבצים שנתקעת או נכשלת: שגיאות העלאה בוורדפרס.
- דיסק מלא שגורם לכתיבות להיכשל: דיסק מלא או Inodes גמורים.
טעויות נפוצות
להגדיל שרת לפני אבחון: הטעות הכי יקרה. אם הבעיה בבוטים, הם פשוט ינצלו גם את השרת הגדול.
להתקין עוד תוסף אופטימיזציה: שני תוספי קאש במקביל מתנגשים, ותוסף "ניקוי" שרץ ברקע מוסיף עומס. בקלאודוויז Breeze ו-Varnish כבר מוגדרים לעבוד יחד.
לבדוק כשהאתר כבר מהיר: הגרפים והטבלאות מתמלאים לפי טווח זמן. בחרו את הטווח שבו היתה האיטיות, ולא "15 דקות אחרונות".
להתעלם מאתרים אחרים באותו שרת: אתר בדיקות נטוש עם תוסף פרוץ יכול להאט את אתר הלקוח הראשי. Application Wise Details מראה את זה תוך שנייה.
לא לקבל התראה: אם גיליתם את העומס מלקוח שהתקשר, הגדירו התראות CloudwaysBot לפעם הבאה.
הקוד BFCM802 מוריד 80% מהחשבון בחודשיים הראשונים (עד 200$ הנחה בחודש), כולל העברת אתרים חינם בלי הגבלה. ללקוחות חדשים בלבד, ורק עד סוף המבצע.
המבצע מסתיים ב-4 בדצמבר 2026, ב-23:59 שעון ישראל.
מתחילים בניסיון חינם, בלי כרטיס אשראי. את הקוד מזינים בקופה ובודקים שהוא מופיע.
אחרי בלאק פריידי: 30% הנחה ל-3 חודשים עם הקוד ASAEL. בשרת גדול (מעל כ-444$ בחודש) ASAEL משתלם יותר כבר עכשיו. למחשבון BFCM802 מול ASAEL
פותחים שרת ניסיון חינם, בלי כרטיס אשראי. כשעוברים לתוכנית בתשלום, הקוד ASAEL מוריד 30% מהחשבון בשלושת החודשים הראשונים.
הקישור ממלא את הקוד בטופס ההרשמה. רק ודאו שהוא מופיע.
מקורות
- web.dev: Time to First Byte (TTFB)
- Cloudways Knowledge Base: How to monitor the CPU usage of a server on Cloudways
- Cloudways Knowledge Base: How to monitor server and application resources on Cloudways Flexible
- Cloudways Knowledge Base: How to fix 502 bad gateway error
- Cloudways Knowledge Base: Disable XML-RPC in WordPress applications
- Cloudways Knowledge Base: How to clean up autoloaded options in WordPress
שאלות נפוצות
הסיבות הנפוצות הן בוטים, תוסף או שאילתה כבדים, משימות Cron תכופות, או קאש שלא עובד. בדקו ב-Application Wise Details איזה אתר אחראי, ואז ב-Traffic וב-Slow Pages של אותו אתר. רק אם העומס לגיטימי והקאש עובד, הגדילו שרת.
מסתכלים על זמן התגובה של המסמך הראשי (TTFB) בכלי בדיקת מהירות. TTFB גבוה מצביע על השרת. TTFB נמוך עם טעינה ארוכה מצביע על תמונות, סקריפטים ופונטים, ושם שרת חזק יותר לא יעזור.
רק אם העומס אמיתי. אם הבעיה בבוטים, ב-Cron או בתוסף, הגדלה רק תדחה אותה ותעלה את החשבון. קלאודוויז ממליצה לשקול הגדלה כשה-CPU נשאר מעל 80% לאורך זמן.
כן. התקפות על xmlrpc.php ו-wp-login.php שולחות כמויות גדולות של בקשות POST וצורכות משאבים. בקלאודוויז הגישה ל-XMLRPC כבויה כברירת מחדל, וכדאי להשאיר אותה כך אם אין לכם שירות שצריך אותה.
בדרך כלל בגלל משימה מתוזמנת: גיבוי, Cron של תוסף, סנכרון מלאי או סריקה. בדקו את גרף CPU Consumption ל-24 שעות ואת Running Crons בזמן העומס, ורווחו משימות לפחות 15 דקות זו מזו.
כן, במיוחד בעמודים שלא נמצאים בקאש. שרת קרוב לישראל מקצר את זמן התגובה, ו-CDN מקצר את הדרך לקבצים הסטטיים. בתל אביב יש מרכזי נתונים של AWS, Google Cloud ו-Vultr.
מדריכים קשורים
- איך לנטר שרת: CPU, RAM, דיסק ו-htop
- איך לנטר אפליקציה: תנועה, PHP, מסד נתונים ו-Cron
- Mixed Content ו-Too Many Redirects בוורדפרס
- Error Establishing a Database Connection
- כל מדריכי פתרון התקלות: פתרון תקלות בקלאודוויז
- שוקלים שרת מנוהל? הביקורת המלאה על קלאודוויז
מקור רשמי: How to Monitor the CPU Usage of a Server, How to Monitor Server and Application Resources, How to Fix 502 Bad Gateway Error, Disable XMLRPC in WordPress Applications, How to Clean Up Autoloaded Options in WordPress (Cloudways Knowledge Base), ו-Time to First Byte (TTFB) (web.dev). המדריך נכתב ונבדק על ידי עשהאל דרייר · עודכן: 06.11.2026
גילוי נאות: זהו אתר עצמאי ואינו האתר הרשמי של Cloudways. חלק מהקישורים באתר הם קישורי שותפים – אם תירשמו דרכם נקבל עמלה, בלי עלות נוספת לכם. לפרטים המלאים