לפני זמן קצר, כתב ווילסון פייג' כתבה מעולה במגזין Smashing שמסבירה איך הם עוררו לחיים את אפליקציית האינטרנט של Financial Times. במאמר, ווילסון מציין:
ככל שהאפליקציה התחילה לגדול, גילינו שהביצועים התדרדרו עוד ועוד.
בילינו כמה שעות על ציר הזמן של הכלים למפתחים ב-Chrome ומצאנו את הגורם לבעיה: הלם, אימה! — זה היה החבר הכי טוב שלנו, flexbox. ציר הזמן הראה שחלק מהפריסות נמשכות קרוב ל-100 אלפיות השנייה. עיבוד מחדש של הפריסות בלי flexbox הפחית את משך הזמן ל-10 אלפיות השנייה!
התגובות של ווילסון עסקו ב-Flexbox המקורי (הקודש) שבו נעשה שימוש ב-display: box;. למרבה הצער, הם אף פעם לא הצליחו לענות אם ה-flexbox החדש (display: flex;) היה מהיר יותר, אבל ב-CSS Tricks, כריס קוייר פתח את השאלה הזו.
שאלנו את Ojan Vafai, שכתב חלק גדול מההטמעה ב-WebKit & Blink, לגבי מודל ה-flexbox החדש וההטמעה שלו.
בקוד ה-flexbox החדש יש הרבה פחות נתיבי קוד לפריסה מרובת שלבים. עם זאת, עדיין אפשר לגשת בקלות לנתיבי קוד מרובים של מעברים (לדוגמה,
flex-align: stretchעובר בדרך כלל ל-2 שלבים). ככלל, המהירות אמורה להיות מהירה יותר במקרה הנפוץ, אך אפשר לבנות מקרה שבו הוא איטי באותה מידה.
עם זאת, אם אפשר להתגבר על הקופסה, פריסת בלוקים רגילה (לא ציפה) תהיה בדרך כלל מהירה או מהירה יותר מה-Flexbox החדש, מאחר שהיא תמיד מתפצלת ל-Single-Pass. אבל ממשק flexbox חדש אמור להיות מהיר יותר משימוש בטבלאות או מכתיבת קוד פריסה מותאם אישית של JS-base.
כדי לראות את ההבדלים בין המספרים, ביצעתי השוואה ישירה בין התחביר הישן לתחביר החדש.
השוואה בין השוואה לגרסה החדשה של Flexbox
- flexbox ישן לעומת flexbox חדש (עם חלופה)
- 500 רכיבים בדף
- הערכה של עלות טעינת הדף לצורך פריסת הרכיבים
- ממוצע של 3 נקודות כל אחת
- שנמדדים במחשב. (הנייד יהיה איטי פי 10 בערך)
flexbox ישן: עלויות פריסה של ~43.5ms
flexbox חדש: עלויות פריסה של ~18.2 אלפיות שנייה
סיכום: הגרסה הישנה איטית פי 2.3 מהחדשה.
מה עליך לעשות?
כשמשתמשים ב-flexbox, יש לכתוב תמיד את התוכן החדש: התחביר של tweener ב-IE10 והגרסה המעודכנת של flexbox ב-Chrome 21 ואילך, ב-Safari 7 ואילך, ב-Firefox 22 ואילך, ב-Opera (ו-Opera Mobile) מגרסה 12.1 ואילך, ב-IE 11 ואילך וב-Blackberry 10 ואילך. במקרים רבים אפשר לחזור לגרסה הקודמת של הדפדפנים לנייד, ולהפך.
זכרו: כלים, לא כללים
מה שחשוב יותר הוא לבצע אופטימיזציה של מה שחשוב. תמיד צריך להשתמש בציר הזמן כדי לזהות צווארי בקבוק לפני שמשקיעים זמן באופטימיזציה של סוג פעולה מסוים.
למעשה, יצרנו קשר עם ווילסון ועם הצוות של Financial Times Labs וכתוצאה מכך שיפרנו את כיסוי הכלים לביצועי פריסה ב-Chrome DevTools. בקרוב נוסיף את היכולת לראות את גבולות הממסר של רכיב, ואירועי Layout בציר הזמן נטענים עם פרטים לגבי ההיקף, הבסיס והעלות של כל פריסה:
