07تیر

معیار بزرگترین عنصر (LCP) چیست؟

تیر 7, 1400 نویسنده آوین آویسا

از نظر تاریخی، اندازه‌گیری سرعت بارگیری و مشاهده محتوای اصلی یک صفحه وب برای کاربران یک چالش مهم برای توسعه‌دهندگان بوده است. معیار بزرگترین عنصر (LCP) کلید ماجراست!

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

معیارهای عملکردی مانند First Meaningful Paint (FMP) و Speed Speed (SI) (هر دو موجود در Lighthouse) نیز موجود هستند، اما توضیح این معیارها پیچیده است، و اغلب اشتباه است – به این معنی که آن‌ها هنوز هم بارگذاری محتوای اصلی صفحه را تشخیص نمی‌دهند.

بعضی اوقات نگاه ساده‌تر، بهتر است. بر اساس بحث در کارگروه عملکرد وب W3C و تحقیقاتی که در Google انجام شده است، متوجه شده‌ایم که یک روش دقیق‌تر برای اندازه‌گیری زمان بارگیری محتوای اصلی یک صفحه، بررسی زمان ارائه بزرگترین عنصر است.

معیار بزرگترین عنصر (LCP) چیست؟

معیار Largest Contentful Paint (LCP) زمان رندر بزرگترین تصویر یا بلوک متنی را که در قسمت viewport قابل مشاهده است، نسبت به زمان بارگیری صفحه برای اولین بار، را گزارش می‌کند.

امتیاز خوب برای معیار بزرگترین عنصر (LCP) چیست؟

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

چه عناصری در این معیار در نظر گرفته می‌شوند؟

انواع عناصر در نظر گرفته شده برای بزرگترین محتوا عبارتند از:

عناصر <img>.
عناصر <image> داخل عنصر <svg>.
عناصر <video> (از تصویر پوستر استفاده می‌شود).
عنصری با تصویر پس‌زمینه که از طریق تابع url () بارگیری می‌شود (در مقابل گرادیان CSS).
عناصر سطح بلوک حاوی گره‌های متنی یا سایر عناصر متن درون خطی فرزندان(children).

توجه داشته باشید، محدود کردن عناصر به این مجموعه محدود به منظور ساده نگه داشتن موارد در ابتدا بوده است. با انجام تحقیقات بیشتر ممکن است در آینده عناصر اضافی (به عنوان مثال <svg> و <video>) اضافه شوند.

اندازه یک عنصر چگونه تعیین می‌شود؟

اندازه عنصر گزارش شده برای بزرگترین محتوا معمولاً اندازه‌ای است که برای کاربر در داخل ویوپورت قابل‌مشاهده است. اگر عنصر خارج از ویوپورت گسترش یابد، یا اگر هر یک از عناصر قطع شده یا دارای سرریز غیرقابل مشاهده(non-visible overflow) باشد‌، آن قسمت‌ها در اندازه عنصر محاسبه نمی‌شوند.

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

برای عناصر متن، فقط اندازه گره‌های متنی آن‌ها در نظر گرفته شده است (کوچکترین مستطیلی که همه گره‌های متنی را در بر می‌گیرد).

برای همه عناصر، هیچ حاشیه، padding یا حاشیه اعمال شده از طریق CSS در نظر گرفته نشده است.

چه زمانی بزرگترین محتوا گزارش می‌شود؟

صفحات وب معمولاً به صورت مرحله‌ای بارگیری می‌شوند و در نتیجه ممکن است بزرگترین عنصر صفحه تغییر کند.

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

به عنوان مثال، در صفحه‌ای با متن و یک تصویر، مرورگر ممکن است در ابتدا متن را رندر کند – در آن زمان مرورگر یک ورودی با بزرگترین محتوا را ارسال می‌کند که ویژگی عنصر آن احتمالاً به یک <p> یا <h1> اشاره دارد. بعداً، پس از اتمام بارگذاری تصویر، دومین ورودی با محتوای بزرگ‌تر ارسال می‌شود و ویژگی عنصر آن به <img> اشاره می‌کند.

