عملکرد وب آسان شد - نسخه Google I/O 2018

در Google IO 2018، مجموعه‌ای از ابزارها، کتابخانه‌ها و تکنیک‌های بهینه‌سازی را ارائه کردیم که بهبود عملکرد وب را آسان‌تر می‌کنند. در اینجا ما آنها را با استفاده از برنامه The Oodles Theater توضیح می دهیم. ما همچنین در مورد آزمایش های خود با بارگذاری پیش بینی و ابتکار جدید Guess.js صحبت می کنیم.

Addy Osmani

Ewa Gasperowicz

ما در سال گذشته بسیار مشغول بودیم تا بفهمیم چگونه وب را سریعتر و کارآمدتر کنیم. این منجر به ابزارها، رویکردها و کتابخانه های جدیدی شد که مایلیم در این مقاله با شما به اشتراک بگذاریم. در بخش اول، برخی از تکنیک‌های بهینه‌سازی را که در عمل هنگام توسعه برنامه The Oodles Theater استفاده می‌کردیم، به شما نشان می‌دهیم. در قسمت دوم، در مورد آزمایش‌های خود با بارگذاری پیش‌بینی‌کننده و ابتکار جدید Guess.js صحبت خواهیم کرد.

نیاز به عملکرد

اینترنت هر سال سنگین تر و سنگین تر می شود. اگر وضعیت وب را بررسی کنیم، می‌بینیم که یک صفحه میانه روی موبایل حدود 1.5 مگابایت وزن دارد که بیشتر آن جاوا اسکریپت و تصاویر است.

اندازه رو به رشد وب سایت ها، همراه با عوامل دیگر، مانند تأخیر شبکه، محدودیت های CPU، الگوهای مسدود کردن رندر یا کدهای اضافی شخص ثالث، به معمای عملکرد پیچیده کمک می کند.

اکثر کاربران سرعت را در بالای سلسله مراتب UX از نیازهایشان ارزیابی می کنند. این خیلی تعجب آور نیست، زیرا تا زمانی که بارگیری یک صفحه تمام نشده باشد، واقعاً نمی توانید کارهای زیادی انجام دهید. شما نمی توانید از صفحه ارزش بگیرید، نمی توانید زیبایی شناسی آن را تحسین کنید.

ما می دانیم که عملکرد برای کاربران مهم است، اما همچنین می تواند مانند یک راز به نظر برسد که از کجا شروع به بهینه سازی کنیم. خوشبختانه ابزارهایی وجود دارند که می توانند به شما در این راه کمک کنند.

فانوس دریایی - پایه ای برای گردش کار عملکرد

Lighthouse بخشی از Chrome DevTools است که به شما امکان می دهد وب سایت خود را ممیزی کنید و نکاتی را در مورد نحوه بهتر کردن آن به شما ارائه می دهد.

اخیراً مجموعه‌ای از ممیزی‌های عملکرد جدید را راه‌اندازی کرده‌ایم که واقعاً در گردش کار توسعه روزمره مفید هستند.

بیایید بررسی کنیم که چگونه می توانید از آنها در یک مثال عملی استفاده کنید: برنامه Oodles Theater . این یک برنامه وب نمایشی کوچک است که می‌توانید برخی از Google Doodles تعاملی مورد علاقه ما را امتحان کنید و حتی یک یا دو بازی را انجام دهید.

در حین ساختن برنامه، ما می‌خواستیم مطمئن شویم که تا حد ممکن کارایی دارد. نقطه شروع بهینه سازی گزارش Lighthouse بود.

عملکرد اولیه برنامه ما همانطور که در گزارش Lighthouse دیده می شود بسیار وحشتناک بود. در یک شبکه 3G، کاربر باید 15 ثانیه برای اولین رنگ معنادار یا برای تعامل برنامه منتظر بماند. Lighthouse تعداد زیادی از مشکلات سایت ما را برجسته کرد و نمره عملکرد کلی 23 دقیقاً منعکس کننده آن بود.

وزن صفحه حدود 3.4 مگابایت بود - ما به شدت نیاز داشتیم مقداری چربی را کاهش دهیم.

این اولین چالش عملکرد ما را آغاز کرد: چیزهایی را بیابیم که به راحتی بتوانیم آنها را حذف کنیم بدون اینکه بر تجربه کلی تأثیر بگذاریم.

فرصت های بهینه سازی عملکرد

منابع غیر ضروری را حذف کنید

موارد واضحی وجود دارد که می توان با خیال راحت حذف کرد: فضای خالی و نظرات.

Lighthouse این فرصت را در ممیزی Unminified CSS و JavaScript برجسته می کند. ما از وب پک برای فرآیند ساخت خود استفاده می کردیم، بنابراین به منظور کوچک سازی، ما به سادگی از پلاگین Uglify JS استفاده کردیم.

Minification یک کار رایج است، بنابراین باید بتوانید یک راه حل آماده برای هر فرآیند ساخت که استفاده می کنید پیدا کنید.

