چگونه The Economic Times از آستانه های Core Web Vitals عبور کرد و به طور کلی 43٪ نرخ پرش بهتری را به دست آورد.

بهینه سازی Core Web Vitals در وب سایت The Economic Times به طور قابل توجهی تجربه کاربر را بهبود بخشید و نرخ پرش را در کل وب سایت کاهش داد.

Anshu Sharma

Prashant Mishra

Sumit Gugnani

با بهبود سرعت اینترنت روز به روز، کاربران انتظار دارند وب سایت ها سریعتر از همیشه پاسخ دهند و رفتار کنند. اکونومیک تایمز بیش از 45 میلیون کاربر فعال ماهانه را مدیریت می کند. با بهینه سازی Core Web Vitals در سراسر دامنه، در صفحات AMP و غیرAMP، ما موفق شدیم نرخ پرش را به میزان قابل توجهی کاهش دهیم و تجربه خواندن را بهبود بخشیم.

اندازه گیری تاثیر

ما روی بزرگترین رنگ محتوا (LCP) و تغییر چیدمان تجمعی (CLS) تمرکز کردیم، زیرا در ارائه یک تجربه خواندن عالی به کاربرانمان بیشترین اهمیت را دارند. پس از اجرای اصلاحات مختلف عملکرد همانطور که در زیر توضیح داده شد، The Economic Times موفق شد معیارهای گزارش آزمایش‌های کاربر Chrome (CrUX) را در عرض چند ماه به طور قابل توجهی بهبود بخشد.

به طور کلی، CLS 250٪ از 0.25 به 0.09 بهبود یافته است . به طور کلی، LCP 80٪ از 4.5 ثانیه به 2.5 ثانیه بهبود یافته است .

علاوه بر این، مقادیر LCP در محدوده «ضعیف» از اکتبر 2020 تا ژوئیه 2021 33 درصد کاهش یافت:

علاوه بر این، مقادیر CLS در محدوده "ضعیف" 65٪ کاهش یافت و مقادیر CLS در محدوده "خوب" 20٪ در همان بازه زمانی افزایش یافت:

نتیجه این بود که The Economic Times - که قبلاً آستانه Core Web Vitals را برآورده نمی کرد - اکنون از آستانه Core Web Vitals در کل مبدا عبور کرده و نرخ پرش را به طور کلی 43٪ کاهش داده است .

LCP چیست و چگونه آن را بهبود بخشیم؟

بزرگترین عنصر مرتبط ترین عنصر برای بهبود تجربه کاربر و تشخیص سرعت بار است. معیارهای عملکرد مانند First Contentful Paint (FCP) تنها تجربه اولیه بارگیری صفحه را نشان می دهد. از طرف دیگر، LCP زمان رندر بزرگترین بخش تصویر، متن یا ویدیو را برای کاربر گزارش می‌کند.

علاوه بر جابجایی به ارائه‌دهنده DNS سریع‌تر و بهینه‌سازی تصاویر، در اینجا برخی از تکنیک‌هایی که برای بهبود LCP اعمال کردیم، آورده شده است.

ابتدا درخواست های حیاتی

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

ظاهر متن

ما با ویژگی font-display آزمایش کردیم زیرا این ویژگی بر LCP و CLS تأثیر می گذارد. ما font-display: auto; و سپس به font-display: swap; . این کار متن را در ابتدا با بهترین فونت منطبق و موجود ارائه می کند، سپس پس از دانلود به فونت تغییر می کند. این منجر به ارائه سریع متن ما، مستقل از سرعت شبکه شد.

فشرده سازی بهتر

Brotli یک الگوریتم فشرده سازی جایگزین برای Gzip و Deflate است که توسط گوگل توسعه یافته است. فونت‌ها و دارایی‌های خود را جایگزین کردیم و فشرده‌سازی سرور را از Gzip به Brotli تغییر دادیم تا ردپای کوچک‌تری داشته باشیم:

• فایل های جاوا اسکریپت 15 درصد کوچکتر از Gzip هستند.
• فایل های HTML 18 درصد کوچکتر از Gzip هستند.
• فایل های CSS و فونت 17 درصد کوچکتر از Gzip هستند.

از قبل به دامنه های شخص ثالث متصل شوید

preconnect باید با دقت استفاده شود زیرا هنوز هم می تواند زمان ارزشمند CPU را بگیرد و سایر منابع مهم را به خصوص در اتصالات امن به تاخیر بیندازد.

با این حال، اگر مشخص باشد که واکشی برای یک منبع در یک دامنه شخص ثالث رخ خواهد داد، preconnect خوب است. اگر فقط گاهی اوقات در یک وب سایت با ترافیک بالا اتفاق می افتد، preconnect ممکن است باعث کار غیر ضروری TCP و TLS شود. بنابراین dns-prefetch برای منابع شخص ثالث - به عنوان مثال، رسانه های اجتماعی، تجزیه و تحلیل و غیره - برای انجام جستجوی DNS پیش از موعد مناسب تر بود.

کد را به قطعات تقسیم کنید

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

ذخیره سازی بهتر

برای تمام مسیرهای جلویی، ما یک لایه Redis اضافه کردیم که الگوها را از حافظه پنهان ارائه می‌کرد. این امر زمان محاسبات روی سرور را کاهش می دهد و کل UI را در هر درخواست ایجاد می کند، بنابراین LCP را در درخواست های بعدی کاهش می دهد.

خلاصه کردن اهداف و دستاوردهای LCP

قبل از شروع پروژه بهینه سازی، تیم امتیاز LCP خود را در 4.5 ثانیه (برای صدک 75 کاربران خود، بر اساس داده های میدانی گزارش CrUX) محک زد. پس از پروژه بهینه سازی، به 2.5 ثانیه کاهش یافت.

CLS چیست و چگونه آن را بهبود بخشیم؟

آیا تا به حال متوجه حرکت غیرمنتظره محتوای صفحه در هنگام مرور یک وب سایت شده اید؟ یکی از دلایل آن بارگذاری ناهمزمان رسانه (تصاویر، فیلم ها، تبلیغات و غیره) در صفحه با ابعاد نامشخص است. به محض بارگیری منابع رسانه ای، طرح بندی صفحه را تغییر می دهند.

ما قصد داریم اقداماتی را که برای بهبود CLS انجام دادیم در وب سایت The Economic Times پوشش دهیم.

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

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

ابعاد ظرف تعریف شده

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

خلاصه کردن اهداف و دستاوردهای CLS

قبل از شروع پروژه بهینه سازی، تیم امتیاز CLS خود را 0.25 محک زد. ما توانستیم آن را به میزان قابل توجهی 90 درصد به 0.09 کاهش دهیم.

اولین تاخیر ورودی (FID) چیست و چگونه آن را بهبود بخشیم؟

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

کارهای طولانی جاوا اسکریپت را جدا کنید

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

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

ما محتوای صفحه را بر اسکریپت های شخص ثالث مانند تجزیه و تحلیل اولویت دادیم تا صفحه را پاسخگوتر نگه داریم. با این حال، محدودیت‌های خاصی در برخی از کتابخانه‌ها وجود دارد، زیرا برای ردیابی دقیق سفر کاربر، باید در سند <head> بارگذاری شوند.

کاهش پلی پرها

ما وابستگی خود را به پلی‌فیل‌ها و کتابخانه‌های خاصی کاهش دادیم، زیرا مرورگرها از APIهای مدرن پشتیبانی می‌کنند و کاربران کمتری از مرورگرهای قدیمی مانند Internet Explorer استفاده می‌کنند.

تبلیغات لود تنبل

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

خلاصه کردن اهداف و دستاوردهای FID

از آزمایش های معمول، امروز توانستیم FID خود را از 200 میلی ثانیه به زیر 50 میلی ثانیه کاهش دهیم.

