|
|
|
Rules for High Performance Web Sites
|
|
מאת גלעד דניאל, מפתח בחברת Netwise. אפריל 2008
|
|
|
תקציר המאמר:
מפתחים נוהגים לחלק אתר חדש לשניים: צד השרת (או הצד האחורי) והצד הקדמי של הלקוח. עד כה, רבות נכתב על צד השרת ולכן מאמר זה יתמקד דווקא בצד הלקוח, המכיל, בין היתר, את ה- IIS, ה- HTML שנוצר, התמונות, קוד לקוח וקובצי CSS. מטרת מאמר זה לענות על השאלה – כיצד ניתן לשפר את זמן העבודה של הדפדפן?
|
|
|
|
במסגרת עבודתי התבקשתי לשפר את הביצועים של אתר web 2 שפיתחנו בצוות. הלקוח ביקש לדעת האם ניתן לשפר את זמן עבודת הדפדפן מרגע שהגולש מבקש להעלות דף ועד הרגע שהדפדפן מסיים את ה "רנדור" שלו. כדי לפתור את הבעיה היה עליי לחקור טכנולוגיות וכלים שונים, ובמהלך המחקר למדתי להכיר את החוקים של yahoo. במאמר אציג את השלבים עד לפתרון הבעיה, וכן אשווה את החוקים של yahoo לשלבים שביצעתי במטרה לשפר את זמן עבודת הדפדפן.
|
|
|
|
שלב I : נסו לצמצם את מספר הקריאות לשרת - Make Fewer HTTP Requests
|
|
כשגולש מבקש דף באתר בעזרת דפדפן זה או אחר, הקריאה יוצאת לשרת ה-IIS שמקבל את הקריאה ומתחיל להפציץ בחזרה נתונים. הנתונים אותם מקבל הדפדפן הם שאר החלקים בדף שהוא חייב לבקש מהשרת כדי לקבל את התמונה המלאה של הדף. דף מורכב מקובץ html שמכיל לרוב תמונות, קובצי קוד לקוח (javascript), גיליונות סגנון מדורגים (CSS), קובצי Flash (למשל וידאו) ועוד. כל קובץ כזה הוא בקשה לשרת ה- IIS שישלח לדפדפן את הקובץ עם הנתונים. אם ניקח לדוגמה את דף הבית של Netwise, נראה כי קיימות 46 בקשות (Request) שגודלן כמעט 400KB. כלומר, על כל גולש שנכנס לדף יש 46 קריאות ל"רנדר" את הדף, זאת מבלי להזכיר עדיין את ה- chache, הקורה בעת שלקוח חוזר או עובר לדפים אחרים באפליקציה.
|
|
|
|
משתמש חדש גוזל מאיתנו המון משאבים כשהוא מבקש דף מסוים, ולכן החוק הראשון הוא לצמצם את מספר הקריאות. ניתן לעשות זאת באמצעות שתי טכניקות:
|
|
|
|
1. CSS Sprites – באתר שבדקנו השתמשנו רבות בטכניקה של החלפת תמונות - מעין תמונה על רקע כחול במקרה רגיל, וכשהעכבר עובר עליה הרקע מתחלף לאדום. השימוש העיקרי שלנו בתמונות הוא כדי להעביר מסרים בצורה גרפית. הדרך שלנו לצמצם את מספר הקריאות היא לאחד את התמונות. לדוגמה, תמונה שנמצאת ב-menu של האתר, ובכל פעם שהלקוח עובר עליה היא משנה את הרקע עליו הייתה כתובה.
|
|
|
 מראה רגיל
|
 מראה משתנה שהגולש לוחץ עליו.
(selected menu)
קיימות שתי קריאות לאלמנט גרפי המשתנה כשהגולש עובר עליו:
|
|
|
 זוהי תמונה שיש עליה כבר את שני המצבים של ה-menu ואפילו הוספנו עוד מצב ל- hover.
