بزرگترین رنگ محتوایی چیست: توضیحی آسان


Largest Contentful Paint (LCP) یک معیار تجربه کاربر گوگل است که در سال 2021 در سیستم های رتبه بندی ادغام شده است.

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

Core Web Vitals به طور متناقضی وجود دارد، به طوری که Google راهنمایی هایی را ارائه می دهد که اهمیت آنها را برجسته می کند اما تأثیر آنها را بر رتبه بندی کم اهمیت می داند.

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

بزرگترین رنگ محتوایی چیست؟

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

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

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

LCP از معیارهای فرعی زیر تشکیل شده است:

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

در اینجا یک مقیاس آستانه برای مرجع شما آمده است:

آستانه های LCPآستانه های LCP

بیایید به معنای این معیارهای فرعی و چگونگی بهبود آن باشیم.

زمان تا اولین بایت (TTFB)

TTFB زمان پاسخگویی سرور است و مدت زمانی که مرورگر کاربر برای دریافت اولین بایت داده از سرور شما طول می کشد را اندازه گیری می کند. این شامل زمان جستجوی DNS، زمان پردازش درخواست‌ها توسط سرور و تغییر مسیرها می‌شود.

بهینه سازی TTFB می تواند به طور قابل توجهی زمان بارگذاری کلی را کاهش دهد و LCP را بهبود بخشد.

زمان پاسخگویی سرور تا حد زیادی به موارد زیر بستگی دارد:

  • پرس و جوهای پایگاه داده
  • حافظه پنهان CDN از دست می رود.
  • رندر سمت سرور ناکارآمد.
  • میزبانی.

بیایید هر کدام را مرور کنیم:

1. پرس و جوهای پایگاه داده

اگر زمان پاسخگویی شما زیاد است، سعی کنید منبع را شناسایی کنید.

به عنوان مثال، ممکن است به دلیل پرس و جوهای بهینه سازی ضعیف یا حجم بالای درخواست ها باشد که زمان پاسخگویی سرور را کند می کند. اگر پایگاه داده MySQL دارید، می توانید پرس و جوهای کند را ثبت کنید تا بفهمید کدام پرس و جو کند هستند.

اگر وب سایت وردپرسی دارید، می توانید از افزونه Query Monitor استفاده کنید تا ببینید پرس و جوهای SQL چقدر زمان می برد.

ابزارهای عالی دیگر Blackfire یا Newrelic هستند که به CMS یا پشته ای که استفاده می کنید بستگی ندارند، اما نیاز به نصب بر روی هاست/سرور شما دارند.

2. CDN Cache Misses

از دست دادن حافظه پنهان CDN زمانی رخ می دهد که منبع درخواستی در حافظه پنهان CDN یافت نشود و درخواست برای واکشی از سرور مبدا ارسال شود. این فرآیند زمان بیشتری می برد و منجر به افزایش تاخیر و زمان بارگذاری طولانی تر برای کاربر نهایی می شود.

معمولاً ارائه‌دهنده CDN شما گزارشی در مورد تعداد دفعات از دست دادن حافظه پنهان دارد.

نمونه ای از گزارش کش CDNنمونه ای از گزارش کش CDN

اگر درصد بالایی (> 10٪) از کمبود حافظه پنهان را مشاهده کردید، ممکن است لازم باشد با ارائه دهنده CDN یا پشتیبانی هاست خود تماس بگیرید در صورتی که میزبانی را با حافظه پنهان یکپارچه برای حل مشکل مدیریت کرده اید.

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

به عنوان مثال، ده ها دامنه هرزنامه به صفحات جستجوی داخلی شما با پرس و جوهای هرزنامه تصادفی مانند [/?q=甘肃代]، که در حافظه پنهان ذخیره نمی شوند زیرا عبارت جستجو هر بار متفاوت است. مشکل این است که Googlebot به طور تهاجمی آنها را می خزد، که ممکن است باعث افزایش زمان پاسخ سرور و از دست رفتن حافظه پنهان شود.

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

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

در اینجا یک مثال واقعی از کنسول جستجو از زمان پاسخ سرور بالا (TTFB) ناشی از از دست دادن حافظه پنهان است:

خزیدن 404 صفحه جستجو که زمان پاسخگویی سرور بالایی دارندخزیدن 404 صفحه جستجو که زمان پاسخگویی سرور بالایی دارند

3. رندر سمت سرور ناکارآمد

ممکن است اجزای خاصی در وب سایت خود داشته باشید که به API های شخص ثالث وابسته هستند.

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

