אופטימיזציית מהירות

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

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

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

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

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

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

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

הם המליצו לקרוא את התובנות של ה-Guardian, ה-BBC ומאמר של Scott Jehl.

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

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

כמובן שבחלק מהאתרים ניסיתי ליישם את התובנות שגיליתי. ברם אולם זה לא תמיד עבד. למשל, למרות ששמתי JS בתחתית, עדיין קיבלתי הודעה שיש לי render blocking scripts. חיפוש בגוגל העלה את השרשור הזה, וממנו הגעתי לשירות המגניב של pagespeed. מה שיפה הוא שאפשר למדוד בכמה הביצועים ישתפרו אחרי שימוש בשירות.

טים קיידל מדבר על חלוקת תקציב הביצועים.

דניאל מאל מדבר על איך ליצור תקציב ביצועים.

בלי קשר, לפני כמה חודשים נתקלתי בסרטון בשם Building For Performance and Resilience. הרצאה מאד מעניינית שבה האיש הסביר את המדדים השונים של WPT כגון  First Byte ו-Start Render, ומה משפיע על כל אחד מהם. במסגרת ההסברים שלו באופן כללי, הוא המליץ על אתר SpeedCurve, המאפשר להשוות אתר האתר שלך עם שני אתרים מתחרים מכל מיני בחינות של מהירות, וגם – לא רק את הדף הראשי, אלא הוא מאפשר (בעצם מכריח) לכלול גם שני דפים פנימיים. הויזואליזציה שלו מאד יפה.
מפאת היותו של SpeedCurve כלי חדש, יש לו UserVoice. באחת הבקשות, היה כתוב כך (ההדגשה שלי) :

WPT was cool… then clients that didn’t understand the tech started using it. Now it’s just trolling designers. Cloudflare gets a terrible TTFB (http://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles) because it waits to send headers until the GZip is complete. WordPress sites always have a dozen external resources that they can’t control and the WP Engine doesn’t do progressive JPGs.

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

גם במסגרת העבודה יצא לי לדבר על זה עם אנשים שעובדים איתנו. למשל, כשדיברתי עם מישהו מריבלייז, הוא המליץ על http://www.httpwatch.com. אבל זה בעצם מאד דומה לפידלר, נראה לי.

הרצאה מעניינת נוספת שנתקלתי בה (כאמור, הנושא של אופטימיזציית מהירות מאד טרנדי כעת) היא הגשת חדשות בפחות מ-1000 מילי-שניות. איש מהגארדיאן מספר על תכנות מחדש שהם עשו לאתר, ובמסגרתו הם הציבו לעצמם תקציב של 1000 מילי שניות. לשם כך הם החליטו שהדבר החשוב ביותר באתר שלהם הוא הכתבה עצמה (כי מי שבא לאתר, בא קודם כל כדי לקרוא חדשות), ולכן הם התמקדו בהבאת התוכן הזה בפחות מ-1000 מילי שניות. את שאר התוכן הם מביאים ב-ajax, כאשר הדרך שבה הם מתמודדים עם SEO זה באמצעות placehoder-ים של קישורים למקומות שבהם ניתן לקרוא את התוכן הנכנס ב-ajax, כך שמנועי חיפוש עדיין יכולים להגיע לתוכן הזה. בעיניי זה רעיון מדליק.
שני  המרצים הסבירו דבר חשוב: למה JavsScript חוסם העלאה של דף HTML (ומשם כך חשוב לשים אותו בתחתית הדף) – הדפדפן חושש שמא יש ב-JS כתיבה של document.write, שתשנה את ה-DOM. לכן חשוב לדפדפן להעלות את ה-JS ולהריץ אותו כדי לבנות את ה-DOM פעם אחת בלבד. לכן, אם ברור לנו (המתכנתים) שאין משהו כזה ב-JS שלנו, עלינו לשים אותו בסוף ו/או להעלות אותו באופן א-סינכרוני.

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

A list apart יצאו בסדרת אירועים סנכרוניים על פיתוח לאינטרנט. הראשון, שהתקיים ביום חמישי ה-26/2, היה על ביצועים, ונמשך שעה. בהתחלה הדוברים דיברו על השאלה איך לשכנע את כל הצוות, ואת הלקוח, שביצועים הם דבר שיש לקחת בחשבון בזמן תכנון האתר. אחרי זה כל אחד מהדוברים ענה על השאלה – איזה דבר הכי חשוב לעשות באתר כדי לשפר ביצועים. דוברת אחת אמרה לכווץ תמונות, ודובר אחר אמר שחשוב לטפל במה שנמצא בנתיב הקריטי.
אחרי זה עברו לשאלות מהקהל (אחד האנשים שהיו בקהל היה קריס קויר! שדרך אגב, כתב פוסט מלא דברים טובים). אחד הצופים שאל האם הדרכים להתמודדות עם הנתיב הקריטי (למשל לשים את ה-CSS בקובץ ה-HTML) הן לא קצת מכוערות. הדוברים ענו שאכן יש בכך מן האמת, אבל שהשיפור המושג באמצעות כך משתלם. שאלה נוספת שעלתה היתה, האם בכך שמתייחסים לנתיב הקריטי, שבעצם מוגדר כ”מה שנמצא מעל ה-fold”, לא בעצם מחזיר את ה-fold, בניגוד לטרנד הנהוג היום, שבו כבר אומרים שאין דבר כזה, ה-fold.

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

עדכון 13/12/2016: פוסט על מקרה פרטי של הפחתת מהירות.

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