אחסון וורדפרס המהיר ביותר 2026: איך למדוד בעצמכם

אין ספק אחסון אחד שהוא "אחסון הוורדפרס המהיר ביותר", וכל מי שמגיש לכם רשימה מדורגת עם מספר מילישניות ליד כל שם מתאר בדיקה אחת, בחבילה אחת, ביום אחד, ממיקום אחד. מה שאתם באמת צריכים הוא את אחסון הוורדפרס המהיר ביותר עבור האתר שלכם והגולשים שלכם, וזה משהו שרק אתם יכולים למדוד. המדריך הזה מסביר מה באמת קובע את זמן התגובה של השרת (TTFB) בוורדפרס, נותן לכם פקודות אמיתיות למדידת האתר שלכם, מראה איך לקרוא נכון את PageSpeed Insights, ומשווה בין קטגוריות אחסון לפי ארכיטקטורה במקום לפי מספרים שאיש לא יכול לשחזר.

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

נקודות מפתח

• מספר TTFB בודד שמתפרסם לצד שם של ספק הוא כמעט חסר משמעות. הוא משקף חבילה אחת, אתר בדיקה אחד, רגע אחד ונקודת מדידה אחת, והוא לא ינבא את התוצאה שלכם.
• רוב זמן התגובה שלכם נקבע בארבעה דברים: גרסת PHP ו-OPcache, מטמון דף מלא, מטמון אובייקטים וזמן שאילתות מסד הנתונים, והמרחק הפיזי בין השרת לגולש.
• ההנחיה של גוגל ב-web.dev מגדירה TTFB טוב כ-0.8 שניות או פחות, ומציינת ש-TTFB עצמו אינו מדד Core Web Vitals. אין טעם לרדוף אחרי 200ms בשרת כשתמונת ה-LCP שלכם שוקלת 3 מגה-בייט.
• אפשר למדוד את זמן התגובה האמיתי עם הרצת curl מפולחת, לולאת דגימות חוזרות ובקשה שמכריחה החטאת מטמון. עשרים דגימות שוות יותר מצילום מסך אחד מאתר בדיקות.
• בחרו קודם קטגוריה של אחסון: וורדפרס מנוהל, שיתופי עם LiteSpeed, VPS ענן בניהול עצמי, או ארכיטקטורת קצה. הארכיטקטורה מנבאת את התוצאה הרבה יותר טוב מכל דירוג מותגים.
• Devoster מגישה ממיקום יחיד בדרום ארה"ב. לקהל ישראלי זה אומר תוספת השהיה אמיתית בכל בקשה שלא נשמרה במטמון, וצריך לקחת את זה בחשבון לפני הרכישה.

מה באמת אומר "אחסון וורדפרס מהיר"

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

TTFB הוא המדד הכן בצד השרת. התיעוד של גוגל ב-web.dev מגדיר אותו כסכום של זמן ההפניות, הפעלת service worker, חיפוש DNS, יצירת חיבור ומשא ומתן TLS, והבקשה עצמה עד הבייט הראשון. הסף לטוב הוא 0.8 שניות או פחות, ומעל 1.8 שניות נחשב גרוע. חשוב לא פחות: אותו עמוד מציין ש-TTFB אינו מדד Core Web Vitals, כלומר הוא כלי אבחון ולא ציון.

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

בדיקה אחת, חבילה אחת, יום אחד, מיקום אחד

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

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

למה בנצ'מרק של ספק לא מנבא את התוצאה שלכם

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

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

מה באמת קובע את זמן התגובה של וורדפרס

גרסת PHP ו-OPcache

וורדפרס בונה כל דף שאינו במטמון על ידי הרצת PHP. גרסאות PHP חדשות מהירות משמעותית מישנות, והרצת ענף שהגיע לסוף חייו היא בעיית ביצועים ואבטחה כאחד. לפי עמוד הגרסאות הנתמכות של php.net, נכון לספטמבר 2026 גרסאות 8.4 ו-8.5 נמצאות בתמיכה פעילה, גרסה 8.2 בתמיכת אבטחה בלבד שמסתיימת ב-31 בדצמבר 2026, וגרסה 8.3 בתמיכת אבטחה עד 31 בדצמבר 2027. ספק שלא יכול להציע לכם ענף נתמך הוא סיבה לעזוב.

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