توجه به این نکته مهم است که فقط می‌توان یک عنصر را بزرگترین عنصر محتوایی در نظر گرفت که برای کاربر قابل‌مشاهده است. تصاویری که هنوز بارگیری نشده‌اند “ارائه” محسوب نمی‌شوند. در چنین مواردی ممکن است عنصر کوچکتر به عنوان بزرگترین عنصر محتوا گزارش شود، اما به محض اتمام رندر، عنصر بزرگتر از طریق یک شی دیگر PerformanceEntry گزارش می‌شود.

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

اگر عنصری که در حال حاضر بزرگترین عنصر محتوایی است از قسمت view حذف شود (یا حتی از DOM حذف شود)، همچنان بزرگترین عنصر محتوایی در نظر گرفته خواهد شد مگر این‌که یک عنصر بزرگ‌تر ارائه شود.

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

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

زمان بارگذاری در مقابل زمان ارائه

به دلایل امنیتی، مهر زمانی تصاویر cross-origin که فاقد هدر Timing-Allow-Origin هستند، قرار نمی‌گیرد. در عوض، فقط زمان بارگذاری آن‌ها در معرض دید قرار دارد (زیرا این مورد از قبل از طریق بسیاری از API‌های وب دیگر نشان داده شده است).

نحوه تغییر عناصر و چیدمان عناصر چگونه انجام می شود؟

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

مثال‌ها

در اینجا چند نمونه در چند وب سایت معروف مرور شده ا‌ند:

در هر دو جدول زمانی بالا، بزرگترین عنصر با بارگذاری محتوا تغییر می‌کند. در مثال اول، محتوای جدید به DOM اضافه می‌شود و این بزرگترین عنصر را تغییر می‌دهد. در مثال دوم، چیدمان تغییر می‌کند و محتوایی که قبلاً بیشترین مقدار را داشت، از ویوپورت حذف می‌شود.

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

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

بزرگترین عنصر (LCP) چگونه اندازه‌گیری می‌شود؟

LCP را می‌توان در آزمایشگاه یا به طور عملیاتی اندازه‌گیری کرد. ابزارهای زیر در دسترس هستند:

ابزار عملیاتی:

ابزار آزمایشگاهی:

اندازه‌گیری LCP در جاوااسکریپت

