אחסון אתרים – איך יודעים אם השרת מהיר?

אחסון אתרים – איך יודעים אם השרת מהיר?

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

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

טריף במבי

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

הדרך הראשונה – CMD

משנה לע"נ הילד דוד ישראל אוחיון ז"ל – ( אבות, א'-ב' ) שמעון הצדיק היה משירי כנסת הגדולה.
הוא היה אומר, על שלשה דברים העולם עומד, על התורה ועל העבודה ועל גמילות חסדים.

 

 

דרך בדיקה שאסור להתעלם ממנה. ראשית, נברר מהי כתובת האייפי של האתר. לשם הדוגמה, נבדוק את אחד האתרים שלנו: https://www.hadash-hot.co.il. איך נבדוק? עם הפקודה הזו: "ping www.hadash-hot.co.il" – כך זה ייראה:

 

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

 

מה אנחנו רואים פה בדיוק?

ובכן, בשורה: "Reply from 35.198.94.155: bytes=32 time=89ms TTL=54" ישנם נתונים על זמן התגובה, מרגע שליחת הבקשה מהמחשב שלנו – בפישוט, כמה זמן לוקח לשרת להגיב. בסך הכל, די טוב (89 מילי-שניות).

מעבר לכך, ייחשפו בפנינו נתונים סטטיסטיים:
"Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 87ms, Maximum = 89ms, Average = 87ms"

מה כל זה אומר? ובכן, נשלחו 4 בקשות – כולן הגיעו בהצלחה לשרת. זמן התגובה המינימלי של השרת עומד על 87 מילי-שניות, המקסימלי על 89 מילי-שניות, והממוצע הוא 87 מילי-שניות. במונחים של היום, זמן התגובה נחשב די מהיר.

הדרך השנייה – בדיקת WebSitePulse

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

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

 

*הכלי מאפשר להריץ בדיקות גם ברמת האייפי.

הדרך השלישית – PageSpeedInsights

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

 

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

 

הדרך הרביעית – SpeeDom

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

 

הדרך החמישית – PingDom

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

 

הדרך השישית – Gtmetrix

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

הדרך השביעית והאחרונה – WebPageTest

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

תמונת מצב:

 

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

סימנים לשרת ואתר איטיים – איך אפשר לדעת?

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

  • שגיאות 503 – לרוב, אלו הודעות מרובות של שגיאות 503 שמעלות דאגות. המסקנה מהן ברורה: יש בעיה עם האתר/השרת שלכם (נובע מעומס גולשים/שרת גרוע). כמו כן, ייתכן שחברת האחסון כלל לא אשמה, והאתר שלכם נתון תחת התקפות שונות (DDoS) אשר מאטות אותו.

  • לוקח לוורדפרס זמן רב מדי להיטען – לעיתים בעיות במערכת הוורדפרס עלולות להעיד על בעיות. אם בזמן שנטען עמוד הפוסטים אתם יכולים להכין כוס קפה – ללא ספק ישנן בעיות במהירות השרת / האתר. בדקו זאת.

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

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

ממה האיטיות נובעת? כיצד אוכל למנוע זאת?

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

  1. המון תוספים – לרוב, בעיות מהירות מסתכמות בנתון (כמות) אחד: "20 תוספים". הפחיתו בכמות התוספים. מחקו את המיותרים מבניהם, והשתמשו רק במה שאתם באמת זקוקים לו. לדעתנו, אם אפשר לשלם למתכנת במקום להסתמך על תוסף – הדבר עדיף בהרבה.

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

  2. קוד מיותר – אתרים רבים, בעיקר אתרי POJO ישנים, עדיין משתמשים בבילדר ישן ולא מעודכן (אם כי גם בילדרים חדשים ומעודכנים עלולים להזיק):

    מבדיקה מלפני כשנה, מצאנו 2 בילדרים יפים מאוד עיצובית. אולם, היו לקוד של הבילדרים “הפרעות אכילה”. מה? ובכן, כ־30% משורות הקוד הכילו קוד מיותר, מסורבל ובזבזני, אשר “זלל” את משאבי האתר כאילו אין מחר.

  3. תמונות בנפח עצום – משתמשים בתמונות ממאגרים קנויים? בעיה. לרוב, התמונות מהם מגיעות בנפח עצום. לנפח השפעה אדירה על מהירות האתר והדפים השונים בו.

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

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

  5. דפים גדולים מבחינת נפח (וידאו, תמונות ורכיבים שונים) – אם תכנסו ותבדקו את אתרכם בכלים שציינו מקודם, תוכלו למצוא סעיף המציג את נפח העמודים. נפח עמוד סטנדרטי, לאחר אופטימיזציה, צריך לעמוד על 150-500KB. שמרו על נפח העמוד בטווח הנ”ל, בגג 800KB. לרוב, עמודים השוקלים  1-3MBבזבזניים ועמוסים מדי, והדבר עשוי להשפיע על מהירות הטעינה של הדפים.

לסיכום – אין לכם ממה לדאוג יותר מדי

אנחנו לא יודעים למה, אך בעלי אתרים, הרבה פעמים, “אובססיביים” לגבי מהירות אתרם. בסופו של דבר, כמעט תמיד הלחץ מיותר – במידה ותעברו ותעבדו לפי רוב הנחיות המאמר, אין שום סיבה לדאגה (לפחות מהצד שלכם).

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

בהצלחה, מאחלים לכם מהירות! ?

צילום PIXABAY
אהבתם? שתפו!
דילוג לתוכן