با این کار جزو نفرات اول دوره GA4 منتوریکس هستید. با شما در ارتباط هستیم :)
  • 1
  • 2
  • 3
کتاب الکترونیکی رایگان

برو مرحله بعدی
  • 1
  • 2
  • 3
دوست عزیز
برای ارسال کتاب به ایمیل و شماره موبایل شما نیاز داریم.
برو مرحله آخر
  • 1
  • 2
  • 3
کتاب شما آماده است، دکمه دریافت لینک دانلود را بزنید.

لینک دانلود به شما ایمیل و پیامک شد.

بزرگ ‌ترین ترسیم محتوایی صفحه یا LCP چیست؟

تحریریه منتوریکس
تحریریه منتوریکس
23:21، 1400/01/28
بزرگ ‌ترین ترسیم محتوایی صفحه یا LCP چیست؟
1 رای    میانگین 5/5
لطفا شما هم امتیاز بدهید!

بزرگ ‌ترین ترسیم محتوایی صفحه یا LCP چیست؟


همانطور که در مطلب «معیارهای اصلی web vitals کدامند؟» دیدیم، LCP هم یک از معیارهای اساسی جدیدترین فاکتور سئو و رتبه‌بندی سایت‌ها یعنی core web vitals است. بزرگ‌ترین ترسیم محتوایی صفحه یا به اختصار LCP یک معیار مهم و کاربر محور برای اندازه‌گیری سرعت بارگذاری صفحه است. زیرا وقتی محتوای اصلی صفحه در حال بارگذاری است، نقطه‌ای در جدول زمانی (تایم لاین) بارگذاری صفحه را مشخص می‌کند؛ یک LCP سریع به کاربر این اطمینان را می‌دهد که آن صفحه حاوی محتوای مفید است.

آنچه در این مطلب می‌خوانید:

  1. بزرگ ترین ترسیم محتوایی صفحه (LCP) چیست؟
  2. چگونه اندازه‌ی یک المان مشخص می‌شود؟
  3. چه زمانی بزرگ ترین ترسیم محتوایی صفحه گزارش می‌شود؟
  4. زمان بارگذاری در برابر زمان رندر
  5. تغییرات اندازه و چیدمان المان‌ها چگونه مدیریت می‌شود؟
  6. چگونگی محاسبه‌ی بزرگ ترین ترسیم محتوایی صفحه LCP
  7. اندازه‌گیری LCP در جاوا اسکریپت
  8. چه اتفاقی می‌افتد اگر بزرگ‌ترین المان، مهم‌ترین المان نباشد؟
  9. چگونه LCP را بهبود دهیم؟
  10. گزارش تغییرات
  11. سخن پایانی


به لحاظ تاریخی،‌ اندازه‌گیری سرعت بارگذاری محتوای اصلی صفحات وب و به نمایش درآمدن آن‌ها برای کاربران همیشه برای توسعه‌دهندگان وب یک چالش بوده است.
معیارهای قدیمی مانند بارگذاری یا DOMContentLoaded خوب نیستند. زیرا لزوما با آنچه کاربران در صفحه وب مشاهده می‌کنند مطابقت ندارند و معیارهای جدیدتر عملکردی کاربر محور مانند اولین ترسیم محتوایی صفحه (FCP) نیز فقط ابتدای تجربه‌ی بارگذاری را ثبت می‌کند. اگر صفحه یک صفحه اسپلش یا نشانگر بارگذاری را به نمایش درآورد، این لحظه برای کاربر اهمیت زیادی ندارد.
در گذشته، ما معیارهای عملکردی مانند اولین ترسیم معنادار (FMP) و شاخص سرعت (SI) (که هر دو در Lighthouse در دسترس هستند) را برای ثبت تجربه‌های بارگذاری بعد از ترسیم اولیه توصیه می‌کردیم اما این معیارها پیچیده هستند، توضیح آن‌ها دشوار است و اغلب نتیجه‌ی درستی ندارند. به این معنا که زمان بارگذاری محتوای اصلی یک صفحه را مشخص نمی‌کنند.
گاهی ‌اوقات، یک معیار ساده‌تر بهتر است. بر اساس مباحث مطرح شده در گروه کاری عملکردی وب W3C و تحقیقات انجام شده در گوگل، ما دریافتیم که یک روش دقیق‌تر برای اندازه‌گیزی زمان بارگذاری محتوای اصلی یک صفحه این است که زمان رندر شدن بزرگ‌ترین المان یا عنصر آن صفحه را بررسی کنیم.

بیشتر بخوانید: core web vitals چیست؟

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

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

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

امتیاز LCP خوب چه امتیازی است؟

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

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

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

  • img المان‌ها
  • image المان‌های داخل المان svg
  • video المان‌ها (تصویر پوستر استفاده شده است)
  • المانی که تصویر پس زمینه آن از طریق تابع url بارگذاری می‌شود (در مقابل گرادیان CSS)
  • المان‌های Block-level شامل text nodes یا سایر زیرمجموعه‌های عناصر inline-level text

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