یکی دیگر از ممیزی های مفید در آن فضا فعال کردن فشرده سازی متن است. دلیلی برای ارسال فایل های فشرده نشده وجود ندارد و این روزها اکثر CDN ها از این موضوع پشتیبانی می کنند.

ما از میزبانی Firebase برای میزبانی کد خود استفاده می‌کردیم، و Firebase به طور پیش‌فرض gzipping را فعال می‌کند، بنابراین به دلیل میزبانی کد خود در یک CDN معقول، آن را به صورت رایگان دریافت کردیم.

در حالی که gzip یک روش بسیار محبوب برای فشرده سازی است، مکانیسم های دیگری مانند Zopfli و Brotli نیز در حال جذب هستند. Brotli در اکثر مرورگرها از پشتیبانی برخوردار است و شما می توانید از یک باینری برای فشرده سازی دارایی های خود قبل از ارسال به سرور استفاده کنید.

از سیاست های کش کارآمد استفاده کنید

قدم بعدی ما این بود که اطمینان حاصل کنیم که در صورت غیرضروری، منابع را دو بار ارسال نمی کنیم.

ممیزی سیاست کش ناکارآمد در Lighthouse به ما کمک کرد تا متوجه شویم که می‌توانیم استراتژی‌های ذخیره‌سازی خود را برای دستیابی به آن دقیقاً بهینه کنیم. با تنظیم هدر انقضای حداکثر سن در سرور خود، مطمئن شدیم که در یک بازدید مکرر کاربر می تواند از منابعی که قبلا دانلود کرده است استفاده مجدد کند.

در حالت ایده‌آل، باید سعی کنید تا آنجایی که ممکن است منابع را به صورت ایمن برای طولانی‌ترین مدت زمان ممکن ذخیره کنید و نشانه‌های اعتبارسنجی را برای اعتبارسنجی مجدد کارآمد منابعی که به‌روزرسانی شده‌اند، تهیه کنید.

کدهای استفاده نشده را حذف کنید

تا اینجا قسمت‌های واضح دانلود غیرضروری را حذف کردیم، اما قسمت‌های کمتر واضح چطور؟ به عنوان مثال، کد استفاده نشده.

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

در ابتدا ما از کتابخانه Material Components برای نمونه سازی سریع برنامه خود استفاده می کردیم. با گذشت زمان به یک ظاهر و احساس سفارشی تر رفتیم و آن کتابخانه را به طور کامل فراموش کردیم. خوشبختانه، بررسی پوشش کد به ما کمک کرد تا آن را دوباره در بسته خود کشف کنیم.

شما می توانید آمار پوشش کد خود را در DevTools، هم برای زمان اجرا و هم برای زمان بارگذاری برنامه خود بررسی کنید. شما می‌توانید دو خط قرمز بزرگ را در تصویر پایین مشاهده کنید - ما بیش از 95 درصد از CSS خود را بدون استفاده داریم، و همچنین یک دسته بزرگ جاوا اسکریپت.

لایت هاوس همچنین این موضوع را در ممیزی قوانین CSS استفاده نشده پی برد. صرفه جویی بالقوه بیش از 400 کیلوبایت را نشان داد. بنابراین ما به کد خود بازگشتیم و هر دو بخش جاوا اسکریپت و CSS آن کتابخانه را حذف کردیم.

این باعث کاهش 20 برابری بسته CSS ما شد که برای یک تعهد کوچک و دو خطی بسیار خوب است.

البته باعث شد نمره عملکرد ما بالا برود و همچنین Time to Interactive خیلی بهتر شد.

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

کد ما در 95٪ استفاده نشده بود - هنوز این 5٪ در جایی وجود دارد. ظاهراً یکی از مؤلفه‌های ما هنوز از سبک‌های آن کتابخانه استفاده می‌کرد - فلش‌های کوچک در نوار لغزنده doodle. از آنجایی که بسیار کوچک بود، می‌توانستیم برویم و به‌طور دستی آن سبک‌ها را در دکمه‌ها قرار دهیم.

بنابراین اگر کد را حذف کردید، فقط مطمئن شوید که یک گردش کار آزمایشی مناسب برای کمک به شما در برابر رگرسیون های بصری بالقوه محافظت کنید.

از بارهای سنگین شبکه خودداری کنید

ما می دانیم که منابع بزرگ می توانند بارگذاری صفحات وب را کاهش دهند. آنها می توانند برای کاربران ما هزینه داشته باشند و می توانند تأثیر زیادی بر برنامه های داده آنها داشته باشند، بنابراین بسیار مهم است که به این موضوع توجه داشته باشید.

Lighthouse توانست تشخیص دهد که ما با برخی از بارهای شبکه خود با استفاده از حسابرسی حجم عظیم شبکه مشکل داریم.

