+Google

خلاصه

+Google کاملاً پاسخگو می شود.

پاسخگو شدن

Google+‎ جایی است که افراد پیرامون علایق مشترک گرد هم می‌آیند، از گربه‌های زامبی گرفته تا ماشین‌حساب‌های قدیمی. تا همین اواخر، +Google دو نسخه مختلف از وب سایت خود داشت - یکی برای دسکتاپ، و دیگری برای وب تلفن همراه که برای مرورگرهای قدیمی طراحی شده بود.

چالش ها

نگهداری از دو سایت مجموعه ای منحصر به فرد از چالش ها را به همراه داشت. داشتن نسخه های جداگانه از سایت به این معنی بود که هر ویژگی باید دو بار پیاده سازی می شد. این منجر به تعداد زیادی کد تکراری و تلاش اضافی برای بهینه سازی دو تجربه برای وب دسکتاپ و موبایل شد. و همانطور که خطوط بین دستگاه‌ها به طور فزاینده‌ای تار می‌شد - با دسکتاپ‌هایی که از لمسی و دستگاه‌های موبایل قدرتمند با صفحه‌نمایش بزرگ‌تر پشتیبانی می‌کنند - داشتن طرح‌های مختلف برای دسک‌تاپ و موبایل کمتر و کمتر حس می‌کرد.

با افزودن ویژگی‌ها، سایت دسکتاپ قدیمی ما نیز کند و متورم شد. در اوایل امسال صفحه اصلی ما حدود 5 مگابایت وزن داشت و حدود 250 درخواست HTTP ایجاد کرد. فقط عملکرد خوبی نداشت تصاویر موجود در سایت سنگین و بهینه نبودند و سرعت صفحه را بیشتر کند کردند. در نتیجه، جریان ما در شبکه‌های کند و ناپایدار تقریباً غیرقابل دسترسی بود و تجربه این کاربران در بهترین حالت ناامیدکننده بود. علاوه بر این، نیاز به پشتیبانی از مرورگرهای قدیمی در وب تلفن همراه، ما را از تکیه بر جاوا اسکریپت در سرتاسر سایت باز داشت و مانع از اجرای ویژگی‌های بسیار تعاملی شد. ما نمی توانستیم به پیشرفت های مرورگرهای وب موبایل تکیه کنیم.

راه حل

ما با تمرکز بر طراحی واکنشگرا شروع کردیم: یک پیاده سازی که در تلفن همراه، تبلت، دسکتاپ و فراتر از آن کار می کند. ما همه ویژگی‌ها، صفحه‌ها، کتابخانه جاوا اسکریپت و کلاس CSS را به طور کامل بررسی کردیم. ما می‌خواستیم سیستمی بسازیم که اطمینان حاصل کند که سایت فقط مواردی را که برای عملکرد کاملا ضروری است دانلود می‌کند مگر اینکه کاربر بیشتر درخواست کند. چالش، ساختن وب‌سایتی بود که در تلفن همراه کندتر با اتصال سلولی به درستی کار می‌کرد، اما همچنان در مرورگرهای سریع‌تر و صفحه‌نمایش‌های بزرگ‌تر، تجربه غوطه‌وری عالی را ارائه می‌کرد.

این مجموعه از محدودیت ها به این معنی بود که ما مجبور بودیم هر تغییر کد را در آینده بررسی کنیم. برای رسیدن به این هدف، یک قانون 6^5 ایجاد کردیم تا اطمینان حاصل کنیم که در بارگذاری اولیه صفحه، بیش از 60 هزار HTML، 60 هزار جاوا اسکریپت، 60 هزار CSS دانلود نمی‌کنیم، انیمیشن‌های ما همیشه 60 فریم در ثانیه بودند و متوسط ​​تأخیر 0.6 داشتیم. س