چگونه اندازه‌ی یک المان مشخص می‌شود؟

چگونه اندازه‌ی یک المان مشخص می‌شود؟

اندازه‌ی یک المان گزارش شده برای بزرگ‌ترین ترسیم محتوایی صفحه معمولا اندازه‌ای است که در نمایشگر برای کاربر قابل رویت و مشاهده باشد. اگر المان به خارج از صفحه نمایشگر کشیده شود یا بخشی از یک المان بریده شده باشد و قابل رویت نباشد، این بخش‌های بریده شده در اندازه‌ی المان به حساب نمی‌آیند.
برای المان‌های تصویری که از اندازه‌ اصلی خود تغییر اندازه داده‌اند، اندازه‌ای که گزارش می‌شود یا اندازه‌ی قابل رویت در نمایشگر و یا اندازه‌ی اصلی است، با توجه به این که کدام کوچک‌تر است. به عنوان مثال، برای تصاویری که نسبت به اندازه‌ی اصلی خود کوچک شده‌اند فقط اندازه‌ای که با آن به نمایش در می‌آیند گزارش می‌شود در حالی که تصاویری که کشیده یا بزرگ‌تر شده‌اند، تنها با اندازه‌ی اصلی خود گزارش می‌شوند.
برای المان‌های متنی، تنها اندازه‌ی text nodes در نظر گرفته می‌شود (کوچک‌ترین مستطیل که شامل همه‌ی گره‌های متنی است).
برای تمام المان‌ها، هرگونه حاشیه، لایه‌گذاری یا مرزگذاری با استفاده از CSS در نظر گرفته نمی‌شود.
تعیین این که کدام text nodes به کدام المان‌های تعلق دارند، گاهی اوقات پیچیده است خصوصا برای زیرمجموعه‌های عناصر inline-level text ساده و المان‌های سطح بلوکی. نکته کلیدی این است که هر text nodes به نزدیک‌ترین المان جد سطح بلوکی خود تعلق دارد. به عبارت دیگر، هر گره متنی به المانی تعلق دارد که بلوک دربرگیرنده آن را تولید می‌کند.

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

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

در اغلب موارد، صفحات وب به صورت مرحله‌ای بارگذاری می‌شود و در نتیجه این امکان وجود دارد که بزرگ‌ترین المان درون صفحه تغییر کند.
به منظور مدیریت این تغییر احتمالی، مرورگر به محض این که اولین فریم را ترسیم می‌کند، یک PerformanceEntry از نوع بزرگ‌ترین ترسیم محتوایی صفحه را ارسال می‌کند تا بزرگ‌ترین ترسیم محتوایی صفحه قابل شناسایی باشد. اما بعد از رندر کردن فریم‌های متوالی، به محض این که تغییری در بزرگ‌ترین المان محتوایی ایجاد شود، یک PerformanceEntry جدیدتر را ارسال می‌کند.
به عنوان مثال، در صفحه‌ای حاوی متن و یک تصویر شاخص، مرورگر به احتمال زیاد ابتدا فقط متن را رندر می‌کند؛ در این زمان مرورگر یک ورودی بزرگ‌ترین ترسیم محتوایی صفحه را ارسال می‌کند که ویژگی المان آن به p یا h1 اشاره دارد.
سپس، به محض این که بارگذاری تصویر شاخص به پایان رسید، دومین ورودی از بزرگ‌ترین ترسیم محتوایی صفحه ارسال خواهد شد و ویژگی المان آن به img اشاره خواهد کرد.
توجه به این نکته حائز اهمیت است که یک المان تنها در صورتی به عنوان بزرگ‌ترین المان محتوایی در نظر گرفته می‌شود که رندر شده و برای کاربر قابل رویت باشد.
تصاویری که هنوز بارگذاری نشده‌اند را نمی‌توان رندر شده در نظر گرفت. همچنین، گره‌های متنی که از فونت‌های وب در بازه‌ی بلوک فونت استفاده می‌کنند را هم نمی‌توان در نظر گرفت. در چنین مواردی، یک المان کوچک‌تر ممکن است به عنوان بزرگ‌ترین المان محتوایی گزارش شود اما به محض این که رندر المان بزرگ‌تر به پایان رسد و کامل شود، یک PerformanceEntry جدید ارسال خواهد شد.
علاوه بر تاخیر در بارگذاری تصاویر و فونت‌ها، این امکان وجود دارد که با قرار دادن یک محتوای جدید المان‌های جدیدی به DOM اضافه شوند. اگر هر یک از این المان‌های جدید بزرگ‌تر از بزرگ‌ترین المان محتوایی پیشین باشند، یک PerformanceEntry جدید ارسال خواهد شد.
در صورتی که المانی که در حال حاضر بزرگ‌ترین المان محتوایی صفحه است از نمایشگر حذف شود (یا حتی از DOM حذف شود)، همچنان بزرگ‌ترین المان محتوایی باقی خواهد ماند تا وقتی که المان بزرگ‌تری رندر شود.
قبل از معرفی کروم 88، المان‌های حذف شده به عنوان بزرگ‌ترین ترسیم محتوایی صفحه در نظر گرفته نمی‌شدند و حذف المان فعلی موجب ارسال یک ورودی جدید به عنوان بزرگ‌ترین ترسیم محتوایی صفحه می‌شد. با این وجود، با توجه به الگوهای UI معروف مانند image carousel که اغلب حاوی المان‌های DOM حذف شده بودند، این معیار به گونه‌ای بروزرسانی شد تا تجربه‌ی کاربر را به طور دقیق منعکس کند.
به محض این که تعامل کاربر با صفحه وب آغاز شود (با استفاده از ضربه زدن، اسکرول کردن یا فشار دادن یک دکمه)، مرورگر گزارش ورودی‌های جدید را متوقف خواهد کرد زیرا تعامل کاربر معمولا آنچه مشاهده می‌کند را تغییر می‌دهد (که البته بیشتر در مورد اسکرول کردن صادق است).
برای اهداف تحلیلی، شما باید آخرین PerformanceEntry ارسال شده را به سرویس تحلیل خود گزارش دهید.

