מדריך לשיפור מהירות טעינת דפים באתר

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

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

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

1.    עקרונות מרכזיים לצמצום מהירות הטעינה (צד התוכנה)

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

צמצום נפח המידע: מתבסס על העברת מינימום קבצים הכרחיים, כיווץ ודחיסת הקבצים המועברים לגודל מינימאלי, צמצום (מיניפיקציה) של HTML וסקריפטים, צמצום יתירות ע"י איחוד קבצים,

צמצום מספר הבקשות: מתבסס על צמצום מספר הקבצים הנדרשים לבניית העמוד, איחוד קבצים במגוון טכניקות (כולל css sprites, איחוד CSS וכו) ושימוש ב cache

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

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

1.1.  ריבוי קבצים

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

1.2.  טעינה טורית

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

1.3.  צמצום מספר הבקשות להעברה ע"י שימוש בפרוטוקול Keep Alive

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

1.4.  CACH בצד השרת

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

1.5.  דחיסה כללית (GZIP)

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

1.6.  הגשת תמונות בגודל מתאים

פעמים רבות, תמונות מועלות למסד הנתונים של האתר בגודל שונה מן הגדול הסופי בו הן מוצגות בעמוד, והתאמת הגודל מתבצעת בעת טעינת התמונה. לרוב הדבר מתבצע בשל אי מודעות של צוות תוכן האתר. לפעמים, הדבר מבוצע אוטומטית ע"י תוסף לניהול תמונות וללא מודעות צוות האתר לנושא. לעיתים, הדבר אף מתוכנן מראש בעת בניית האתר- מתוך כוונה לחסוך מאמץ ו/או מקום על הדיסק, בוני המערכת בוחרים בגישה זו במצבים בהם קובץ תמונה אחד מוצג במספר מקומות באתר בגדלים שונים (לדוגמא- thumbnail, גודל ביניים וגודל מלא).
חשוב לציין כי עיבוד תמונה הינה פעולה כבדה, המצריכה יחסית משאבים רבים. כתוצאה, התאמת גודל התמונה בעת הטעינה מכבידה מאוד על השרת ומאיטה מאוד את טעינת העמוד.
אי לכך, יש להימנע ככל הניתן מביצוע התאמות לגודל התמונה בעת הטעינה- יש להקפיד להעלות לשרת אך ורק תמונות בגודל הסופי, ובמידה ויש צורך במספר גדלים- יש להעלות מספר גרסאות של התמונה, אחת לכל גודל נדרש (מקום על השרת אינו ממש בעיה בימינו).
עקרון  זה מצריך הקפדה לאורך זמן, והדרכת צוות התוכן של האתר בנושא מראש יכולה לחסוך הרבה עבודה בהמשך. לחלופין- ניתן להטמיע באתר מערכת שמבצעת התאמה של גודל התמונה בעת העלאתה לשרת, ושומרת רק את הקובץ בגודל הנכון, ובכך להימנע לחלוטין מהצורך להסתמך על צוות התוכן של האתר ומהאפשרות לשגיאות אנוש.

1.7.  דחיסת תמונות

דחיסת תמונות הינה מקרה ספציפי של דחיסת מידע, ומשמשת לאותה מטרה- האצת הטעינה ע"י צמצום נפח המידע שיש להעביר.
במרבית האתרים הסטנדרטיים, תמונות הינן הקבצים הכבדים ביותר בעמודי האתר. לצוותי התוכן של האתר יש נטייה מובנית לעשיית שימוש בתמונות באיכות הגבוהה ביותר שניתן, ובשילוב עם ריבוי תמונות בעמוד- מתקבלים עמודים כבדים מאוד, הנטענים לאט מאוד.
חשוב להבין ולהסביר לצוות התוכן כי מהבחינה הטכנית, מרבית המידע המיוצג בקובץ התמונה הינו מיותר, וניתן לצמצום או דחיסה מבלי לפגוע כלל באיכות התמונה המוצגת לגולש. הדבר נכון במיוחד אם התמונה אינה בגודל הסופי הנכון (ראו סעיף קודם)
חובה לדחוס תמונות לגודל המינימאלי הנדרש לפני העלתן למסד הנתונים של האתר. מומלץ לעשות שימוש באלגוריתמים lossless (שאינם מביאים לאובדן מידע מקובץ התמונה) ע"מ להימנע מפגיעה באיכות בעת הדחיסה (http://www.smushit.com/ysmush.it).
קל מאוד ליישם סעיף זה ובכך להאיץ את טעינת האתר. סעיף זה הינו בסיסי ביותר והפרה שלו תביא ליצירת עמודים כבדים מאוד הנטענים באיטיות.

1.8.  CSS SPRITES

נושא זה הוא מקרה פרטי של איחוד משאבים, הנידון לגבי קבצים אחרים בהמשך.
אתרים רבים משתמשים במספר משמעותי של קבצי תמונה כחלק ממבנה העמודים שלהם. לרוב לא מדובר בקבצים שהמשתמשים רואים כתמונה, אלא הכוונה היא לתמונות קטנות המרכיבות את העמוד (עיצוב העמוד- חץ, עיגול, רקע אפור, נקודה, מסגרת עגולה וכו). ריבוי קבצים שכאלו מביא להגדלת מספר הבקשות למשאבים (קבצים) שהעמודים נזקקים להם, ולכן מפל הטעינה מתארך ומשך זמן הטעינה עולה.
ישנה אפשרות לאחד תמונות קטנות כאלו בעזרת css sprites, על מנת לצמצם את מספר בקשות המשאבים ובכך להאיץ את טעינת העמוד. מומלץ לעשות שימוש בכך במידת האפשר, אך להימנע מיצירת cluster גדול וכבד מידי של תמונות- שוב, יש למצוא את נקודת האופטימום בין הרבה קבצים קלים מאוד לקובץ אחד כבד מידי.

1.9.  HTTP או HTTPS

לשימוש בפרוטוקול תקשורת מאובטח (HTTPS) ישנם יתרונות, ומנועי חיפוש רבים (וגוגל בראשם) הכריזו כי הם רואים תקשורת מאובטחת כעדיפה על שאינה מאובטחת, ויפעלו לקדם פרוטוקול זה. עם זאת, בפועל- לשימוש ב HTTPS יש לא מעט חסרונות. ספציפית מבחינת מהירות, השימוש ב HTTPS מביא להאטה משמעותית בזמני הטעינה, לעיתים עד פי 4 יותר מזמן הטעינה הנדרש לאותו עמוד בדיוק ב HTTP.
לאור בעיה זו וחסרונות נוספים שעניינם מעבר לנושא מסמך זה, מומלץ באופן חד משמעי להימנע מ HTTPS אם אין בכך צורך ממשי.

1.10. EXPIRYDATE- ניצול CACHE בצד הגולש

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

1.11. סדר מפל טעינה (בדגש על דחיית תוספים חברתיים והרצת סקריפטים לסוף המפל)

כפי שצוין בנוגע לנושא הטעינה המקבילית, לסדר טעינת הקבצים בעמוד ("מפל הטעינה") יש לא מעט השפעה על מהירות הטעינה. אופטימיזציה של מפל הטעינה, במיוחד ע"י צמצום מספר הבקשות ומקסום יכולת העברת הקבצים במקביל ע"י תכנון נכון של הסדר (קרי- סידור קבצים במידת האפשר כך שתתאפשר העברה מקבילית עם ניצול מיטבי של יכולת העברת הנתונים של השרת), הינה שלב לא פשוט המצריך מאמץ וזמן מצד מפתחי האתר, אך הינו שלב מחייב, ובעל תוצאות מתגמלות מאוד (מבחינת זמני טעינה). חשוב לשים לב שלא כדאי להשתמש תמיד ב100% מיכולת העברת הנתונים של השרת, וזאת בכדי להימנע מהאפשרות לעומס יתר.
אחת הנקודות הקלות ביותר לטיפול, היא דחיית סקריפטים לא הכרחיים לסוף מפל הטעינה- הרצת סקריפטים בשלב מוקדם מידי בזמן טעינת העמוד מעמיסה על השרת ומאריכה את זמן הטעינה הכולל. מומלץ להעביר כל הניתן סקריפטים לא הכרחיים לסוף המפל, או לפחות לאחרי נקודת תחילת הרינדור (בניית העמוד).
נתון בולט נוסף הוא קבצי תוספים חברתיים- לרוב מדובר בקבצים כבדים ובמיוחד הנטענים משרתים חיצוניים, ובסקריפטים המעמיסים על השרת (בולט במיוחד בקבצי פייסבוק), ואין שום צורך לטעון אותם בשבלים מוקדמים של המפל- מומלץ לדחות תוספים חברתיים לשלב מאוחר ככל האפשר.

1.12. איחוד סקריפטים ו CSS

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

1.13. מיניפיקציה של HTML CSS וסקריפטים

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

1.14. טעינת CSS מקומית (ללא css@import)

ככל, במידת האפשר עדיף להכיל בכל קובת CSS את כל המידע הנדרש לאותו קובץ, מבלי לייצר קריאות מתוך קובץ CSS אחד לקובץ CSS אחר, וזאת במיוחד לאור הטעינה הטורית הנדרשת לרוב ב CSS. אם משיבה כלשהיא יש צורך במידע הנמצא בקובץ השני, עדיך להשתמש ב <link> tag ולא ב css@import.