برای اندازه‌گیری LCP در JavaScript، می‌توانید از Largest Contentful Paint APIAPI استفاده کنید. مثال زیر نحوه ایجاد PerformanceObserver را نشان می‌دهد که ورودی‌های largest-contentful-paint را زیر نظر می‌گیرد و آن‌ها را به کنسول وارد می‌کند.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('LCP candidate:', entry.startTime, entry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

new PerformanceObserver((entryList) => {

for (const entry of entryList.getEntries()) {

console.log('LCP candidate:', entry.startTime, entry);

}

}).observe({type: 'largest-contentful-paint', buffered: true});

در مثال بالا، هر ورودی largest-contentful-paintنشان‌دهنده کاندیدای فعلی LCP است. به طور کلی، مقدار startTime آخرین ورودی منتشر شده مقدار LCP است – با این حال، همیشه اینطور نیست. همه ورودی های largest-contentful-paint برای اندازه گیری LCP معتبر نیستند.

تفاوت‌های بین معیار و API

API بزرگترین محتوا را برای صفحات بارگیری شده در یک برگه پس زمینه ارسال می کند، اما هنگام محاسبه LCP این صفحات باید نادیده گرفته شوند.
API پس از ایجاد پس زمینه در یک صفحه، به largest-contentful-paint بیشتر ادامه می‌دهد، اما هنگام محاسبه LCP، باید این ورودی‌ها را نادیده گرفت (فقط در صورتی که صفحه در تمام زمان در پیش‌زمینه باشد، عناصر در نظر گرفته می‌شوند).
هنگام بازگرداندن صفحه از کش بک/ فرانت، API، ورودی‌های largest-contentful-paint را گزارش نمی‌کند، اما LCP باید در این موارد اندازه‌گیری شود زیرا کاربران آنها را به عنوان بازدیدهای صفحه تجربه می‌کنند.
API، ورودی‌هایی را که درون iframes رخ می‌دهند گزارش نمی‌کند، اما برای اندازه‌گیری صحیح LCP باید آنها را در نظر بگیرید. فریم‌های فرعی می‌توانند با استفاده از API ورودی‌های largest-contentful-paint خود را برای تجمیع در فریم والد گزارش دهند.

توسعه‌دهندگان به جای اینکه همه این تفاوت‌های ظریف را بخاطر بسپارند، می‌توانند برای اندازه‌گیری LCP از کتابخانه جاوا اسکریپت web-vitals استفاده کنند که این اختلافات را برای شما کنترل می‌کند (در صورت امکان).

import {getLCP} from 'web-vitals';
// Measure and log LCP as soon as it's available.
getLCP(console.log);

import {getLCP} from 'web-vitals';

// Measure and log LCP as soon as it's available.

getLCP(console.log);

اگر بزرگترین عنصر مهمترین عنصر نباشد چه می‌شود؟

در بعضی موارد مهمترین عنصر (یا عناصر) صفحه با بزرگترین عنصر یکی نیست و توسعه‌دهندگان ممکن است به جای آن علاقه بیشتری به اندازه‌گیری زمان رندر این عناصر دیگر را داشته باشند. همان‌طور که در مقاله معیارهای سفارشی شرح داده شده است، این مساله با استفاده از Element Timing API امکان‌پذیر است.

نحوه بهینه‌سازی معیار بزرگترین عنصر محتوا (LCP)

درمقاله جداگانه با جزییات تمام نحوه بهینه‌سازی LCP شرح داده شده است.

منبع:

https://web.dev/lcp/

ادامه مطلب

08خرداد

بهینه سازی بزرگترین عنصر محتوا (LCP)

خرداد 8, 1400 نویسنده آوین آویسا

من هیچ محتوای مفیدی نمی توانم ببینم! چرا بارگیری اینقدر طولانی است؟ بیایید با بهینه سازی بزرگترین عنصر محتوا (LCP) این تجربه کاربری ناخوشایند را از بین ببریم.

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

LCP یک از معیارهای اصلی Core Web Vital است و زمانی را محاسبه می‌کند که بزرگترین عنصر محتوای در viewport قابل مشاهده است.این معیار می‌تواند برای تعیین زمان پایان ارائه محتوای اصلی صفحه بر روی صفحه استفاده شود.

معمول‌ترین دلایل LCP ضعیف عبارتند از:

زمان طولانی پاسخ‌دهی سرور.
رندر–بلاکینگ جاوا اسکریپت و CSS.
زمان طولانی بارگیری منابع.
رندرینگ در سمت کاربر.

زمان طولانی پاسخ‌دهی سرور

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

قبل از هر چیز دیگری، نحوه و مکانی که سرور محتوای شما را هندل می‌کند بهبود ببخشید. برای اندازه‌گیری زمان پاسخ سرور از Time to First Byte (TTFB) استفاده کنید. شما می‌توانید TTFB خود را به روش‌های مختلفی بهبود بخشید:

سرور خود را بهینه کنید.
کاربران را به CDN نزدیک هدایت کنید.
کش محتوا.
ابتدا صفحات HTML را به صورت کش سرو کنید.
ارتباطات شخص ثالث را زودهنگام برقرار کنید.

بهینه‌سازی سرور

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

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

هدایت کاربران به نزدیک‌ترین CDN

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

کش محتوا

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

بسته به ابزار شما، روش‌های مختلفی برای اعمال کش محتوا سرور وجود دارد:

پروکسی‌های معکوس (Varnish، nginx) را برای ارائه محتوای ذخیره‌شده پیکربندی کنید.
کش محتوا ارائه دهنده ابر (Firebase ، AWS ، Azure) خود را پیکربندی و مدیریت کنید.
از CDN که سرورهای لبه را فراهم می‌کنند استفاده کنید تا محتوای شما در نزدیکی کاربران ذخیره شود.

سرو صفحات HTML به صورت کش در ابتدا

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

ارتباطات زودهنگام با شخص ثالث

درخواست‌های سرور به مبدا شخص ثالث نیز می‌تواند بر LCP تأثیر بگذارد، مخصوصاً اگر برای نمایش محتوای مهم در صفحه مورد نیاز باشد. با استفاده از rel = “preconnect” به مرورگر اطلاع دهید که صفحه شما قصد دارد در اسرع وقت اتصال برقرار کند.

<span style="color: #000000; font-size: 16px;"><link rel="preconnect" href="https://example.com" /></span>

1	<span style="color: #000000; font-size: 16px;"><link rel="preconnect" href="https://example.com" /></span>

برای حل سریع‌تر جستجوی DNS می توانید از dns-prefetch نیز استفاده کنید.

<span style="color: #000000; font-size: 16px;"><link rel="dns-prefetch" href="https://example.com" /></span>

1	<span style="color: #000000; font-size: 16px;"><link rel="dns-prefetch" href="https://example.com" /></span>

گرچه هر دو متفاوت عمل می کنند، استفاده از dns-prefetch را به عنوان گزینه فال‌بک برای مرورگرهایی که از اتصال مجدد پشتیبانی نمی‌کنند، در نظر بگیرید.

<span style="color: #000000; font-size: 16px;"><head>
  …
  <link rel="preconnect" href="https://example.com" />
  <link rel="dns-prefetch" href="https://example.com" />
</head></span>

…

</head></span>

رندر بلاکینگ جاوااسکریپت و CSS

قبل از اینکه یک مرورگر بتواند هر محتوایی را ارائه دهد، باید مارک HTML را در یک درخت DOM تجزیه کند. تجزیه کننده HTML اگر با صفحه‌های خارجی (<link rel = “stylesheet”>) یا برچسب‌های هم‌گام جاوااسکریپت (<script src = “main.js”>) روبرو شود، صبر می‌کند. اسکریپت‌ها و شیوه‌نامه‌ها هر دو منابع مسدود کننده هستند که FCP و در نتیجه LCP را به تأخیر می‌اندازند. برای سرعت بخشیدن به بارگذاری محتوای اصلی صفحه وب خود‌، JavaScript و CSS غیر مهم را به تعویق بیندازید.

کاهش زمان مسدودسازی CSS

با رعایت موارد زیر اطمینان حاصل کنید که حداقل مقدار CSS لازم، رندر را در سایت شما مسدود می‌کند:

CSS را کم کنید.

CSS غیر مهم را به تعویق بیندازید.
درون خطی CSS مهم.

کاهش CSS

برای خوانایی آسان‌تر، فایل‌های CSS می‌توانند شامل نویسه‌هایی مانند فاصله یا کامنت باشند. این کاراکترها برای مرورگر غیرضروری هستند و کوچک کردن این پرونده‌ها باعث می‌شود که حذف شوند. در نهایت‌، کاهش میزان مسدود کردن CSS همیشه باعث بهینه سازی بزرگترین عنصر محتوا (LCP) می‌شود.

تعویق CSS غیرمهم

برای یافتن CSS استفاده نشده در صفحه وب خود از تب Coverage در Chrome DevTools استفاده کنید.

برای بهینه سازی:

در صورت استفاده در صفحه جداگانه سایت خود ، CSS بدون استفاده را به طور کامل حذف کنید یا آن را به صفحه سبک دیگری منتقل کنید.
برای هر CSS که برای ارائه اولیه نیازی به آن نیست، از loadCSS برای بارگیری همزمان پرونده‌ها استفاده کنید، که از rel = “preload” و onload استفاده می‌شود.

<span style="font-size: 16px; color: #000000;">html <link rel="preload" href="stylesheet.css" as="style" onload="this.rel='stylesheet'"></span>

1	<span style="font-size: 16px; color: #000000;">html <link rel="preload" href="stylesheet.css" as="style" onload="this.rel='stylesheet'"></span>

درون‌خطی CSS

با قرار دادن CSS مهم در سربرگ فایل HTML آن را درون‌خطی کنید:

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

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

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

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

پلی‌فیلزهای استفاده‌نشده را به حداقل برسانید.

زمان طولانی بارگیری منابع

اگرچه افزایش زمان انسداد CSS یا JavaScript مستقیماً منجر به عملکرد بدتر می‌شود، اما زمان بارگیری برای بسیاری از انواع دیگر منابع نیز می‌تواند بر LCP تأثیر بگذارد.

انواع عناصر موثر بر LCP عبارتند از:

<img>.
<image> داخل عنصر <svg>.
<video>.
عنصری با تصویر پس زمینه که از طریق تابع url () بارگیری می‌شود (در مقابل گرادیان CSS).
عناصر سطح بلوک حاوی گره‌های متنی یا سایر عناصر متن سطح درون‌خطی.

مدت زمان لازم برای بارگیری این عناصر ، تأثیر مستقیمی بر LCP خواهد داشت. چند روش برای اطمینان از بارگیری سریع این پرونده‌ها وجود دارد:

بهینه‌سازی و فشرده‌سازی تصاویر.
منابع مهم را از قبل بارگیری کنید.
فشرده‌سازی فایل‌های متنی.
ارائه دارایی‌های مختلف بر اساس اتصال به شبکه (سرویس انطباقی).
دارایی‌ها را با استفاده از یک سرویس ورکر ذخیره کنید.

بهینه‌سازی و فشرده‌سازی تصاویر

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

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

در وهله اول استفاده نکردن از تصویر را در نظر بگیرید. اگر مربوط به محتوا نیست، آن را حذف کنید.
فشرده سازی تصاویر (به عنوان مثال با Imagemin).
تبدیل تصاویر به قالب‌های جدیدتر (JPEG 2000 ،JPEG XR یا WebP).
از تصاویر رسپانسیو استفاده کنید.
استفاده از CDN تصویر را در نظر بگیرید.

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

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

اگر می‌دانید یک منبع خاص باید اولویت‌بندی شود، از <link rel = “preload”> استفاده کنید تا آن را زودتر بارگیری کنید. بسیاری از منابع می‌توانند از قبل بارگیری شوند، اما ابتدا باید روی بارگیری دارایی های مهم مانند فونت‌ها، تصاویر یا فیلم‌های حجیم و CSS یا JavaScript تمرکز کنید.

<link rel="preload" as="script" href="script.js" />
<link rel="preload" as="style" href="style.css" />
<link rel="preload" as="image" href="img.png" />
<link rel="preload" as="video" href="vid.webm" type="video/webm" />
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin />

فایل‌های تکست را فشرده‌سازی کنید

الگوریتم‌های فشرده‌سازی، مانند Gzip و Brotli، می‌توانند اندازه فایل‌های متنی (HTML،CSS، JavaScript) را به میزان قابل‌توجهی کاهش دهند زیرا آن‌ها بین سرور و مرورگر منتقل می‌شوند. Gzip به طور موثر در همه مرورگرها پشتیبانی می‌شود و Brotli ، که حتی نتایج فشرده‌سازی بهتری را نیز فراهم می‌کند، تقریباً در همه مرورگرهای جدیدتر قابل استفاده است. با فشرده‌سازی منابع، زمان تحویل و زمان بارگذاری آن‌ها کاهش می‌یابد و در نتیجه LCP بهبود می‌یابد.

ابتدا بررسی کنید که آیا سرور شما از قبل فایل‌ها را به طور خودکار فشرده می‌کند یا خیر. بیشتر سیستم عامل‌های هاست، CDN ها و سرورهای معکوس پروکسی یا دارایی‌ها را به صورت پیش‌فرض فشرده‌سازی می‌کنند یا به شما امکان می‌دهند به راحتی آنها را پیکربندی کنید.
اگر می‌خواهید سرور خود را برای فشرده‌سازی فایل‌ها اصلاح کنید، استفاده از Brotli به جای gzip را در نظر بگیرید زیرا می‌تواند نسبت‌های فشرده‌سازی بهتری را فراهم کند.
هنگامی که یک الگوریتم فشرده‌سازی برای استفاده انتخاب کردید، دارایی‌ها را در زمان ساخت فشرده‌ کنید نه در هنگام ارسال. با این کار سربار سرور به حداقل می‌رسد و از تأخیر در هنگام درخواست به ویژه هنگام استفاده از نسبت‌های فشرده‌سازی بالا جلوگیری می‌کند.

سرو کردن متناسب داده

هنگام بارگیری منابعی که محتوای اصلی یک صفحه را تشکیل می‌دهند، بسته به شرایط و ضوابط کاربر، می‌توان دارایی‌های مختلف را ارسال کرد. این کار را می‌توان با استفاده از APIهای اطلاعات شبکه، حافظه دستگاه و HardwareConcurrency انجام داد. به عنوان مثال، می‌توانید برای سرعت اتصال کمتر از 4G، به جای فیلم، یک تصویر نمایش دهید:

if (navigator.connection && navigator.connection.effectiveType) {
  if (navigator.connection.effectiveType === '4g') {
    // Load video
  } else {
    // Load image
  }
}

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

if (navigator.connection.effectiveType === '4g') {

// Load video

} else {

// Load image

}

لیستی از ویژگی‌های مفیدی که می‌توانید استفاده کنید:

navigator.connection.effectiveType
navigator.connection.saveData
navigator.hardwareConcurrency
navigator.deviceMemory

کش کردن دارایی‌ها با سرویس‌ورکر

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

precaching منابع حیاتی با استفاده از سرویس‌ورکر می‌تواند زمان بارگیری آن‌ها را به میزان قابل‌توجهی کاهش دهد، خصوصاً برای کاربرانی که صفحه وب را با اتصال ضعیف‌تری بارگیری می‌کنند (یا حتی به صورت آفلاین به آن دسترسی دارند). کتابخانه‌هایی مانند Workbox می‌توانند روند به روزرسانی دارایی‌های منسوخ شده را آسان‌تر از نوشتن یک سرویس‌ورکر سفارشی کنند تا خودتان این کار را انجام دهید.

رندر سمت کاربر

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

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

هنگام ساخت یک سایت رندر در سمت کاربر، بهینه‌سازی‌های زیر را در نظر بگیرید:

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

استفاده از رندر سمت سرور

به حداقل رساندن مقدار جاوا اسکریپت همیشه باید اولین موضوعی باشد که در سایت‌هایی که در سمت کاربر رندر می شوند تمرکز کرد. با این حال، شما همچنین باید ترکیبی از رندر سمت سرور برای بهبود هرچه بیشتر LCP را در نظر داشته باشید.

این مفهوم با استفاده از سرور برای رندر اپلیکیشن به HTML کار می‌کند، جایی که مشتری سپس تمام JavaScript و داده‌های مورد نیاز را روی همان محتوا “hydrates” می‌کند. این کار می‌تواند با اطمینان از اینکه محتوای اصلی صفحه ابتدا در سرور ارائه می شود نه فقط در کلاینت، LCP را بهبود بخشد، اما چند اشکال وجود دارد:

حفظ اپلیکیشن رندر شده توسط JavaScript در سرور و کاربر می‌تواند پیچیدگی را افزایش دهد.
اجرای جاوا اسکریپت برای رندر یک فایل HTML در سرور همیشه باعث افزایش زمان پاسخ سرور (TTFB) در مقایسه با رندر فقط صفحات ثابت از سرور می‌شود.
یک صفحه رندر شده از سرور ممکن است به نظر برسد که می‌توان با آن تعامل کرد، اما تا زمانی که تمام JavaScript سمت کاربر را اجرا نکند، نمی‌تواند به هیچ ورودی کاربر پاسخ دهد. به طور خلاصه، می‌تواند Time to Interactive (TTI) را بدتر کند.

استفاده از پیش رندر

پیش رندر یک تکنیک جداگانه است که پیچیدگی کمتری نسبت به رندر سمت سرور دارد و همچنین روشی را برای بهبود LCP در برنامه شما ارائه می‌دهد.

پیش رندر، همچنان بر TTI تأثیر منفی می‌گذارد اما بر زمان پاسخگویی سرور تحت تأثیر رندر سمت سرور که هر صفحه را فقط پس از درخواست به صورت پویا ارائه می دهد، تأثیر نمی گذارد.

منبع:

https://web.dev/optimize-lcp/

ادامه مطلب