گوگل نحوه رفع مشکلات LCP در Core Web Vitals را نشان داد

بارری پولارد از گوگل کروم ۵ نکته بهینه‌سازی برای LCP توضیح داد. هر سئوکاری باید این را بخواند.

بارری پولارد، توسعه‌دهنده متخصص عملکرد وب در گوگل کروم، توضیح داد که چگونه می‌توان دلایل واقعی نمره ضعیف Lowest Contentful Paint (LCP) را پیدا کرده و آنها را برطرف کرد.

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

برای LCP، بزرگ‌ترین عناصر محتوایی، عناصر HTML بلوک‌-سطح هستند که بیشترین فضای افقی را اشغال می‌کنند، مانند پاراگراف‌ها <p>، عناوین (H1 – H6)، و تصاویر <img> (به‌طور کلی اکثر عناصر HTML که فضای زیادی را در افق اشغال می‌کنند).

۱. بدانید که چه داده‌ای را بررسی می‌کنید بارری پولارد نوشت که یک اشتباه رایج در بین ناشران و سئوکارها پس از مشاهده نمره ضعیف LCP در PageSpeed Insights (PSI)، تلاش برای اشکال‌زدایی از آن با ابزار Lighthouse یا Chrome Dev Tools است.

پولارد توصیه می‌کند که از PSI خارج نشوید زیرا این ابزار چندین نکته برای درک مشکلات مربوط به عملکرد ضعیف LCP ارائه می‌دهد.

مهم است که بدانید PSI چه داده‌هایی به شما می‌دهد، به‌ویژه داده‌هایی که از گزارش تجربه کاربری کروم (CrUX) استخراج شده‌اند و از نمرات بازدیدکنندگان ناشناس کروم هستند. این داده‌ها به دو صورت هستند:

• داده‌های سطح URL
• داده‌های سطح مبدا

داده‌های سطح URL نمرات صفحه خاصی هستند که در حال اشکال‌زدایی است. داده‌های سطح مبدا نمرات تجمیع شده از کل سایت هستند.

PSI داده‌های سطح URL را نشان می‌دهد اگر ترافیک کافی به آن URL اندازه‌گیری شده باشد. در غیر این صورت، داده‌های سطح مبدا را نشان می‌دهد (نمره کلی سایت).

۲. بررسی نمره TTFB بارری توصیه می‌کند که نمره TTFB (زمان تا اولین بایت) را بررسی کنید زیرا به گفته او، “TTFB اولین چیزی است که برای صفحه شما رخ می‌دهد.”

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

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

پولارد می‌نویسد:

“یک TTFB کند به طور کلی به این معناست که یکی از دو مشکل زیر وجود دارد:

۱) ارسال درخواست به سرور شما خیلی زمان می‌برد. ۲) سرور شما خیلی دیر پاسخ می‌دهد.

اما تشخیص اینکه کدام مشکل است (و چرا!) ممکن است پیچیده باشد و دلایل مختلفی برای هر یک از این مشکلات وجود دارد.”

۳. مقایسه TTFB با آزمایش Lighthouse Lab پولارد توصیه می‌کند که آزمایش‌های Lighthouse Lab، به‌ویژه ارزیابی “زمان پاسخ‌دهی اولیه سرور” را انجام دهید. هدف این است که بررسی کنید آیا مشکل TTFB قابل تکرار است تا احتمال اینکه مقادیر PSI سریع‌تر از آنچه که کاربران واقعی تجربه می‌کنند نشان داده شود را رد کنید.

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

۴. نکته متخصص: چگونه بفهمید که آیا CDN مشکلی را پنهان کرده است پولارد نکته خوبی در مورد شبکه‌های تحویل محتوا (CDN) مانند Cloudflare ارائه داد. CDN نسخه‌ای از صفحه وب را در مراکز داده خود ذخیره می‌کند که باعث تسریع در تحویل صفحات وب می‌شود، اما همچنین می‌تواند مشکلات سطح سرور را پنهان کند.

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

پولارد پیشنهاد می‌کند که برای دور زدن کش CDN، آزمایشات زیر را انجام دهید:

• آزمایش صفحه کند با افزودن پارامتر URL (مانند افزودن “?XYZ” به انتهای URL).
• آزمایش صفحه‌ای که معمولاً درخواست نمی‌شود.

او همچنین ابزاری را معرفی کرد که می‌تواند برای آزمایش کشورهای خاص استفاده شود.

این نکات می‌توانند کمک کنند که شما بتوانید به درستی عملکرد LCP را تحلیل کنید و آن را بهبود دهید.

۵. رفع مشکلات قابل تکرار

پولارد بحث خود را با این نکته به پایان رساند که یک مشکل تنها زمانی قابل حل است که تأیید شود که مشکل قابل تکرار است.

او توصیه کرد:

“برای مشکلات سرور، آیا سرور قدرت کافی ندارد؟

یا کد پیچیده/غیرموثر است؟

یا پایگاه‌داده نیاز به بهینه‌سازی دارد؟

برای اتصالات کند از برخی مکان‌ها آیا به CDN نیاز دارید؟

یا باید بررسی کنید که چرا ترافیک زیادی از آنجا می‌آید (آیا کمپین تبلیغاتی است؟)

اگر هیچ‌کدام از این‌ها واضح نبود، ممکن است مشکل از ریدایرکت‌ها باشد، به‌ویژه از تبلیغات. ریدایرکت‌ها می‌توانند حدود ۰.۵ ثانیه به TTFB اضافه کنند – برای هر ریدایرکت!

سعی کنید ریدایرکت‌ها را به حداقل برسانید:

• از URL نهایی صحیح استفاده کنید تا نیازی به ریدایرکت به www یا https نباشد.
• از استفاده از خدمات کوتاه‌کننده URL چندگانه خودداری کنید.”

مربوط: Core Web Vitals: راهنمای کامل

نتایج‌گیری‌ها: چگونه برای Largest Contentful Paint بهینه‌سازی کنیم بارری پولارد از گوگل کروم پنج نکته مهم ارائه داد:

۱. داده‌های PageSpeed Insights (PSI) ممکن است سرنخ‌هایی برای اشکال‌زدایی مشکلات LCP ارائه دهند، همچنین نکات دیگری که در این مقاله توضیح داده شده به درک بهتر داده‌ها کمک می‌کند.

۲. داده‌های TTFB (زمان تا اولین بایت) از PSI ممکن است نشان دهد که چرا یک صفحه نمرات ضعیف LCP دارد.

۳. آزمایش‌های Lighthouse Lab برای اشکال‌زدایی مفید هستند زیرا نتایج آنها قابل تکرار هستند. نتایج قابل تکرار برای شناسایی دقیق منبع مشکلات LCP کلیدی است که سپس می‌توانند به اعمال راه‌حل‌های درست منجر شوند.

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

۵. بارری شش علت بالقوه برای نمرات ضعیف LCP ذکر کرد:

• عملکرد سرور
• ریدایرکت‌ها
• کد
• پایگاه‌داده
• اتصالات کند به‌ویژه به دلیل موقعیت جغرافیایی
• اتصالات کند از مناطق خاص که به دلایلی مانند کمپین‌های تبلیغاتی ایجاد شده‌اند.
• talahost.com