LCP چیست؟ راه های بهبود LCP یا Largest Contentful Paint

امان از این سه‌حرفی‌های اختصاری که حرف‌های زیادی هم برای گفتن دارند! LCP از فاکتورهای اصلی پرفورمنس وب‌سایت، یکی از همین سه‌حرفی‌هاست که اتفاقاً جزییات زیادی دارد. در این مقاله تلاش کرده‌ایم از چیستی تا بهینه‌سازی فاکتور LCP سایت، هرچیزی دربارهٔ Largest Contentful Paint را به زبان ساده توضیح بدهیم. 

LCP چیست؟

سه حرف LCP سرواژهٔ عبارت Largest Contentful Paint  یا به فارسی «زمان رنگ بزرگ‌ترین محتوا» هستند. ساده‌تر بگوییم، مدت زمانی که طول می‌کشد بزرگ‌ترین المان در هر صفحهٔ وب رندر شود را با شاخص عددی LCP نشان می‌دهیم. گوگل این فاکتور را برای تجربهٔ کاربر و پرفورمنس درنظر می‌گیرد.

عدد خوب برای LCP چیست؟

اگر معیار عددی خوب را ابزارهای گوگل (به‌طور خاص گوگل سرچ کنسول و Page Speed Insights) در نظر بگیریم، LCP زیر ۲.۵ ثانیه خوب است. گوگل عدد LCP بالاتر از ۴ ثانیه را با عنوان Needs Improvement یا «نیازمند بهبود» نمایش می‌دهد.

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

چرا LCP در سئو مهم است؟

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

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

هرچه سایت شما سریع‌تر لود شود، کاربران راضی‌تر هستند. این لود سریع با سه‌فاکتور LCP و CLS و FID که به معیارهای Core Web Vitals یا فاکتورهای حیاتی وب مشهور هستند، سنجیده می‌شود.

پس می‌توان گفت که LCP بهتر یعنی پرفورمنس بالاتر و در نتیجه امتیاز بالاتر در رتبه‌بندی‌های موتور جستجو!

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

اگر نگران لود شدن کدهای سنگین صفحات خود شده‌اید، بگذارید همین‌ ابتدا نگرانی‌های اضافی را از بین ببریم. گوگل در امتیاز LCP صرفاً المان‌هایی را در نظر می‌گیرد که برای کاربر قابل‌ دیدن باشند. یعنی بلوک متنی، تصویر، کاور ویدئو یا برخی از کدهای HTML (مثل تگ‌ها یا سایر بلوک‌های قابل مشاهده) و برخی موارد خاص در CSS می‌توانند به‌عنوان بزرگ‌ترین المان محتوا شناسایی شوند. 

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

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

برای محاسبه اندازه بزرگ‌ترین المان محتوایی به‌طور کلی این قواعد درنظرگرفته می‌شود:

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

مدت زمانی که این محتوا در انتظار لود و نمایش به‌کاربر بماند، مدت زمان ‌‌‌LCP ‌است. 

چطور یک المان به عنوان ‌‌LCP تشخیص داده می‌شود؟

مرورگرها برای تشخیص بزرگ‌ترین المان محتوا، Performance Entry را به صفحه می‌فرستند. سپس به‌محض رندر شدن اولین فریم بزرگ نسبت به سایرین، آن را به عنوان بزرگ‌ترین المان محتوا در نظر می‌گیرند. اگر در ادامهٔ رندرینگ، فریم بزرگ‌تری پیدا شود، با فریم اول جایگزین می‌شود. 

مثلاً اگر hero سایت شما پیش از هرچیز با H1 و پاراگراف متنی شروع شده باشد، همین المان‌های متنی بزرگ‌ترین عنصر تشخیص داده می‌شوند. اگر حین رندر کمی پایین‌تر تصویر بزرگ‌تری درکار باشد، حالا تصویر بزرگ‌ترین المان صفحه در نظر گرفته می‌شود. 

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

حتی در صورتی که بزرگ‌ترین المان از viewport  یا DOM حذف شود، تا پیداشدن المان‌ بزرگ‌تر هم‌چنان به‌عنوان LCP در نظر گرفته می‌شود. 

