למה מיקום השרת משנה — אחסון וורדפרס בישראל מול חו״ל
כמה באמת עולה זמן ההשהיה כשהשרת בווירג׳יניה והמבקר בתל אביב, מתי זה קריטי, ומתי CDN מספיק כדי לגשר.
אביר
אחראי מידע ותוכן
תוכן עניינים13 פרקים
"השרת בארצות הברית, אבל יש לנו CDN" היא תשובה נפוצה, והיא נכונה רק חלקית. יש דברים ש-CDN פותר, ויש דברים שהוא לא יכול לפתור מעצם הגדרתו.
המאמר הזה מפריד בין השניים.
הפיזיקה, בקצרה
אור בסיב אופטי נע בכשני שלישים ממהירותו בוואקום — בערך 200,000 ק״מ לשנייה. המרחק תל אביב–וירג׳יניה הוא כ-9,500 ק״מ. הלוך ושוב: 19,000 ק״מ.
19,000 ÷ 200,000 = 95 מילישניות, בתנאי מעבדה מושלמים.
בפועל מוסיפים ניתובים, מתגים ותורים, והמספר האמיתי הוא 120–180 מילישניות. זו רצפה שאי אפשר לרדת מתחתיה בשום אופטימיזציה — היא מרחק כפול מהירות האור.
| ממיקום | לתל אביב | RTT טיפוסי |
|---|---|---|
| ישראל | — | 5–15ms |
| פרנקפורט | 2,900 ק״מ | 45–65ms |
| לונדון | 3,600 ק״מ | 60–80ms |
| וירג׳יניה | 9,500 ק״מ | 120–180ms |
| סינגפור | 7,500 ק״מ | 150–200ms |
למה זה מתרבה
אילו הייתה בקשה אחת בלבד, 150 מילישניות היו זניחות. אבל טעינת דף אינה בקשה אחת.
הפתיחה — לפני שהועבר בייט אחד של תוכן
| שלב | סבבים | עלות ב-150ms RTT |
|---|---|---|
| חיפוש DNS | 1 | 150ms |
| TCP handshake | 1 | 150ms |
| TLS handshake | 1–2 | 150–300ms |
| סה״כ לפני הבקשה | 450–600ms |
חצי שנייה לפני ששרת הוורדפרס התחיל לעבוד. אחר כך מגיע זמן העיבוד עצמו, ואז ה-HTML חוזר — עוד סבב.
TTFB מינימלי מווירג׳יניה הוא כ-600 מילישניות, גם אם השרת עצמו מגיב באפס זמן. מישראל אותו שרת יגיע ל-50–80.
המשאבים שאחריו
דף וורדפרס טיפוסי טוען 40–80 משאבים. HTTP/2 מרבה אותם על חיבור אחד, אבל תלויות נשארות: הדפדפן מגלה קובץ CSS, מוריד אותו, מגלה בתוכו גופן, מוריד אותו. כל גילוי כזה הוא סבב נוסף.
מה CDN פותר — ומה לא
מה כן
CDN מציב עותקים של הקבצים הסטטיים בשרתי קצה. מבקר ישראלי מקבל את התמונות מנקודה בישראל או באירופה במקום מווירג׳יניה.
זה פותר את החלק הגדול של המשקל — תמונות, CSS ו-JavaScript הם בדרך כלל 80% מהבייטים.
מה לא
את ה-HTML. וורדפרס מייצר אותו מחדש בכל בקשה שאינה במטמון, והוא מגיע מהשרת המקורי. אם השרת בווירג׳יניה, ה-HTML מגיע מווירג׳יניה — עם כל 600 המילישניות.
וה-HTML הוא הבקשה הראשונה. עד שהוא לא הגיע, הדפדפן לא יודע אילו קבצים בכלל לבקש מה-CDN. ה-CDN המהיר בעולם מחכה לו.
את הדפים הדינמיים. עגלת קנייה, אזור אישי, תוצאות חיפוש — אלה לעולם לא במטמון קצה, כי הם שונים לכל משתמש.
Full Page Cache ב-CDN
יש פתרון ביניים: לשמור גם את ה-HTML בשרתי הקצה. Cloudflare ואחרים תומכים בזה.
זה עובד, אבל הוא דורש:
- חוקי פינוי מדויקים — אחרת מבקרים רואים תוכן ישן
- החרגה קפדנית של כל דף אישי
- ניהול של שכבת מטמון נוספת מעל הקיימות
לאתר תדמית זו הגדרה טובה. לחנות זה מקור נדיר לתקלות עדינות.
מתי מיקום השרת קריטי
חנויות אונליין. תהליך התשלום הוא רצף של דפים דינמיים, אף אחד מהם לא ניתן לשמירה במטמון. כל שלב משלם את מלוא ההשהיה. שיעורי נטישה בעגלה רגישים מאוד לזה.
אתרים עם משתמשים מחוברים. אזור אישי, מערכת לימוד, פורום — כמעט הכל דינמי.
אתרים עם טפסים ארוכים. כל שליחה, כל שלב, כל ולידציה בצד השרת.
אתרים שנשענים על AJAX. חיפוש חי, סינון מוצרים, טעינה אינסופית — כל אינטראקציה היא סבב מלא לשרת ובחזרה.
מתי זה פחות קריטי
בלוג או אתר תדמית עם מטמון מלא. אם כל דף מוגש מהמטמון ו-CDN מגיש גם את ה-HTML, ההפרש מצטמצם משמעותית.
אתר עם קהל בינלאומי מפוזר. אם המבקרים בכל העולם, שום מיקום בודד לא יהיה קרוב לכולם. אז ארכיטקטורת קצה חשובה יותר מהמיקום המקורי.
ההשפעה על SEO
גוגל מודדת Core Web Vitals ממבקרים אמיתיים. עבור אתר ישראלי, רוב המבקרים בישראל — ולכן הנתונים שנאספים משקפים את ההשהיה מישראל לשרת שלכם.
LCP מורכב מ-TTFB ועוד שלבים. אם ה-TTFB שלכם מתחיל ב-600 מילישניות בגלל המרחק, נותרו לכם פחות משתי שניות לכל השאר כדי לעבור את הסף — וזה מעט.
HTTP/3 ו-QUIC — כמה זה עוזר
פרוטוקולים חדשים מצמצמים חלק מהעלות אך לא את כולה, ושווה לדעת מה בדיוק.
HTTP/3 מעל QUIC מאחד את לחיצת היד של התעבורה ושל ההצפנה לסבב אחד במקום שניים או שלושה. בחיבור ראשון זה חוסך RTT אחד — כ-150 מילישניות מווירג׳יניה.
0-RTT מאפשר לחיבור חוזר לשלוח נתונים כבר בחבילה הראשונה, בלי לחיצת יד כלל.
מה זה לא פותר: את הבקשה עצמה. אחרי שהחיבור נוצר, ה-HTML עדיין צריך לנסוע לשרת ובחזרה. QUIC חוסך את ההכנה, לא את הנסיעה.
במספרים: מווירג׳יניה, HTTP/3 יכול להוריד את הפתיחה מ-450–600ms לכ-300ms. שיפור אמיתי — ועדיין פי ארבעה מהזמן שלוקח לפתוח חיבור לשרת בישראל.
מה עם אירופה כפשרה
פרנקפורט או אמסטרדם הן פשרה נפוצה לאתרים ישראליים, ולעיתים היא סבירה.
היתרון: 45–65ms במקום 150. זה שליש מהעלות, ואירופה מציעה מגוון ספקים ומחירים.
החיסרון: זה עדיין פי ארבעה עד עשרה מאחסון מקומי, והפער מורגש בדיוק באותם מקומות — תשלום, אזור אישי, טפסים.
שיקול נוסף: מידע של תושבי ישראל המאוחסן באיחוד האירופי כפוף גם ל-GDPR. לרוב העסקים זה לא מכשול, אבל זו שכבת רגולציה נוספת שכדאי להיות מודעים לה.
כלל אצבע: אם הקהל ישראלי והתקציב מאפשר — ישראל. אם יש מגבלת תקציב או צורך בשירות ספציפי שאין מקומית — אירופה. ארצות הברית רק אם רוב הקהל שם.
שיקולים שאינם ביצועים
רגולציה. עסקים מסוימים — בריאות, פיננסים, גופים ציבוריים — מחויבים לשמור מידע בישראל. זה שיקול משפטי שקודם לכל דיון טכני.
תמיכה באותו אזור זמן. תקלה בעשר בבוקר שנענית בשלוש לפנות בוקר אצל הספק היא תקלה שנפתרת בערב.
שפה. תמיכה בעברית, בכתב ובעל פה, כשמסבירים בעיה טכנית מורכבת.
חשבונית ותשלום בשקלים, בלי עמלות המרה והפרשי שער.
איך למדוד בעצמכם
curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://example.co.ilאיך לקרוא את התוצאה:
ConnectפחותDNSהוא זמן ה-TCP — קירוב טוב ל-RTT- אם הוא מעל 100ms, השרת רחוק
TTFBפחותTLSהוא זמן העיבוד בשרת עצמו
ההפרדה הזו חשובה: היא אומרת לכם אם הבעיה במרחק או בשרת. אם זמן העיבוד גבוה, מעבר לישראל לא יפתור — צריך לטפל בביצועים. אם זמן העיבוד נמוך וה-TTFB גבוה, המרחק הוא כל הסיפור.
סיכום
מיקום השרת קובע רצפה שאי אפשר לרדת מתחתיה. CDN מוריד את התקרה, אבל לא נוגע ברצפה עבור תוכן דינמי.
לאתר ישראלי שמשרת קהל ישראלי — במיוחד חנות או אתר עם אזור אישי — שרת בישראל הוא ההחלטה הפשוטה. חבילות האחסון שלנו יושבות בראש העין, והתמיכה עונה בעברית בשעות שאתם עובדים בהן.
שאלות נפוצות
האם שרת בישראל תמיד מהיר יותר? לקהל ישראלי — כן מבחינת השהיה. אבל שרת מקומי חלש יהיה איטי מסיבה אחרת. מיקום פותר את המרחק, לא את כוח העיבוד; צריך את שניהם.
איך יודעים איפה השרת של האתר שלי? בדיקת WHOIS על כתובת ה-IP, או כלי איתור IP. אפשר גם למדוד: זמן חיבור מעל 100 מילישניות מישראל מעיד על שרת רחוק.
האם Cloudflare הופך את מיקום השרת ללא רלוונטי? לא. Cloudflare מקרב את הקבצים הסטטיים ואת לחיצת היד של ה-TLS, אבל כל בקשה דינמית עדיין נוסעת לשרת המקורי. בחנות זה רוב התנועה שחשובה.
מה קורה אם הקהל שלי מעורב — ישראל וחו״ל? מקמו את השרת קרוב לרוב הקהל ובנו שכבת CDN לשאר. אם החלוקה שווה, ישראל או מרכז אירופה הן פשרה סבירה.
שלוש נקודות לזכור
המרחק הוא רצפה. אפשר לשפר כל דבר אחר באתר; את מהירות האור אי אפשר. שרת רחוק מתחיל כל בקשה בחוב שאין דרך להחזיר.
CDN מוריד את התקרה, לא את הרצפה. הוא פותר את הקבצים הסטטיים ולא נוגע בתוכן דינמי — שהוא בדיוק מה שמשנה בעגלה, בתשלום ובאזור האישי.
מדדו לפני שמחליטים. שורת curl אחת מפרידה בין זמן הנסיעה לזמן העיבוד ואומרת לכם אם הבעיה במיקום או בשרת. השניים דורשים פתרונות שונים לחלוטין.
נכתב על ידי אביר, אחראי מידע ותוכן ב-CloudX. רוצים לדעת מה ה-TTFB של האתר שלכם היום? שלחו לנו את הכתובת ונמדוד יחד.