در اینجا دیدیم که بیش از 3 مگابایت کد داشتیم که در حال ارسال بود - که بسیار زیاد است، به خصوص در تلفن همراه.

در بالای این لیست، Lighthouse تاکید کرد که ما یک بسته فروشنده جاوا اسکریپت داریم که 2 مگابایت کد فشرده نشده دارد. این نیز مشکلی است که توسط webpack برجسته شده است.

به قول معروف: سریعترین درخواست، درخواستی است که انجام نشود.

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

در مورد ما، چون با بسته‌های جاوا اسکریپت زیادی سروکار داریم، خوش شانس بودیم زیرا جامعه جاوا اسکریپت دارای مجموعه‌ای غنی از ابزارهای حسابرسی بسته جاوا اسکریپت است.

ما با تحلیلگر بسته وب بسته شروع کردیم، که به ما اطلاع داد که وابستگی به نام یونیکد را اضافه کرده ایم که 1.6 مگابایت جاوا اسکریپت تجزیه شده است، بنابراین بسیار زیاد است.

سپس به ویرایشگر خود رفتیم و با استفاده از افزونه Import Cost برای کدهای ویژوال توانستیم هزینه هر ماژولی را که وارد می‌کردیم تجسم کنیم. این به ما امکان داد تا کشف کنیم کدام مؤلفه شامل کدی است که به این ماژول ارجاع می دهد.

سپس به ابزار دیگری، BundlePhobia تغییر مکان دادیم. این ابزاری است که به شما امکان می دهد نام هر بسته NPM را وارد کنید و در واقع ببینید اندازه کوچک شده و gzip آن تخمین زده می شود. ما یک جایگزین خوب برای ماژول اسلاگ که استفاده می کردیم با وزن 2.2 کیلوبایت پیدا کردیم و بنابراین آن را تغییر دادیم.

این تاثیر زیادی روی عملکرد ما داشت. بین این تغییر و کشف فرصت‌های دیگر برای کاهش اندازه بسته جاوا اسکریپت، 2.1 مگابایت کد ذخیره کردیم.

با در نظر گرفتن اندازه gzip و کوچک‌شده این بسته‌ها، در کل شاهد 65 درصد پیشرفت‌ها بودیم. و ما متوجه شدیم که این واقعا ارزش انجام دادن به عنوان یک فرآیند را دارد.

بنابراین، به طور کلی سعی کنید دانلودهای غیر ضروری را در سایت ها و برنامه های خود حذف کنید. فهرستی از دارایی‌های خود تهیه کنید و تأثیر عملکرد آن‌ها را اندازه‌گیری کنید، می‌تواند واقعاً تفاوت بزرگی ایجاد کند، بنابراین مطمئن شوید که دارایی‌های خود را به طور منظم حسابرسی می‌کنید.

کاهش زمان بوت آپ جاوا اسکریپت با تقسیم کد

اگرچه بارهای بزرگ شبکه می تواند تأثیر زیادی بر برنامه ما داشته باشد، چیز دیگری وجود دارد که می تواند تأثیر بسیار زیادی داشته باشد و آن جاوا اسکریپت است.

جاوا اسکریپت گران ترین دارایی شماست. در تلفن همراه، اگر بسته‌های بزرگ جاوا اسکریپت را ارسال می‌کنید، می‌تواند سرعت تعامل کاربران با اجزای رابط کاربری شما را به تاخیر بیاندازد. این بدان معناست که آنها می توانند روی UI ضربه بزنند بدون اینکه واقعاً اتفاق معنی داری بیفتد. بنابراین برای ما مهم است که بفهمیم چرا جاوا اسکریپت اینقدر هزینه دارد.

به این ترتیب مرورگر جاوا اسکریپت را پردازش می کند.

ما اول از همه باید آن اسکریپت را دانلود کنیم، یک موتور جاوا اسکریپت داریم که باید آن کد را تجزیه کند، باید آن را کامپایل کرده و اجرا کند.

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

برای کمک به شما در کشف این مشکلات در برنامه خود، ما یک ممیزی جدید زمان راه اندازی جاوا اسکریپت را به Lighthouse معرفی کردیم.

و در مورد برنامه Oodle، به ما گفت که ما 1.8 ثانیه زمان را در راه‌اندازی جاوا اسکریپت صرف کرده‌ایم. اتفاقی که در حال رخ دادن بود این بود که ما در حال وارد کردن استاتیک در همه مسیرها و اجزای خود در یک بسته جاوا اسکریپت یکپارچه بودیم.

یکی از تکنیک‌های حل این مشکل، استفاده از تقسیم کد است.

تقسیم کد این مفهوم است که به جای اینکه به کاربران خود یک پیتزای کامل جاوا اسکریپت بدهید، چه می‌شود اگر هر بار فقط یک تکه به آن‌ها بدهید چه می‌شود؟