php -i | grep -E "opcache.enable|opcache.memory_consumption|opcache.max_accelerated_files"
    

באחסון שיתופי לרוב אין גישה למסוף, ולכן בדקו את עמוד ה-PHP info בלוח הבקרה. ב-cPanel זה בדרך כלל תחת Software, ואז Select PHP Version, ואז Extensions.

מטמון דף מלא, המנוף הגדול ביותר

מטמון דף מלא שומר את ה-HTML המוגמר ומגיש אותו בבקשה הבאה בלי לגעת ב-PHP או ב-MySQL בכלל. ההפרש בין פגיעה להחטאה במטמון על אותו שרת גדול בדרך כלל בהרבה מההפרש בין שני ספקים. לכן "מי הספק הכי מהיר" היא כל כך הרבה פעמים השאלה הלא נכונה: אתר עם מטמון טוב בחבילה צנועה ינצח אתר בלי מטמון בחבילה יקרה.

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

מטמון אובייקטים וזמן שאילתות

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

כדי לגלות אם מסד הנתונים הוא צוואר הבקבוק, הפעילו זמנית תיעוד שאילתות ב-wp-config.php באמצעות define('SAVEQUERIES', true); והתקינו את Query Monitor על עותק סטייג'ינג. תראו את מספר השאילתות, זמן השאילתות הכולל, ואיזה תוסף אחראי לאיטיות. אתר עם ממשק ניהול איטי וחזית מהירה כמעט תמיד סובל ממטמון אובייקטים חסר או מטבלת wp_options נפוחה. החלפת ספק לא מתקנת אף אחד מאלה.

המרחק הפיזי מהגולש

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

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

שכנים, קלט/פלט ומגבלות משאבים

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

מדדו את האתר שלכם: פקודות שנותנות מספרים אמיתיים

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

מדידת curl מפולחת

זמן טעינה כולל מסתיר לאן הלך הזמן. curl יודע לפרק את הבקשה לשלבים כדי שתראו אם הבעיה ב-DNS, ב-TLS או באמת בשרת.

curl -sS -o /dev/null -w "dns      %{time_namelookup}\ntcp      %{time_connect}\ntls      %{time_appconnect}\npretrans %{time_pretransfer}\nttfb     %{time_starttransfer}\ntotal    %{time_total}\n" https://example.com/
    

איך קוראים את זה: השורה ttfb היא זמן התגובה. חסרו את pretrans מ-ttfb ותקבלו את זמן החשיבה של השרת, שהוא החלק היחיד שבאמת באחריות הספק. אם dns תופס נתח גדול מהזמן הכולל, הבעיה אצל ספק ה-DNS ולא אצל המארח. אם ההפרש בין tls ל-tcp גדול, בדקו את שרשרת התעודות ואת חידוש הסשן ב-TLS.

קחו דגימות חוזרות, לא ירייה אחת

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

for i in $(seq 1 20); do
  curl -sS -o /dev/null -w "%{time_starttransfer}\n" https://example.com/
  sleep 3
done | sort -n | awk '{v[NR]=$1} END {printf "n=%d  min %.3f  median %.3f  p90 %.3f  max %.3f\n", NR, v[1], v[int(NR*0.5)+1], v[int(NR*0.9)], v[NR]}'
    

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

הכריחו החטאת מטמון

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

curl -sS -o /dev/null -w "cache-miss ttfb %{time_starttransfer}\n" "https://example.com/?nocache=$(date +%s)"
    

השוו את זה למספר מהמטמון. אם התשובה מהמטמון מהירה וההחטאה איטית פי כמה, הספק עושה את החלק הקל היטב ואת החלק הקשה פחות. הפער הזה הוא מה שלקוח מחובר או קונה ב-WooCommerce חווה בכל עמוד. הוספת -H "Cache-Control: no-cache" היא חלופה חלשה יותר, כי הרבה שכבות מטמון מתעלמות מהוראות מטמון בצד הבקשה.

בדקו אם הוגשתם מהמטמון

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

curl -sSI https://example.com/ | grep -iE "cache|age:|server:|vary"
    

כותרת אחת שאפשר לסמוך עליה מתועדת במסמכי המטמון של Cloudflare: CF-Cache-Status, עם ערכים כמו HIT, MISS, EXPIRED, BYPASS ו-DYNAMIC. אם אתם רואים DYNAMIC על ה-HTML, Cloudflare בכלל לא שומרת את הדפים שלכם ואתם משלמים על קפיצה נוספת בלי התועלת.

מדדו מהמקום שבו הגולשים באמת נמצאים

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

לקרוא נכון את PageSpeed Insights: נתוני שדה מול נתוני מעבדה

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

היבט	נתוני שדה (CrUX)	נתוני מעבדה (Lighthouse)
מקור	משתמשי Chrome אמיתיים שהצטרפו	טעינה מדומה אחת, מווסתת
חלון זמן	28 הימים האחרונים	הרגע הזה
על מה עונה	האם לגולשים שלי באמת טוב	מה טכנית לא בסדר בעמוד
זמינות	רק כשיש מספיק תנועה לכתובת או לדומיין	תמיד
תגובה לתיקון	איטית, ככל שחלון 28 הימים מתגלגל	מיידית
למה משמש	להחליט אם בכלל יש בעיה	להחליט מה לשנות

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

קטגוריות אחסון והפשרות הארכיטקטוניות שלהן

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

קטגוריה	מאיפה מגיעה המהירות	חזק ב	חלש ב	מי מכוון את הסטאק
וורדפרס מנוהל (Kinsta, WP Engine, Nexcess וכדומה)	סטאק מוגדר מראש, מטמון דף ואובייקטים מובנים, סטייג'ינג וגיבויים	צוותים שלא רוצים לגעת בשרת	מחיר לאתר, הגבלות תוספים, מגבלות ביקורים	הספק
אחסון שיתופי עם LiteSpeed או Nginx	מטמון ברמת השרת ולוח בקרה, עלות נמוכה לאתר	אתרי תדמית, בלוגים, תנועה נמוכה עד בינונית	תקרות מעבד וקלט/פלט, ביצועים בהחטאת מטמון תחת עומס	בעיקר הספק
VPS ענן בניהול עצמי	מעבד וזיכרון ייעודיים, אתם בוחרים PHP, מטמון וכוונון מסד נתונים	שליטה, יעילות עלות בקנה מידה, כמה אתרים על מכונה אחת	עדכונים, גיבויים ואבטחה עליכם	אתם
קצה או סטטי (מטמון HTML מלא ב-CDN, או וורדפרס headless)	מגיש HTML שמור מנקודת נוכחות קרובה לגולש	קהל גלובלי, גלי תנועה, תוכן ברובו סטטי	עמודים אישיים, מחוברים ומסחריים שלא ניתן לשמור	אתם וה-CDN

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

איפה Devoster מתאימה ואיפה לא

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

באחסון שיתופי, חבילת Lite עומדת על 2.90 דולר לחודש ו-Standard על 5.90 דולר לחודש נכון לכתיבת שורות אלה, שתיהן עם cPanel, מה שמאפשר בחירת גרסת PHP וניהול הרחבות בלי מסוף. בצד ה-VPS, החבילות נעות מ-Nano ב-3.49 דולר לחודש ועד Mega ב-34.99 דולר לחודש. כל חבילות ה-VPS הן KVM עם גישת root מלאה, רצות על מעבדי Intel Xeon Gold 6138 עם אחסון NVMe וקו 1 Gbps, כוללות תעבורה ללא הגבלה וכתובת IPv4 אחת, ומגיעות עם הגנת DDoS והעברה חינם.

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

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

עץ החלטה לבחירת קטגוריה

עברו על אלה לפי הסדר ועצרו בהתאמה הראשונה.