تفاوت زمان بارگذاری و زمان رندرینگ چیست؟

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

حالا ارتباط این دو تعریف با LCP چیست؟

در تعریف LCP گفتیم که زمان رندرینگ بزرگ‌ترین المان محتواست. بنابراین زمان رندر شدن برای تعیین امتیاز LCP در اولویت است. اما اگر در هدر صفحه Timing-Allow-Origin وجود نداشته باشد، زمان رندر در نظرگرفته نمی‌شود.

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

مثال‌هایی برای درک بهتر مفهوم LCP

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

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

آموزش کامل بهینه سازی فاکتور LCP سایت

خیلی‌خب! به‌اندازه‌ٔ کافی دربارهٔ معیار LCP می‌دانیم که بتوانیم وارد بهینه‌سازی فاکتور LCP سایت شویم. پس آستین‌ها را بالا بزنید و آماده شوید که تأخیر رندرینگ و لود را با آموزش‌های زیر بهینه‌سازی کنید. 

۱. کاهش تأخیر در لود منابع 

در مرحلهٔ اول با این هدف فعالیت می‌کنیم که مطمئن شویم منابع LCP هرچه سریع‌تر بارگذاری شوند. از لحاظ تئوری، اولین منبع بلافاصله بعد از TTFB (دریافت اولین بایت داده از وب‌سرور) شروع به بارگذاری می‌کند. اما درواقع بین دریافت اولین بایت داده از وب‌سرور و شروع لود منابع توسط مرورگر هم تأخیر وجود دارد.

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

به طور کلی، دو عامل بر سرعت بارگیری یک منبع LCP تأثیر می‌گذارد:

• منبع چه زمانی شناسایی می‌شود؟

• منبع چه اولویتی دارد؟

بهینه سازی زمان شناسایی منبع LCP

برای این که مطمئن شوید منبع LCP صفحهٔ شما در کوتاه‌ترین زمان ممکن لود می‌شود، بایستی منبع در HTML برای اسکنر preloading قابل شناسایی باشد. مثلاً المان‌های زیر به‌خوبی برای Preloading قابل شناسایی هستند:

• المان تصویری با ویژگی‌های src یا srcset آن در نشانه‌گذاری اولیه HTML

• المان LCP در تصویر پس‌زمینه CSS که از طریق تگ <link rel=”preload”> در HTML در هدر معرفی شده است.

• یک node متنی که برای رندرینگ نیاز به یک فونت وب دارد که از طریق <link rel=”preload”> در HTML در هدر معرفی شده است.

و در مقابل موارد زیر برای اسکنر قابل شناسایی نیستند:

• اگر عنصر LCP یک <img> باشد که به صورت دینامیک از طریق جاوا اسکریپت به صفحه اضافه می‌شود.

• اگر عنصر LCP با یک کتابخانه جاوا اسکریپت بارگذاری می‌شود که ویژگی های src یا srcset خود را پنهان می‌کند (معمولاً به‌صورت data-src یا data-srcset).

• عنصر LCP به یک تصویر پس زمینه CSS نیاز داشته باشد.

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

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

بهینه‌سازی اولویت لود منابع

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

مثلاً اگر برای یک تصویر Lazyloading را تنظیم کرده باشید، می‌توانید لود تصویر  LCP را با HTML به تأخیر بیندازید. Lazyloading به این معناست که منبع تا زمانی که نوبت اسکرول به فریم موردنظر نرسد، لود را شروع نمی‌کند تا کاربران سرعت بالاتری در لود منابع ضروری را تجربه کنند.

هشدار: هرگز تصویر LCP خود را با Lazyloading بارگذاری نکنید، زیرا این کار همیشه به تاخیر بارگذاری منابع غیرضروری منجر می‌شود و تأثیر منفی بر LCP خواهد داشت.