تقسیم کد را می توان در سطح مسیر یا سطح جزء اعمال کرد. با React و React Loadable، Vue.js، Angular، Polymer، Preact و چندین کتابخانه دیگر عالی کار می کند.

ما تقسیم کد را در برنامه خود گنجانده ایم، از واردات استاتیک به واردات پویا تغییر می دهیم و به ما امکان می دهد کد بارگذاری ناهمزمان را در صورت نیاز به آن بارگذاری کنیم.

تأثیری که این داشت هم کاهش اندازه بسته‌های ما بود، هم زمان راه‌اندازی جاوا اسکریپت را کاهش داد. آن را به 0.78 ثانیه کاهش داد و برنامه را 56٪ سریعتر کرد.

به طور کلی، اگر در حال ساختن تجربه‌ای با جاوا اسکریپت هستید، مطمئن شوید که فقط برای کاربر مورد نیاز کد ارسال می‌کنید.

از مفاهیمی مانند تقسیم کد، کاوش ایده هایی مانند تکان دادن درختان، و بررسی مخزن webpack-libs-optimizations برای چند ایده در مورد اینکه چگونه می توانید اندازه کتابخانه خود را در صورت استفاده از بسته وب کم کنید، استفاده کنید.

بهینه سازی تصاویر

در برنامه Oodle ما از تصاویر زیادی استفاده می کنیم. متأسفانه، Lighthouse نسبت به ما بسیار کمتر مشتاق آن بود. در واقع، ما در هر سه ممیزی مربوط به تصویر شکست خوردیم.

ما فراموش کردیم تصاویر خود را بهینه سازی کنیم، اندازه آنها را به درستی تعیین نکردیم، و همچنین می توانستیم از استفاده از فرمت های تصویری دیگر سود ببریم.

ما با بهینه سازی تصاویر خود شروع کردیم.

برای دور بهینه سازی یکباره می توانید از ابزارهای بصری مانند ImageOptim یا XNConvert استفاده کنید.

یک رویکرد خودکارتر این است که یک مرحله بهینه سازی تصویر را با کتابخانه هایی مانند imagemin به فرآیند ساخت خود اضافه کنید.

به این ترتیب مطمئن می شوید که تصاویر اضافه شده در آینده به طور خودکار بهینه می شوند. برخی از CDN ها، به عنوان مثال Akamai یا راه حل های شخص ثالث مانند Cloudinary ، Fastly یا Uploadcare راه حل های جامع بهینه سازی تصویر را به شما ارائه می دهند. بنابراین شما همچنین می توانید به سادگی تصاویر خود را در آن سرویس ها میزبانی کنید.

اگر به دلیل هزینه یا مشکلات تأخیر نمی‌خواهید این کار را انجام دهید، پروژه‌هایی مانند Thumbor یا Imageflow جایگزین‌های خود میزبانی می‌کنند.

PNG پس‌زمینه ما در وب‌پک به‌عنوان بزرگ علامت‌گذاری شد، و به درستی چنین بود. پس از اندازه گیری صحیح آن در ویوپورت و اجرای آن از طریق ImageOptim، به 100 کیلوبایت کاهش یافتیم که قابل قبول است.

تکرار این کار برای چندین تصویر در سایت ما به ما امکان داد تا وزن کلی صفحه را به میزان قابل توجهی کاهش دهیم.

از قالب مناسب برای محتوای متحرک استفاده کنید

گیف ها می توانند واقعا گران شوند. با کمال تعجب، فرمت GIF در وهله اول هرگز به عنوان یک پلت فرم انیمیشن در نظر گرفته نشد. بنابراین، جابجایی به فرمت ویدیویی مناسب تر، صرفه جویی زیادی را از نظر اندازه فایل به شما ارائه می دهد.

در برنامه Oodle، ما از یک GIF به عنوان دنباله مقدماتی در صفحه اصلی استفاده می کردیم. طبق گفته Lighthouse، ما می‌توانیم با تغییر فرمت ویدیویی کارآمدتر، بیش از 7 مگابایت صرفه‌جویی کنیم. کلیپ ما حدود 7.3 مگابایت وزن داشت که برای هر وب سایت معقولی بسیار زیاد است، بنابراین در عوض آن را به یک عنصر ویدیویی با دو فایل منبع تبدیل کردیم - mp4 و WebM برای پشتیبانی گسترده تر از مرورگر.

ما از ابزار FFmpeg برای تبدیل GIF انیمیشن خود به فایل mp4 استفاده کردیم. فرمت WebM حتی صرفه جویی بیشتری را به شما ارائه می دهد - ImageOptim API می تواند چنین تبدیلی را برای شما انجام دهد.

ffmpeg -i animation.gif -b:v 0 -crf 40 -vf scale=600:-1 video.mp4

ما به لطف این تبدیل توانستیم بیش از 80٪ از وزن کلی خود را ذخیره کنیم. این ما را به حدود 1 مگابایت کاهش داد.