برای رسیدن به این هدف، ما چارچوب‌های جاوا اسکریپت و CSS را انتخاب کردیم که از ابتدا ماژولار بودن و بارگذاری تنبل را ایجاد می‌کردند. بنابراین اطمینان حاصل می کنیم که کاربران فقط زمانی جاوا اسکریپت و CSS را دانلود می کنند که واقعاً از ویژگی مورد نیاز استفاده می کنند. این کار از طریق یک رویکرد مبتنی بر الگو انجام می شود که با سیستم ساخت و ماژول ما ترکیب می شود تا کارها تقریباً بدون تلاش توسعه دهندگان کار کنند.

با این چارچوب جدید، ما شروع به ساخت نمونه اولیه از Google+ در وب کردیم. شروع کردیم به نپذیرفتن چیزهای «بد» و وضع قوانین سختگیرانه برای توسعه. یکی از قوانین اصلی ما این بود که همه صفحات ما باید هم سمت سرور و هم در سمت کلاینت رندر شوند. با رندر سمت سرور، مطمئن می شویم که کاربر می تواند به محض بارگیری HTML شروع به خواندن کند و برای به روز رسانی محتوای صفحه نیازی به اجرا شدن جاوا اسکریپت نیست. هنگامی که صفحه بارگیری می شود و کاربر روی یک پیوند کلیک می کند، ما نمی خواهیم یک سفر رفت و برگشت کامل انجام دهیم تا همه چیز دوباره ارائه شود. اینجاست که رندر سمت کلاینت اهمیت می‌یابد - فقط باید داده‌ها و الگوها را واکشی کنیم و صفحه جدید را روی کلاینت رندر کنیم. این شامل مبادلات زیادی است. بنابراین ما از چارچوبی استفاده کردیم که رندر سمت سرور و سمت کلاینت را آسان می‌کند، بدون اینکه مجبور باشیم همه چیز را دوبار پیاده‌سازی کنیم - روی سرور و روی کلاینت.

قوانین دیگر شامل غیرمجاز ساختن انیمیشن ارتفاع و عرض بود که باعث طرح‌بندی مجدد مرورگر می‌شد و تأثیرات منفی بر عملکرد خواهد داشت. برای دستکاری‌های DOM و انیمیشن‌ها، وظایفی را برنامه‌ریزی کردیم که به صورت همگام با نرخ به‌روزرسانی رندر مرورگر انجام شوند. ما همچنین همه وظایف اندازه گیری را با هم گروه بندی می کنیم تا بتوانیم از محاسبات تکراری سبک پرهزینه جلوگیری کنیم. ما همچنین به شدت به ابزارهای نمایه‌ساز کروم متکی بودیم تا مطمئن شویم که همه چیز همانطور که در نظر داشتیم کار می‌کند. علاوه بر این، ما ابزارهایی ایجاد کردیم که تأثیر تغییرات کد را بر روی JS-footprint محاسبه می‌کند تا مطمئن شویم اندازه صفحه خود را به شدت افزایش نمی‌دهیم.

این مدتی طول کشید، اما اگر توانایی شناسایی و حذف مشکلات را در حین ساختن نداشتیم، بسیار دشوارتر بود.

ما نسخه موبایل-وب خود را از این پیاده سازی پاسخگو در فوریه 2015 راه اندازی کردیم. این به ما اجازه داد تا طرح های جدید و روند جدید خود را بررسی کنیم. ما از داده‌های این راه‌اندازی استفاده کردیم تا تأیید کنیم که چه چیزی کار می‌کند و چه چیزی نیست. ما طرح را تکرار کردیم و شروع به گسترش برای پشتیبانی از دستگاه‌های بیشتری کردیم. در نوامبر 2015، ما این پیاده سازی جدید را در همه دستگاه ها راه اندازی کردیم.

نتایج

بدون به خطر انداختن عملکرد، Google+‎ توانست یک برنامه وب پیچیده با رابط کاربری غنی بسازد. سایت در حال حاضر سریعتر و نابتر از قبل است.