1.15. ניקוי מפל טעינה- שימוש בכתובות סופיות בלבד (302, 404)

חשוב מאוד לעשות שימוש אך ורק כתובות סופיות לכל הקבצים במפל הטעינה- קובץ שלא נמצא (404) או עבר כתובת (301 או 302) מאלצים את השרת לבזבז זמן בניסיון לאתר את הקובץ, ללא שום הצדקה. יש להקפיד לנקות את מפל הטעינה בסוף בנייתו, ולדאוג שלא יכיל קבצים שאינם הכרחיים, הפניות לקבצים שלא קיימים עוד או לכתובות לא סופיות של קבצים.

1.16. הגשת קבצים מ URL אחיד

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

1.17. שימוש בטכנולוגיות כבדות (כדוגמת פלאש)

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

1.18. CDN

במצבים בהם יש מספר רב של קבצים (במיוחד קבצי מדיה), או בהם האתר מקבל גולשים ממספק מקומות שונים בעולם ואין לאתר יכולת להחזיק מספר שרתים במיקומים שהולמים את המבקרים, ניתן לעשות שימוש ב Content Distribution Networks (CDN)- לפזר את הקבצים המרובים והכבדים בין שרתים שונים, וכך להקל על העומס על השרת ועל מהירות הטעינה, כמו גם לתת מענה הולם ולצמצם זמני תעבורת נתונים בעת טעינת האתר ממיקומים גיאוגרפיים שונים.
שרותי הענן של Yahoo הינם נפוצים מאוד בארץ, אך אינם הפתרון היחידי, וקיימים עוד ספקי שרות מצוינים רבים. חשוב לציין, כי לא משנה השרות שנבחר, תמיד קיים lag מסוים בתגובה (לעיתים אפילו עד שנייה וחצי), גם של CDN טובים, ולכן שימוש ב CDN שלא לצורך עלול דווקא להרע את זמני הטעינה. מסיבה זו, כמו גם משמעויות נלוות אחרות (כגון עלויות ותלות במספק ה CDN לאורך זמן), לא רצוי לעשות שימוש ב CDN כלאחר יד, אלא רק לאחר שכל בעיה אחרת באתר טופלה, ולא ניתן לקצר את זמני הטעינה בשום צורה אחרת.

2.    עקרונות נוספים

2.1.  חומרה: עומס בשרתים משותפים ו throtting

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

2.2.  אופי בדיקת האתר: בדיקת מהירות רגעית לעומת מעקב לאורך זמן, בדיקה בסביבת פיתוח ויציבות האתר

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

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

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

3.    כלי בדיקה חינמיים וקישורים מועילים

3.1.  כלי בדיקת מהירות (ותאימות לעקרונות בתחום) של מנועי חיפוש

גוגל- מציעה כלי נוח מאוד לבדיקת מהירות בשם Page speed, הבוחן לא רק את מהירות האתר אלא גם את כל העקרונות החשובים לגוגל, ומציע פתרונות לתיקון, כמו גם הסברים על כל בעיה. חסרונו המרכזי של כלי זה הוא שאינו מציג נתונים סטטיסטיים לגבי מהירות הטעינה (כמו מהירות טעינת העמוד עצמה) , אלא ציון כללי לעמוד.
כלי זה הינו תוסף לדפדפן, וניתן להורידו (בגרסאות שונות) בקישור הבא:   https://developers.google.com/speed/pagespeed

Yahoo- מציעים כלי דומה. ניתן להורדה ב http://developer.yahoo.com/yslow

3.2.  כלי בדיקת מהירות טעינת עמוד

Pingdom tools - מציעים כלי נוח מאוד לבדיקת עמודים. הכלי מציג זמני טעינה, נתונים סטטיסטיים, מפל טעינה מלא, חלוקת זמנים לפי משאבים וכו, ומאפשר אף לשמור את תוצאות הבדיקה בשרתי Pingdom ולגשת אליהם מאוחר יותר, או לייצא אותם לקובץ להורדה. עם זאת, כלי זה מציג לעיתים זמני טעינה קצרים מאלו שגוגל מחשב לאתרים, ולכן יש להתייחס אליו מעט בשמרנות. כמו כן- הכלי מייצג מהירות למחשבים נייחים. יש לקחת בחשבון שבפלטפורמות סלולאריות זמני הטעינה שונים.
ניתן לעשות שימוש בכלי זה בכתובת http://tools.pingdom.com/fpt

3.3.  ניטור מהירות לאורך זמן ב Google analytics

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

אין תגובות למאמר

עדיין לא נכתבו תגובות.

כתוב תגובה

שדות חובה מסומנים בכוכבית (*)