با این حال، 1 مگابایت منبع بزرگی برای فشار دادن سیم است، به خصوص برای کاربری با پهنای باند محدود. خوشبختانه ما می‌توانیم از Effective Type API استفاده کنیم تا بفهمیم پهنای باند آن‌ها کم است و به جای آن یک JPEG بسیار کوچک‌تر به آنها بدهیم.

این رابط برای تخمین نوع شبکه ای که کاربر استفاده می کند، از زمان رفت و برگشت موثر و مقادیر پایین استفاده می کند. این به سادگی یک رشته، 2G، 2G، 3G یا 4G کند را برمی گرداند. بنابراین بسته به این مقدار، اگر کاربر زیر 4G باشد، می‌توانیم عنصر ویدیو را با تصویر جایگزین کنیم.

if (navigator.connection.effectiveType) { ... }

کمی از تجربه حذف می شود، اما حداقل سایت در یک اتصال آهسته قابل استفاده است.

تصاویر خارج از صفحه نمایش با بارگذاری تنبل

چرخ فلک ها، لغزنده ها یا صفحات واقعا طولانی اغلب تصاویر را بارگیری می کنند، حتی اگر کاربر نمی تواند بلافاصله آنها را در صفحه ببیند.

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

بارگذاری تنبل هنوز به صورت بومی در مرورگر پشتیبانی نمی شود، بنابراین برای افزودن این قابلیت باید از جاوا اسکریپت استفاده کنیم. ما از کتابخانه Lazysizes برای اضافه کردن رفتار بارگذاری تنبل به جلدهای Oodle خود استفاده کردیم.

<!-- Import library -->
import lazysizes from 'lazysizes'  <!-- or -->
<script src="lazysizes.min.js"></script>

<!-- Use it -->

<img data-src="image.jpg" class="lazyload"/>
<img class="lazyload"
    data-sizes="auto"
    data-src="image2.jpg"
    data-srcset="image1.jpg 300w,
    image2.jpg 600w,
    image3.jpg 900w"/>

Lazysizes هوشمند است زیرا نه تنها تغییرات دید عنصر را ردیابی می کند، بلکه به طور فعال عناصری را که در نزدیکی دید هستند برای تجربه کاربری بهینه واکشی می کند. همچنین یک ادغام اختیاری از IntersectionObserver را ارائه می دهد که جستجوهای دید بسیار کارآمدی را در اختیار شما قرار می دهد.

پس از این تغییر، تصاویر ما بر حسب تقاضا واکشی می شوند. اگر می‌خواهید در آن موضوع عمیق‌تر شوید، images.guide را بررسی کنید - یک منبع بسیار مفید و جامع.

به مرورگر کمک کنید تا منابع حیاتی را زودتر تحویل دهد

هر بایتی که از طریق سیم به مرورگر ارسال می شود درجه اهمیت یکسانی ندارد و مرورگر این را می داند. بسیاری از مرورگرها دارای اکتشافی هستند تا تصمیم بگیرند ابتدا چه چیزی را واکشی کنند. بنابراین گاهی اوقات آنها CSS را قبل از تصاویر یا اسکریپت ها واکشی می کنند.

چیزی که می تواند مفید باشد این است که ما به عنوان نویسندگان صفحه به مرورگر اطلاع می دهیم که واقعاً چه چیزی برای ما مهم است. خوشبختانه، طی چند سال گذشته، فروشندگان مرورگر تعدادی ویژگی را برای کمک به ما در این زمینه اضافه کرده اند، به عنوان مثال نکات منابعی مانند link rel=preconnect ، یا preload یا prefetch .

این قابلیت‌هایی که به پلتفرم وب آورده شده‌اند به مرورگر کمک می‌کنند تا چیز درست را در زمان مناسب واکشی کند، و می‌توانند کمی کارآمدتر از برخی از رویکردهای بارگیری سفارشی و مبتنی بر منطق که به جای آن با استفاده از اسکریپت انجام می‌شوند، باشند.

بیایید ببینیم که Lighthouse چگونه ما را به سمت استفاده مؤثر از برخی از این ویژگی ها راهنمایی می کند.

اولین چیزی که لایت هاوس به ما می گوید این است که از سفرهای رفت و برگشت پرهزینه به هر مبدأ خودداری کنیم.

در مورد برنامه Oodle، ما در واقع به شدت از فونت های گوگل استفاده می کنیم. هر زمان که یک شیوه نامه فونت گوگل را در صفحه خود می اندازید، تا دو زیر دامنه به آن متصل می شود. و چیزی که Lighthouse به ما می گوید این است که اگر بتوانیم آن اتصال را گرم کنیم، می توانیم در زمان اتصال اولیه خود تا 300 میلی ثانیه صرفه جویی کنیم.

با بهره گیری از پیش اتصال لینک rel، می توانیم به طور موثری این تأخیر اتصال را پنهان کنیم.

