وقتی کاربر صفحه‌ای را باز می‌کند، اولین چیزی که تجربه می‌کند انتظار است. اگر بزرگ‌ترین و مهم‌ترین بخش صفحه دیر ظاهر شود، حس می‌کند سایت کند است. حتی اگر بقیهٔ صفحه سریع آماده شده باشد. سنجه‌ای که این تجربه را اندازه می‌گیرد LCP نام دارد، و مخفف بزرگ‌ترین عنصر محتوایی است.
این سنجه یکی از سه سنجهٔ اصلی تجربهٔ کاربری است که گوگل در ارزیابی صفحات به آن نگاه می‌کند. در این مقاله می‌بینیم، LCP دقیقاً چه چیزی را اندازه می‌گیرد. چطور آن را درست اندازه بگیریم. چه چیزهایی آن را خراب می‌کند. و با چه ترتیبی باید اصلاح شود، تا وقت تیم هدر نرود.
خلاصهٔ یک‌خطی: LCP زمانی است که بزرگ‌ترین عنصر دیدنی صفحه کامل نمایش داده می‌شود. آستانهٔ خوب ۲٫۵ ثانیه است. بیشترین اثر بر آن تصویر اصلی صفحه و سرور و فونت است، نه حجم کل صفحه.
LCP چیست؟ تعریف فنی به زبان ساده
LCP زمانی را اندازه می‌گیرد که بزرگ‌ترین عنصر محتوایی در ناحیهٔ دید کاربر به‌طور کامل رندر شده باشد. «کامل» یعنی تصویر دانلود شده باشد، و متن با فونت نهایی نمایش داده شود. «ناحیهٔ دید»، یعنی بخشی از صفحه که کاربر بدون اسکرول می‌بیند.
سه نکته در این تعریف مهم است. اول اینکه سنجه به بزرگ‌ترین عنصر مربوط است، نه به کل صفحه. دوم اینکه فقط عناصر دیدنی در محاسبه می‌آیند. سوم اینکه اگر عنصر بزرگ بعداً تغییر کند، سنجه دوباره محاسبه می‌شود. به همین دلیل، انیمیشن‌های ورودی و اسلایدرهایی که محتوای اصلی را جابه‌جا می‌کنند، می‌توانند سنجه را بدتر نشان دهند.
| مفهوم | معنی دقیق | اشتباه رایج |
|---|---|---|
| بزرگ‌ترین عنصر | بیشترین سطح دیدنی در ناحیهٔ دید | فرض اینکه تصویر هدر است |
| ناحیهٔ دید | بخشی که بدون اسکرول دیده می‌شود | محاسبهٔ کل صفحه |
| رندر کامل | دانلود تصویر و آماده بودن فونت | اکتفا به شروع دانلود |
| بازمحاسبه | تغییر عنصر بزرگ در طول بارگذاری | نادیده گرفتن اسلایدر |
کدام عنصر LCP محسوب می‌شود؟
عنصر بزرگ‌ترین معمولاً یکی از این چهار مورد است. تصویر بزرگ صفحه. تصویر پس‌زمینه که با استایل بارگذاری می‌شود. بلوک متنی بزرگ. یا ویدئوی پوشش صفحه. در بیشتر سایت‌ها این عنصر، همان تصویر اصلی بالای صفحه است.
| نوع عنصر | مثال | عامل کندی |
|---|---|---|
| تصویر محتوایی | تصویر اصلی مقاله | حجم زیاد و ابعاد نامناسب |
| تصویر پس‌زمینه | بنر بالای صفحه | کشف دیرهنگام توسط مرورگر |
| بلوک متنی | تیتر اصلی بزرگ | انتظار برای فونت |
| ویدئو | ویدئوی معرفی | بارگذاری سنگین و پوستر بزرگ |
برای پیدا کردن عنصر واقعی لازم نیست حدس بزنید. ابزارهای سنجش دقیقاً نشان می‌دهند، کدام عنصر به عنوان LCP انتخاب شده است. این اولین کاری است که باید انجام دهید، چون بهینه‌سازی عنصر اشتباه اتلاف وقت است.
آستانه‌ها: خوب و نیازمند بهبود و ضعیف
گوگل برای این سنجه سه بازه تعریف کرده است. این بازه‌ها بر اساس دادهٔ واقعی کاربران تعیین شده‌اند، و مبنای قضاوت در گزارش‌ها هستند.
| بازه | مقدار | تفسیر |
|---|---|---|
| خوب | ۲٫۵ ثانیه یا کمتر | تجربهٔ قابل قبول برای بیشتر کاربران |
| نیازمند بهبود | بیش از ۲٫۵ و تا ۴ ثانیه | فرصت مشخص برای بهینه‌سازی |
| ضعیف | بیش از ۴ ثانیه | ریسک از دست دادن کاربر |
یک نکتهٔ مهم: این آستانه در سطح هفتاد و پنجم درصد کاربران سنجیده می‌شود. یعنی باید بیشتر کاربران شما زیر آستانه باشند، نه میانگین آن‌ها. اگر میانگین خوب باشد، اما بخشی از کاربران تجربهٔ بد داشته باشند، باز هم وضعیت قابل قبول نیست.
نکته: هدف را روی عدد ۲٫۵ ثانیه نگذارید. هدف را روی فاصلهٔ مطمئن از آن بگذارید. شرایط شبکه و دستگاه کاربران شما متفاوت است، و مقدار اندازه‌گیری‌شده در هر اجرا کمی تغییر می‌کند. اگر عدد شما ۲٫۳ ثانیه است، حاشیهٔ امن دارید. اگر ۲٫۴ است، هر تغییر کوچکی شما را به بازهٔ بعدی می‌برد.
رابطهٔ LCP با سئو: مستقیم یا غیرمستقیم؟
این سؤال پاسخ دو بخشی دارد. بخش اول: تجربهٔ صفحه یکی از سیگنال‌های رتبه‌بندی است. بخش دوم: اثر آن در مقایسه با محتوا و لینک کوچک‌تر است. یعنی صفحهٔ کند با محتوای عالی می‌تواند رتبه بگیرد، اما صفحهٔ کند با محتوای متوسط شانس کمتری دارد.
اثر غیرمستقیم مهم‌تر است. کاربری که سه ثانیه منتظر مانده قبل از دیدن محتوا، صفحه را ترک می‌کند. ترک زودهنگام یعنی نرخ پرش بالا، و زمان حضور کم. این‌ها سیگنال‌های رفتاری هستند که به‌طور غیرمستقیم بر ارزیابی اثر می‌گذارند. پس بهینه‌سازی سرعت هم مستقیم و هم غیرمستقیم به نفع سئو است.
یک اثر سوم هم وجود دارد که کمتر گفته می‌شود. صفحات کند کمتر خزیده می‌شوند. اگر سرور شما در پاسخ کندی دارد، خزنده هم زمان بیشتری صبر می‌کند و در نهایت بخشی از صفحات را رها می‌کند. این موضوع به بودجهٔ خزش مربوط است، که در مطلب بودجهٔ خزش توضیح داده شده است.
دادهٔ میدانی و دادهٔ آزمایشگاهی
دو نوع اندازه‌گیری وجود دارد، و اشتباه گرفتن این دو یکی از رایج‌ترین خطاهاست. دادهٔ میدانی از کاربران واقعی جمع می‌شود. دادهٔ آزمایشگاهی از اجرای کنترل‌شده روی یک دستگاه و شبکهٔ مشخص.
| ویژگی | دادهٔ میدانی | دادهٔ آزمایشگاهی |
|---|---|---|
| منبع | کاربران واقعی | اجرای کنترل‌شده |
| تأخیر شبکه | واقعی و متغیر | ثابت و شبیه‌سازی‌شده |
| سرعت بازخورد | کند و تجمعی | فوری |
| کاربرد | قضاوت نهایی | عیب‌یابی و آزمایش |
| تأثیر دستگاه | شامل تنوع واقعی | محدود به دستگاه آزمایش |
قاعدهٔ عملی ساده است. برای تصمیم نهایی به دادهٔ میدانی نگاه کنید. برای پیدا کردن علت و آزمایش راه‌حل، از دادهٔ آزمایشگاهی استفاده کنید. اگر فقط آزمایشگاهی را ببینید، ممکن است چیزی را بهینه کنید که کاربران واقعی شما با آن مشکل ندارند.
چهار مرحلهٔ شکل‌گیری LCP
زمان کل از چهار بخش تشکیل می‌شود. اگر بدانید کدام بخش بزرگ‌تر است، می‌دانید کجا سرمایه‌گذاری کنید. این تقسیم‌بندی، مهم‌ترین ابزار تشخیص است.
| مرحله | چه چیزی طول می‌کشد | راه اصلاح |
|---|---|---|
| تأخیر شروع | انتظار برای پاسخ سرور | کش و بهبود سرور |
| زمان دانلود | دریافت فایل تصویر | فشرده‌سازی و ابعاد درست |
| زمان پاسخ | پردازش و آماده‌سازی | کاهش کار اصلی رشته |
| تأخیر رندر | انتظار برای استایل و فونت | حذف منابع مسدودکننده |
در بیشتر سایت‌های ایرانی، مرحلهٔ اول و دوم بزرگ‌ترین سهم را دارند. یعنی سرور کند است یا تصویر سنگین. اگر این دو حل شوند، معمولاً بخش زیادی از مشکل برطرف می‌شود، بدون آنکه به سراغ تغییرات پیچیدهٔ کد بروید.
علت‌های رایج کندی
فهرست زیر بر اساس تکرار در پروژه‌های واقعی، مرتب شده است. از بالا به پایین بررسی کنید.
| علت | نشانه | اثر تقریبی |
|---|---|---|
| تصویر بدون فشرده‌سازی | فایل چند مگابایتی در بالای صفحه | بسیار زیاد |
| عدم تعیین ابعاد تصویر | جهش چیدمان هنگام بارگذاری | زیاد |
| سرور کند یا بدون کش | زمان پاسخ بالا در ابزار | زیاد |
| فونت خارجی مسدودکننده | متن نامرئی تا آماده شدن فونت | متوسط تا زیاد |
| اسکریپت سنگین در سر صفحه | تأخیر در رندر اولیه | زیاد |
| اسلایدر در بالای صفحه | عنصر بزرگ متغیر | متوسط |
| بارگذاری تصویر دیرهنگام | کشف تصویر پس از اسکریپت | زیاد |
کشف زودهنگام تصویر: نکته‌ای که بیشتر پروژه‌ها از دست می‌دهند
بارگذاری سریع تصویر دو شرط دارد. اول اینکه فایل کوچک باشد. دوم اینکه مرورگر آن را زود کشف کند. اگر مرورگر تصویر اصلی را بعد از اجرای چند اسکریپت پیدا کند، حتی فایل کوچک هم دیر می‌رسد. این وضعیت در خروجی ابزار، به شکل فاصلهٔ زیاد میان شروع بارگذاری و شروع دانلود دیده می‌شود.
چرا این اتفاق می‌افتد؟ چون تصویر در کد صفحه مستقیم نیامده، و با اسکریپت تزریق شده است. یا چون در استایل یک عنصر پنهان تعریف شده، و مرورگر آن را در فاز اول نمی‌بیند. یا چون اسلایدر تصویر اول را با تأخیر فعال می‌کند. در هر سه حالت راه‌حل یکسان است: تصویر اصلی باید در کد اولیهٔ صفحه و به‌صورت مستقیم حضور داشته باشد.
| الگوی مشکل | چرا کند است | اصلاح |
|---|---|---|
| تصویر تزریقی با اسکریپت | کشف پس از اجرای کد | قرار دادن در کد اولیه |
| تصویر پنهان در استایل | عدم کشف در فاز اول | نمایش مستقیم در ابتدا |
| اسلایدر با تأخیر | تصویر اول دیر فعال می‌شود | اولین اسلاید ایستا |
| تصویر پس‌زمینه در فایل جدا | کشف دیرهنگام فایل استایل | تعریف مستقیم در صفحه |
مثال: صفحه‌ای را در نظر بگیرید که تصویر اصلی آن در فایل استایل تعریف شده است. مرورگر باید ابتدا فایل استایل را دانلود کند، و بعد تصویر را کشف کند. اگر بین این دو یک اسکریپت سنگین هم اجرا شود، تأخیر چند برابر می‌شود. انتقال همان تصویر به کد صفحه معمولاً بخش بزرگی از این تأخیر را حذف می‌کند، بدون آنکه حجم فایل تغییر کند.
یک مثال عینی: صفحهٔ محصول فروشگاه
صفحهٔ یک محصول با تصویر بزرگ در بالای صفحه را در نظر بگیرید. کاربران این صفحه معمولاً از شبکهٔ موبایل وارد می‌شوند. سه مشکل معمول در چنین صفحه‌ای وجود دارد.
مشکل اول حجم تصویر است. عکسی که با دوربین گرفته شده و بدون فشرده‌سازی روی سایت گذاشته شده، می‌تواند چند برابر حد لازم حجم داشته باشد. مشکل دوم نبود ابعاد ثابت است که باعث جهش چیدمان می‌شود. مشکل سوم رقابت تصویر اصلی با تصاویر کوچک گالری است. اگر همه با اولویت یکسان بارگذاری شوند، تصویر اصلی منابع کمتری می‌گیرد.
ترتیب اصلاح در این مثال، روشن است. اول فشرده‌سازی و تغییر ابعاد تصویر اصلی. دوم تعیین ابعاد ثابت برای کادر تصویر. سوم کاهش اولویت تصاویر گالری. این سه کار معمولاً بیشترین بهبود را می‌دهد، و نیاز به تغییر ساختار صفحه ندارد.
| مشکل | نشانه در ابزار | اقدام |
|---|---|---|
| حجم زیاد تصویر | زمان دانلود طولانی | فشرده‌سازی و ابعاد درست |
| نبود ابعاد ثابت | جهش چیدمان | تعیین عرض و ارتفاع |
| رقابت منابع | تأخیر شروع دانلود | اولویت به تصویر اصلی |
اندازه‌گیری روی موبایل
بیشتر کاربران سایت‌های ایرانی با گوشی وارد می‌شوند. اندازه‌گیری روی رایانهٔ دفتر با اینترنت پرسرعت، تصویر واقعی نمی‌دهد. حداقل یک بار، همان صفحه را با شبیه‌سازی شبکهٔ موبایل و پردازندهٔ کندتر بسنجید.
اگر عدد موبایل بسیار بدتر از رایانه بود، دو علت محتمل است. اول حجم تصاویر که در شبکهٔ کندتر بیشتر خود را نشان می‌دهد. دوم حجم کد که در پردازندهٔ ضعیف‌تر دیرتر اجرا می‌شود. تفکیک این دو با نگاه به مرحلهٔ زمانی ممکن است. اگر زمان دانلود بزرگ است، مشکل اول و اگر زمان پردازش بزرگ است، مشکل دوم است.
گام‌به‌گام اندازه‌گیری درست
پیش از هر تغییری، عدد پایه را ثبت کنید. بدون عدد پایه نمی‌توانید بگویید تغییر شما اثر داشته یا نه.
- آدرس صفحهٔ اصلی و دو صفحهٔ پرترافیک را انتخاب کنید.
- در ابزار سنجش میدانی عدد فعلی را ثبت کنید.
- در ابزار آزمایشگاهی همان صفحه را چند بار اجرا کنید، و میانه را ثبت کنید.
- عنصر LCP را در خروجی ابزار پیدا کنید.
- هر چهار مرحلهٔ زمانی را جداگانه یادداشت کنید.
- پس از هر تغییر همان اندازه‌گیری را تکرار کنید.
یک نکته دربارهٔ تکرار: نتیجهٔ یک اجرا قابل اعتماد نیست. حداقل سه اجرا بگیرید، و میانه را مبنا بگذارید. اگر نتیجهٔ اجراها بسیار متفاوت بود، مشکل شبکه یا سرور دارید و باید ابتدا آن را حل کنید.
قاعده: قبل از بهینه‌سازی بفهمید کدام مرحله بزرگ‌ترین سهم را دارد. اگر سرور شما پاسخ را در یک ثانیه برمی‌گرداند، بهینه‌سازی تصویر بهبود محدودی می‌دهد. اگر تصویر شما سه مگابایت است، فشرده‌سازی آن بیشترین اثر را دارد. ترتیب کار را از داده بگیرید، نه از عادت.
بهینه‌سازی تصویر: بیشترین اثر با کمترین هزینه
در بیشتر پروژه‌ها، این بخش تنها کاری است که نتیجهٔ محسوس می‌دهد. سه کار را انجام دهید. اول ابعاد تصویر را با اندازهٔ نمایش آن هم‌خوان کنید. تصویری که در عرض پانصد پیکسل نمایش داده می‌شود، نباید در ابعاد دو هزار پیکسل بارگذاری شود.
دوم فرمت مناسب انتخاب کنید. فرمت‌های جدیدتر در حجم یکسان، کیفیت بهتری می‌دهند. توضیح کامل این فرمت‌ها در مطلب فرمت وب‌پی آمده است. سوم بارگذاری تصویر اصلی را در اولویت قرار دهید. مرورگر باید تصویر اصلی را زودتر از تصاویر پایین صفحه کشف کند.
| اقدام | چه چیزی را حل می‌کند | هزینهٔ اجرا |
|---|---|---|
| هم‌خوان کردن ابعاد | دانلود حجم اضافه | کم |
| تغییر فرمت | حجم زیاد با کیفیت یکسان | کم |
| اولویت بارگذاری | کشف دیرهنگام تصویر | کم |
| تعیین ابعاد ثابت | جهش چیدمان | کم |
| حذف تصویر تزئینی | رقابت برای پهنای باند | کم |
فونت و متن: عاملی که دیده نمی‌شود
اگر LCP صفحهٔ شما یک بلوک متنی است، مشکل احتمالاً فونت است. مرورگر تا آماده شدن فونت ممکن است متن را پنهان نگه دارد. این حالت باعث می‌شود متن دیر ظاهر شود، حتی اگر سرور سریع پاسخ داده باشد.
سه راه‌حل وجود دارد. استفاده از فونت محلی به‌جای فونت خارجی. محدود کردن تعداد وزن‌های فونت به دو یا سه وزن. و تنظیم رفتار نمایش فونت به‌گونه‌ای که متن با فونت جایگزین فوراً دیده شود، و بعد فونت اصلی جای آن بنشیند. راه سوم تجربهٔ کاربری بهتری می‌دهد، چون کاربر محتوا را زودتر می‌بیند.
هشدار: استفاده از چند فونت خارجی با چند وزن و آیکون‌های فونت‌محور یکی از سنگین‌ترین ترکیب‌های ممکن است. هر فایل فونت یک درخواست جداگانه است. اگر فقط سه وزن از یک فونت لازم دارید، بقیه را حذف کنید. این کار در بسیاری از پروژه‌ها به‌تنهایی، بخش محسوسی از زمان بارگذاری را کم می‌کند.
سرور و شبکه
اگر زمان پاسخ سرور بالا باشد، هیچ بهینه‌سازی سمت مرورگر جبرانش نمی‌کند. دو کار پایه انجام دهید. اول فعال کردن کش سمت سرور و کش مرورگر. دوم استفاده از شبکهٔ توزیع محتوا برای فایل‌های ثابت. اثر شبکهٔ توزیع، در مطلب شبکهٔ توزیع محتوا و نقش آن توضیح داده شده است.
یک نکتهٔ کاربردی برای سایت‌های ایرانی: اگر بخش زیادی از کاربران شما از یک منطقهٔ جغرافیایی هستند، سروری انتخاب کنید که به همان منطقه نزدیک باشد. کاهش تأخیر شبکه در این حالت، از هر تنظیم نرم‌افزاری مؤثرتر است.
جاوااسکریپت و رندر
اسکریپت‌های سنگین در بخش ابتدایی صفحه رندر را متوقف می‌کنند. راه‌حل استاندارد این است که اسکریپت‌های غیرضروری به تعویق بیفتند، یا به‌صورت غیرهمزمان بارگذاری شوند. اما این کار باید با احتیاط انجام شود، چون بعضی اسکریپت‌ها به ترتیب وابسته‌اند.
یک اشتباه رایج بارگذاری اسکریپت‌های تحلیلی و تبلیغاتی در سر صفحه است. این اسکریپت‌ها معمولاً برای نمایش اولیه لازم نیستند. انتقال آن‌ها به انتهای صفحه یا بارگذاری تأخیری معمولاً بی‌خطر است، و اثر محسوسی دارد.
اولویت‌بندی برای تیم کوچک
اگر تیم شما دو یا سه نفر است، نمی‌توانید همهٔ صفحات را هم‌زمان بهینه کنید. اولویت‌بندی درست بر اساس اثر تجاری است، نه بر اساس بدترین عدد. سه معیار را با هم ببینید. میزان ترافیک صفحه. نقش صفحه در مسیر فروش. و فاصلهٔ عدد فعلی از آستانه.
معمولاً صفحهٔ اصلی و صفحه‌های خدمت یا محصول بیشترین اثر را دارند. اما اگر صفحه‌ای ترافیک کمی دارد و عدد آن بسیار بد است، اولویت پایین‌تری دارد. برعکس صفحه‌ای با ترافیک بالا و عدد نزدیک به آستانه، می‌تواند با یک تغییر کوچک نتیجه بدهد و اولویت بالاتری دارد.
| معیار | وزن | نشانهٔ اولویت بالا |
|---|---|---|
| ترافیک صفحه | بالا | ورودی زیاد از جست‌وجو |
| نقش در فروش | بالا | صفحهٔ خدمت یا محصول |
| فاصله از آستانه | متوسط | نزدیک مرز بازهٔ خوب |
| هزینهٔ اصلاح | متوسط | تغییر کوچک با اثر روشن |
یک قاعدهٔ عملی برای شروع: صفحهٔ اصلی و دو صفحهٔ پرترافیک را انتخاب کنید و همان چرخهٔ چهار مرحله‌ای را روی آن‌ها اجرا کنید. بعد از دیدن نتیجه، تصمیم بگیرید آیا ادامه دهید یا ابتدا ساختار قالب را اصلاح کنید. اگر همان مشکل در همهٔ صفحات تکرار می‌شد، بهتر است یک بار در قالب حل شود، نه صفحه به صفحه.
اشتباه‌های رایج در بهینه‌سازی
بعضی از این اشتباه‌ها نتیجه را بدتر می‌کند. جدول زیر را قبل از شروع مرور کنید.
| اشتباه | پیامد | اصلاح |
|---|---|---|
| بهینه‌سازی عنصر اشتباه | اتلاف وقت بدون نتیجه | تشخیص عنصر واقعی با ابزار |
| اتکا به یک اجرا | نتیجهٔ گمراه‌کننده | میانهٔ چند اجرا |
| فشرده‌سازی بیش از حد تصویر | افت کیفیت محسوس | تعادل حجم و کیفیت |
| تأخیر در بارگذاری تصویر اصلی | بدتر شدن سنجه | اولویت به تصویر اصلی |
| نادیده گرفتن موبایل | تجربهٔ بد برای بیشتر کاربران | سنجش جداگانه موبایل |
| تغییر چند عامل هم‌زمان | نامشخص بودن اثر هر تغییر | تغییر مرحله‌ای |
چک‌لیست اجرایی
این فهرست را برای هر صفحهٔ مهم به‌صورت جداگانه اجرا کنید. برای صفحهٔ اصلی و صفحات پرترافیک، اولویت دارد.
| بررسی | وضعیت | نکته |
|---|---|---|
| عنصر LCP شناسایی شده است | بله یا خیر | با ابزار نه با حدس |
| ابعاد تصویر با نمایش هم‌خوان است | بله یا خیر | بزرگ‌ترین اثر |
| فرمت تصویر بهینه است | بله یا خیر | فرمت‌های جدیدتر |
| ابعاد ثابت تعیین شده است | بله یا خیر | جلوگیری از جهش |
| فونت‌ها محدود شده‌اند | بله یا خیر | حداکثر سه وزن |
| کش سرور فعال است | بله یا خیر | کاهش زمان پاسخ |
| اسکریپت‌های غیرضروری به تعویق افتاده‌اند | بله یا خیر | بدون شکستن عملکرد |
| عدد پایه ثبت شده است | بله یا خیر | برای مقایسه |
یک نکتهٔ پایانی دربارهٔ انتظار واقع‌بینانه: رسیدن به آستانهٔ خوب در همهٔ صفحات همیشه ممکن نیست. در شبکه‌های کند و دستگاه‌های قدیمی، محدودیت فیزیکی وجود دارد. هدف درست این است که بیشتر کاربران تجربهٔ قابل قبول داشته باشند، نه اینکه عدد آزمایشگاهی کامل شود.
یک سؤال رایج این است که چرا عدد یک صفحه با صفحهٔ دیگر فرق دارد، در حالی که قالب یکی است. پاسخ معمولاً در تصویر شاخص و حجم متن آن صفحه است. صفحه‌ای با تصویر بزرگ در بالای متن عدد بدتری دارد. به همین دلیل، نمی‌توان یک قالب را با یک عدد ارزیابی کرد. قالب را باید روی چند صفحه با محتوای متفاوت سنجید.
نکتهٔ دوم دربارهٔ ترتیب اولویت در تیم کوچک است. اگر مجبورید بین بازنویسی محتوا و بهینه‌سازی سرعت یکی را انتخاب کنید، اول سرعت را اصلاح کنید، چون اثر آن روی همهٔ صفحات و همهٔ کانال‌ها پخش می‌شود. بهبود محتوا معمولاً روی یک صفحه اثر می‌گذارد اما اصلاح قالب روی کل سایت اثر دارد.
سنجه‌های مکمل
سرعت تنها بخشی از تجربهٔ کاربری است. دو سنجهٔ دیگر هم اهمیت دارند، و باید هم‌زمان بررسی شوند. اگر فقط یکی را بهینه کنید، ممکن است تجربهٔ کلی بدتر شود.
| سنجه | چه می‌سنجد | ریسک نادیده گرفتن |
|---|---|---|
| پایداری چیدمان | جهش عناصر هنگام بارگذاری | کلیک اشتباه کاربر |
| تأخیر تعامل | زمان پاسخ به اولین کلیک | حس کندی با وجود بارگذاری سریع |
| زمان پاسخ سرور | سرعت پاسخ اولیه | کندی همهٔ سنجه‌ها |
ابزارهای سنجش
سه دسته ابزار لازم است. ابزار میدانی برای قضاوت نهایی. ابزار آزمایشگاهی برای عیب‌یابی. و ابزار صفحه به صفحه برای بررسی گروهی.
| ابزار | نوع | کاربرد اصلی |
|---|---|---|
| گزارش تجربهٔ صفحه در سرچ کنسول | میدانی | وضعیت کلی سایت |
| ابزار سنجش سرعت گوگل | آزمایشگاهی و میدانی | عیب‌یابی صفحه |
| ابزار تحلیل مرورگر | آزمایشگاهی | بررسی مرحله به مرحله |
| ابزار سنجش گروهی | آزمایشگاهی | مقایسهٔ چند صفحه |
| گزارش کاربران واقعی | میدانی | تفکیک دستگاه و شبکه |
برای کار با یکی از این ابزارها، راهنمای آموزش جی‌تی‌متریکس را ببینید. برای تصویر کلی سرعت هم مطلب اهمیت سرعت لود سایت و افزایش سرعت سایت مکمل این مقاله هستند.
سؤالات متداول
LCP خوب چه عددی است؟
۲٫۵ ثانیه یا کمتر در سطح هفتاد و پنجم درصد کاربران. این عدد در دادهٔ میدانی سنجیده می‌شود، نه در آزمایشگاه. برای قضاوت نهایی به گزارش کاربران واقعی مراجعه کنید.
آیا LCP مستقیماً بر رتبه اثر دارد؟
تجربهٔ صفحه یکی از سیگنال‌های رتبه است، اما وزن آن از محتوا و لینک کمتر است. اثر غیرمستقیم آن از طریق رفتار کاربر معمولاً مهم‌تر است. صفحهٔ کند کاربر را زودتر از دست می‌دهد.
چرا عدد ابزار من با گزارش سرچ کنسول فرق دارد؟
ابزار آزمایشگاهی در یک شرایط ثابت اجرا می‌شود. گزارش سرچ کنسول از کاربران واقعی با دستگاه و شبکهٔ متفاوت می‌آید. تفاوت طبیعی است. برای تصمیم نهایی، دادهٔ میدانی را مبنا بگیرید.
آیا فشرده‌سازی همهٔ تصاویر لازم است؟
نه. تصویر LCP اولویت اول است. بعد تصاویری که در ناحیهٔ دید قرار دارند. تصاویر پایین صفحه اثر کمی بر این سنجه دارند، اما بر حجم کل صفحه اثر دارند.
چقدر طول می‌کشد اثر تغییرات دیده شود؟
در دادهٔ آزمایشگاهی فوری. در دادهٔ میدانی معمولاً چند هفته، چون داده به‌صورت تجمعی و با تأخیر به‌روزرسانی می‌شود. عجله نکنید و بازهٔ چهار هفته‌ای را در نظر بگیرید.
آیا اسلایدر بالای صفحه مشکل‌ساز است؟
می‌تواند باشد، چون عنصر بزرگ را در طول بارگذاری تغییر می‌دهد و سنجه بازمحاسبه می‌شود. اگر اسلایدر لازم است اولین اسلاید را سریع بارگذاری کنید و بقیه را تأخیری.
آیا بهینه‌سازی سرعت روی همهٔ صفحات لازم است؟
اولویت با صفحهٔ اصلی، و صفحات پرترافیک و صفحات ورودی است. بهبود در این صفحات بیشترین اثر تجاری را دارد. بقیهٔ صفحات را می‌توان در مرحلهٔ بعد بررسی کرد.
جمع‌بندی
LCP سنجهٔ ساده‌ای است، اما اصلاح آن نیاز به ترتیب درست دارد. اول عنصر واقعی را پیدا کنید. دوم بفهمید کدام مرحلهٔ زمانی بزرگ‌ترین سهم را دارد. سوم از مؤثرترین اقدام شروع کنید، که در بیشتر موارد تصویر است. چهارم نتیجه را با دادهٔ میدانی بسنجید، نه با حس شخصی.
اگر این چرخه را برای صفحهٔ اصلی و دو صفحهٔ پرترافیک اجرا کنید، معمولاً بخش زیادی از مشکل حل می‌شود. برای بررسی جنبه‌های فنی دیگر، مطلب سئو فنی را ببینید.