توجه

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

زمان بارگذاری در برابر زمان رندر

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

تغییرات اندازه و چیدمان المان‌ها چگونه مدیریت می‌شود؟

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

مثال‌ها

در ادامه مثال‌هایی از بزرگ‌ترین ترسیم محتوایی صفحه در چند وبسایت پرطرفدار را با هم بررسی می‌کنیم:

تغییرات اندازه و چیدمان المان‌ها چگونه مدیریت می‌شود؟

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

تغییرات اندازه و چیدمان المان‌ها چگونه مدیریت می‌شود؟

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

چگونگی محاسبه‌ی بزرگ ترین ترسیم محتوایی صفحه LCP

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

ابزارهای میدانی (Field)

ابزارهای آزمایشگاهی (Lab)

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

به منظور اندازه‌گیری LCP در جاوا اسکریپت شما می‌توانید از API بزرگ‌ترین ترسیم محتوایی صفحه استفاده کنید. مثال ارائه شده نشان می‌دهد که چگونه می‌توانید یک PerformanceObserver ایجاد کنید که به دنبال ورودی‌های largest-contentful-paint می‌گردد، آن‌ها را با هم جمع کرده و وارد کنسول می‌کند:

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

توجه

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

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

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

به جای این که خودتان را با این مسائل درگیر کنید و بخواهید آن‌ها را به خاطر بسپارید، توسعه‌دهندگان می‌توانند از کتابخانه‌ی web-vitals جاوا اسکریپت برای محاسبه‌ی LCP استفاده کنند که همه‌ی موارد مذکور را شامل می‌شود:

اندازه‌گیری LCP در جاوا اسکریپت
برای مطالعه‌ی یک مثال کامل از چگونگی محاسبه‌ی LCP در جاوا اسکریپت می‌توانید به کد منبع getCLS مراجعه کنید.
در برخی موارد (مانند iframes متقاطع)، اندازه‌گیری LCP در جاوا اسکریپت امکان‌پذیر نیست. برای جزئیات بیشتر به بخش محدودیت‌ها در کتابخانه‌ی web-vitals رجوع کنید.

چه اتفاقی می‌افتد اگر بزرگ‌ترین المان، مهم‌ترین المان نباشد؟

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

چگونه LCP را بهبود دهیم؟

LCP عمدتا تحت تاثیر چهار فاکتور قرار می‌گیرد:

  • زمان پاسخ سرور کند
  • مشکل Render-blocking در جاوا اسکریپت و CSS
  • زمان بارگذاری منابع
  • رندر کردن Client-Side

به منظور کسب اطلاعات بیشتر در مورد چگونگی بهینه کردن LCP به لینک‌  Optimize LCP مراجعه کنید. برای راهنمایی‌های بیشتر در زمینه‌ی تکنیک‌های عملکردی مجزا که می‌توانند موجب بهبود LCP شوند،‌ به لینک‌های زیر مراجعه کنید:

گزارش تغییرات

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

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

سخن پایانی

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

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

تحریریه منتوریکس
تحریریه منتوریکس

این مطلب توسط اعضای تیم منتوریکس تهیه و گردآوری شده است.

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

ما نظرات و سوالات شما را با دقت می‌خوانیم و پاسخ می‌دهیم
نظرات تعداد کاراکترهای باقی مانده: 300
انصراف