به خصوص با چیزی مانند فونت های گوگل که در آن CSS صورت قلم ما در googleapis.com میزبانی می شود، و منابع فونت ما در Gstatic میزبانی می شود، این می تواند تأثیر بسیار زیادی داشته باشد. بنابراین ما این بهینه‌سازی را اعمال کردیم و چند صد میلی‌ثانیه اصلاح کردیم.

نکته بعدی که Lighthouse پیشنهاد می کند این است که درخواست های کلیدی را از قبل بارگذاری کنیم.

<link rel=preload> واقعاً قدرتمند است، به مرورگر اطلاع می‌دهد که به یک منبع به عنوان بخشی از پیمایش فعلی نیاز است، و سعی می‌کند مرورگر را در اسرع وقت آن را واکشی کند.

اکنون اینجا Lighthouse به ما می گوید که باید برویم و منابع کلیدی فونت وب خود را از قبل بارگذاری کنیم، زیرا در حال بارگیری در دو فونت وب هستیم.

پیش بارگذاری در یک فونت وب به این شکل است - با تعیین rel=preload ، شما as نوع فونت را وارد می کنید، و سپس نوع قلمی را که می خواهید بارگذاری کنید، مانند woff2 را مشخص می کنید.

تاثیری که این می تواند روی صفحه شما داشته باشد بسیار شدید است.

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

با استفاده از پیش بارگذاری لینک، به محض اینکه مرورگر HTML شما را تجزیه کرد، در واقع می تواند خیلی زودتر شروع به واکشی آن فونت های وب کند. در مورد برنامه ما، این می‌توانست یک ثانیه زمان لازم برای رندر متن با استفاده از فونت‌های وب را کاهش دهد.

حالا اگر بخواهید فونت‌ها را از قبل با استفاده از فونت‌های گوگل بارگیری کنید، کار چندان ساده‌ای نیست، یک مشکل وجود دارد.

نشانی‌های اینترنتی فونت Google که ما روی فونت‌های خود در استایل شیت‌ها مشخص می‌کنیم، اتفاقاً چیزی است که تیم فونت‌ها به‌طور منظم به‌روزرسانی می‌کنند. این URL ها می توانند منقضی شوند یا در یک فرکانس منظم به روز شوند، بنابراین اگر می خواهید کنترل کاملی بر تجربه بارگیری فونت خود داشته باشید، کاری که ما پیشنهاد می کنیم انجام دهید این است که فونت های وب خود را خود میزبانی کنید. این می تواند عالی باشد زیرا به شما امکان دسترسی به مواردی مانند پیش بارگذاری لینک rel را می دهد.

در مورد ما ابزار Google Web Fonts Helper را برای کمک به ما در آفلاین کردن برخی از فونت‌های وب و راه‌اندازی آنها به صورت محلی بسیار مفید یافتیم، بنابراین این ابزار را بررسی کنید.

چه از فونت‌های وب به عنوان بخشی از منابع مهم خود استفاده می‌کنید یا از جاوا اسکریپت استفاده می‌کنید، سعی کنید به مرورگر کمک کنید تا منابع مهم شما را در اسرع وقت ارائه دهد.

تجربی: نکات اولویت

امروز چیز خاصی برای به اشتراک گذاشتن با شما داریم. علاوه بر ویژگی‌هایی مانند نکات منابع، و همچنین بارگذاری پیش‌بار، ما روی یک ویژگی آزمایشی جدید مرورگر کار کرده‌ایم که به آن نکات اولویتی می‌گوییم.

این یک ویژگی جدید است که به شما امکان می دهد به مرورگر اشاره کنید که یک منبع چقدر مهم است. این یک ویژگی جدید - اهمیت - را با مقادیر کم، زیاد یا خودکار نشان می دهد.

این به ما امکان می‌دهد اولویت منابع کمتر مهم را کاهش دهیم، مانند سبک‌های غیر انتقادی، تصاویر، یا واکشی فراخوان‌های API برای کاهش مشاجره. همچنین می‌توانیم اولویت چیزهای مهم‌تری مانند تصاویر قهرمان خود را افزایش دهیم.

در مورد برنامه Oodle ما، این در واقع به یک مکان عملی منجر شد که در آن می‌توانیم بهینه‌سازی کنیم.

قبل از اینکه ما بارگذاری تنبل را به تصاویر خود اضافه کنیم، کاری که مرورگر انجام می داد این بود که ما این چرخ فلک تصویر را با همه doodle های خود داشتیم و مرورگر در همان ابتدای کار چرخ و فلک همه تصاویر را با اولویت بالا در اوایل واکشی می کرد. متأسفانه این تصاویر وسط چرخ و فلک بود که برای کاربر اهمیت بیشتری داشت. بنابراین کاری که ما انجام دادیم این بود که اهمیت آن تصاویر پس‌زمینه را روی خیلی کم، تصاویر پیش‌زمینه را روی خیلی زیاد قرار دادیم، و این تاثیر دو ثانیه‌ای روی 3G کند بود، و اینکه چقدر سریع توانستیم آن تصاویر را واکشی و رندر کنیم. . بنابراین یک تجربه مثبت خوب.

