مطالعه موردی تغییراتی که GoDaddy برای بهبود عملکرد وب‌سایت برای میلیون‌ها سایت پیاده‌سازی کرده است، به آنها کمک می‌کند تا به امتیازات خوب PageSpeed Insights و Core Web Vitals دست یابند.
GoDaddy بزرگترین پلت فرم خدمات در جهان برای کارآفرینان در سراسر جهان است. ما مأموریت داریم تا جامعه جهانی خود را با بیش از 20 میلیون مشتری - و کارآفرینان در همه جا - با ارائه تمام کمک‌ها و ابزارهایی که برای رشد آنلاین نیاز دارند، تقویت کنیم.
در سال 2019 GoDaddy Websites + Marketing را با تعهد به ارائه ابزارها و خدماتی راه اندازی کرد که استفاده از آنها آسان است و به صاحبان مشاغل کمک می کند تا به اهداف خود برسند. Websites + Marketing ساخت وب سایت را با ابزارهای بازاریابی و تجارت الکترونیک ادغام می کند و آنها را با بهترین راهنمایی های کلاس جفت می کند تا به مشتریان کمک کند با سرمایه گذاری های جدید خود به موفقیت برسند.
از زمان راه‌اندازی وب‌سایت‌ها + بازاریابی، عملکرد بخش مهمی از محصول و چیزی است که به طور فعال نظارت و روی آن کار شده است. در این مقاله، سفر GoDaddy را از استفاده از تست عملکرد آزمایشگاهی تا استفاده از داده‌های دنیای واقعی با Core Web Vitals و مجموعه‌ای از پیشرفت‌های انجام شده در محصول برای دریافت نرخ عبور بسیار بالا برای سایتهای مشتریان خود مرور می‌کنیم.
ردیابی عملکرد با Lighthouse
ما برای ردیابی عملکرد به داده های Lighthouse تکیه کرده ایم. هر بار که یک وب‌سایت بر روی پلتفرم منتشر می‌شود، عملکرد آن را با استفاده از ابزار داخلی خود به نام «Lighthouse4u» اندازه‌گیری می‌کنیم، که Google Lighthouse را به عنوان یک سرویس ارائه می‌کند https://github.com/godaddy/lighthouse4u . این به ما نشان خوبی از نحوه عملکرد سایت ها در یک محیط آزمایشگاهی داد.
از آنجایی که میلیون‌ها سایتی که ما روی پلتفرم خود میزبانی می‌کنیم دارای طیف گسترده‌ای از ویژگی‌ها و محتوا هستند، ترکیب داده‌های عملکرد با ابرداده‌های مربوط به هر سایت در حال آزمایش (مانند الگوی استفاده‌شده، نوع ابزارک‌های ارائه‌شده و غیره) مهم بود. این به ما اجازه داد تا در مورد اینکه چه ویژگی‌های وب‌سایتی عملکرد پایین‌تری دارند، نتیجه‌گیری کنیم، در حالی که بینشی برای یافتن بهبود در کجا فراهم می‌کند.
به عنوان مثال، این به ما کمک کرد تشخیص دهیم که "popup modal" تاثیر منفی بر سرعت صفحه دارد. سایت های دارای این ویژگی 12 امتیاز کمتر از سایت های بدون آن داشتند. پس از به‌روزرسانی کد برای به تعویق انداختن بارگذاری جاوا اسکریپت، امتیاز Lighthouse خود را 2 امتیاز بهبود دادیم. ما توانستیم این یادگیری را برای ویژگی‌های دیگری مانند "بنر کوکی" که بلافاصله پس از بارگیری صفحه ارائه می‌شود، اعمال کنیم.
همراه با بررسی سایتهای مشکل‌ساز بر اساس ویژگی‌ها، تجزیه و تحلیلی از بسته جاوا اسکریپت خود انجام دادیم و دیدیم که بخش بزرگی از اندازه آن از وابستگی‌های خارجی (immutable.js و draft.js) ناشی می‌شود. ما با تغییر ساختار مصرف کنندگان به وابستگی بار تنبل به تقاضا، اندازه بسته را کاهش دادیم. این امر منجر به کاهش بیش از 50 درصدی اندازه بسته نرم افزاری جاوا اسکریپت رایج شد که از بیش از 200 کیلوبایت به حدود 90 کیلوبایت (کوچک شده) رسید. اندازه کوچکتر بسته نرم افزاری به مرورگر اجازه می دهد تا دارایی های خارجی را بارگیری کند و اسکریپت های حیاتی را زودتر در چرخه عمر بارگذاری اولیه سایت اجرا کند، که منجر به افزایش در بزرگترین رنگ محتوایی (LCP) و تاخیر ورودی اولیه (FID) می شود.
به لطف تلاش‌های مستمر ما، میانگین امتیاز سایت مشتری Lighthouse از حدود 40 امتیاز در نوامبر 2020 به بالاتر از 70 امتیاز در ماه مه 2021 رسید. با این حال، همه تلاش‌های ما جواب نداد و زمانی که نتایج همیشه بین آنچه در محیط‌های آزمایشی محلی آزمایش شده بود و نتایجی که در میدان به دست می‌آوریم سازگار نبود، گاهی شگفت‌زده می‌شدیم. نتایج آزمایشگاهی واقعاً مفید بودند، اما زمان آن فرا رسیده بود که روی تجربیات واقعی کاربر مشاهده شده در این زمینه تمرکز کنیم.
ردیابی داده های واقعی کاربر با Core Web Vitals
پس از افزودن کتابخانه web-vitals به سایتهای مشتریانمان، توانستیم داده‌ها را روی دستگاه‌های واقعی از بازدیدکنندگان واقعی اندازه‌گیری کنیم، جایی که سخت‌افزار، سرعت شبکه، تعامل با کاربر (مانند پیمایش یا کلیک کردن) مانند تنظیمات آزمایشگاهی با استفاده از Lighthouse در یک خط پایه ثابت نیستند. این یک گام بزرگ در مسیر درست بود، زیرا اکنون داده‌هایی داشتیم که نمایانگر آنچه بازدیدکنندگان وب‌سایت ما تجربه می‌کردند بود.
تمرکز بر ضعیف ترین پیوند ما: تغییر چیدمان تجمعی (CLS)
تجزیه و تحلیل داده های جدید به ما دیدگاه جدیدی در مورد آنچه که باید برای بهبود سرعت وب سایت انجام می شد به ما داد. به دلیل کار انجام شده برای بهبود امتیاز Lighthouse، LCP صدک 75 ما 860 میلی‌ثانیه و FID ما در همان آستانه زیر 10 میلی‌ثانیه بود، بنابراین ما از نرخ قبولی بالایی برای این معیارها در سایتهای مشتریان خود بهره‌مند شدیم: به ترتیب 78 درصد و 98 درصد. با این حال، اعداد CLS (Cumulative Layout Shift) کاملاً متفاوت از آنچه در Lighthouse به آن عادت داشتیم به نظر می رسند. CLS ما در صدک 75 0.17 بود – بالاتر از آستانه 0.1 برای «گذراندن» – و بنابراین نرخ قبولی ما در تمام سایتهای ما فقط 47٪ بود.
این معیار میزان پاس کلی ما را به 40 درصد کاهش داد، بنابراین ما تصمیم گرفتیم یک هدف بلندپروازانه تعیین کنیم تا این عدد را تا پایان آگوست 2021 به بالای 60 درصد برسانیم. برای انجام این کار، باید روی CLS تمرکز کنیم .
در زندگی واقعی، کاربران با صفحه ارتباط برقرار می‌کنند و از محتوای «بالاتر» عبور می‌کنند، که Core Web Vitals بهتر می‌گیرد. به دلیل تنوع در نحوه تعامل کاربران با سایت در هنگام بارگیری اولیه، CLS با داده های آزمایشگاهی و میدانی متفاوت بود.
جاده ای برای عبور از تمام Core Web Vitals
بهبود عملکرد مستلزم آزمون و خطا است و هر تلاشی همیشه آنطور که انتظار می رود کار نمی کند. با این حال، در اینجا چند پیشرفت وجود دارد که به ما در رسیدن به اهدافمان کمک کرد.
رزرو فضا برای بارگذاری تصاویر امتیاز CLS ما را به شدت بهبود بخشید زیرا از تغییر محتوای زیر تصاویر جلوگیری می کند. ما از ویژگی aspect-ratio CSS برای رفع این مشکل در مرورگرهایی که از آن پشتیبانی می‌کنند استفاده کردیم. برای کسانی که این کار را نمی کنند، ما یک تصویر مکان نگهدار شفاف را بارگذاری کردیم که در حافظه پنهان و اندازه آن فقط چند بایت بود، بنابراین تقریباً بلافاصله بارگیری می شود.
این رفتار کلی تصویر به ما این امکان را می‌دهد که ارتفاع تصویر نهایی را در حین رندر سمت سرور، بر اساس عرض و نسبت تصویر تصویر، از قبل محاسبه کنیم. این منجر به نشانه گذاری HTML با فضای عمودی مناسب برای تصویر نهایی شد. این بهبود به‌ویژه در دستگاه‌های تلفن همراه قابل مشاهده بود، زیرا تصاویر در گستره کامل درگاه‌های نمایش تلفن همراه ارائه می‌شوند.
برخی از مؤلفه‌ها در سایتهای مشتریان ما دارای محتوای پویا هستند (مثلاً فهرستی از نظرات مشتریان خارجی) و نمی‌توان آنها را به CSS خالص تبدیل کرد تا از مزایای عملکرد رندر سمت سرور استفاده کند. اینها مناطق دشواری برای بهبود تغییرات چیدمان هستند زیرا محتوا (در نتیجه ارتفاع) متفاوت خواهد بود. در آن موارد، ما جزء را در ظرفی پیچیده کردیم که min-height بر اساس مشاهده میانگین ارتفاع برای هر یک از اجزای خاص از پیش تعیین شده بود. زمانی که مولفه دینامیک داخلی رندر انجام شد min-height حذف می‌شود. اگرچه این راه حل کامل نیست، اما به ما امکان داد تا تغییر طرح را تا حد زیادی کاهش دهیم.
در حالی که روی بهبودهای CLS تمرکز داشتیم، به کار بر روی LCP ادامه دادیم. در بسیاری از وب‌سایت‌ها، تصاویر بزرگترین عاملی هستند که به LCP کمک می‌کنند و برای ما این یک زمینه واضح برای بهبود بود. ما با استفاده از IntersectionObserver برای بارگذاری تنبل تصاویر بهبودهایی ایجاد کرده بودیم، اما متوجه شدیم که اندازه‌های تصویر به بهترین شکل برای هر نقطه شکست (موبایل، تبلت، دسکتاپ، دسکتاپ بزرگ) تنظیم نشده است، بنابراین کد تولید تصویر خود را به‌روزرسانی کردیم تا تصاویر را در هر نقطه شکست گیره و مقیاس کنیم و سپس مجدداً وضوح را بر اساس تراکم پیکسل مقیاس کنیم. به عنوان مثال، این کار اندازه یک تصویر بزرگ خاص را از 192 کیلوبایت به 102 کیلوبایت کاهش داد.
برای رندر سریع وب‌سایت‌ها در دستگاه‌هایی با اتصالات شبکه ضعیف، کدی را اضافه کردیم تا به صورت پویا کیفیت تصویر را بر اساس سرعت اتصال کاهش دهیم. این را می توان با استفاده از ویژگی downlink که توسط navigator.connection برگردانده شده است انجام داد. ما پارامترهای پرس و جو مبتنی بر URL را برای کاهش کیفیت تصویر از طریق API دارایی خود بر اساس آن شرایط شبکه اعمال می کنیم.
تعدادی از بخش های سایت های مشتریان ما به صورت پویا بارگیری می شوند. از آنجایی که می‌دانیم چه بخش‌هایی در یک سایت مشخص در زمان انتشار آن ارائه می‌شوند، از راهنمایی منبع rel=preconnect برای مقداردهی اولیه اتصال و دست دادن‌های ضروری قبل از زمان استفاده کردیم. ما همچنین از نکات منابع برای بارگیری سریع فونت ها و سایر منابع مهم استفاده می کنیم.
هنگام ساخت سایت های خود، مشتریان بخش های مختلفی را اضافه می کنند که ممکن است دارای اسکریپت های درون خطی باشند تا قابلیت های مختلف را امکان پذیر کنند. وجود این اسکریپت‌ها در صفحه HTML همیشه برای عملکرد بهینه نیست. ما تصمیم گرفتیم این اسکریپت ها را خارجی کنیم تا به مرورگر اجازه دهیم محتوای اسکریپت را به صورت ناهمزمان بارگیری و تجزیه کند. اسکریپت های جدید خارجی نیز می توانند در بین صفحات به اشتراک گذاشته شوند. این باعث افزایش عملکرد بیشتر در قالب حافظه پنهان مرورگر و CDN شد. ما اسکریپت های مهم را در خط نگه می داریم تا مرورگر آنها را سریعتر تجزیه و اجرا کند.
نتایج
با تمرکز تلاش ما بر روی CLS نتیجه داد، نرخ عبور Core Web Vitals ما از حدود 40٪ به تقریبا 70٪ رسید: بهبود 75٪!
همانطور که کاربران برای به‌روزرسانی و انتشار مجدد سایتهای خود به پلتفرم ما باز می‌گردند، آخرین پیشرفت‌های عملکردی را دریافت می‌کنند و در نتیجه تعداد سایت‌هایی با "گذر از Core Web Vitals" به طور پیوسته در حال افزایش است، همانطور که در نمودار زیر نشان داده شده است:
نتیجه گیری
یافتن زمینه هایی برای بهبود عملکرد و ردیابی موفقیت آمیز پیشرفت به شدت به ابزارهایی که برای اندازه گیری استفاده می شود بستگی دارد. در حالی که Lighthouse برای اندازه‌گیری عملکرد بالاتر در یک "تنظیمات آزمایشگاهی" مفید بود، مشکلات عملکردی را که فقط از تعاملات کاربر (مانند پیمایش در صفحه) رخ می‌داد به‌دقت ثبت نکرد.
ردیابی Core Web Vitals دنیای واقعی با ابرداده به ما این امکان را می‌دهد تا تأثیر پیشرفت‌های خود را تجسم، هدف‌گیری و اندازه‌گیری کنیم. سفر برای بهبود نمرات Core Web Vitals به تیم این امکان را داد تا الگوهای غیرعملکردی موجود در سرتاسر پایگاه کد ما را شناسایی و جایگزین کنند. گاهی اوقات تغییرات امیدوارکننده تقریباً تأثیری را که ما انتظار داشتیم نداشتند، برخی اوقات برعکس این اتفاق می افتاد. دنیایی بکر نیست، پس باید به تلاش ادامه دهید.
،مطالعه موردی تغییراتی که GoDaddy برای بهبود عملکرد وب‌سایت برای میلیون‌ها سایت پیاده‌سازی کرده است، به آنها کمک می‌کند تا به امتیازات خوب PageSpeed Insights و Core Web Vitals دست یابند.
GoDaddy بزرگترین پلت فرم خدمات در جهان برای کارآفرینان در سراسر جهان است. ما مأموریت داریم تا جامعه جهانی خود را با بیش از 20 میلیون مشتری - و کارآفرینان در همه جا - با ارائه تمام کمک‌ها و ابزارهایی که برای رشد آنلاین نیاز دارند، تقویت کنیم.
در سال 2019 GoDaddy Websites + Marketing را با تعهد به ارائه ابزارها و خدماتی راه اندازی کرد که استفاده از آنها آسان است و به صاحبان مشاغل کمک می کند تا به اهداف خود برسند. Websites + Marketing ساخت وب سایت را با ابزارهای بازاریابی و تجارت الکترونیک ادغام می کند و آنها را با بهترین راهنمایی های کلاس جفت می کند تا به مشتریان کمک کند با سرمایه گذاری های جدید خود به موفقیت برسند.
از زمان راه‌اندازی وب‌سایت‌ها + بازاریابی، عملکرد بخش مهمی از محصول و چیزی است که به طور فعال نظارت و روی آن کار شده است. در این مقاله، سفر GoDaddy را از استفاده از تست عملکرد آزمایشگاهی تا استفاده از داده‌های دنیای واقعی با Core Web Vitals و مجموعه‌ای از پیشرفت‌های انجام شده در محصول برای دریافت نرخ عبور بسیار بالا برای سایتهای مشتریان خود مرور می‌کنیم.
ردیابی عملکرد با Lighthouse
ما برای ردیابی عملکرد به داده های Lighthouse تکیه کرده ایم. هر بار که یک وب‌سایت بر روی پلتفرم منتشر می‌شود، عملکرد آن را با استفاده از ابزار داخلی خود به نام «Lighthouse4u» اندازه‌گیری می‌کنیم، که Google Lighthouse را به عنوان یک سرویس ارائه می‌کند https://github.com/godaddy/lighthouse4u . این به ما نشان خوبی از نحوه عملکرد سایت ها در یک محیط آزمایشگاهی داد.
از آنجایی که میلیون‌ها سایتی که ما روی پلتفرم خود میزبانی می‌کنیم دارای طیف گسترده‌ای از ویژگی‌ها و محتوا هستند، ترکیب داده‌های عملکرد با ابرداده‌های مربوط به هر سایت در حال آزمایش (مانند الگوی استفاده‌شده، نوع ابزارک‌های ارائه‌شده و غیره) مهم بود. این به ما اجازه داد تا در مورد اینکه چه ویژگی‌های وب‌سایتی عملکرد پایین‌تری دارند، نتیجه‌گیری کنیم، در حالی که بینشی برای یافتن بهبود در کجا فراهم می‌کند.
به عنوان مثال، این به ما کمک کرد تشخیص دهیم که "popup modal" تاثیر منفی بر سرعت صفحه دارد. سایت های دارای این ویژگی 12 امتیاز کمتر از سایت های بدون آن داشتند. پس از به‌روزرسانی کد برای به تعویق انداختن بارگذاری جاوا اسکریپت، امتیاز Lighthouse خود را 2 امتیاز بهبود دادیم. ما توانستیم این یادگیری را برای ویژگی‌های دیگری مانند "بنر کوکی" که بلافاصله پس از بارگیری صفحه ارائه می‌شود، اعمال کنیم.
همراه با بررسی سایتهای مشکل‌ساز بر اساس ویژگی‌ها، تجزیه و تحلیلی از بسته جاوا اسکریپت خود انجام دادیم و دیدیم که بخش بزرگی از اندازه آن از وابستگی‌های خارجی (immutable.js و draft.js) ناشی می‌شود. ما با تغییر ساختار مصرف کنندگان به وابستگی بار تنبل به تقاضا، اندازه بسته را کاهش دادیم. این امر منجر به کاهش بیش از 50 درصدی اندازه بسته نرم افزاری جاوا اسکریپت رایج شد که از بیش از 200 کیلوبایت به حدود 90 کیلوبایت (کوچک شده) رسید. اندازه کوچکتر بسته نرم افزاری به مرورگر اجازه می دهد تا دارایی های خارجی را بارگیری کند و اسکریپت های حیاتی را زودتر در چرخه عمر بارگذاری اولیه سایت اجرا کند، که منجر به افزایش در بزرگترین رنگ محتوایی (LCP) و تاخیر ورودی اولیه (FID) می شود.
به لطف تلاش‌های مستمر ما، میانگین امتیاز سایت مشتری Lighthouse از حدود 40 امتیاز در نوامبر 2020 به بالاتر از 70 امتیاز در ماه مه 2021 رسید. با این حال، همه تلاش‌های ما جواب نداد و زمانی که نتایج همیشه بین آنچه در محیط‌های آزمایشی محلی آزمایش شده بود و نتایجی که در میدان به دست می‌آوریم سازگار نبود، گاهی شگفت‌زده می‌شدیم. نتایج آزمایشگاهی واقعاً مفید بودند، اما زمان آن فرا رسیده بود که روی تجربیات واقعی کاربر مشاهده شده در این زمینه تمرکز کنیم.
ردیابی داده های واقعی کاربر با Core Web Vitals
پس از افزودن کتابخانه web-vitals به سایتهای مشتریانمان، توانستیم داده‌ها را روی دستگاه‌های واقعی از بازدیدکنندگان واقعی اندازه‌گیری کنیم، جایی که سخت‌افزار، سرعت شبکه، تعامل با کاربر (مانند پیمایش یا کلیک کردن) مانند تنظیمات آزمایشگاهی با استفاده از Lighthouse در یک خط پایه ثابت نیستند. این یک گام بزرگ در مسیر درست بود، زیرا اکنون داده‌هایی داشتیم که نمایانگر آنچه بازدیدکنندگان وب‌سایت ما تجربه می‌کردند بود.
تمرکز بر ضعیف ترین پیوند ما: تغییر چیدمان تجمعی (CLS)
تجزیه و تحلیل داده های جدید به ما دیدگاه جدیدی در مورد آنچه که باید برای بهبود سرعت وب سایت انجام می شد به ما داد. به دلیل کار انجام شده برای بهبود امتیاز Lighthouse، LCP صدک 75 ما 860 میلی‌ثانیه و FID ما در همان آستانه زیر 10 میلی‌ثانیه بود، بنابراین ما از نرخ قبولی بالایی برای این معیارها در سایتهای مشتریان خود بهره‌مند شدیم: به ترتیب 78 درصد و 98 درصد. با این حال، اعداد CLS (Cumulative Layout Shift) کاملاً متفاوت از آنچه در Lighthouse به آن عادت داشتیم به نظر می رسند. CLS ما در صدک 75 0.17 بود – بالاتر از آستانه 0.1 برای «گذراندن» – و بنابراین نرخ قبولی ما در تمام سایتهای ما فقط 47٪ بود.
این معیار میزان پاس کلی ما را به 40 درصد کاهش داد، بنابراین ما تصمیم گرفتیم یک هدف بلندپروازانه تعیین کنیم تا این عدد را تا پایان آگوست 2021 به بالای 60 درصد برسانیم. برای انجام این کار، باید روی CLS تمرکز کنیم .
در زندگی واقعی، کاربران با صفحه ارتباط برقرار می‌کنند و از محتوای «بالاتر» عبور می‌کنند، که Core Web Vitals بهتر می‌گیرد. به دلیل تنوع در نحوه تعامل کاربران با سایت در هنگام بارگیری اولیه، CLS با داده های آزمایشگاهی و میدانی متفاوت بود.
جاده ای برای عبور از تمام Core Web Vitals
بهبود عملکرد مستلزم آزمون و خطا است و هر تلاشی همیشه آنطور که انتظار می رود کار نمی کند. با این حال، در اینجا چند پیشرفت وجود دارد که به ما در رسیدن به اهدافمان کمک کرد.
رزرو فضا برای بارگذاری تصاویر امتیاز CLS ما را به شدت بهبود بخشید زیرا از تغییر محتوای زیر تصاویر جلوگیری می کند. ما از ویژگی aspect-ratio CSS برای رفع این مشکل در مرورگرهایی که از آن پشتیبانی می‌کنند استفاده کردیم. برای کسانی که این کار را نمی کنند، ما یک تصویر مکان نگهدار شفاف را بارگذاری کردیم که در حافظه پنهان و اندازه آن فقط چند بایت بود، بنابراین تقریباً بلافاصله بارگیری می شود.
این رفتار کلی تصویر به ما این امکان را می‌دهد که ارتفاع تصویر نهایی را در حین رندر سمت سرور، بر اساس عرض و نسبت تصویر تصویر، از قبل محاسبه کنیم. این منجر به نشانه گذاری HTML با فضای عمودی مناسب برای تصویر نهایی شد. این بهبود به‌ویژه در دستگاه‌های تلفن همراه قابل مشاهده بود، زیرا تصاویر در گستره کامل درگاه‌های نمایش تلفن همراه ارائه می‌شوند.
برخی از مؤلفه‌ها در سایتهای مشتریان ما دارای محتوای پویا هستند (مثلاً فهرستی از نظرات مشتریان خارجی) و نمی‌توان آنها را به CSS خالص تبدیل کرد تا از مزایای عملکرد رندر سمت سرور استفاده کند. اینها مناطق دشواری برای بهبود تغییرات چیدمان هستند زیرا محتوا (در نتیجه ارتفاع) متفاوت خواهد بود. در آن موارد، ما جزء را در ظرفی پیچیده کردیم که min-height بر اساس مشاهده میانگین ارتفاع برای هر یک از اجزای خاص از پیش تعیین شده بود. زمانی که مولفه دینامیک داخلی رندر انجام شد min-height حذف می‌شود. اگرچه این راه حل کامل نیست، اما به ما امکان داد تا تغییر طرح را تا حد زیادی کاهش دهیم.
در حالی که روی بهبودهای CLS تمرکز داشتیم، به کار بر روی LCP ادامه دادیم. در بسیاری از وب‌سایت‌ها، تصاویر بزرگترین عاملی هستند که به LCP کمک می‌کنند و برای ما این یک زمینه واضح برای بهبود بود. ما با استفاده از IntersectionObserver برای بارگذاری تنبل تصاویر بهبودهایی ایجاد کرده بودیم، اما متوجه شدیم که اندازه‌های تصویر به بهترین شکل برای هر نقطه شکست (موبایل، تبلت، دسکتاپ، دسکتاپ بزرگ) تنظیم نشده است، بنابراین کد تولید تصویر خود را به‌روزرسانی کردیم تا تصاویر را در هر نقطه شکست گیره و مقیاس کنیم و سپس مجدداً وضوح را بر اساس تراکم پیکسل مقیاس کنیم. به عنوان مثال، این کار اندازه یک تصویر بزرگ خاص را از 192 کیلوبایت به 102 کیلوبایت کاهش داد.
برای رندر سریع وب‌سایت‌ها در دستگاه‌هایی با اتصالات شبکه ضعیف، کدی را اضافه کردیم تا به صورت پویا کیفیت تصویر را بر اساس سرعت اتصال کاهش دهیم. این را می توان با استفاده از ویژگی downlink که توسط navigator.connection برگردانده شده است انجام داد. ما پارامترهای پرس و جو مبتنی بر URL را برای کاهش کیفیت تصویر از طریق API دارایی خود بر اساس آن شرایط شبکه اعمال می کنیم.
تعدادی از بخش های سایت های مشتریان ما به صورت پویا بارگیری می شوند. از آنجایی که می‌دانیم چه بخش‌هایی در یک سایت مشخص در زمان انتشار آن ارائه می‌شوند، از راهنمایی منبع rel=preconnect برای مقداردهی اولیه اتصال و دست دادن‌های ضروری قبل از زمان استفاده کردیم. ما همچنین از نکات منابع برای بارگیری سریع فونت ها و سایر منابع مهم استفاده می کنیم.
هنگام ساخت سایت های خود، مشتریان بخش های مختلفی را اضافه می کنند که ممکن است دارای اسکریپت های درون خطی باشند تا قابلیت های مختلف را امکان پذیر کنند. وجود این اسکریپت‌ها در صفحه HTML همیشه برای عملکرد بهینه نیست. ما تصمیم گرفتیم این اسکریپت ها را خارجی کنیم تا به مرورگر اجازه دهیم محتوای اسکریپت را به صورت ناهمزمان بارگیری و تجزیه کند. اسکریپت های جدید خارجی نیز می توانند در بین صفحات به اشتراک گذاشته شوند. این باعث افزایش عملکرد بیشتر در قالب حافظه پنهان مرورگر و CDN شد. ما اسکریپت های مهم را در خط نگه می داریم تا مرورگر آنها را سریعتر تجزیه و اجرا کند.
نتایج
با تمرکز تلاش ما بر روی CLS نتیجه داد، نرخ عبور Core Web Vitals ما از حدود 40٪ به تقریبا 70٪ رسید: بهبود 75٪!
همانطور که کاربران برای به‌روزرسانی و انتشار مجدد سایتهای خود به پلتفرم ما باز می‌گردند، آخرین پیشرفت‌های عملکردی را دریافت می‌کنند و در نتیجه تعداد سایت‌هایی با "گذر از Core Web Vitals" به طور پیوسته در حال افزایش است، همانطور که در نمودار زیر نشان داده شده است:
نتیجه گیری
یافتن زمینه هایی برای بهبود عملکرد و ردیابی موفقیت آمیز پیشرفت به شدت به ابزارهایی که برای اندازه گیری استفاده می شود بستگی دارد. در حالی که Lighthouse برای اندازه‌گیری عملکرد بالاتر در یک "تنظیمات آزمایشگاهی" مفید بود، مشکلات عملکردی را که فقط از تعاملات کاربر (مانند پیمایش در صفحه) رخ می‌داد به‌دقت ثبت نکرد.
ردیابی Core Web Vitals دنیای واقعی با ابرداده به ما این امکان را می‌دهد تا تأثیر پیشرفت‌های خود را تجسم، هدف‌گیری و اندازه‌گیری کنیم. سفر برای بهبود نمرات Core Web Vitals به تیم این امکان را داد تا الگوهای غیرعملکردی موجود در سرتاسر پایگاه کد ما را شناسایی و جایگزین کنند. گاهی اوقات تغییرات امیدوارکننده تقریباً تأثیری را که ما انتظار داشتیم نداشتند، برخی اوقات برعکس این اتفاق می افتاد. دنیایی بکر نیست، پس باید به تلاش ادامه دهید.
،مطالعه موردی تغییراتی که GoDaddy برای بهبود عملکرد وب‌سایت برای میلیون‌ها سایت پیاده‌سازی کرده است، به آنها کمک می‌کند تا به امتیازات خوب PageSpeed Insights و Core Web Vitals دست یابند.
GoDaddy بزرگترین پلت فرم خدمات در جهان برای کارآفرینان در سراسر جهان است. ما مأموریت داریم تا جامعه جهانی خود را با بیش از 20 میلیون مشتری - و کارآفرینان در همه جا - با ارائه تمام کمک‌ها و ابزارهایی که برای رشد آنلاین نیاز دارند، تقویت کنیم.
در سال 2019 GoDaddy Websites + Marketing را با تعهد به ارائه ابزارها و خدماتی راه اندازی کرد که استفاده از آنها آسان است و به صاحبان مشاغل کمک می کند تا به اهداف خود برسند. Websites + Marketing ساخت وب سایت را با ابزارهای بازاریابی و تجارت الکترونیک ادغام می کند و آنها را با بهترین راهنمایی های کلاس جفت می کند تا به مشتریان کمک کند با سرمایه گذاری های جدید خود به موفقیت برسند.
از زمان راه‌اندازی وب‌سایت‌ها + بازاریابی، عملکرد بخش مهمی از محصول و چیزی است که به طور فعال نظارت و روی آن کار شده است. در این مقاله، سفر GoDaddy را از استفاده از تست عملکرد آزمایشگاهی تا استفاده از داده‌های دنیای واقعی با Core Web Vitals و مجموعه‌ای از پیشرفت‌های انجام شده در محصول برای دریافت نرخ عبور بسیار بالا برای سایتهای مشتریان خود مرور می‌کنیم.
ردیابی عملکرد با Lighthouse
ما برای ردیابی عملکرد به داده های Lighthouse تکیه کرده ایم. هر بار که یک وب‌سایت بر روی پلتفرم منتشر می‌شود، عملکرد آن را با استفاده از ابزار داخلی خود به نام «Lighthouse4u» اندازه‌گیری می‌کنیم، که Google Lighthouse را به عنوان یک سرویس ارائه می‌کند https://github.com/godaddy/lighthouse4u . این به ما نشان خوبی از نحوه عملکرد سایت ها در یک محیط آزمایشگاهی داد.
از آنجایی که میلیون‌ها سایتی که ما روی پلتفرم خود میزبانی می‌کنیم دارای طیف گسترده‌ای از ویژگی‌ها و محتوا هستند، ترکیب داده‌های عملکرد با ابرداده‌های مربوط به هر سایت در حال آزمایش (مانند الگوی استفاده‌شده، نوع ابزارک‌های ارائه‌شده و غیره) مهم بود. این به ما اجازه داد تا در مورد اینکه چه ویژگی‌های وب‌سایتی عملکرد پایین‌تری دارند، نتیجه‌گیری کنیم، در حالی که بینشی برای یافتن بهبود در کجا فراهم می‌کند.
به عنوان مثال، این به ما کمک کرد تشخیص دهیم که "popup modal" تاثیر منفی بر سرعت صفحه دارد. سایت های دارای این ویژگی 12 امتیاز کمتر از سایت های بدون آن داشتند. پس از به‌روزرسانی کد برای به تعویق انداختن بارگذاری جاوا اسکریپت، امتیاز Lighthouse خود را 2 امتیاز بهبود دادیم. ما توانستیم این یادگیری را برای ویژگی‌های دیگری مانند "بنر کوکی" که بلافاصله پس از بارگیری صفحه ارائه می‌شود، اعمال کنیم.
همراه با بررسی سایتهای مشکل‌ساز بر اساس ویژگی‌ها، تجزیه و تحلیلی از بسته جاوا اسکریپت خود انجام دادیم و دیدیم که بخش بزرگی از اندازه آن از وابستگی‌های خارجی (immutable.js و draft.js) ناشی می‌شود. ما با تغییر ساختار مصرف کنندگان به وابستگی بار تنبل به تقاضا، اندازه بسته را کاهش دادیم. این امر منجر به کاهش بیش از 50 درصدی اندازه بسته نرم افزاری جاوا اسکریپت رایج شد که از بیش از 200 کیلوبایت به حدود 90 کیلوبایت (کوچک شده) رسید. اندازه کوچکتر بسته نرم افزاری به مرورگر اجازه می دهد تا دارایی های خارجی را بارگیری کند و اسکریپت های حیاتی را زودتر در چرخه عمر بارگذاری اولیه سایت اجرا کند، که منجر به افزایش در بزرگترین رنگ محتوایی (LCP) و تاخیر ورودی اولیه (FID) می شود.
به لطف تلاش‌های مستمر ما، میانگین امتیاز سایت مشتری Lighthouse از حدود 40 امتیاز در نوامبر 2020 به بالاتر از 70 امتیاز در ماه مه 2021 رسید. با این حال، همه تلاش‌های ما جواب نداد و زمانی که نتایج همیشه بین آنچه در محیط‌های آزمایشی محلی آزمایش شده بود و نتایجی که در میدان به دست می‌آوریم سازگار نبود، گاهی شگفت‌زده می‌شدیم. نتایج آزمایشگاهی واقعاً مفید بودند، اما زمان آن فرا رسیده بود که روی تجربیات واقعی کاربر مشاهده شده در این زمینه تمرکز کنیم.
ردیابی داده های واقعی کاربر با Core Web Vitals
پس از افزودن کتابخانه web-vitals به سایتهای مشتریانمان، توانستیم داده‌ها را روی دستگاه‌های واقعی از بازدیدکنندگان واقعی اندازه‌گیری کنیم، جایی که سخت‌افزار، سرعت شبکه، تعامل با کاربر (مانند پیمایش یا کلیک کردن) مانند تنظیمات آزمایشگاهی با استفاده از Lighthouse در یک خط پایه ثابت نیستند. این یک گام بزرگ در مسیر درست بود، زیرا اکنون داده‌هایی داشتیم که نمایانگر آنچه بازدیدکنندگان وب‌سایت ما تجربه می‌کردند بود.
تمرکز بر ضعیف ترین پیوند ما: تغییر چیدمان تجمعی (CLS)
تجزیه و تحلیل داده های جدید به ما دیدگاه جدیدی در مورد آنچه که باید برای بهبود سرعت وب سایت انجام می شد به ما داد. به دلیل کار انجام شده برای بهبود امتیاز Lighthouse، LCP صدک 75 ما 860 میلی‌ثانیه و FID ما در همان آستانه زیر 10 میلی‌ثانیه بود، بنابراین ما از نرخ قبولی بالایی برای این معیارها در سایتهای مشتریان خود بهره‌مند شدیم: به ترتیب 78 درصد و 98 درصد. با این حال، اعداد CLS (Cumulative Layout Shift) کاملاً متفاوت از آنچه در Lighthouse به آن عادت داشتیم به نظر می رسند. CLS ما در صدک 75 0.17 بود – بالاتر از آستانه 0.1 برای «گذراندن» – و بنابراین نرخ قبولی ما در تمام سایتهای ما فقط 47٪ بود.
این معیار میزان پاس کلی ما را به 40 درصد کاهش داد، بنابراین ما تصمیم گرفتیم یک هدف بلندپروازانه تعیین کنیم تا این عدد را تا پایان آگوست 2021 به بالای 60 درصد برسانیم. برای انجام این کار، باید روی CLS تمرکز کنیم .
در زندگی واقعی، کاربران با صفحه ارتباط برقرار می‌کنند و از محتوای «بالاتر» عبور می‌کنند، که Core Web Vitals بهتر می‌گیرد. به دلیل تنوع در نحوه تعامل کاربران با سایت در هنگام بارگیری اولیه، CLS با داده های آزمایشگاهی و میدانی متفاوت بود.
جاده ای برای عبور از تمام Core Web Vitals
بهبود عملکرد مستلزم آزمون و خطا است و هر تلاشی همیشه آنطور که انتظار می رود کار نمی کند. با این حال، در اینجا چند پیشرفت وجود دارد که به ما در رسیدن به اهدافمان کمک کرد.
رزرو فضا برای بارگذاری تصاویر امتیاز CLS ما را به شدت بهبود بخشید زیرا از تغییر محتوای زیر تصاویر جلوگیری می کند. ما از ویژگی aspect-ratio CSS برای رفع این مشکل در مرورگرهایی که از آن پشتیبانی می‌کنند استفاده کردیم. برای کسانی که این کار را نمی کنند، ما یک تصویر مکان نگهدار شفاف را بارگذاری کردیم که در حافظه پنهان و اندازه آن فقط چند بایت بود، بنابراین تقریباً بلافاصله بارگیری می شود.
این رفتار کلی تصویر به ما این امکان را می‌دهد که ارتفاع تصویر نهایی را در حین رندر سمت سرور، بر اساس عرض و نسبت تصویر تصویر، از قبل محاسبه کنیم. این منجر به نشانه گذاری HTML با فضای عمودی مناسب برای تصویر نهایی شد. این بهبود به‌ویژه در دستگاه‌های تلفن همراه قابل مشاهده بود، زیرا تصاویر در گستره کامل درگاه‌های نمایش تلفن همراه ارائه می‌شوند.
برخی از مؤلفه‌ها در سایتهای مشتریان ما دارای محتوای پویا هستند (مثلاً فهرستی از نظرات مشتریان خارجی) و نمی‌توان آنها را به CSS خالص تبدیل کرد تا از مزایای عملکرد رندر سمت سرور استفاده کند. اینها مناطق دشواری برای بهبود تغییرات چیدمان هستند زیرا محتوا (در نتیجه ارتفاع) متفاوت خواهد بود. در آن موارد، ما جزء را در ظرفی پیچیده کردیم که min-height بر اساس مشاهده میانگین ارتفاع برای هر یک از اجزای خاص از پیش تعیین شده بود. زمانی که مولفه دینامیک داخلی رندر انجام شد min-height حذف می‌شود. اگرچه این راه حل کامل نیست، اما به ما امکان داد تا تغییر طرح را تا حد زیادی کاهش دهیم.
در حالی که روی بهبودهای CLS تمرکز داشتیم، به کار بر روی LCP ادامه دادیم. در بسیاری از وب‌سایت‌ها، تصاویر بزرگترین عاملی هستند که به LCP کمک می‌کنند و برای ما این یک زمینه واضح برای بهبود بود. ما با استفاده از IntersectionObserver برای بارگذاری تنبل تصاویر بهبودهایی ایجاد کرده بودیم، اما متوجه شدیم که اندازه‌های تصویر به بهترین شکل برای هر نقطه شکست (موبایل، تبلت، دسکتاپ، دسکتاپ بزرگ) تنظیم نشده است، بنابراین کد تولید تصویر خود را به‌روزرسانی کردیم تا تصاویر را در هر نقطه شکست گیره و مقیاس کنیم و سپس مجدداً وضوح را بر اساس تراکم پیکسل مقیاس کنیم. به عنوان مثال، این کار اندازه یک تصویر بزرگ خاص را از 192 کیلوبایت به 102 کیلوبایت کاهش داد.
برای رندر سریع وب‌سایت‌ها در دستگاه‌هایی با اتصالات شبکه ضعیف، کدی را اضافه کردیم تا به صورت پویا کیفیت تصویر را بر اساس سرعت اتصال کاهش دهیم. این را می توان با استفاده از ویژگی downlink که توسط navigator.connection برگردانده شده است انجام داد. ما پارامترهای پرس و جو مبتنی بر URL را برای کاهش کیفیت تصویر از طریق API دارایی خود بر اساس آن شرایط شبکه اعمال می کنیم.
تعدادی از بخش های سایت های مشتریان ما به صورت پویا بارگیری می شوند. از آنجایی که می‌دانیم چه بخش‌هایی در یک سایت مشخص در زمان انتشار آن ارائه می‌شوند، از راهنمایی منبع rel=preconnect برای مقداردهی اولیه اتصال و دست دادن‌های ضروری قبل از زمان استفاده کردیم. ما همچنین از نکات منابع برای بارگیری سریع فونت ها و سایر منابع مهم استفاده می کنیم.
هنگام ساخت سایت های خود، مشتریان بخش های مختلفی را اضافه می کنند که ممکن است دارای اسکریپت های درون خطی باشند تا قابلیت های مختلف را امکان پذیر کنند. وجود این اسکریپت‌ها در صفحه HTML همیشه برای عملکرد بهینه نیست. ما تصمیم گرفتیم این اسکریپت ها را خارجی کنیم تا به مرورگر اجازه دهیم محتوای اسکریپت را به صورت ناهمزمان بارگیری و تجزیه کند. اسکریپت های جدید خارجی نیز می توانند در بین صفحات به اشتراک گذاشته شوند. این باعث افزایش عملکرد بیشتر در قالب حافظه پنهان مرورگر و CDN شد. ما اسکریپت های مهم را در خط نگه می داریم تا مرورگر آنها را سریعتر تجزیه و اجرا کند.
نتایج
با تمرکز تلاش ما بر روی CLS نتیجه داد، نرخ عبور Core Web Vitals ما از حدود 40٪ به تقریبا 70٪ رسید: بهبود 75٪!
از آنجا که کاربران برای به روزرسانی و انتشار مجدد سایت های خود به پلتفرم ما باز می گردند ، آخرین پیشرفت های عملکرد را بدست می آورند و در نتیجه تعداد سایت هایی با "گذر از وب ویتامان اصلی" همانطور که در نمودار زیر نشان داده شده است ، به طور پیوسته در حال رشد است:
نتیجه گیری
یافتن زمینه هایی برای پیشرفت عملکرد و پیگیری موفقیت آمیز پیشرفت بسیار وابسته به اینکه از ابزارهایی برای اندازه گیری استفاده می شود ، بسیار وابسته است. در حالی که Lighthouse برای اندازه گیری عملکرد بالاتر از برابر در "تنظیم آزمایشگاه" مفید بود ، اما به طور دقیق مشکلات عملکردی را که فقط از تعامل کاربر رخ داده است (مانند پیمایش در صفحه) به طور دقیق ضبط نکرد.
ردیابی ویتام های وب واقعی جهان با ابرداده به ما امکان می دهد تا تأثیر پیشرفت های خود را تجسم ، هدف و اندازه گیری کنیم. سفر برای بهبود نمرات اصلی وب ویتامان به تیم امکان می دهد الگوهای غیر عملکردی موجود در پایگاه کد ما را شناسایی و جایگزین کند. گاهی اوقات تغییرات امیدوارکننده تقریباً تاثیری را که انتظار داشتیم نداشتند ، بعضی اوقات برعکس اتفاق افتاد. این یک دنیای بکر در آنجا نیست ، بنابراین شما باید تلاش کنید.
،مطالعه موردی از تغییرات Godaddy که برای بهبود عملکرد وب سایت برای میلیون ها سایت اجرا شده است ، و به آنها در دستیابی به بینش خوب و نمرات اصلی وب ویتامین کمک می کند.
Godaddy بزرگترین بستر خدمات جهان برای کارآفرینان در سراسر جهان است. ما در حال مأموریت هستیم تا جامعه جهانی خود را با بیش از 20 میلیون مشتری - و کارآفرین در همه جا - با کمک و ابزارهای مورد نیاز برای رشد آنلاین به آنها توانمند کنیم.
در سال 2019 ، Godaddy وب سایت ها + بازاریابی را با تعهد به ارائه ابزارها و خدماتی که استفاده از آنها آسان است و به صاحبان مشاغل در دستیابی به اهداف خود کمک می کند ، راه اندازی کرد. وب سایت ها + بازاریابی ، ایجاد وب سایت را با ابزارهای بازاریابی و تجارت الکترونیک ادغام می کند و آنها را با راهنمایی های بهترین کلاس برای کمک به مشتریان در دستیابی به موفقیت در سرمایه گذاری های جدید خود جفت می کند.
از زمان راه اندازی وب سایت ها + بازاریابی ، عملکرد بخش مهمی از محصول و چیزی بوده است که به طور فعال تحت نظارت و کار شده است. در این مقاله ، ما سفر GoDaddy را از استفاده از آزمایش عملکرد آزمایشگاه تا استفاده از داده های دنیای واقعی با Core Web Vitals ، و سری پیشرفت های انجام شده در این محصول بررسی خواهیم کرد تا نرخ عبور بسیار بالایی برای سایت های مشتری خود بدست آوریم.
ردیابی عملکرد با فانوس دریایی
ما برای ردیابی عملکرد به داده های فانوس دریایی اعتماد کرده ایم. هر بار که یک وب سایت روی این سیستم عامل منتشر می شود ، ما عملکرد آن را با استفاده از ابزار داخلی ما به نام "Lighthouse4u" اندازه گیری می کنیم ، که Google Lighthouse را به عنوان یک سرویس https://github.com/godaddy/lighthouse4u ارائه می دهد. این نشانگر خوبی از نحوه عملکرد سایتها در یک آزمایشگاه به ما نشان می داد.
از آنجا که میلیون ها سایت که ما در پلتفرم خود میزبان هستیم دارای طیف گسترده ای از ویژگی ها و محتوا است ، مهم بود که داده های عملکرد را با ابرداده در مورد هر سایت مورد آزمایش قرار دهیم (مانند الگوی مورد استفاده ، نوع ابزارک های ارائه شده و غیره). این به ما اجازه می دهد تا نتیجه گیری در مورد ویژگی های وب سایت عملکرد کمتری داشته باشیم ، در حالی که بینشی را برای جستجوی پیشرفت ها ارائه می دهیم.
به عنوان مثال ، این به ما کمک کرد تا تشخیص دهیم که "معین بازشو" تأثیر منفی بر سرعت صفحه داشته است. سایت هایی با این ویژگی 12 امتیاز پایین تر از بدون آن را انجام داده اند. پس از به روزرسانی در کد برای به تعویق انداختن بارگذاری جاوا اسکریپت ، نمره فانوس دریایی خود را با 2 امتیاز بهبود بخشیدیم. ما توانستیم این یادگیری را برای سایر ویژگی هایی مانند "پرچم کوکی" که به زودی پس از بار صفحه ارائه می شود ، اعمال کنیم.
در کنار نگاه کردن به سایتهای مشکل ساز بر اساس ویژگی ها ، ما تجزیه و تحلیل بسته نرم افزاری JavaScript را انجام دادیم و دیدیم که بخش بزرگی از اندازه آن از وابستگی های خارجی ناشی می شود (تغییر ناپذیر. js و پیش نویس. js). ما با بازسازی مصرف کنندگان به وابستگی بار تنبل در صورت تقاضا ، اندازه بسته نرم افزاری را کاهش دادیم. این منجر به افت بیش از 50 درصدی در اندازه بسته نرم افزاری جاوا اسکریپت ، که از بیش از 200 کیلوبایت به حدود 90 کیلوبایت (Minified) رفت. اندازه بسته نرم افزاری کوچکتر به مرورگر اجازه می دهد تا دارایی های خارجی را بارگیری کرده و اسکریپت های بحرانی را در اوایل چرخه عمر بارگذاری سایت اولیه اجرا کند و منجر به دستیابی به بزرگترین رنگ محتوا (LCP) و اولین تأخیر ورودی (FID) شود.
به لطف تلاش های مداوم ما ، میانگین نمره فانوس دریایی سایت مشتری از حدود 40 امتیاز در نوامبر 2020 به بیش از 70 امتیاز در ماه مه 2021 منتقل شد. با این حال ، همه تلاش های ما کار نکردند و ما گاهی اوقات تعجب می کردیم که نتایج همیشه بین آنچه در محیط های آزمایش محلی آزمایش شده و نتایج ما در این زمینه سازگار نبود. نتایج آزمایشگاه واقعاً مفید بوده است ، اما زمان آن رسیده بود که روی تجربیات واقعی کاربر مشاهده شده در این زمینه تمرکز کنیم.
ردیابی داده های کاربر واقعی با وب سایت های اصلی
پس از افزودن کتابخانه web-vitals به سایت های مشتری ، ما توانستیم داده های مربوط به دستگاه های واقعی را از بازدید کنندگان واقعی اندازه گیری کنیم ، جایی که سخت افزار ، سرعت شبکه ، تعامل کاربر (مانند پیمایش یا کلیک) در یک پایه ثابت مانند یک آزمایشگاه با استفاده از فانوس دریایی قرار ندارند. این یک گام بزرگ در جهت درست بود ، زیرا اکنون داده هایی داشتیم که نماینده آنچه بازدید کنندگان وب سایت ما تجربه می کردند.
تمرکز بر ضعیف ترین پیوند ما: تغییر چیدمان تجمعی (CLS)
تجزیه و تحلیل داده های جدید چشم انداز جدیدی را در مورد آنچه باید برای بهبود سرعت وب سایت انجام شود ، به ما داد. به دلیل کارهایی که برای بهبود نمره فانوس دریایی انجام شده است ، LCP صدک 75 ما 860 میلی ثانیه و FID ما در همان آستانه زیر 10 میلی ثانیه بود ، بنابراین ما به ترتیب از نرخ پاس بالا برای این معیارها در سایت های مشتری خود برخوردار بودیم: 78 ٪ و 98 ٪. با این حال ، اعداد تغییر چیدمان تجمعی (CLS) کاملاً متفاوت از آنچه ما با فانوس دریایی استفاده می کردیم. CLS ما در صدک 75 0.17 -آستانه 0.1 آستانه به "عبور" بود - و نرخ پاس ما از این رو تنها 47 ٪ نسبت به تمام سایتهای ما بود.
این متریک نرخ پاس کلی ما را به 40 ٪ کاهش داد ، بنابراین ما تصمیم گرفتیم تا پایان اوت 2021 ، هدف بلندپروازانه را برای انتقال این تعداد به بالای 60 ٪ تعیین کنیم. برای انجام این کار ، ما باید روی CLS تمرکز کنیم .
در زندگی واقعی ، کاربران با صفحه تعامل دارند و از محتوای "بالاتر از برابر" عبور می کنند ، این چیزی است که وب ویتام های اصلی بهتر می شوند. با توجه به تنوع در نحوه تعامل کاربران با سایت در حالی که در ابتدا بارگیری می شود ، CLS از داده های آزمایشگاهی و میدانی متفاوت است.
جاده عبور از تمام ویتام های اصلی وب
بهبود عملکرد آزمایش و خطا را انجام می دهد ، و هر تلاشی همیشه همانطور که انتظار می رفت کار نمی کند. با این حال ، در اینجا چند پیشرفت وجود دارد که به ما در رسیدن به اهداف خود کمک کرده است.
رزرو فضای برای بارگیری تصاویر به طرز چشمگیری نمره CLS ما را بهبود بخشید زیرا مانع از تغییر محتوای زیر تصاویر می شود. ما از ویژگی aspect-ratio برای پرداختن به این موضوع در مرورگرهایی که از آن پشتیبانی می کنند استفاده کردیم. برای آنهایی که این کار را نمی کنند ، ما یک تصویر نگهدارنده شفاف را که ذخیره شده و فقط چند بایت در اندازه بود ، بارگذاری کردیم ، بنابراین تقریباً بلافاصله بارگیری می کنیم.
این رفتار تصویر عمومی به ما این امکان را می دهد تا بر اساس عرض نمای و نسبت ابعاد تصویر ، ارتفاع تصویر نهایی را در حین ارائه سمت سرور محاسبه کنیم. این منجر به نشانه گذاری HTML با فضای عمودی مناسب برای تصویر نهایی شد. این پیشرفت به ویژه در دستگاه های تلفن همراه قابل مشاهده بود ، زیرا تصاویر به اندازه کامل نمای تلفن همراه ارائه می شوند.
برخی از مؤلفه ها در سایت های مشتریان ما دارای محتوای پویا هستند (به عنوان مثال ، لیستی از بررسی های مشتری خارجی) و نمی توانند به CSS خالص تبدیل شوند تا از مزایای عملکرد ارائه سمت سرور استفاده کنند. اینها مناطق دشوار برای بهبود تغییرات طرح هستند زیرا محتوا (در نتیجه ارتفاع) متفاوت خواهد بود. در این موارد ، ما مؤلفه را در یک ظرف با یک min-height استفاده کردیم ، از پیش تعیین شده بر اساس مشاهده ارتفاع متوسط برای هر یک از مؤلفه های خاص. هنگامی که مؤلفه پویا درونی انجام می شود min-height برداشته می شود. در حالی که کامل نیست ، این راه حل به ما اجازه می دهد تا تغییر چیدمان را به مقدار زیادی کاهش دهیم.
در حالی که روی پیشرفت های CLS تمرکز داشتیم ، ما به کار خود در LCP ادامه دادیم. در بسیاری از وب سایت ها ، تصاویر بزرگترین مقصر مشارکت در LCP هستند و برای ما یک منطقه آشکار از پیشرفت بود. ما در تصاویر بار تنبل با استفاده از IntersectionObserver پیشرفت هایی ایجاد کرده بودیم اما فهمیدیم که اندازه تصویر بهینه ترین روش برای هر نقطه شکست (تلفن همراه ، تبلت ، دسک تاپ ، دسک تاپ بزرگ) تنظیم نشده است ، بنابراین ما کد تولید تصویر خود را برای گیره و مقیاس در هر نقطه به روز کردیم و دوباره بر اساس چگالی پیکسل. به عنوان نمونه ، این اندازه یک تصویر بزرگ خاص را از سال 192 کیلوبایت به 102 کیلوبایت کاهش می دهد.
برای ارائه سریع وب سایت ها در دستگاه هایی با اتصالات شبکه ضعیف ، ما کد را برای کاهش پویا کیفیت تصویر بر اساس سرعت اتصال اضافه کردیم. این کار را می توان با استفاده از ویژگی downlink که توسط navigator.connection برگشته است انجام دهید. ما پارامترهای پرس و جو مبتنی بر URL را برای کاهش کیفیت تصویر از طریق API دارایی خود بر اساس آن شرایط شبکه اعمال می کنیم.
تعدادی از بخش های سایت های مشتری ما به صورت پویا بارگیری می شوند. از آنجا که می دانیم هنگام انتشار ، چه بخش هایی در یک سایت معین ارائه می شود ، ما از rel=preconnect منبع استفاده کردیم تا اتصال و دست های لازم را قبل از زمان انجام دهیم. ما همچنین از نکات منابع برای بارگیری فونت ها و سایر منابع مهم به سرعت استفاده می کنیم.
هنگام ساخت سایت های خود ، مشتریان بخش های مختلفی را اضافه می کنند که ممکن است دارای اسکریپت های درون خطی باشند تا قابلیت های مختلف را فراهم کنند. داشتن این اسکریپت ها به صورت درون صفحه HTML همیشه برای عملکرد بهینه نیست. ما تصمیم گرفتیم که این اسکریپت ها را بیرونی کنیم تا به مرورگر اجازه دهد تا محتوای اسکریپت را به صورت غیر همزمان بارگیری و تجزیه کند. اسکریپت های تازه بیرونی نیز می توانند در صفحات به اشتراک گذاشته شوند. این امر باعث می شود سود عملکرد دیگری در قالب مرورگر و حافظه پنهان CDN باشد. ما اسکریپت های بحرانی را بصورت آنلاین نگه داشتیم تا مرورگر بتواند آنها را سریعتر تجزیه کند و آنها را اجرا کند.
نتایج
با تمرکز تلاش ما بر روی CLS پرداخت شده ، نرخ گذرگاه اصلی ما در حدود 40 ٪ به 70 ٪ رسید: بهبود 75 ٪!
از آنجا که کاربران برای به روزرسانی و انتشار مجدد سایت های خود به پلتفرم ما باز می گردند ، آخرین پیشرفت های عملکرد را بدست می آورند و در نتیجه تعداد سایت هایی با "گذر از وب ویتامان اصلی" همانطور که در نمودار زیر نشان داده شده است ، به طور پیوسته در حال رشد است:
نتیجه گیری
یافتن زمینه هایی برای پیشرفت عملکرد و پیگیری موفقیت آمیز پیشرفت بسیار وابسته به اینکه از ابزارهایی برای اندازه گیری استفاده می شود ، بسیار وابسته است. در حالی که Lighthouse برای اندازه گیری عملکرد بالاتر از برابر در "تنظیم آزمایشگاه" مفید بود ، اما به طور دقیق مشکلات عملکردی را که فقط از تعامل کاربر رخ داده است (مانند پیمایش در صفحه) به طور دقیق ضبط نکرد.
ردیابی ویتام های وب واقعی جهان با ابرداده به ما امکان می دهد تا تأثیر پیشرفت های خود را تجسم ، هدف و اندازه گیری کنیم. سفر برای بهبود نمرات اصلی وب ویتامان به تیم امکان می دهد الگوهای غیر عملکردی موجود در پایگاه کد ما را شناسایی و جایگزین کند. گاهی اوقات تغییرات امیدوارکننده تقریباً تاثیری را که انتظار داشتیم نداشتند ، بعضی اوقات برعکس اتفاق افتاد. این یک دنیای بکر در آنجا نیست ، بنابراین شما باید تلاش کنید.