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

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

بزرگترین رنگ محتوایی (LCP)

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

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

، عناوین (H1 – H6) و تصاویر (اصولا اکثر عناصر HTML که فضای افقی زیادی را اشغال می کنند).

1. بدانید به چه داده هایی نگاه می کنید

بری پولارد نوشت که اشتباه رایجی که ناشران و سئوکاران پس از مشاهده اینکه PageSpeed ​​Insights (PSI) یک صفحه را برای امتیاز LCP ضعیف پرچم‌گذاری می‌کند، مرتکب می‌شوند این است که مشکل را در ابزار Lighthouse یا از طریق Chrome Dev Tools رفع کنند.

پولارد توصیه می کند که روی PSI بمانید زیرا نکات متعددی برای درک مشکلاتی که باعث عملکرد ضعیف LCP می شود ارائه می دهد.

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

1. داده های سطح URL
2. داده های سطح مبدا

نمرات سطح URL برای صفحه خاصی است که در حال اشکال زدایی است. Origin-Level Data امتیازهای جمع آوری شده از کل وب سایت است.

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

2. امتیاز TTFB را مرور کنید

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

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

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

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

یک TTFB کند اساساً به معنای 1 از 2 چیز است:

1) ارسال درخواست به سرور شما خیلی طول می کشد
2) پاسخ سرور شما خیلی طول می کشد

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

بری مرور کلی اشکال زدایی LCP خود را با آزمایش های خاصی که در زیر به آنها اشاره شده است ادامه داد.

3. مقایسه TTFB با تست لابراتوار فانوس دریایی

پولارد آزمایش با تست های آزمایشگاه فانوس دریایی، به ویژه ممیزی “زمان پاسخ اولیه سرور” را توصیه می کند. هدف این است که بررسی شود آیا مسئله TTFB قابل تکرار است تا احتمال تصادفی بودن مقادیر PSI از بین برود.

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

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

اگر تست Lighthouse Lab این مشکل را تکرار نکرد، به این معنی است که مشکل از سرور نیست.

او توصیه کرد:

نکته کلیدی در اینجا این است که بررسی کنید آیا TTFB کند قابل تکرار است یا خیر. بنابراین به پایین پیمایش کنید و ببینید آیا تست آزمایشگاه Lighthouse با این TTFB کاربر واقعی آهسته در هنگام آزمایش صفحه مطابقت دارد یا خیر. به دنبال ممیزی “زمان پاسخ اولیه سرور” باشید.

در این مورد خیلی سریعتر بود – جالب است!»

4. نکته تخصصی: چگونه بررسی کنیم که آیا CDN مشکلی را پنهان می کند یا خیر

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

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

باری ترفندهای زیر را برای دور زدن حافظه پنهان CDN پیشنهاد می کند:

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

او همچنین ابزاری را پیشنهاد می کند که می تواند برای آزمایش کشورهای خاص مورد استفاده قرار گیرد:

«همچنین می‌توانید بررسی کنید که آیا به‌ویژه کشورهایی هستند که کند هستند – به ویژه اگر از CDN استفاده نمی‌کنید – با CrUX و @alekseykulikov.bsky.social's Treo یکی از بهترین ابزارها برای انجام این کار است.

می‌توانید یک آزمایش رایگان را در اینجا اجرا کنید: treo.sh/sitespeed و به سمت نقشه پایین بروید و به TTFB بروید.

اگر کشورهای خاصی دارای TTFB کند هستند، بررسی کنید که چه میزان ترافیک از آن کشورها می آید. به دلایل حفظ حریم خصوصی، CrUX حجم ترافیک را به شما نشان نمی دهد، (به غیر از مواردی که ترافیک کافی برای نمایش داشته باشد)، بنابراین برای این کار باید به تجزیه و تحلیل خود نگاه کنید.

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

5. آنچه را که می توان تکرار کرد رفع کنید

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

او توصیه کرد:

برای مشکلات سرور، آیا سرور ضعیف است؟

یا کد خیلی پیچیده/ناکارآمد است؟

یا پایگاه داده نیاز به تنظیم دارد؟

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

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

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

سعی کنید تا حد امکان تغییر مسیرها را کاهش دهید:
– از URL نهایی صحیح استفاده کنید تا نیازی به تغییر مسیر به www یا https نداشته باشید.
– از چندین سرویس کوتاه کننده URL اجتناب کنید.

نکات مهم: نحوه بهینه سازی برای بزرگترین رنگ محتوایی

بری پولارد از گوگل کروم پنج نکته مهم را ارائه کرد.

1. داده‌های PageSpeed ​​Insights (PSI) ممکن است سرنخ‌هایی را برای اشکال‌زدایی مسائل LCP، به‌علاوه سایر نکات ظریفی که در این مقاله مورد بحث قرار گرفته‌اند، ارائه دهد که به درک داده‌ها کمک می‌کند.

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

3. تست های آزمایشگاه فانوس دریایی برای رفع اشکال مفید هستند زیرا نتایج قابل تکرار هستند. نتایج تکرارپذیر برای شناسایی دقیق منبع مشکلات LCP کلیدی است که سپس امکان اعمال راه حل های مناسب را فراهم می کند.

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

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

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

پست بری در Bluesky را بخوانید:

اخیراً چند نفر با من تماس گرفته‌اند و برای مشکلات LCP درخواست کمک کرده‌اند

تصویر برجسته توسط Shutterstock/BestForBest