امیدواریم چند هفته دیگر این ویژگی را به Canary بیاوریم، پس مراقب آن باشید.

استراتژی بارگذاری فونت وب داشته باشید

تایپوگرافی برای طراحی خوب ضروری است، و اگر از فونت های وب استفاده می کنید، در حالت ایده آل نمی خواهید رندر متن خود را مسدود کنید، و قطعاً نمی خواهید متن نامرئی را نشان دهید.

ما اکنون این را در Lighthouse با استفاده از متن نامرئی اجتناب کنید در حالی که فونت های وب در حال بارگیری ممیزی هستند، برجسته می کنیم.

اگر فونت های وب خود را با استفاده از یک بلوک صورت فونت بارگیری می کنید، به مرورگر اجازه می دهید تصمیم بگیرد که اگر زمان زیادی طول بکشد تا آن فونت وب واکشی شود، چه کاری انجام دهد. برخی از مرورگرها قبل از بازگشت به فونت سیستم، حداکثر تا سه ثانیه منتظر می‌مانند و در نهایت پس از دانلود آن را با فونت جایگزین می‌کنند.

ما سعی می کنیم از این متن نامرئی اجتناب کنیم، بنابراین در این مورد اگر فونت وب خیلی طولانی می شد، نمی توانستیم doodles کلاسیک این هفته را ببینیم. خوشبختانه، با یک ویژگی جدید به نام font-display ، در واقع کنترل بسیار بیشتری روی این فرآیند خواهید داشت.

    @font-face {
      font-family: 'Montserrat';
      font-style: normal;
      font-display: swap;
      font-weight: 400;
      src: local('Montserrat Regular'), local('Montserrat-Regular'),
          /* Chrome 26+, Opera 23+, Firefox 39+ */
          url('montserrat-v12-latin-regular.woff2') format('woff2'),
            /* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
          url('montserrat-v12-latin-regular.woff') format('woff');
    }

نمایش فونت به شما کمک می کند تا تصمیم بگیرید که چگونه فونت های وب بر اساس مدت زمانی که برای جابجایی آنها طول می کشد، رندر یا بازگشتی داشته باشند.

در این مورد ما از جابجایی نمایش فونت استفاده می کنیم. Swap به صورت فونت یک دوره بلوک دوم صفر و یک دوره تعویض بی نهایت می دهد. این بدان معناست که اگر بارگذاری فونت کمی طول بکشد، مرورگر بلافاصله متن شما را با یک فونت جایگزین ترسیم می کند. و زمانی که فونت فیس در دسترس باشد، آن را تعویض می کند.

در مورد برنامه ما، چرا این عالی بود این است که به ما اجازه می‌دهد متنی معنی‌دار را خیلی زود نمایش دهیم و پس از آماده شدن به فونت وب منتقل کنیم.

به طور کلی، اگر از فونت‌های وب استفاده می‌کنید، همانطور که درصد زیادی از وب استفاده می‌کنند، یک استراتژی بارگذاری فونت وب خوب داشته باشید.

بسیاری از ویژگی‌های پلتفرم وب وجود دارد که می‌توانید از آنها برای بهینه‌سازی تجربه بارگیری فونت‌ها استفاده کنید، اما همچنین مخزن دستور العمل‌های قلم وب Zach Leatherman را بررسی کنید، زیرا واقعا عالی است.

اسکریپت های مسدود کننده رندر را کاهش دهید

بخش‌های دیگری از برنامه ما وجود دارد که می‌توانیم آن‌ها را زودتر در زنجیره دانلود فشار دهیم تا حداقل برخی از تجربه‌های اولیه کاربر را کمی زودتر ارائه کنیم.

در نوار تایم لاین Lighthouse می توانید ببینید که در این چند ثانیه اول که همه منابع در حال بارگیری هستند، کاربر واقعا نمی تواند محتوایی را ببیند.

دانلود و پردازش شیوه نامه های خارجی روند رندر ما را از هر گونه پیشرفتی مسدود می کند.

ما می توانیم با ارائه برخی از سبک ها کمی زودتر سعی کنیم مسیر رندر بحرانی خود را بهینه کنیم.

اگر سبک‌هایی را که مسئول این رندر اولیه هستند استخراج کنیم و آنها را در HTML خود درون خطی کنیم، مرورگر می‌تواند آنها را فوراً بدون منتظر ماندن برای رسیدن شیت‌های خارجی رندر کند.

در مورد ما، ما از یک ماژول NPM به نام Critical استفاده کردیم تا محتوای مهم خود را در index.html در یک مرحله ساخت قرار دهیم.

در حالی که این ماژول بیشتر کارهای سنگین را برای ما انجام می داد، هنوز هم کمی مشکل بود که این ماژول به راحتی در مسیرهای مختلف کار کند.

اگر مراقب نباشید یا ساختار سایت شما واقعا پیچیده است، اگر از ابتدا برای معماری پوسته برنامه برنامه ریزی نکرده باشید، ممکن است معرفی این نوع الگو واقعاً دشوار باشد.

به همین دلیل بسیار مهم است که در ابتدا ملاحظات عملکرد را در نظر بگیرید. اگر از ابتدا برای عملکرد طراحی نکنید، احتمال زیادی وجود دارد که بعداً در انجام آن با مشکلاتی مواجه شوید.

در نهایت ریسک ما نتیجه داد، ما موفق شدیم آن را به کار بیاندازیم و برنامه خیلی زودتر شروع به ارائه محتوا کرد و اولین زمان رنگ آمیزی معنی دار ما را به طور قابل توجهی بهبود بخشید.

نتیجه

این لیست طولانی از بهینه سازی های عملکردی بود که ما در سایت خود اعمال کردیم. بیایید نگاهی به نتیجه بیاندازیم. به این صورت است که برنامه ما قبل و بعد از بهینه سازی روی یک دستگاه تلفن همراه متوسط ​​در شبکه 3G بارگیری می شود.

امتیاز عملکرد Lighthouse از 23 به 91 افزایش یافت. این پیشرفت بسیار خوبی از نظر سرعت است. همه تغییرات با بررسی و پیگیری مداوم گزارش فانوس دریایی ایجاد شد. اگر می‌خواهید بررسی کنید که چگونه ما از لحاظ فنی همه پیشرفت‌ها را پیاده‌سازی کرده‌ایم، به‌راحتی نگاهی به مخزن ما بیندازید، به‌ویژه به PRهایی که در آنجا فرود آمدند.

عملکرد پیش بینی - تجربیات کاربر مبتنی بر داده

ما معتقدیم که یادگیری ماشینی یک فرصت هیجان انگیز برای آینده در بسیاری از زمینه ها است. یکی از ایده‌هایی که امیدواریم در آینده جرقه آزمایش‌های بیشتری را برانگیزد، این است که داده‌های واقعی واقعاً می‌توانند تجربیات کاربر را که ایجاد می‌کنیم راهنمایی کند.

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

ما در واقع داده هایی در دسترس داریم تا امروز بهینه سازی های خود را بهتر اطلاع رسانی کنیم. با استفاده از API گزارش گوگل آنالیتیکس، می‌توانیم نگاهی به صفحه بالای بعدی و درصد خروج از هر URL در سایت خود بیندازیم و بنابراین نتیجه‌گیری در مورد منابعی که باید اولویت‌بندی کنیم را به دست آوریم.

اگر این را با یک مدل احتمال خوب ترکیب کنیم، از هدر دادن داده های کاربر خود با واکشی بیش از حد تهاجمی محتوا جلوگیری می کنیم. ما می‌توانیم از داده‌های Google Analytics استفاده کنیم و از یادگیری ماشین و مدل‌هایی مانند زنجیره مارکوف یا شبکه عصبی برای پیاده‌سازی چنین مدل‌هایی استفاده کنیم.

به منظور تسهیل این آزمایش‌ها، ما خوشحالیم که ابتکار جدیدی را به نام Guess.js اعلام می‌کنیم.

Guess.js یک پروژه متمرکز بر تجربیات کاربر مبتنی بر داده برای وب است. ما امیدواریم که الهام بخش کاوش استفاده از داده ها برای بهبود عملکرد وب و فراتر از آن باشد. این همه منبع باز است و امروز در GitHub در دسترس است. این با همکاری جامعه منبع باز توسط Minko Gechev، Kyle Matthews از Gatsby، Katie Hempenius، و تعدادی دیگر ساخته شده است.

Guess.js را بررسی کنید، نظر خود را با ما در میان بگذارید.

خلاصه

امتیازات و معیارها در بهبود سرعت وب مفید هستند، اما آنها فقط وسیله هستند، نه خود اهداف.

همه ما بارگذاری کند صفحه را در حین حرکت تجربه کرده‌ایم، اما اکنون فرصتی داریم تا تجربیات لذت‌بخش‌تری را به کاربران خود ارائه دهیم که بسیار سریع بارگیری می‌شوند.

بهبود عملکرد یک سفر است. بسیاری از تغییرات کوچک می تواند منجر به دستاوردهای بزرگ شود. با استفاده از ابزارهای بهینه سازی مناسب و زیر نظر گرفتن گزارش های Lighthouse، می توانید تجربه بهتر و فراگیرتری را برای کاربران خود فراهم کنید.

با تشکر ویژه از: Ward Peeters، Minko Gechev، Kyle Mathews، Katie Hempenius، Dom Farolino، Yoav Weiss، Susie Lu، Yusuke Utsunomiya، Tom Ankers، Lighthouse و Google Doodles.