جلوگیری از پسرفت

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

بهینه سازی Core Web Vitals در وب سایت The Economic Times به طور قابل توجهی تجربه کاربر را بهبود بخشید و نرخ پرش را در کل وب سایت کاهش داد.

Anshu Sharma

Prashant Mishra

Sumit Gugnani

با بهبود سرعت اینترنت روز به روز، کاربران انتظار دارند وب سایت ها سریعتر از همیشه پاسخ دهند و رفتار کنند. اکونومیک تایمز بیش از 45 میلیون کاربر فعال ماهانه را مدیریت می کند. با بهینه سازی Core Web Vitals در سراسر دامنه، در صفحات AMP و غیرAMP، ما موفق شدیم نرخ پرش را به میزان قابل توجهی کاهش دهیم و تجربه خواندن را بهبود بخشیم.

اندازه گیری تاثیر

ما روی بزرگترین رنگ محتوا (LCP) و تغییر چیدمان تجمعی (CLS) تمرکز کردیم، زیرا در ارائه یک تجربه خواندن عالی به کاربرانمان بیشترین اهمیت را دارند. پس از اجرای اصلاحات مختلف عملکرد همانطور که در زیر توضیح داده شد، The Economic Times موفق شد معیارهای گزارش آزمایش‌های کاربر Chrome (CrUX) را در عرض چند ماه به طور قابل توجهی بهبود بخشد.

به طور کلی، CLS 250٪ از 0.25 به 0.09 بهبود یافته است . به طور کلی، LCP 80٪ از 4.5 ثانیه به 2.5 ثانیه بهبود یافته است .

علاوه بر این، مقادیر LCP در محدوده «ضعیف» از اکتبر 2020 تا ژوئیه 2021 33 درصد کاهش یافت:

علاوه بر این، مقادیر CLS در محدوده "ضعیف" 65٪ کاهش یافت و مقادیر CLS در محدوده "خوب" 20٪ در همان بازه زمانی افزایش یافت:

نتیجه این بود که The Economic Times - که قبلاً آستانه Core Web Vitals را برآورده نمی کرد - اکنون از آستانه Core Web Vitals در کل مبدا عبور کرده و نرخ پرش را به طور کلی 43٪ کاهش داده است .

LCP چیست و چگونه آن را بهبود بخشیم؟

بزرگترین عنصر مرتبط ترین عنصر برای بهبود تجربه کاربر و تشخیص سرعت بار است. معیارهای عملکرد مانند First Contentful Paint (FCP) تنها تجربه اولیه بارگیری صفحه را نشان می دهد. از طرف دیگر، LCP زمان رندر بزرگترین بخش تصویر، متن یا ویدیو را برای کاربر گزارش می‌کند.

علاوه بر جابجایی به ارائه‌دهنده DNS سریع‌تر و بهینه‌سازی تصاویر، در اینجا برخی از تکنیک‌هایی که برای بهبود LCP اعمال کردیم، آورده شده است.

ابتدا درخواست های حیاتی

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

ظاهر متن

ما با ویژگی font-display آزمایش کردیم زیرا این ویژگی بر LCP و CLS تأثیر می گذارد. ما font-display: auto; و سپس به font-display: swap; . این کار متن را در ابتدا با بهترین فونت منطبق و موجود ارائه می کند، سپس پس از دانلود به فونت تغییر می کند. این منجر به ارائه سریع متن ما، مستقل از سرعت شبکه شد.

فشرده سازی بهتر

Brotli یک الگوریتم فشرده سازی جایگزین برای Gzip و Deflate است که توسط گوگل توسعه یافته است. فونت‌ها و دارایی‌های خود را جایگزین کردیم و فشرده‌سازی سرور را از Gzip به Brotli تغییر دادیم تا ردپای کوچک‌تری داشته باشیم:

• فایل های جاوا اسکریپت 15 درصد کوچکتر از Gzip هستند.
• فایل های HTML 18 درصد کوچکتر از Gzip هستند.
• فایل های CSS و فونت 17 درصد کوچکتر از Gzip هستند.

از قبل به دامنه های شخص ثالث متصل شوید

preconnect باید با دقت استفاده شود زیرا هنوز هم می تواند زمان ارزشمند CPU را بگیرد و سایر منابع مهم را به خصوص در اتصالات امن به تاخیر بیندازد.

با این حال، اگر مشخص باشد که واکشی برای یک منبع در یک دامنه شخص ثالث رخ خواهد داد، preconnect خوب است. اگر فقط گاهی اوقات در یک وب سایت با ترافیک بالا اتفاق می افتد، preconnect ممکن است باعث کار غیر ضروری TCP و TLS شود. بنابراین dns-prefetch برای منابع شخص ثالث - به عنوان مثال، رسانه های اجتماعی، تجزیه و تحلیل و غیره - برای انجام جستجوی DNS پیش از موعد مناسب تر بود.

کد را به قطعات تقسیم کنید

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

ذخیره سازی بهتر

برای تمام مسیرهای جلویی، ما یک لایه Redis اضافه کردیم که الگوها را از حافظه پنهان ارائه می‌کرد. این امر زمان محاسبات روی سرور را کاهش می دهد و کل UI را در هر درخواست ایجاد می کند، بنابراین LCP را در درخواست های بعدی کاهش می دهد.

خلاصه کردن اهداف و دستاوردهای LCP

قبل از شروع پروژه بهینه سازی، تیم امتیاز LCP خود را در 4.5 ثانیه (برای صدک 75 کاربران خود، بر اساس داده های میدانی گزارش CrUX) محک زد. پس از پروژه بهینه سازی، به 2.5 ثانیه کاهش یافت.

CLS چیست و چگونه آن را بهبود بخشیم؟

آیا تا به حال متوجه حرکت غیرمنتظره محتوای صفحه در هنگام مرور یک وب سایت شده اید؟ یکی از دلایل آن بارگذاری ناهمزمان رسانه (تصاویر، فیلم ها، تبلیغات و غیره) در صفحه با ابعاد نامشخص است. به محض بارگیری منابع رسانه ای، طرح بندی صفحه را تغییر می دهند.

ما قصد داریم اقداماتی را که برای بهبود CLS انجام دادیم در وب سایت The Economic Times پوشش دهیم.

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

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

ابعاد ظرف تعریف شده

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

خلاصه کردن اهداف و دستاوردهای CLS

قبل از شروع پروژه بهینه سازی، تیم امتیاز CLS خود را 0.25 محک زد. ما توانستیم آن را به میزان قابل توجهی 90 درصد به 0.09 کاهش دهیم.

اولین تاخیر ورودی (FID) چیست و چگونه آن را بهبود بخشیم؟

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

کارهای طولانی جاوا اسکریپت را جدا کنید

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

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

ما محتوای صفحه را بر اسکریپت های شخص ثالث مانند تجزیه و تحلیل اولویت دادیم تا صفحه را پاسخگوتر نگه داریم. با این حال، محدودیت‌های خاصی در برخی از کتابخانه‌ها وجود دارد، زیرا برای ردیابی دقیق سفر کاربر، باید در سند <head> بارگذاری شوند.

کاهش پلی پرها

ما وابستگی خود را به پلی‌فیل‌ها و کتابخانه‌های خاصی کاهش دادیم، زیرا مرورگرها از APIهای مدرن پشتیبانی می‌کنند و کاربران کمتری از مرورگرهای قدیمی مانند Internet Explorer استفاده می‌کنند.

تبلیغات لود تنبل

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

خلاصه کردن اهداف و دستاوردهای FID

از آزمایش های معمول، امروز توانستیم FID خود را از 200 میلی ثانیه به زیر 50 میلی ثانیه کاهش دهیم.

جلوگیری از رگرسیون

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