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

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

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

נתחיל מהסוף – האיטיות היא מושג אבסולוטי שניתן למדוד אותו.

הנתון נמדד מרגע ביצוע הבקשה לשרת ע"י הדפדפן ועד לקבלת התוצאה המלאה מהשרת.

מהו האתר האידאלי?

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

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

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

למה "האתר האידאלי" שהדגמתי יטען מהר יותר מכל אתר אחר בעולם?

לטובת השאלה הזו, אנחנו צריכים להתחיל למנות את הפרמטרים הרלוונטים למהירות טעינת האתר:

Time To First Byte: או בקיצור, TTFB, הוא הנתון המרכזי שקובע את זמן מהירות התגובה של השרת – אך לא רק.
TTFB אומר בעצם "כמה זמן עבר מהרגע בו הגשתי את הבקשה לשרת לראשונה (ה-GET הבסיסי לעמוד) ועד הרגע שקיבלתי מהשרת את התגובה הראשונית" – שימו לב, לא מדובר על הטעינה של כלל האתר, אלה על ה-GET הראשוני בלבד.הנתון מורכב מ-2 פרמטרים עיקריים:
א. זמן התגובה של השרת: ככול שהשרת מהיר יותר, ה-TTFB יהיה מהיר יותר – מהו שרת מהיר? ובכן, לצורך הדיון אנחנו נתייחס לשרת מהיר לכזה שאינו עמוס.
איך ניתן למדוד זאת? במידה ומדובר בעומס כלשהו מצד השרת (עומס על ה-CPU או רוחב פס) העומס הזה יופיע גם בטעינה של אתר מורכב (דינאמי עם הרבה אלמנטים, ההפך הגמור מ"האתר האידאלי" שלנו) וגם בטעינה של תמונת JPG פשוטה.
ב. זמן הטעינה של הקוד: ברור לכולנו שעמוד המכיל מידע הנמשך ממסד הנתונים, מעבד אותו, ומציג אותו בצורה מעוצבת יוצר עיבוד מורכב ברמת הקוד אל מול עמוד המציג טקסט בלבד (גם אם אנחנו לא מבינים את החלקים הטכניים, אנחנו יכולים להבין שבמקרה הראשון יש יותר שלבים – ולכן, הוא לרוב יהיה איטי יותר).לדוגמא:

מקרה א': בקשה של הגולש לעמוד Php שמגיש בקשה למסד הנתונים לצורך שליפת נתונים (כמו בכל אתר WordPress סטנדטי)

מקרה ב': הגולש מבקש בקשה פשוטה מעמוד טקסט ללא פניה למסד הנתונים או עיבוד מורכב

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

ב. Download time: זמן ההורדה של העמוד הראשי הוא רלוונטי- אומנם לא כמו במקרים של תמונות, אבל עדין רלוונטי (ולכן, צריך לוודא שה-HTML המיוצר מהבקשה הראשונית לא עולה על כמה מאות קילו-בתים).

ג. Initial connection: הקמת החיבור בין הדפדפן לשרת לוקחת זמן (בדיוק כפי שכאשר אתם משוחחים עם אדם אחר, יקח לו זמן מסויים להגיב לקריאת ה"שלום" שלכם אליו).

ד. SSL Negotiation: הקמת תקשורת SSL (אשר לעיתים הכרחית) לוקחת זמן (ומוסיפה לזמן הטעינה הראשונית של האתר).

כמות אלמנטים בעמוד: המשוואה היא פשוטה – ככול שישנם יותר אלמנטים בעמוד, כך ידרש יותר זמן לדפדפן לטעון אותם.
ולכן, תמיד נשאף לכמות מינימלית ככול שניתן של אלמנטים שאנו טוענים בעמוד (באמצעות CSS Sprites, Image maps וכו').
גודל תמונות: גודל התמונות הוא אומנם פחות קריטי מבעבר (בגלל העליה בקצבי הגלישה באינטרנט), אבל עדין חשוב – ככול שכל שהתמונה גדולה יותר, כך זמן הטעינה שלה עולה, העקרון הוא פשוט: כל תמונה שאנחנו "צופים" בה בעמוד למעשה "יורדת" מחשב שלנו (בדיוק כמו שאנחנו מורידים כל קובץ אחר), מה שאומר שהורדה של תמונה בגודל 100K תהיה מהירה יותר מהורדה של תמונה בגודל 2 מגה בייט.
גודל אלמנטים כולל: מקרה מעניין בכל הנוגע למדידת מהירות האתר הוא "מי מודד" – כלומר, מודד אחד יכול להיות הגולש שיבצע את המדידה "עד שהוא רואה את העמוד בצורה תקינה" – יחד עם זאת, כאשר כלים אוטומטים בודקים את מהירות האתר (כפי שניתן דוגמאות בהמשך), הם מודדים את הזמן מהרגע שבה התבצעה הבקשה הראשונה ועד לרגע שבו התקבלה התשובה האחרונה.
כלומר, ייתכן מצב שבו הגולש יראה את העמוד בצורה תקינה (לדעתו), אך בפועל, ה"רובוט" לא יראה זאת.
ולכן, לא צריך להסתכל רק על כמות האלמנטים וגודל כל אלמנט בצורה עצמאית, אלה גם את הגודל הכולל של כל אלמנטים יחד..
מספר המקורות ומקורות טעינה: כאשר אתם גולשים לעמוד, הדפדפן למעשה "מוריד" את האלמנטים מהשרת.
יחד עם זאת, הדפדפן עובד בצורה "טורית".
לדוגמא: גלשנו לאתר spd.co.il והדפדפן מתחיל להוריד אלמנטים מהאתר (דף ה-HTML, ה-CSS, ה-JavaScript והתמונות שבו) בהנחה שכל האלמנטים יטענו בדיוק מאותו המקום (כלומר, כל האלמנטים נטענים מהדומיין spd.co.il), הטעינה תתבצע בצורה טורית – כלומר, אחד אחרי השני.
לעומת זאת, אם נחליט שכל קבצי ה-CSS ימשכו מ-css.spd.co.il וכל התמונות ימשכו מ-img.spd.co.il – אנו נאפשר לדפדפן לבצע את ההורדה במקביל מ-2 המקורות (גם אם בפועל מדובר באותו השרת), מה שבעצם יאפשר הורדה מהירה יותר של האלמנטים ויאיץ את טעינת האתר.מה שאומר בעצם שככול שיהיו יותר מקורות טעינה, הטעינה תהיה מקבילית, והאתר יעלה מהר יותר.
החסרון הוא כמובן שריבוי מקורות טעינה יכול גם לגרום לנקודות כשל – לדוגמא, אי זמינות של מקור הטעינה.

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

האתר שלי איטי, מי אשם? אני או חברת האחסון?

הגענו לפאנץ' של כל הפוסט הזה.

ראשית, לא ניתן לענות על השאלה מבלי לבדוק את הנתונים היבשים – כלומר, מהי הסיבה לטעינה האיטית? (ה-TTFB? כמות האלמנטים בעמוד? גודל האלמנטים בעמוד?)

כלים חיצוניים לבדיקה

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

רשימת הכלים:

https://performance.sucuri.net

https://developers.google.com/speed/pagespeed/insights

http://tools.pingdom.com/fpt

http://www.webpagetest.org

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

דוגמא לדו"ח

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

תוצאות הבדיקה יראו באופן דומה לתמונה הנ"ל:

הכתובת הישירה לדו"ח: http://www.webpagetest.org/result/150602_T6_FEJ/1/details
(קשה לדעת עד מתי הדו"ח עצמו ישאר באוויר, אז אני מתנצל מראש אם הדו"ח לא יהיה זמין)

אז בואו נבחן את הדו"ח לפי הפרמטרים שהעמדנו קודם:

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

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

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

דף לדוגמא:
<?
$example = mysql_connect ("mysqlserver1", "user", "pass");
?>

בדיקה ב'
רוב האתרים המפותחים היום מבוססים אפליקציות קוד פתוח כלשהן (WordPress, Joomla, Drupal וכו').
לרוב, אפליקציות אלו בנויות בצורה טובה ויעילה – אבל, האפליקציות גם מציעות מספר רב של הרחבות (בין אם מדובר בפלאגינים, עיצובים או תוספים).
ההרחבות אומנם מציעות לנו פונקציונאליות שלא היתה קיימת קודם באתר, אבל מצד שני, גם מייצרות סיבוכיות קוד נוספת וכן קריאות נוספות למסד הנתונים – משמע, ההרחבות מאיטות את האתר.
ולכן, אחד הבדיקות הראשונות שנרצה לבצע היא הורדה של כלל הפלאגינים הנטענים והסרת העיצוב.

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

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

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

"האתר איטי לסרוגין בשעות היום"
מקרה בעייתי, בעיקר מכיוון שייתכן ומדובר בבעיה מצד חברת האחסון (לדוגמא, האם האתר איטי בשעה שבו חברת האחסון מבצעת עבורכם גיבוי?), מצד שני, ייתכן מאוד שהאיטיות לא קשורה לחברת האחסון (לדוגמא, האתר מושך נתונים מצד שלישי – והוא, איטי לסרוגין).
כמות אלמנטים בעמוד:
במקרה שלנו, כמות האלמנטים הנטענים מהעמוד היא מאוד נמוכה (34 בקשות בלבד), דבר שגורם לטעינה מהירה יותר.
מהו מספר "נורמלי" של בקשות? ובכן, אני חושב שעמוד עם 100 בקשות הוא המספר המקסימלי של בקשות שהייתי רוצה לראות בעמוד.
גודל האלמנטים: גודל האלמנטים בעמוד עומד על 445 KB, לא מדהים, היה אפשר לחסוך עוד, אבל מדובר במספר לא רע בכלל.
מהו גודל הגיוני כולל של הבקשות? קשה לומר בדיוק, כי זה נורא תלוי מה יש באתר.
צריך לזכור שמהירויות האינטרנט בארץ הם עדין מוגבלות יחסות, מה שאומר שעמוד בגודל של כמה מגות – יכול להיות בעייתי להורדה עבור רוב המשתמשים.
אני חושב שבמידה ותשמרו על כמות המידע שיורד מהאתר קטן מ-1MB, ככלל אצבע, אתם תהיו בסדר.
מספר מקורות טעינה:
האמת שבמקרה הזה לא עשינו עבודה טובה באתר spd.co.il, רוב האלמנטים נטענים ממקור אחד – מה שאומר שרוב הטעינה היא טורית ולא מקבילית.

האם הכלים מדוייקים?

ובכן, לרוב – כן.

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

ולסיכום

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

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

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

הסיבה לכך שהמאמר לא חופר לעומק על "כיצד לשפר" היא בעיקר כי האינטרנט מלא במאמרים כאלו, לראיה:
http://blog.crazyegg.com/2013/12/11/speed-up-your-website
http://www.smashingmagazine.com/2014/06/25/how-to-speed-up-your-wordpress-website
http://wpsite.co.il/guides/acceleration-wordpress.html
http://www.geektime.co.il/how-to-push-wordpress-faster
https://developer.yahoo.com/performance/rules.html

בהצלחה!

About
Latest Posts

מנהל מערכת

חלק מחברת SPD Hosting החל משנת 2006.
כחלק מהתפקידים שלי בחברה, אני אחראי על תוכניות ההכשרה של עובדים חדשים.
חי ונושם Hosting, קוד פתוח ו-Linux (ויש גם מילה טובה ל-Windows)

Latest posts by מנהל מערכת (see all)