מה נמדד ?

שני הפתרונות מודדים בעקרון את אותו נתון – הזמן שעובר מביצוע הבקשה עצמה ועד לשלב ה-Document Complete, השלב שבו מופעלת פונקציית ה-onLoad.

איך מתבצעת המדידה ?

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

לעומתו, GA מבצע את המדידות באמצעות ה-Navigation Timing API, סטנדרט שהולך ומתהווה אשר מגדיר ממשק סטנדרטי שיאפשר לתשאל את הדפדפן באמצעות קוד (למשל JavaScript)  לגבי מהירות טעינת הדפים ומי שיבצע את המדידות השונות יהיו הדפדפנים השונים. לאור העובדה שסטנדרט זה נתמך רק בדפדפנים החדשים (IE9, כרום ופיירפוקס), איסוף הנתונים מדפדפנים ישנים מתבצע באמצעות Google Toolbar (נכון רק לגבי IE6-8 ולא לגבי Firefox 2-4).

כמה ואלו גולשים נמדדים ?

כמו שציינתי קודם לכן, בשל השימוש השונה בטכנולוגיות, קיים הבדל בסוג הגולשים הנמדדים ומספרם. כאמור, WMT אוסף נתונים אך ורק מדפדפני IE6-8 ו-Firefox 2-4 אשר אפשרו את תכונת ה-PageRank ב-Google Toolbar. כל הגולשים באתר שלכם העונים לקריטריון זה נמדדים באמצעות WMT.

כיון ש-GA עושה שימוש בסטנדרט החדש, רק דפדפנים חדשים נמדדים באמצעותו (בנוסף לדפדפני IE6-8 הנמדדים באמצעות ה-Toolbar). רשימה מלאה של כל הדפדפנים התומכים ניתן למצוא כאן. מתוך אלו, נאספת דגימה של 1% מכלל הגולשים עד למגבלה של 10,000 גולשים ביום באתר. מגבלה זו ניתנת לעדכון כחלק מקוד' ה-Analytics שאתם מוסיפים לאתר שלכם.

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

כיצד מחושב הממוצע לאתר ?

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

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

המלצות

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

San Francisco, California, USA and Yokneam Moshava, Israel: February 6, 2012 – MuseGlobal, Inc. and Efficens Software Ltd. announced today that Efficens will resell in Israel the MuseGlobal suite of Social Business Content Platform. The reseller agreement, which further expands MuseGlobal’s worldwide channel, enables the Israeli market to tap into the most comprehensive and proven Smart Connector technology from one source.

Efficens, headquartered in Yokneam Moshava, Israel is a leader in Application Performance Management solutions (APM) and Web Performance Operations (WPO). The company helps organizations maximize their business value through the use of cutting edge technologies and innovative ideas.

“MuseGlobal is the world leader of content harvesting and federation technologies,” said Gil Givati, Efficens’ CEO. “MuseGlobal has the world’s largest inventory of 6,500 Smart Connectors. We’re excited by the opportunity to work with MuseGlobal to increase the accessibility of Social Business Software in the growing Israeli market.”

MuseGlobal is headquartered in San Francisco, California USA and has development offices in Craiova, Romania. Whether it's structured or unstructured content, Internet, mobile or enterprise networks, startups or Global 2000 corporations, the world's leading organizations trust MuseGlobal to deliver the most important content from every key source and to facilitate informed decisions.

“Our channel growth strategy is designed to match potential new partners throughout the world with MuseGlobal’s proven Social Business Content Platform,” said Kristina Bivins, President and CEO of MuseGlobal. “Efficens is an established and credible reseller in Israel. This partnership marks MuseGlobal’s aggressive commitment to expand its worldwide channel.”

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

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

הרמה השנייה של ההגנה הינה בעצם היכולת לחסום גישה לכתובות מסויימות, דבר אשר קיים גם ברכיבי הגנה ו-Load Balancers נפוצים בשוק. כאשר מותקן aiCache בסביבת אשכול (cluster) כל השרתים מעדכנים אחד את השני בכתובות המותרות והאסורות ובכך מקלים על הניהול.

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

הרמה הרביעית והאחרונה הינה RTATC - Reverse-Turing Access Token Control. במסגרת רמה זו, אם aiCache מזהה פעילות עודפת, נשלחת בקשה לגולש על מנת לאשר את היותו אדם (כמו בקשת Captcha המוכרת לנו בטפסים שונים). אם הגולש ענה נכונה, נשלחת לגולש מאחורי הקלעים מעין "סיסמת הזדהות חבויה" המצורפת לכל התקשורת שלו מול השרת ובכך תאושר המשך עבודתו מול השרת וכתובתו לא תיחסם.

