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

פורמטי תמונות – תזכורת

GIF

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

JPG

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

 PNG

פורמט ה-PNG פותח כתחליף לפורמט ה-GIF ויכול להחליפו כמעט תמיד (למעט כאשר נדרשת אנימציה). תמונות בפורמט זה יכולות להיות באחת משתי רמות צבע: PNG-8 שומר 256 צבעים ואילו PNG24 מאפשר צבעים אמיתיים. פורמט ה-PNG שומר את המידע בנפחים קטנים יותר מאשר קבצי GIF והופך להיות פופולארי יותר ויותר. לראיה: בשנה האחרונה 7% מהתמונות באתרים שינו את סוגם מ-GIF ל-PNG. חשוב לדעת כי בדפדפנים ישנים מאד דוגמת Internet Explorer 6, קיימת בעיית הצגת תמונות בפורמט זה הכוללות שקיפות, אולם הדבר ניתן לתיקון באמצעות קוד JavaScript.

 המלצות

• אלא אם מדובר בתמונה עם אנימציה, תמיד העדיפו PNG על GIF. שימו לב, ברוב המוחלט של המקרים עליכם לוודא שאתם עושים שימוש ב-PNG8 אחרת הקובץ יהיה גדול יותר ויכיל מידע מיותר.
• עבור תמונות הדורשות צבעים רבים, בחרו ב-JPEG.
• קבצי PNG שומרים את המידע בקבוצות המייצרות תקורה מסויימת. חלק מקבוצות אלה ניתנות למחיקה אולם מרבית התוכנות אינן עושות זאת באופן אוטומטי. עשו שימוש בכלים כגון PNGCrush או OptiPNG.
• בעת שמירת תמונה בפורמט JPEG מתוך תוכנות גרפיות, לעיתים רבים אנו נשאלים על "איכות" התמונה בעת השמירה. במקרים רבים ראינו כי ברירת המחדל שמציעים כלים אלה עומדת על 80. אין משמעות הדבר שתאבדו 20% מאיכות התמונה. גופים כמו Adobe, ממליצים לשמור תמונות באיכות שנעה בין 70 ל-80 ובכך לחסוך משמעותית בגודל הקובץ בלי לפגוע כמעט באופן שבו עין רגילה תזהה את איכות התמונה.
• קבצי JPEG מכילים מידע רב שנועד לשמש כתיאור התמונה. מומלץ בטרם העלאת התמונות לאתר לעשות שימוש בתוכניות שירות כגון JPEGtran.

את ההשוואה למתחרים ביצענו רק בסיום המשימה שקיבלנו על עצמנו.

נקודת הפתיחה לפרויקט

את הפרויקט התחלנו לאחר ביצוע בדיקות חוזרות ונשנות לאתר, הן באמצעות Internet Explorer והן  באמצעות Chrome במהירויות גלישה שונות.  בסיום הבדיקות מצאנו אתר, אשר למרות ציון PageSpeed גבוה של 94 (מתוך 100), זמני הטעינה הממוצעים שלו עומדים על למעלה מ-7 שניות . בנוסף, משתמש הגולש לאתר נאלץ לחכות למעלה מ-2 שניות עד שתכני הדף מתחילים להיות מוצגים לו.

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

שלב א' – איחוד קריאות ושיפור זמן תגובת שרת

לאור העובדה שריבוי בקשות לשרת הינו הגורם המשמעותי ביותר בזמני טעינת דפים, התחלנו לבדוק אלו בקשות ניתן לאחד. בדקנו את הקריאות הבודדות לקבצי JS, את מיקומן בעץ הקריאות  והאם ניתן לאחדם באופן שלא יפגע בפונקציונליות של האתר. באופן דומה בדקנו גם את הגדרות ה-CSS השונות. במקביל לפעולות איחוד אלה, התחברנו ישירות לשרת המארח את האתר ושינינו בו הגדרות, אשר יאפשרו לאתר האינטרנט לתת מענה מהיר יותר לבקשות הגולשים ולנהל את הדיאלוג מולם בצורה יעילה.

הרווח שלנו: שנייה בזמן התצוגה, 700 מילישניות בזמן הלוקח לשרת לענות לבקשה ושניה בזמן הלוקח לדפדפן להתחיל לצייר את הדף.

שלב ב' – שיפור הפניות לתמונות מרכזיות

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

הרווח שלנו: 500 מילישניות בהצגת הדף כולו ו-20 מילישניות בתחילת זמן הצגת הדף לגולש.

שלב ג' – שיפור קריאות לרכיבי צד שלישי (למעט רשתות חברתיות)

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

הרווח שלנו: 2.6 שניות בזמן הצגת הדף כולו לגולש ו-60 מילישניות נוספות בזמן תחילת התצוגה.

סיכום ביניים

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

ומה עם חברות SEO אחרות ?

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

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

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

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

מה נמדד ?

שני הפתרונות מודדים בעקרון את אותו נתון – הזמן שעובר מביצוע הבקשה עצמה ועד לשלב ה-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) מוקדם ככל האפשר ואת אותם סקריפטים לטעון ולהריץ מאוחר ככל האפשר.