Google+‎

סיכום

Google+ מגיב באופן מלא.

מעבר למודעות רספונסיביות

Google+ הוא המקום שבו אנשים מתאספים יחד סביב תחומי עניין משותפים, מחתולי זומבי ועד מחשבונים ישנים. עד לא מזמן, ל-Google+ היו שתי גרסאות שונות של האתר – אחת למחשב ואחת לאינטרנט לנייד, שנועדה לדפדפנים ישנים יותר.

אתגרים

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

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

פתרון

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

כתוצאה מהאילוצים האלה, היינו צריכים לבחון בקפדנות כל שינוי בקוד בעתיד. כדי להשיג זאת, יצרנו כלל של 6^5 כדי להבטיח שבטעינת הדף הראשונית לא נוריד יותר מ-60K של HTML, 60K של JavaScript ו-60K CSS, האנימציות שלנו היו תמיד 60fps ו היה לנו זמן אחזור ממוצע של 0.6 שניות.

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

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

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

התהליך נמשך זמן מה, אבל זה היה הרבה יותר קשה אילו לא הייתה לנו יכולת לזהות את הבעיות ולטפל בהן במהלך הפיתוח.

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

תוצאות

מבלי להתפשר על הביצועים, Google+ הצליח ליצור אפליקציית אינטרנט מורכבת עם ממשק משתמש עשיר. האתר מהיר וצר יותר מאי פעם.