aiCache משרת היום את אתר CNBC כך שאין מה לחשוש מעיכובי ביצועים. נהפוך הוא, מבדיקות ביצועים שערכנו, עצם העובדה שהשרת שומר אצלו בזכרון רכיבים רבים עוזרת לשפר את מהירות האתר בכ-30%.

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

]]> http://www.efficens-software.com/2012/01/dos_preventio/feed/ 0 http://www.efficens-software.com/2012/01/social_plugins/ http://www.efficens-software.com/2012/01/social_plugins/#comments Thu, 12 Jan 2012 08:15:10 +0000 gil http://www.efficens-software.com/?p=684

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

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

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

אז מה הפתרון ?

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

<script>

(function(d, s) {

  var js, fjs = d.getElementsByTagName(s)[0], load = function(url, id) {

    if (d.getElementById(id)) {return;}

    js = d.createElement(s); js.src = url; js.id = id;

    fjs.parentNode.insertBefore(js, fjs);

  };

  load('//connect.facebook.net/en_US/all.js#appId=272697932759946&xfbml=1', 'fbjssdk');

  load('https://apis.google.com/js/plusone.js', 'gplus1js');

  load('//platform.twitter.com/widgets.js', 'tweetjs');

}(document, 'script'));

</script>

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

הפתרון הטוב יותר מבוסס על קטע הקוד הבא:

<script>

(function(w, d, s) {

  function go(){

    var js, fjs = d.getElementsByTagName(s)[0], load = function(url, id) {

         if (d.getElementById(id)) {return;}

         js = d.createElement(s); js.src = url; js.id = id;

         fjs.parentNode.insertBefore(js, fjs);

       };

    load('//connect.facebook.net/en_US/all.js#appId=272697932759946&xfbml=1', 'fbjssdk');

    load('https://apis.google.com/js/plusone.js', 'gplus1js');

    load('//platform.twitter.com/widgets.js', 'tweetjs');

  }

  if (w.addEventListener) { w.addEventListener("load", go, false); }

  else if (w.attachEvent) { w.attachEvent("onload",go); }

}(window, document, 'script'));

</script>

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

 אחרי כל המאמר הזה, מה באמת חשוב לזכור ?

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

]]> http://www.efficens-software.com/2012/01/social_plugins/feed/ 0 http://www.efficens-software.com/2011/10/wpo_group_new/ http://www.efficens-software.com/2011/10/wpo_group_new/#comments Tue, 25 Oct 2011 20:22:20 +0000 gil http://www.efficens-software.com/?p=646 אפיסנס סופטוור, המובילה בתחום שיפור מהירות אתרי אינטרנט, השיקה את קבוצת המשתמשים הישראלית בנושא. הקבוצה, אחת מתוך רשת בינלאומית, מונה עשרות חברים ותדון בנושאים הקשורים למהירות אתרים. במפגש הראשון, אשר נערך במשרדי חברת מטריקס ובחסותה, הוצגו עקרונות תורת שיפור מהירות האתרים, מהגדרת חשיבותם העסקית וכלה בכלי בדיקה ללא תשלום. המפגשים ייערכו אחת למספר שבועות ללא תשלום.

ניתן לצפות במצגת שהועברה במפגש בכתובת זו.

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

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

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

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

את המדידה ביצענו מספר פעמים באמצעות אתר WebPageTest על דפדפן Internet Explorer 8 שמותקן על מחשב נייד סטנדרטי ברשת ביתית ממוצעת בישראל. התוצאות שהתקבלו היו מפתיעות. דווקא אתר טוטי היה המהיר ביותר מבין חמשת האתרים ונטען תוך פרק זמן של 3 שניות. הצגת דף הבית במלואו ארכה עוד 100 מילישניות נוספות ובסה"כ דף הבית נטען תוך פרק זמן של 3.1 שניות.

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

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

אז מדוע קיבל "הלול" ציון כה גבוה ? הנה שלוש סיבות:

1. בגלל שימוש נכון בזכרון של הדפדפן בבית כל גולש וגולש לאתר
2. בגלל מספר מועט של קבצי פקודות המגיעות מהאתר עצמו (כל הקריאות לקבצים של פייסבוק מגיעים מ"דפי משנה – IFRAMES בדף)
3. בגלל סדר נכון של רכיבי קוד בדף

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

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

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

הבקשה (The Request)

מרגע שסיימנו לכתוב את כתובת הדף המבוקש (ה-URL) או שלחצנו על קישור, שולח הדפדפן בקשה אל שרת האינטרנט. הבקשה מעובדת על ידי השרת והמנועים שעומדים מאחוריו (PHP, ASP.NET, Java, Python ואחרים) עד אשר הושלמה מלאכת בניית דף ה-HTML אותו ביקשנו. בשלב זה לא נתעכב על מאחורי הקלעים של שרת ה-Web כיון שברובם המוחלט של האתרים, צוואר הבקבוק אינו נמצא בשלב זה.

מה שחשוב לנו לדעת הוא שמרגע שהשרת התחיל לשלוח אלינו חזרה את הדף, עם קבלת הבית (Byte) הראשון מתחיל השלב שבו הדפדפן נכנס לפעולה. אם ברצונכם להבין מה הזמן שלוקח לשרת להגיב לבקשה הראשית ולייצר את הדף, תוכלו להסתכל על ה-waterfall chart (מדריך מהיר להבנת התרשים פורסם כאן) ולחפש את הקריאה הראשונה לדף. ה-Time To First Byte, או בקיצור TTFB של הבקשה הוא זמן השרת.

דף חדש נולד – The Response

מרגע קבלת הבית הראשון של התשובה מהשרת, מתחיל הדפדפן להעביר את הטקסט שהגיע ל-HTML Parser. בתהליך שנקרא טוקניזציה (tokenization), ה-Parser מייצר token-ים עבור כל תחילת תג, סוף תג וכל תו ביניהם. למשל, אם מתקבל הטקסט <b>hello</b>, מייצר תהליך זה שבעה Token-ים:

start-tag { name: b }
character { data: h }
character { data: e }
character { data: l }
character { data: l }
character { data: o }
end-tag { name: b }

אחרי שכל Token נוצר, הוא מועבר לפי סדר הגעה לרכיב אשר בונה את עץ ה-DOM. רכיב זה מייצר את ה"ענפים" המתאימים בעץ שייצג לנו את דף ה-HTML אותו קיבלנו מהשרת. ברגע שבו ענף פונה למשאב חיצוני כמו תמונה, סקריפט או קובץ CSS, מתחיל תהליך של הבאת אותו משאב. הדפדפן עצמו בנוי לבצע מספר פעילויות מסוג זה  במקביל על מנת לקצר את הזמן הדרוש להשלמת שלב זה. רמת המקביליות נעה בין 4 ל-8 פעולות מול כתובת שרת בודדת ומשתנה מדפדפן לדפדפן. כל תהליך ה-Parsing יעיל תמיד למעט הטיפול בדבר אחד: סקריפטים.

סקריפטים

כאשר מגיע ה-Parser לתג סיום סקריפט הוא חייב להריצו לפני שיוכל להמשיך ב-parsing עצמו. זה נכון לכל המקרים למעט סקריפטים שצויינו במפורש ככאלו שייטענו או יופעלו מאוחר יותר באמצעות תגיות Defer או Async. לפני שסקריפט יכול לרוץ, חייבים להתקיים שני תנאים:

• אם הסקריפט חיצוני הוא חייב להיטען במלואו מהמקור החיצוני
• כל קבצי ה-CSS והגדרות העיצוב חייבים להיטען במלואם

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

למה לעצור את ניתוח הדף ?

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

למה לחכות להגדרות העיצוב ?

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

האם ההמתנה פוגעת בביצועים ?

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

איך מתמודדים ?

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

סיימנו, מה עכשיו ?

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

בשורה התחתונה

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

חברת riverbed הינה אחת הספקיות הגדולות בעולם בתחום שיפור ביצועי רשתות WAN. בנוסף רכשה החברה גם את חברת zeus, המתמחה בפתרונות load balancing.

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

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

זמני טעינת הדפים (במלואם)

1. קופת חולים לאומית – 2.917 שנ'
2. מכבי שירותי בריאות – 3.55 שנ'
3. שירותי בריאות כללית – 5.995 שנ'
4. קופת חולים מאוחדת – 10.194 שנ'

בעת ביקור חוזר התוצאות מעט שונות:

1. מכבי שירותי בריאות – 2.379 שנ'
2. קופת חולים לאומית  – 2.398 שנ'
3. קופת חולים כללית – 6.174 שנ'
4. קופת חולים מאוחדת – 8.365 שנ'

מספר הרכיבים בדף

1. מכבי שירותי בריאות – 49
2. שירותי בריאות כללית – 62
3. קופת חולים לאומית – 92
4. קופת חולים מאוחדת – 124

בעת ביקור חוזר התוצאות לצערנו דומות:

1. מכבי שירותי בריאות – 48
2. שירותי בריאות כללית – 61
3. קופת חולים לאומית – 88
4. קופת חולים מאוחדת – 124

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

נפח הנתונים בדף למבקר חדש (ב-KB)

1. שירותי בריאות כללית – 519
2. קופת חולים לאומית – 790
3. מכבי שירותי בריאות – 900
4. קופת חולים מאוחדת – 1663 (1.6MB בערך !!!)

מה רצינו שתקחו מההשוואה הזו ?

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

ואיך זה נראה אצל הגולש בבית (אחד לצד השני ) ?

אם אינכם יכולים לצפות בסרטון בדף זה, הורידו את הסרטון אליכם 

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

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

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

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