حتی بدون ویژگی‌ بارگذاری تنبل‌ هم تصاویر معمولاً در اولویت لود مرورگر نیستند. بنابراین ایدهٔ خوبی است که با ویژگی‌ fetchpriority برای منبع، اولویت آن را به مرورگر نشان دهید. نمونه‌ای از قرار دادن Fetchpriority در اولویت:

<img fetchpriority=”high” src=”/path/to/hero-image.webp”>

منابعی که حدس می‌زنید LCP صفحه‌تان هستند را روی fetchpriority=”high” روی المان تصویر تنظیم کنید. اما یادتان باشد که برای بیش از یکی دو تصویر این کار را انجام ندهید. در غیر این صورت سیگنال اولویتی که به مرورگر می‌فرستید، کلاً بی‌معنا می‌شود.

در مقابل می‌توانید اولویت تصاویری که می‌دانید در ابتدای صفحه قرار ندارند را به شکل نمونه پایین بیاورید:

<img fetchpriority=”low” src=”/path/to/carousel-slide-3.webp”>

پس از بهینه‌سازی اولویت‌های لود منابع، پهنای باند شما به شکل بسیار بهتری مصرف می‌شود. ترتیب لود المان‌ها بعد از بهینه‌سازی باید چیزی شبیه به تصویر زیر باشد:

۲. کاهش تأخیر رندر المان اصلی

هدف بهینه‌سازی‌های این مرحله این است که مطمئن شویم المان LCP می‌تواند بلافاصله پس از لود منبع، رندر شود. اصلی‌ترین موانع این هدف، مسدود شدن رندر به یکی از دلایل زیر است:

۱. رندر کل صفحه به‌دلیل لود شدن همزمان شیوه‌نامه‌ها و اسکریپت‌ها در <head> متوقف شده‌ است.

۲. لود شدن منبع LCP تمام شده اما المان LCP هنوز به DOM اضافه نشده و در انتظار یک کد جاوا اسکریپت است.

۳. المان  LCP توسط برخی کدهای دیگر (مثل کتابخانهء تست A/B) پنهان می‌شود.

۴. رشتهٔ اصلی به دلیل تسک‌های طولانی مسدود شده و رندرینگ تنها پس از تکمیل تسک رندر صورت می‌گیرد.

حالا به‌هردلیلی که در دام Render-blocking ها افتاده باشید، با روش‌های بخش بعدی می‌توانید آن‌ها را برطرف کنید.

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

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

• برای جلوگیری از درخواست‌های اضافی شبکه، استایل‌شیت را در به‌صورت خطی ( inline) HTML قرار بدهید.

• اندازهٔ استایل‌شیت را کاهش دهید.

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

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

برای کاهش اندازه استایل‌شیت می‌توانید موارد زیر را اجرا کنید:

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

 

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

 CSS .۲های غیرضروری را به تعویق بیندازید

استایل‌شیت را به بخش‌های کوچک‌تر تقسیم کنید. مواردی که برای لود اولیهٔ صفحه ضروری هستند را نگه‌دارید. موارد غیرضروری را با ویژگی lazyload  به تأخیر بیندازید.

  CSS .۳‌ها را فشرده‌سازی کنید

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

 ۴. رندربلاک‌های جاوا اسکریپت را به‌تعویق انداخته یا اینلاین کنید 

می‌شود گفت هرگز لازم نیست اسکریپت‌های همزمان (اسکریپت‌های بدون ویژگی‌های async یا defer) به <head> صفحات خود اضافه کنید. انجام این کار تقریباً همیشه نتیجه منفی روی پرفورمنس دارد.

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

⛔ هرگز در این بهینه‌سازی جاوا اسکریپت اعمال نکنید	✅در این بهینه‌سازی جاوا اسکریپت اعمال کنید
<head>   <script src=”/path/to/main.js”></script> </head>	<head>   <script>     // Inline script contents directly in the HTML.     // IMPORTANT: only do this for very small scripts.   </script> </head>

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

رندر سمت سرور (SSR) برنامهٔ سمت کاربران را روی سرور اجرا می‌کند و به‌ درخواست‌های سند HTML پاسخ می‌دهد. ‌استفاده از SSR برای بهینه‌سازی LCP دو مزیت دارد:

• منابع تصویری شما از HTML قابل شناسایی خواهند بود (همانطور که در مرحله ۱ توضیح دادیم).

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

تنها نقطه ضعف SSR این است که به زمان پردازش سرور اضافی نیاز دارد. این یعنی می‌تواند TTFB شما را غیربهینه کند. اما در مجموع این کار ارزش‌اش را دارد چرا که زمان پردازش سرور در کنترل شماست.

SSG هم چیزی مشابه SSR است اما برای ایجاد سایت استاتیک‌. یعنی فرآیند ایجاد صفحات به‌جای درخواست صفحات HTML طی می‌شود. بنابراین اگر Prerendering با معماری سایت شما سازگاری دارد، SSG بهترین راه‌کار برای بهبود پرفورمنس است.   

تقسیم تسک‌های طولانی

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

امروزه تمامی مرورگرها تصاویر را در رشتهٔ اصلی رندر می‌کنند. این یعنی هر چیزی که thread اصلی را بلاک کند می‌تواند باعث تأخیر رندر المان شود. 

۳. کاهش زمان بارگیری منبع

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

۱. کاهش حجم منابع

۲. کوتاه‌کردن مسیر منبع

۳. کاهش رقابت برای پهنای باند شبکه

۴. حذف کامل زمان شبکه

کاهش اندازه منبع

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

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

 

در مقاله بهینه‌سازی تصاویر به‌طور کامل دربارهٔ این‌ راه‌کارها صحبت کرده‌ایم. در صورت نیاز می‌توانید به این مقاله مراجعه کنید.

کاهش مسافتی که منبع باید طی کند

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

کاهش رقابت برای پهنای باند شبکه

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

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

حذف کامل زمان شبکه

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

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

در نهایت اگر منبع LCP شما بزرگ نیست، منطقی است که منابع را به‌عنوان URL داده درج کنید تا درخواست‌های اضافی شبکه حذف شوند. حواستان باشد که این کار می‌تواند باعث بروز ارور شود. چرا که منابع نمی‌توانند کَش شوند و ممکن است به‌دلیل هزینهٔ مرزگشایی اضافی باعث تأخیرهای طولانی‌تر در رندر شود.

۴.  کاهش زمان  TTFB

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

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

بررسی نتیجه را فراموش نکنید

 در این مطلب به سوال LCP چیست پاسخ دادیم و روش‌های بهینه‌سازی largest content painfull را با تمرکز بر روی بهبود پرفورمنس سایت توضیح دادیم. از حالا به‌بعد لازم است نتیجهٔ اقدامات خود را بررسی کنید و این فاکتور حیاتی‌وب را زیرنظر بگیرید. برای مانیتورینگ LCP می‌توانید از ابزارهای گوگل مثل Lighthouse ،PageSpeed Insights ،Chrome DevTools و حتی سرچ کنسول به‌صورت رایگان استفاده کنید. در صورتی که بخواهید به‌ داده‌هایی جز داده‌های گوگل استناد کنید، ابزار WebPageTest نیز گزینهٔ‌ مناسبی است. در صورتی که تمام سوالات شما دربارهٔ  LCP در این مطلب پاسخ داده نشده است یا سوالاتی تازه‌ای در ذهن‌تان ایجاد شده‌، از بخش نظرات زیر همین پست با ما درمیان بگذارید و پاسخ بگیرید. 

---

سوالات پرتکرار 

---

۱. LCP چیست؟

واژه LCP  اختصاری از عبارت Largest Contentful Paint است که مدت زمانی که طول می‌کشد بزرگ‌ترین المان محتوایی صفحه لود شود را اندازه می‌گیرد. 

۲. بهینه‌سازی LCP از چه طریقی انجام می‌شود؟

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

۳. چه اندازه‌ای برای LCP خوب در نظر گرفته می‌شود؟ 

طبق نظر گوگل LCP زیر ۲.۵ ثانیه خوب و بالاتر از ۴ ثانیه ضعیف و هر عددی میان این دو نیازمند بهبود است.