تصور کنید وقتی درخواستی به سرور ارسال می شود، به اشتراک گذاری و API های GA4 متصل شویم. اجرای هر درخواست در حدود 300 تا 500 میلی‌ثانیه طول می‌کشد و به دلیل رندر ناکارآمد در سمت سرور، حدود 1000 میلی‌ثانیه تأخیر اضافه می‌کنیم. بنابراین، مطمئن شوید که باطن شما بهینه شده است.

4. میزبانی

توجه داشته باشید که میزبانی برای TTFB پایین بسیار مهم است. با انتخاب هاست مناسب، ممکن است بتوانید TTFB خود را دو تا سه برابر کاهش دهید.

میزبانی با CDN و کش ادغام شده در سیستم را انتخاب کنید. این به شما کمک می کند تا از خرید جداگانه CDN اجتناب کنید و در زمان نگهداری آن صرفه جویی کنید.

بنابراین، سرمایه گذاری در هاست مناسب نتیجه خواهد داد.

راهنمای دقیق تر را بخوانید:

اکنون، بیایید به سایر معیارهای ذکر شده در بالا که به LCP کمک می کنند نگاه کنیم.

تاخیر بارگذاری منابع

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

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

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

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

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

البته، حتی بهتر است که صفحات وب را طوری طراحی کنید که از تصاویر قهرمان یا لغزنده اجتناب کنید، زیرا این صفحات معمولاً ارزش افزوده ای ندارند و کاربران تمایل دارند از آنها عبور کنند، زیرا حواس پرتی را پرت می کنند.

یکی دیگر از عوامل مهم در تاخیر بارگذاری تغییر مسیر است.

اگر بک لینک های خارجی با تغییر مسیر دارید، کار زیادی نمی توانید انجام دهید. اما شما بر پیوندهای داخلی خود کنترل دارید، بنابراین سعی کنید پیوندهای داخلی را با تغییر مسیر پیدا کنید، معمولاً به دلیل از دست دادن اسلش های انتهایی، نسخه های غیر WWW یا URL های تغییر یافته، و آنها را با مقصد واقعی جایگزین کنید.

تعدادی از ابزارهای فنی سئو وجود دارد که می توانید از آنها برای خزیدن وب سایت خود و یافتن تغییر مسیرهایی که باید جایگزین شوند استفاده کنید.

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

مدت زمان بارگذاری منبع به زمان واقعی صرف شده برای دانلود منبع LCP اشاره دارد.

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

شما می توانید مدت زمان بار منبع را با پیاده سازی کاهش دهید:

  • فرمت WebP.
  • تصاویر با اندازه مناسب (اندازه ذاتی تصویر را با اندازه قابل مشاهده مطابقت دهید).
  • اولویت بندی بار
  • CDN.

تاخیر رندر عنصر

تأخیر رندر عنصر زمانی است که مرورگر برای پردازش و رندر عنصر LCP طول می کشد.

این معیار تحت تأثیر پیچیدگی HTML، CSS و جاوا اسکریپت شما قرار دارد.

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

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

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

مراقب این “Gotchas” گلزنی باشید

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

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

نحوه اندازه گیری امتیاز LCP

دو نوع ابزار امتیازدهی وجود دارد. اولی نامیده می شود ابزارهای میدانی، و دومی نامیده می شود ابزار آزمایشگاهی.

ابزارهای میدانی اندازه گیری های واقعی یک سایت هستند.

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

در اینجا روشی وجود دارد که می توانید منابع LCP را پیدا کنید و زمان نمایش آنها را از طریق آن اندازه گیری کنید DevTools > عملکرد گزارش:

می‌توانید در راهنمای عمیق ما در مورد نحوه اندازه‌گیری معیارهای CWV ​​بیشتر بخوانید، جایی که می‌توانید نحوه عیب‌یابی نه تنها LCP بلکه سایر معیارها را به طور کلی بیاموزید.

بهینه سازی LCP موضوع بسیار عمیق تری است

بهبود LCP گامی مهم در جهت بهبود CVW است، اما می‌تواند چالش‌برانگیزترین معیار CWV برای بهینه‌سازی باشد.

LCP از چندین لایه زیرمتری تشکیل شده است که هر یک به درک کامل برای بهینه سازی موثر نیاز دارند.

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

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

منابع بیشتر:


اعتبار تصویر ویژه: BestForBest/Shutterstock



منبع

مطالب مرتبط