|
|
|
|
אנחנו נציג את התמונה הנכונה בעזרת CSS (בדוגמאות שמצורפות מטה יש הסברים מדויקים איך למקם בעזרתbackground-postion שעובד גם בכל הדפדפנים). כמובן שבאותה תמונה נוכל להשתמש לאורך כל הדף ובכל האלמנטים של ה- Menus. כלומר, אין צורך לשכפל את התמונות, אלא אפשר לקחת תמונה גדולה ובעזרת positions לבחור איזו תמונה להציג.
|
|
|
|
הדוגמה הבאה מציגה בעזרת CSS לינקים של צורות גיאומטריות. בעזרת הזזות של CSS נוצר רושם של מספר תמונות למרות שמדובר בתמונה אחת.
|
|
|
(הדוגמה לקוחה מהאתר: http://www.alistapart.com/d/sprites/ala-blobs2.html)
|
|
|
|
לסיכום: הורדנו את מספר הקריאות לשרת, ובמקביל חסכנו כמה KB. תמונה גדולה אחת חסכונית יותר בגודלה בהשוואה לכמה תמונות קטנות.
|
|
|
|
2. חיבור של מספר קבצים לקובץ אחד Combined files – אחד היתרונות של קובצי
javascript חיצוניים הוא שניתן לשמור אותם ב-chache של הגולש, כדי לחסוך בזמן ההורדה בדף הבא שהוא גולש אליו או בפעם הבאה שהוא חוזר לאתר. אבל מה קורה כשגולש נכנס לאתר בפעם הראשונה?
|
|
|
|
באתר Netwise שעדיין לא עבר שינויים ישנם 7 קובצי javascript חיצוניים (הקוד שלהם נמצא בקובץ ולא נכתב על ה-html עצמו). כלומר, ישנן 7 קריאות שונות כדי לקבל את הקבצים. הרעיון של הורדת מספר הקריאות יתאפשר אם נאחד בין כל הקבצים, וניצור קובץ משותף אחד שיכיל את הקוד של שאר הקבצים. איחוד כזה יחסוך לנו 6 קריאות לשרת! הקובץ החדש שיצרנו עלול לגרום לעיכוב קצר בזמן הפיתוח, כיוון שצריך לעקוב אחריו ולדאוג שלא יהיו שינויים בסביבת הפיתוח שנפספס בסביבת הייצור. לכן מומלץ להכין אסטרטגיה של העברת גרסה לסביבת הייצור כך שלא ניפגע. בשלב הבא נדבר על כיווץ קובץ כדי לחסוך במקום, בנוסף להורדה במספר הקריאות.
|
|
|
|
לסיכום: חשוב מאוד להקפיד ולנסות להוריד את מספר הקריאות לשרת, כדי לחסוך את התעבורה מול אותו שרת.
|
|
|
|
שלב II: נסו לכווץ את המידע שנשלח למשתמש במערכת
|
|
בסעיף הקודם דיברנו על הורדת מספר הבקשות לשרת ה- IIS אבל עדיין נשארנו עם אותה "חבילה" של מידע שמגיעה עם כל בקשה לדף. לכן אנחנו צריכים למצוא פתרון הדומה לכיווץ ZIP, כמו שאנחנו עושים במערכת ההפעלה. גם כאן נדבר על שתי טכניקות של כיווץ:
|
|
|
1. כיווץ JavaScript - בדרך כלל קובץ JavaScript מכיל המון תווים מיותרים, חלקם תווי רווח, ירידת שורה, הערות ועוד. התווים הללו אולי נחוצים לקריאות של אותם קבצים בזמן הפיתוח אבל אין שום סיבה שהלקוח יקבל אותם. לכן חיפשתי כלי שיקרא את הקובץ, ובעזרת החלפות יוריד בצורה חכמה את כל התווים שאנחנו לא צריכים. אותו כלי צריך להבין גם את נושא ההערות וניואנסים נוספים. הכלי הראשון שנתקלתי בו נקרא JsMin - זהו קובץ EXE שניתן להריץ על קובץ קיים וגם על ה- class בכמה שפות תכנות שנוכל לממש בעצמנו.
באמצעות הכלי נקבל קובץ מכווץ שאותו ניתן לשתול בסביבת הייצור במקום אותו קובץ גדול. החיסכון במקום ברוב המקרים הוא גדול ויכול להגיע ליותר מ-50% חיסכון במקום. השיטה שהשתמשתי באתר שבדקתי היתה לייצר קובץ רגיל > לשנות לו את הסיומת > לכווץ אותו ואת התוצאה לשמור בקובץ עם השם המקורי. כך יהיו לנו שני קבצים, אחד פתוח והשני מכווץ. הדבר קצת סירבל את המעקב כיוון שצריך לדאוג לשתי גרסאות ובזמן העלייה לשרת הייצור צריך לבדוק אם הגרסה טובה ועדכנית.
כלי נוסף שאני ממליץ להשתמש בו הוא JsLint. כלי זה בודק את התחביר של הקובץ כדי למנוע בעיות בכיווץ, כגון אי הקפדה על ; (למרות שלא חובה ב JavaScript) ובעיקר בעיות עם ביטויים רגלורים. באתר ניתן לעלות את הקובץ כדי לבדוק טעויות תחביריות לפני כיווץ.
ניתן להשתמש בדוחס JavaScript באתר:
http://www.brainjar.com/js/crunch/demo.html
|
|
|
2. כיווץ Gzip של קבצים:
האם אנחנו יכולים לכווץ את כל הקבצים של האתר בקובץZIP , לשלוח ללקוח ולקוות שהוא יוכל לפתוח אותו ולגלוש בדף? התשובה היא כן אבל עם סייגים. אם משתמשים ב-IIS6, קיימת אפשרות לדאוג לכך שכל הקבצים יעברו כיווץ בעזרת Gzip לפני שהם נשלחים ללקוח כי הדפדפן אחראי על פתיחה מחדש ו"רנדור" שלהם. הדפדפן אחראי לשלוח לנו בקשה לדף עם כותרת שקובעת אם הוא יכול לקבל מידע מכווץ. שרת ה- IIS מקבל את הבקשה ולפי הכללים שהגדרנו על האתר שלנו הקבצים יכווצו בהתאמה ויישלחו ללקוח. ישנם שני סוגים של דפים שניתן לכווץ: דפים סטטיים ודינמיים.
לפני תחילת המימוש יש ללחוץ על המאפיינים של כל ה- Websites,להגיע לתגית של ה- service ולכווץ.
לסיכום: תכווצו, תכווצו, תכווצו, וכמובן תדאגו שהכל עובד אחר הכיווץ.
מידע נוסף בנושא ניתן לקרוא באתרים:
|
|
|
|
שלב III – היכרות קצרה עם Yslow ו- Exceptional Performance Team
|
במהלך חיפוש המידע מצאתי קבוצה ב-Yahoo שאחראית על כתיבה ויישום של נהלי עבודה לשיפור ביצועים של אתרי Yahoo למיניהם. הקבוצה ניסחה 14 כללים לשיפור צד הלקוח. הכללים לקוחים מהאתר:
http://developer.yahoo.com/performance/index.html#rules
|
|
|
1. Make Fewer HTTP Requests
2. Use a Content Delivery Network
3. Add an Expires Header
4. Gzip Components
5. Put CSS at the Top
6. Move Scripts to the Bottom
7. Avoid CSS Expressions
8. Make JavaScript and CSS External
9. Reduce DNS Lookups
10. Minify JavaScript
11. Avoid Redirects
12. Remove Duplicate Scripts
13. Configure ETags
14. Make Ajax Cacheable
|
|
|
|
בכללים 1, 4 ו-10 טיפלנו עד כה. כעת נעבור בקצרה על שאר הכללים שמימשתי באתר.
|
|
|
כלל 2: מתייחס למערכות cache גדולות כמו Akamai, שחוץ מ-cache אחראיות על כל נושא טיפול בבקשות של לקוח לפי מיקום גיאוגרפי.
כלל 3: חשוב מאוד בהגדרה של שרת ה- IIS לתיקיות. חשוב להוסיף expiration header - אותן תגיות שחוזרות עם הבקשה כדי לבקש מהדפדפן שאותו קובץ יישמר בזיכרון שלו לתקופה שהגדרנו. כל בקשה שהולכת ל- cache ולא הולך לשרת שלנו, דיינו.
כלל 5: שימו את כל ה- CSS לינקים בתגיות head של ה-html.
כלל 6: כלל זה היה בעייתי בשבילי מכיוון שעל פיו יש למקם את קובצי צד הלקוח בסוף, כך שכל הקבצים האחרים יעלו לפניהם. עבורי זו היתה בעיה כיוון שחלק מהדפים דרשו פונקציות צד לקוח שעקב המעבר שלהם לסוף עדיין לא עלו.
כלל 7: expression הוא כתיבה של ביטויים ב-JavaScript בתוך קובצי ה CSS שלנו.
כלל 8: כל הקוד יהיה בקבצים ולא רשום בדפים, ואם הוא רשום אז ניתן לכווץ אותו. כמו כן, כל crawlers (מנועי חיפוש) מוגבלים לגודל של הדף אותו הם שואבים (נכון להיום הם פשוט די מתעלמים למרות שיש משהו מכיוון של גוגל). אם נרשום קוד JavaScript בתוך הדפים הם יהפכו לחלק מהדף, מה שעלול לגרום לחלק מהתוכן האיכותי להיעלם.
כלל 14: בעזרת הכלים שהזכרתי עד כה הצלחנו גם פה לחסוך.
עם כללים 9, 12, 13 לא עבדתי ולכן ניתן לקרוא עליהם בהרחבה באתר.
|
|
|
כדי לדעת אם אנו עומדים בחוקים של yahoo, אני ממליץ להשתמש בתוסף Yslow. אני נוהג להריץ את התוסף על מוזילה, וכמעט בכל אתר שאליו אני גולש אני מתחיל בבדיקה קצרה כדי לראות איפה האתר עומד.
כאשר ניגשתי למשימה צד השרת היה חשוב יותר: שיפור הגישה ל-database ועוד שיפורים בקוד. אבל את השיפור המשמעותי קיבלתי כאשר עבדתי על צד הלקוח. חשוב לזכור שהמשתמשים הם החשובים ביותר, ואם לוקח זמן עד שבדף עולה, גם אם האתר כתוב בטכנולוגיה החדשה ביותר - יצא שכרנו בהפסדנו.
אני ממליץ להמשיך לקרוא בנושא בספר של ראש הצוות של High Performance Web Sites :yahoo (הספר קצר אמנם אבל נותן מספיק מידע שיתניע אותנו המפתחים להתחיל לחשוב על צד הלקוח).
|
|
|
|
דוגמאות ל- CSS Sprites
|
http://www.websiteoptimization.com/speed/tweak/css-sprites/
http://websitetips.com/articles/css/sprites/
http://css-tricks.com/css-sprites-what-they-are-why-theyre-cool-and-how-to-use-them/
before CSS Sprites
http://css-tricks.com/examples/CSS-Sprites/Example2Before/default.htm
after CSS Sprites
http://css-tricks.com/examples/CSS-Sprites/Example2After/default.htm
|
|
|
|
|