• אם הקהל שלכם פרוס על כמה יבשות והעמודים ברובם ציבוריים וניתנים לשמירה, אז התחילו ממטמון HTML מלא בקצה והתייחסו לספק המקור כהחלטה משנית.
• אם אתם מפעילים WooCommerce או אתר מנויים שבו רוב הסשנים מחוברים, אז תנו עדיפות למעבד במקור, למרווח נשימה ב-PHP workers ולמטמון אובייקטים קבוע, והיו חשדניים כלפי ספק שכל המצגת שלו היא ה-CDN.
• אם אף אחד בצוות לא מרגיש בנוח במסוף, אז בחרו וורדפרס מנוהל או אחסון שיתופי עם cPanel, לא VPS לא מנוהל. השרת הזול מפסיק להיות זול ברגע שהוא נשבר.
• אם אתם מנהלים כמה אתרים ויש מי שיריץ עדכונים וגיבויים, אז VPS בדרך כלל משתלם יותר לאתר. ראו את המדריך על אירוח כמה אתרים על VPS אחד.
• אם יש לכם כמה אלפי כניסות בחודש לבלוג או לאתר תדמית, אז אחסון שיתופי עם מטמון ברמת השרת באמת מספיק, והכסף עדיף על התמונות והתבנית.
• אם יש לכם דרישה חוקית או חוזית למיקום נתונים, אז רשימת האזורים מחליטה לפניכם עוד לפני שאלת הביצועים.

איך לשפוט כל בנצ'מרק מהירות שמתפרסם

אם בנצ'מרק לא עונה על לפחות חמש מהשאלות האלה, התעלמו מהמספרים שלו.

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

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

מה החלפת ספק לא תתקן

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

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

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

תוכנית מדידה לפני הגירה

• בסיס, שבוע לפני. הריצו את לולאת עשרים הדגימות על דף הבית, על עמוד תוכן עמוק, ועל עמוד שלא ניתן לשמור כמו עגלה או חשבון. שמרו את הפלט וצלמו את נתוני השדה ב-PageSpeed Insights.
• תעדו את התנאים. רשמו את גרסת ה-PHP, אם מטמון אובייקטים פעיל, איזה CDN מלפנים, ומאיפה מדדתם. בלי זה ההשוואה חסרת ערך אחר כך.
• הורידו TTL ב-DNS. ל-300 שניות לפחות 24 שעות לפני המעבר, כדי שתוכלו לחזור אחורה מהר.
• בדקו את הספק החדש לפני DNS. הפנו רשומת hosts או תת-דומיין זמני לשרת החדש והריצו את אותן שלוש בדיקות, באותן שעות ביום.
• מדדו שוב אחרי 24 שעות ואחרי 30 יום. מספרי ה-curl יזוזו מיד. נתוני השדה ייקחו עד 28 יום בגלל חלון האיסוף המתגלגל.
• השאירו את הספק הישן פעיל שבוע. זו פוליסת ביטוח זולה ומאפשרת השוואה אמיתית תחת אותה תנועה.

התשובה הכנה על אחסון הוורדפרס המהיר ביותר ב-2026

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

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

שאלות נפוצות

מהו TTFB טוב לאתר וורדפרס?

ההנחיה של גוגל ב-web.dev מגדירה TTFB טוב כ-0.8 שניות או פחות, ומעל 1.8 שניות נחשב גרוע. אותו עמוד מציין ש-TTFB אינו מדד Core Web Vitals, כלומר הוא כלי אבחון ולא ציון. מדדו גם TTFB בהחטאת מטמון, כי המספר מהמטמון מחמיא כמעט לכל ספק.

למה בדיקות מהירות נותנות לי תוצאה שונה בכל פעם?

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

האם אחסון NVMe הופך וורדפרס למהיר יותר?

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

האם CDN יפתור ספק אחסון איטי?

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

איך אני יודע אם העמוד הוגש מהמטמון?

בקשו את הכותרות עם curl -sSI וחפשו שדות שקשורים למטמון. שמות הכותרות משתנים בין ספקים, אז חפשו רחב במקום לנחש. ב-Cloudflare הכותרת CF-Cache-Status מדווחת HIT, MISS, EXPIRED, BYPASS או DYNAMIC. ערך DYNAMIC על ה-HTML אומר שהעמודים לא נשמרים בקצה.

האם VPS מהיר יותר מאחסון שיתופי לוורדפרס?

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

האם מעבר ספק משנה את ה-Core Web Vitals מיד?

זמני השרת משתנים מיד, אבל נתוני השדה ב-PageSpeed Insights מדווחים על פני חלון של 28 הימים האחרונים, ולכן המספרים הפומביים זזים בהדרגה. השתמשו במדידות ה-curl שלכם כדי לאמת את השיפור ביום הראשון, וחכו שחלון האיסוף יתעדכן.