اگر طراح سایت یا سئوکار هستید، قطعا یکبار با سوال LCP چیست، روبرو شده اید. بزرگترین رنگ محتوایی (LCP) مدت زمانی است که برای بارگیری بزرگترین عنصر قابل مشاهده در پنجره مشاهده می شود. این نشاندهنده بارگذاری بصری وبسایت است و یکی از سه معیار اصلی وب حیاتی (Core Web Vitals) است که Google برای اندازهگیری تجربه صفحه از آن استفاده میکند.
اولین برداشتی که کاربران از سایت شما دارند، سرعت بارگذاری آن است.
بزرگترین عنصر معمولاً یک تصویر برجسته یا شاید تگ <h1> است. اما ممکن است یکی از این موارد نیز باشد:
-
عنصر <img>
-
عنصر <image> در داخل عنصر <svg>
-
تصویر درون عنصر <video>
-
تصویر پس زمینه با تابع url() بارگذاری شده است
-
بلوک های متن
-
<svg> و <video> ممکن است در آینده اضافه شوند.
هنگام تعیین اندازه، هر چیزی خارج از viewport یا هر سرریزی در نظر گرفته نمی شود. اگر یک تصویر کل نمای را اشغال کند، برای LCP در نظر گرفته نمی شود.
بیایید بررسی کنیم که LCP شما چقدر باید سریع باشد و چگونه آن را بهبود ببخشید.
یک مقدار LCP خوب چیست؟
یک مقدار LCP خوب کمتر از 2.5 ثانیه است و باید براساس دادههای گزارش تجربه کاربر Chrome (CrUX) باشد. این دادههای کاربران واقعی Chrome است که در سایت شما هستند و اشتراکگذاری این اطلاعات را انتخاب کردهاند. برای بارگیری در 2.5 ثانیه یا کمتر به 75 درصد از بازدیدهای صفحه نیاز دارید.
صفحه شما ممکن است در یکی از گروه های زیر طبقه بندی شود:
-
خوب: <=2.5 ثانیه
-
نیاز به بهبود دارد: >2.5 ثانیه و <=4 ثانیه
-
ضعیف: > 4 ثانیه
معمولا سایتهایی که از تصاویر کمتر و با حجم پایینتر استفاده میکنند، کمتر با این مشکل روبرو میشوند. برای مثال در طراحی سایت ساختمانی این مشکل کمتر اتفاق میافتد.
داده های LCP
57.1٪ از سایت ها در گروه LCP خوب از آوریل 2023 هستند. این میانگین در سراسر سایت است. همانطور که اشاره کردیم، شما به 75 درصد از بازدیدهای صفحه نیاز دارید تا در 2.5 ثانیه یا کمتر بارگذاری شود تا در اینجا به عنوان "خوب" نشان داده شود.
LCP هسته حیاتی وب است که مردم بیشترین تلاش را برای بهبود آن دارند. زمانی که مطالعهای را روی Core Web Vitals انجام دادیم، دیدیم که صفحات در مقایسه با دسکتاپ کمتر احتمال دارد که مقادیر LCP خوبی در دستگاههای تلفن همراه داشته باشند.
نحوه اندازه گیری LCP
چند روش مختلف برای اندازه گیری LCP وجود دارد که می خواهید به آنها نگاه کنید: داده های میدانی و داده های آزمایشگاهی.
دادههای میدانی از گزارش تجربه کاربر Chrome (CrUX) میآید، که دادههای کاربران واقعی Chrome است که انتخاب میکنند دادههای خود را به اشتراک بگذارند. این بهترین ایده را از عملکرد LCP در دنیای واقعی در شرایط مختلف شبکه، دستگاهها، حافظه پنهان، و غیره به شما میدهد. همچنین این همان چیزی است که در واقع توسط Google برای Core Web Vitals اندازهگیری خواهید شد.
دادههای آزمایشگاهی مبتنی بر آزمایشهایی با شرایط یکسان هستند تا آزمایشها را تکرار کنند. Google از این برای Core Web Vitals استفاده نمیکند، اما برای آزمایش مفید است زیرا دادههای CrUX/فیلد یک میانگین 28 روزه است، بنابراین مدتی طول میکشد تا تأثیر تغییرات را ببینید.
بهترین ابزار برای اندازهگیری LCP به نوع دادهای که میخواهید (آزمایشگاه/حوزه) و اینکه آن را برای یک URL میخواهید یا چند URL بستگی دارد.
1- اندازه گیری LCP برای یک URL واحد
Pagespeed Insights دادههای فیلد سطح صفحه را میکشد که در غیر این صورت نمیتوانید در مجموعه داده CrUX پرس و جو کنید. همچنین تست های آزمایشگاهی را بر اساس Google Lighthouse برای شما اجرا می کند و داده های مبدا را به شما می دهد تا بتوانید عملکرد صفحه را با کل سایت مقایسه کنید.
2- اندازه گیری LCP برای بسیاری از URL ها یا کل سایت
میتوانید دادههای CrUX را در کنسول جستجوی Google دریافت کنید که در دستههای خوب، نیاز به بهبود و ضعیف قرار دارند.
با کلیک بر روی یکی از مسائل، گروههای صفحهای که تحت تأثیر قرار گرفتهاند را به تفکیک تقسیم میکنید. گروه ها صفحاتی با مقادیر مشابه هستند که احتمالاً از یک الگو استفاده می کنند. شما تغییرات را یک بار در قالب ایجاد می کنید و این تغییرات در صفحات گروه برطرف می شود.
نحوه بهبود LCP
در PageSpeed Insights، عنصر LCP در بخش «Diagnostics» مشخص میشود. همچنین، توجه داشته باشید که یک برگه برای انتخاب LCP وجود دارد که فقط مسائل مربوط به LCP را نشان می دهد. اینها مسائلی است که در آزمایش آزمایشگاهی مشاهده می شود که می خواهید آنها را حل کنید.
نظریه کلی به اندازه کافی آسان به نظر می رسد. بزرگترین عنصر را سریعتر به من بدهید. اما در عمل، این می تواند نسبتاً پیچیده شود. برخی از فایلها ممکن است نیاز داشته باشند که ابتدا فایلهای دیگر بارگیری شوند، یا ممکن است اولویتهای متناقضی در مرورگر وجود داشته باشد. ممکن است تعدادی از مشکلات را بدون مشاهده بهبودی برطرف کنید، که می تواند ناامید کننده باشد.
اگر خیلی فنی نیستید و نمیخواهید کسی را استخدام کنید، به دنبال پلاگینها، ماژولها یا بستههای بهینهسازی عملکرد یا سرعت صفحه برای هر سیستمی که استفاده میکنید باشید. میتوانید از اطلاعات زیر به عنوان راهنمای ویژگیهایی که ممکن است نیاز داشته باشید استفاده کنید.
در اینجا چند راه برای بهبود LCP وجود دارد:
1. عنصر LCP خود را پیدا کنید
در PageSpeed Insights، میتوانید روی «بزرگترین عنصر رنگ محتوایی» در بخش «تشخیص» کلیک کنید و عنصر LCP شما را شناسایی میکند.
2. بارگذاری منابع را اولویت بندی کنید
برای عبور از بررسی LCP، باید نحوه بارگیری منابع خود را در مسیر رندر بحرانی اولویت بندی کنید. منظور من از آن این است که شما می خواهید ترتیب بارگیری و پردازش منابع را دوباره ترتیب دهید.
ابتدا باید منابع مورد نیاز برای عنصر LCP و سایر منابع مورد نیاز برای محتوای بالای صفحه را بارگیری کنید. پس از بارگذاری عناصر اولیه قابل مشاهده برای کاربران، بقیه آنها بارگذاری میشوند.
بسیاری از سایتها میتوانند تنها با افزودن برخی نکات اولیه یا بیانیههای پیش بارگذاری برای مواردی مانند تصویر اصلی، و همچنین شیوه نامهها و فونتهای ضروری، به زمان گذرا برای LCP برسند. بیایید نحوه بهینه سازی انواع منابع را بررسی کنیم.
تصاویر زود هنگام
اگر به تصویر نیاز ندارید، موثرترین راه حل این است که به سادگی از شر آن خلاص شوید. اگر باید تصویر را داشته باشید، پیشنهاد می کنم اندازه و کیفیت آن را بهینه کنید تا آن را تا حد امکان کوچک نگه دارید.
همچنین می توانید از نکات اولیه استفاده کنید. Fetchpriority=”high” را می توان در تگ های <img> یا <link> استفاده کرد و به مرورگرها می گوید که تصویر را زودتر دریافت کنند. این بدان معنی است که کمی زودتر نمایش داده می شود.
نکات اولیه در همه مرورگرها کار نمی کند، بنابراین ممکن است بخواهید تصویر را از قبل بارگذاری کنید. با این کار دانلود آن تصویر کمی زودتر آغاز میشود، اما نه در اوایل fetchpriority=”high”.
یک دستور پیش بارگذاری برای یک تصویر پاسخگو به این صورت است:
<link rel="preload" as="image" href="cat.jpg"
imagesrcset=“cat_400px.jpg 400w,
cat_800px.jpg 800w, cat_1600px.jpg 1600w"
imagesizes="50vw">
حتی می توانید از fetchpriority=”high” استفاده کنید و با هم پیش بارگذاری کنید!
تصاویر با تاخیر
شما باید هر تصویری را که نیاز ندارید فوراً بارگذاری کنید. این تصاویر در مراحل بعدی یا زمانی که کاربر نزدیک به دیدن آنها است بارگیری می شود. می توانید از loading=“lazy” مانند این استفاده کنید:
<img src="cat.jpg" alt="cat" loading="lazy">
2 توصیه مهم:
-
تصاویر را در بالای صفحه بارگذاری نکنید!
-
این کار در طراحی سایت گردشگری به علت تعداد زیاد عکسها می تواند عالی باشد.
اول CSS
شما باید هر CSS که دارید را کوچک کنید. در صورت امکان، CSS استفاده نشده را نیز حذف کنید.
کار اصلی دیگری که باید انجام دهید این است که CSS حیاتی را درون خطی کنید. کاری که این کار انجام می دهد این است که بخشی از CSS مورد نیاز برای بارگیری محتوایی که کاربران بلافاصله می بینند را می گیرد و سپس آن را مستقیماً در HTML اعمال می کند. هنگامی که HTML دانلود می شود، تمام CSS مورد نیاز برای بارگیری آنچه کاربران می بینند از قبل در دسترس است.
CSS با تاخیر
با هر CSS اضافی که حیاتی نیست، می خواهید آن را در مراحل بعدی اعمال کنید. میتوانید ادامه دهید و دانلود CSS را با یک عبارت preload شروع کنید، اما CSS را تا بعداً با یک رویداد onload اعمال نکنید. این به نظر می رسد:
<link rel="preload" href="stylesheet.css" as="style" onload="this.rel='stylesheet'">
فونت ها
من در اینجا چند گزینه به شما می دهم:
-
خوب: فونت های خود را از قبل بارگذاری کنید. حتی بهتر است اگر از همان سرور برای خلاص شدن از شر اتصال استفاده کنید.
-
بهتر: فونت-نمایش: اختیاری. این را می توان با یک عبارت preload جفت کرد. این به فونت شما یک پنجره کوچک از زمان برای بارگذاری می دهد. اگر فونت به موقع درست نشود، بارگذاری صفحه اولیه به سادگی یک فونت پیش فرض را نشان می دهد. سپس فونت سفارشی شما در حافظه پنهان ذخیره می شود و در بارگذاری های بعدی صفحه نمایش داده می شود.
-
بهترین: فقط از یک فونت سیستم استفاده کنید. چیزی برای بارگیری وجود ندارد - بنابراین هیچ تاخیری وجود ندارد.
جاوا اسکریپت زودهنگام
ما قبلاً در مورد حذف جاوا اسکریپت استفاده نشده و کوچک کردن آنچه دارید صحبت کردیم. اگر از فریم ورک جاوا اسکریپت استفاده می کنید، ممکن است بخواهید صفحه را از قبل اجرا یا رندر سمت سرور (SSR) کنید.
شما همچنین می توانید جاوا اسکریپت مورد نیاز را زودتر به صورت خطی وارد کنید. این کار به همان روشی عمل می کند که در بخش CSS توضیح داده شد، جایی که شما بخش هایی را از فایل های جاوا اسکریپت خود منتقل می کنید تا در عوض با HTML بارگذاری شوند.
گزینه دیگر این است که فایل های جاوا اسکریپت را از قبل بارگذاری کنید تا زودتر آنها را دریافت کنید. این فقط باید برای دارایی های مورد نیاز برای بارگیری محتوا در بالای صفحه انجام شود یا اگر برخی از عملکردها به این جاوا اسکریپت بستگی دارد.
جاوا اسکریپت با تاخیر
هر جاوا اسکریپتی که فوراً به آن نیاز ندارید باید بعداً بارگیری شود. دو راه اصلی برای انجام این کار وجود دارد - ویژگیهای defer و async. این ویژگی ها را می توان به تگ های اسکریپت شما اضافه کرد.
معمولاً اسکریپتی که دانلود می شود، تجزیه کننده را هنگام دانلود و اجرا مسدود می کند. Async اجازه می دهد تجزیه و دانلود به طور همزمان انجام شود اما همچنان تجزیه را در طول اجرای اسکریپت مسدود می کند. Defer تجزیه را در حین دانلود مسدود نمی کند و فقط پس از اتمام تجزیه HTML اجرا می شود.
نموداری که نشان میدهد چگونه ناهمگامسازی و تأخیر بر بارگذاری صفحه تأثیر میگذارد
کدام را باید استفاده کنید؟ برای هر چیزی که قبلاً می خواهید یا وابستگی دارد، من به سمت ناهمگامی متمایل می شوم.
به عنوان مثال، من تمایل دارم از async در برچسب های تجزیه و تحلیل استفاده کنم تا کاربران بیشتری ثبت شوند. شما می خواهید هر چیزی را که لازم نیست به بعد یا وابستگی ندارد به تعویق بیندازید. افزودن ویژگی ها بسیار آسان است.
3. فایل ها را کوچکتر کنید
اگر بتوانید از شر هر فایل خلاص شوید یا اندازه آنها را کاهش دهید، صفحه شما سریعتر بارگذاری می شود. این بدان معناست که ممکن است بخواهید فایلهایی را که استفاده نمیشوند یا قسمتهایی از کد استفاده نشده را حذف کنید.
نحوه انجام این کار بستگی زیادی به تنظیمات شما دارد، اما فرآیند حذف بخشهای غیرضروری فایلها معمولاً به عنوان تکان دادن درخت شناخته میشود.
این معمولاً از طریق یک فرآیند خودکار با Webpack یا Grunt با چارچوبهای جاوا اسکریپت یا حتی گاهی اوقات سیستمهایی مانند WordPress انجام میشود، اما اکثر سیستمهای CMS رایج ممکن است این را پشتیبانی نکنند.
ممکن است بخواهید از این کار رد شوید یا ببینید آیا افزونه هایی وجود دارد که این گزینه را برای سیستم شما دارد.
برای کوچکتر کردن فایلها، معمولاً میخواهید آنها را فشرده کنید.
تقریباً هر نوع فایلی که برای ساخت وب سایت شما استفاده می شود، می تواند فشرده شود، از جمله CSS، جاوا اسکریپت، تصاویر و HTML. همچنین، تقریباً هر سیستم و سرور از فشرده سازی پشتیبانی می کند.
معمولاً در سطح سرور یا CDN انجام می شود، اما برخی از افزونه ها مانند WP Rocket برای وردپرس از آن پشتیبانی می کنند.
4. فایل ها را نزدیک تر به کاربران ارائه دهید
اطلاعات برای سفر به زمان نیاز دارد. هر چه از یک سرور دورتر باشید، انتقال داده ها بیشتر طول می کشد. مگر اینکه به یک منطقه جغرافیایی کوچک خدمت کنید، داشتن یک شبکه تحویل محتوا (CDN) ایده خوبی است.
CDN ها راهی برای اتصال و ارائه خدمات به سایت خود که به کاربران نزدیک تر است را به شما می دهد. مانند داشتن نسخه هایی از سرور خود در مکان های مختلف در سراسر جهان است.
5. میزبانی منابع بر روی همان سرور
هنگامی که برای اولین بار به یک سرور متصل می شوید، فرآیندی وجود دارد که در وب حرکت می کند و یک ارتباط امن بین شما و سرور برقرار می کند.
این مدتی طول میکشد و هر اتصال جدیدی که باید ایجاد کنید، در حالی که همان فرآیند را طی میکند، تاخیر بیشتری اضافه میکند. اگر منابع خود را روی همان سرور میزبانی کنید، می توانید این تاخیرهای اضافی را حذف کنید.
اگر نمی توانید از همان سرور استفاده کنید، ممکن است بخواهید از پیش اتصال یا DNS-prefetch برای شروع زودتر اتصالات استفاده کنید. یک مرورگر معمولاً قبل از شروع اتصال منتظر می ماند تا دانلود HTML به پایان برسد. اما با اتصال اولیه یا واکشی اولیه DNS، زودتر از حالت عادی شروع می شود. توجه داشته باشید که DNS-prefetch پشتیبانی بهتری نسبت به اتصال اولیه دارد.
برای هر منبعی که می خواهید زودتر به دست آورید، یک عبارت جدید اضافه می کنید مانند:
<link rel="preconnect" href="https://fonts.googleapis.com/">
<link rel="dns-prefetch" href="https://fonts.googleapis.com/" />
6. از کش استفاده کنید
هنگامی که منابع را کش میکنید، برای اولین نمای صفحه دانلود میشوند، اما برای بازدیدهای بعدی از صفحه نیازی به دانلود ندارند. با منابع موجود، بارگذاری صفحات اضافی بسیار سریعتر خواهد بود.
اگر می توانید، روی CDN نیز کش کنید. زمان کش شما باید تا زمانی باشد که با آن راحت هستید.
معمولا در طراحی سایت پزشکی که احتمال بازگشت افراد زیاد است، این کار جواب میدهد.
7. متفرقه
چند فناوری دیگر وجود دارد که ممکن است بخواهید برای کمک به عملکرد به آنها نگاه کنید. این موارد عبارتند از Prerendering Speculative، Signed Exchanges و HTTP/3.
افکار نهایی
آیا معیار بهتری برای اندازه گیری بار مرئی وجود دارد؟ در حال حاضر هیچ چیز جدیدی در افق نمی بینم. ما قبلاً چندین تکامل را در تلاش برای اندازه گیری بار مشاهده کرده ایم.
Load و DOMContentLoaded واقعاً به شما نمی گویند که کاربر چه می بیند. First Contentful Paint (FCP) آغاز تجربه بارگیری است. First Meaning Paint (FMP) و Speed Index (SI) پیچیده هستند و واقعاً مشخص نمی کنند که محتوای اصلی چه زمانی بارگذاری شده است.
منبع: ahrefs.com