تا حالا شده با کلی ذوق روی یه لینک کلیک کنی، ولی صفحه انقدر کُند، سنگین و ‘لَش’ بالا بیاد که همون ثانیه اول پشیمون بشی و فرار کنی؟ یا بدتر، خواستی روی یه دکمه کلیک کنی ولی یهو صفحه پریده و انگشتت خورده روی یه تبلیغ رو اعصاب؟
این حس بد، این تجربه ناخوشایند، دقیقاً همون چیزیه که گوگل اسمش رو گذاشته «تجربه کاربری ضعیف» و مستقیماً تو گزارش Experience (تجربه کاربری) سایتها دنبالش میگرده.
من نگین شیخ الاسلامیام و امروز میخوام به زبون خودمونی بریم سراغ سه تا غول مرحله آخر سئو فنی که اسمشون Core Web Vitals هست. قراره یاد بگیریم چطور این سه تا معیار (LCP, INP, CLS) رو نه فقط برای گوگل، که برای حس خوبِ کاربرمون رام کنیم.
📊 جدول کاربردی
قبل از اینکه عمیق بشیم، بیا یه نمای کلی از این سه تا معیار داشته باشیم تا دستت بیاد با چی طرفیم:
| معیار (Metric) | مخفف چیست؟ | چه چیزی را میسنجد؟ | امتیاز خوب (Good) |
| LCP | Largest Contentful Paint | سرعت بارگذاری (چقدر طول میکشه محتوای اصلی دیده بشه؟) | زیر ۲.۵ ثانیه |
| INP | Interaction to Next Paint | سرعت تعامل (چقدر طول میکشه سایت به کلیک جواب بده؟) | زیر ۲۰۰ میلیثانیه |
| CLS | Cumulative Layout Shift | ثبات بصری (چقدر صفحه موقع لود شدن میپره؟) | زیر 0.1 |
Core Web Vitals (هستههای حیاتی وب) چیست و چرا سرنوشت سئوی شما به آن گره خورده است؟
بیا یه لحظه صادق باشیم. تا حالا شده وارد یه سایتی بشی و قبل از اینکه اصلاً چیزی بالا بیاد، از بس منتظر موندی، دکمه ‘بک’ رو بزنی و فرار کنی؟ یا بدتر، خواستی روی یه دکمه کلیک کنی، ولی یهو یه تبلیغ پریده جلوش و روی اون کلیک کردی؟
حس بدیه، نه؟ انگار یکی وسط حرفت پریده یا تو رو معطل یه کار ساده کرده.
این حس بد، دقیقاً همون چیزیه که گوگل میخواد با Core Web Vitals (CWV) یا ‘هستههای حیاتی وب’ جلوش رو بگیره. این فقط یه بحث فنی و خشک برای برنامهنویسها نیست؛ این داستانِ «احترام» به وقت و اعصاب کاربَره.
امروز میخوام به زبون ساده و خودمونی برات تعریف کنم که این سه تا معیار اصلی چی هستن و چرا اگه بهشون بیتوجهی کنی، انگار داری قید رتبههای خوب گوگل رو میزنی.
تعریف ساده Core Web Vitals: فراتر از «سرعت سایت»
سالهاست که همهمون شنیدیم «سایتت باید سریع باشه». خب آره، این که درسته. ولی «سریع» یه کلمه خیلی کلیه. مثل این میمونه که بگی «غذا باید خوشمزه باشه». خب چه طعمی؟ چقدر تند؟
گوگل با Core Web Vitals اومده این «سرعت» رو برای ما معنی کرده. گفته من دیگه به یه عدد کلی نگاه نمیکنم. من به تجربه واقعی کاربر نگاه میکنم.
یعنی چی؟ یعنی برای گوگل مهمه که:
- کاربر چقدر سریع محتوای اصلی رو میبینه؟
- چقدر سریع میتونه با صفحه تعامل کنه (مثلاً کلیک کنه)؟
- و چقدر صفحهات موقع بارگذاری ثبات داره و بالا پایین نمیپره؟
پس CWV فقط سرعت لود شدنِ کل صفحه نیست؛ این استاندارد گوگل برای سنجش حس خوب (یا بد) کاربر تو اون چند ثانیه اول ورود به سایته.
تأثیر مستقیم LCP, FID, و CLS بر رتبه سئو (فاکتور Page Experience)
خب، حالا چرا اینقدر مهمه و سرنوشت سئوی ما بهش گره خورده؟
چون گوگل رسماً اعلام کرده که Core Web Vitals بخش خیلی مهمی از سیگنالی به اسم «تجربه صفحه» (Page Experience) هستن.
«تجربه صفحه» یعنی اینکه کاربر از لحظهای که روی لینک تو در نتایج جستجو کلیک میکنه تا وقتی که از سایتت خارج میشه، چه حسی داره.
- آیا سایتت امنه (HTTPS)؟
- آیا روی موبایل خوب نمایش داده میشه (Mobile-Friendly)؟
- و آیا این هستههای حیاتی وبت (CWV) اوضاعشون خوبه؟
اگه جوابت به آخری «نه» باشه، گوگل میگه این سایت تجربه کاربری رضایتبخشی ارائه نمیده. در نتیجه، حتی اگه محتوای فوقالعادهای داشته باشی، ممکنه یه رقیب که محتواش کمی ضعیفتره ولی تجربه کاربری بهتری داره، تو رتبهبندی از تو جلو بزنه. به همین صراحت!
ارتباط پنهان Core Web Vitals با E-E-A-T (چگونه سرعت، اعتماد میسازد؟)
این تیکهش رو شاید کمتر جایی شنیده باشی، ولی برای من که همیشه روی E-E-A-T (تجربه، تخصص، اعتبار، اعتماد) حساسم، خیلی مهمه.
«اعتماد» (Trustworthiness) فقط به این نیست که بگی منبع اطلاعاتت کجاست یا نویسندهات یه متخصصه. اعتماد از همون ثانیه اول ساخته میشه.
سایتی که کُنده، سایتی که دکمههاش موقع کلیک میپرن، ناخودآگاه حس «غیرحرفهای» بودن یا حتی «ناامن» بودن رو منتقل میکنه. مثل یه فروشگاه شلخته و بههمریختهست که توش احساس راحتی نمیکنی.
وقتی سایتت مثل ساعت کار میکنه، سریع و روانه، تو داری در عمل به کاربر نشون میدی که براش ارزش قائل بودی، وقت گذاشتی و توی کارت متخصص هستی. اینطوریه که CWV خوب، به طور غیرمستقیم، پایههای «اعتماد» (T) و «اعتبار» (A) تو رو توی ذهن کاربر (و البته گوگل) محکمتر میکنه.
آشنایی با سه معیار اصلی: بارگذاری (LCP)، تعامل (FID) و ثبات (CLS)
این سه تا معیار، در واقع سه تا سوالی هستن که گوگل از سایتت میپرسه. بیا خیلی خودمونی با تصویرسازی بازشون کنیم:
۱. LCP (Largest Contentful Paint) – سرعت بارگذاری
- سوال گوگل: «بزرگترین و مهمترین بخش محتوات (معمولاً عکس اصلی بالای صفحه یا اولین پاراگراف بزرگ) چقدر طول میکشه تا به کاربر نشون داده بشه؟»
- تصویرسازیش: فکر کن وارد یه اتاق میشی. LCP یعنی چقدر طول میکشه تا چراغ اصلی روشن بشه و تو بفهمی کجایی. اگه این فرآیند طول بکشه، تو یه مدت توی تاریکی معطلی و حس ناخوشایندی داری. (گوگل میگه زیر ۲.۵ ثانیه عالیه).
۲. FID (First Input Delay) – سرعت تعامل
- سوال گوگل: «از وقتی کاربر روی یه دکمه کلیک کرد (یا مثلاً توی یه فرم شروع به تایپ کرد)، چقدر طول کشید تا سایتت جواب بده و فرآیند رو شروع کنه؟»
- تصویرسازیش: این همون حس «گیر کردن» دکمهست. مثل زنگ در خونهای که میزنی، ولی صداش ۱۰ ثانیه بعد درمیاد! خیلی رو اعصابه و کاربر حس میکنه سایتت خرابه. (گوگل میگه زیر ۱۰۰ میلیثانیه عالیه).
- (نکته: گوگل داره FID رو با یه معیار جدیدتر به اسم INP جایگزین میکنه که حتی سختگیرتره، ولی فعلاً پایه و اساسش همینه).
۳. CLS (Cumulative Layout Shift) – ثبات بصری
- سوال گوگل: «چقدر محتوای صفحهات موقع لود شدن، جابجا شد و بالا پایین پرید؟»
- تصویرسازیش: این همون مثالیه که اول زدم. میخوای روی دکمه «افزودن به سبد خرید» کلیک کنی، یهو یه بنر تبلیغاتی بالای صفحه لود میشه و کل صفحه رو میده پایین، و تو اشتباهی روی دکمه «انصراف» کلیک میکنی. این برای تجربه کاربری یه فاجعهست! (گوگل میگه این جابجایی باید نزدیک به صفر باشه).
بخش اول: LCP (Largest Contentful Paint) چیست؟ عمیقترین بررسی معیار بارگذاری
خب، بریم سراغ اولین غول از این سه غول مرحله آخر: LCP یا Largest Contentful Paint.
اگه بخوام یه تجربه شخصی رو بگم، LCP برای من شبیه اون لحظهایه که توی یه رستوران شلوغ منتظر سفارشم هستم. برام مهم نیست چقدر طول میکشه تا پیشغذا و نوشیدنی بیاد؛ من منتظر اون «غذای اصلی»ام! LCP دقیقاً همون «غذای اصلی» صفحه توئه. اون بزرگترین و مهمترین چیزیه که کاربر اومده تا ببینه.
معنی LCP به زبان ساده: صفحه شما چقدر سریع “مفید” به نظر میرسد؟
بیا یه جور دیگه بهش نگاه کنیم.
تصور کن وارد یه فروشگاه میشی. LCP این نیست که چقدر طول میکشه در فروشگاه باز بشه. LCP اینه که چقدر طول میکشه تا تو بتونی «ویترین اصلی» و اون محصولی که براش اومدی رو ببینی.
به زبون فنی، LCP مدت زمانی رو اندازه میگیره که بزرگترین عنصر محتوایی (حالا چه یه عکس بزرگ بالای صفحه باشه، چه یه بلوک متنی یا یه ویدیو) توی دید کاربر (viewport) بارگذاری و قابل دیدن بشه.
چرا این مهمه؟ چون اون لحظهایه که کاربر با خودش میگه: «آها، درسته. جای درستی اومدم و این صفحه داره لود میشه». اگه این لحظه زیادی طول بکشه، کاربر حس میکنه سایتت کُنده یا اصلاً خرابه و… خب، دکمه بک رو میزنه.
امتیاز خوب LCP (Good, Needs Improvement, Poor) از نظر گوگل چیست؟
گوگل برای اینکه به ما بگه «حس کاربر» چیه، این زمانبندیها رو تعریف کرده:
- خوب (Good): 💚 زیر ۲.۵ ثانیه
- این یعنی عالی! کاربر اصلاً فرصت نمیکنه به «منتظر بودن» فکر کنه. همه چیز سریع و روونه.
- نیاز به بهبود (Needs Improvement): 💛 بین ۲.۵ تا ۴ ثانیه
- اینجا منطقه زرده. کاربر یه کم مکث میکنه. ممکنه یه نفس عمیق بکشه و با خودش بگه «چرا بالا نمیاد؟». اینجا جاییه که داری کاربر رو کمکم عصبی میکنی.
- ضعیف (Poor): ❤️ بالای ۴ ثانیه
- این یعنی فاجعه! ۴ ثانیه تو دنیای وب مثل ۴ ساعته. به احتمال ۹۰ درصد، کاربر قبل از اینکه اصلاً عنصر LCP تو رو ببینه، صفحه رو بسته و رفته سراغ رقیبت.
دلایل اصلی LCP پایین: از سرور کند (TTFB) تا تصاویر و فونتهای سنگین
وقتی LCP سایتت داغونه، معمولاً تقصیر یکی از این چندتا رفیق نابابه:
- سرور کند (TTFB بالا):
- TTFB یا Time to First Byte یعنی چقدر طول میکشه تا سرور تو اصلاً جواب «سلام» مرورگر رو بده. اگه هاست یا سرورت ضعیف باشه، مثل اینه که آشپزخونه رستوران کلاً خواب باشه. تا اون بیدار بشه و اولین بایت اطلاعات رو بفرسته، کلی از زمان LCP از دست رفته.
- تصاویر غولپیکر (Unoptimized Images):
- این شایعترین دلیله. یه عکس هدر ۵ مگابایتی که مستقیم از دوربین عکاسی آپلود شده! این مثل اینه که بخوای یه فایل زیپ نشده رو با اینترنت دایالآپ دانلود کنی. کاربر بیچاره باید کلی منتظر بشه تا اون عکس سنگین لود بشه.
- فونتهای سنگین و خارجی (Heavy Fonts):
- گاهی اوقات اون عنصر LCP، یه تیکه متن بزرگه (مثل عنوان مقاله). اگه برای نمایش این متن، مرورگر مجبور باشه بره از یه سرور دیگه یه فایل فونت سنگین رو دانلود کنه، متنت تا اون موقع یا نشون داده نمیشه یا با یه فونت دیگه نشون داده میشه و بعداً میپره (که این خودش CLS رو هم خراب میکنه).
- کدهای جاوا اسکریپت و CSS که جلوی لود رو میگیرن (Render-Blocking):
- اینا مثل نگهبانهای دم در هستن. تا وقتی این کدها (مثلاً کدهای مربوط به اسلایدر یا انیمیشنهای مختلف) کامل اجرا نشن، به اون عنصر LCP اجازه نمیدن که خودش رو نشون بده.
۷ تکنیک طلایی برای بهبود LCP (شامل بهینهسازی TTFB، فشردهسازی تصاویر و Caching)
خب، چطوری این «غذای اصلی» رو سریعتر به میز مشتری برسونیم؟
- آشپزخونه (سرور) رو قوی کن: روی یه هاست یا سرور خوب سرمایهگذاری کن. اگه TTFB تو بالاست، هر کار دیگهای بکنی، باز هم اولش لنگی.
- از حافظه پنهان (Caching) استفاده کن: بهجای اینکه سرور برای هر کاربر، هر بار صفحه رو از اول بسازه، از سیستم کش استفاده کن تا یه نسخه آماده و سریع تحویل کاربر بده. (مثل غذای از قبل آماده شده).
- از شبکه توزیع محتوا (CDN) استفاده کن: این کار باعث میشه فایلهای سنگینت (مثل عکسها) از نزدیکترین سرور به کاربر براش ارسال بشه. انگار بهجای یه رستوران مرکزی، چندتا شعبه تو جاهای مختلف داشته باشی.
- عکسها رو «رژیم» بده (Image Compression): قبل از آپلود، حجم عکسهات رو تا جای ممکن کم کن. ابزارهای آنلاین زیادی برای این کار هست.
- از فرمتهای مدرن عکس (مثل WebP) استفاده کن: این فرمتها کیفیت رو عالی نگه میدارن ولی حجمشون خیلی کمتر از JPG یا PNG هست.
- بارگذاری تنبل (Lazy Loading) رو مدیریت کن: لود تنبل (که عکسها فقط وقتی لود بشن که کاربر بهشون نزدیک میشه) عالیه، اما… مراقب باش! هیچوقت عنصر LCP (عکس بالای صفحه) رو Lazy Load نکن. این یه اشتباه کشندهست. اون باید بلافاصله لود بشه.
- فونتها رو بهینهسازی کن: فونتها رو روی سرور خودت میزبانی کن و سعی کن فقط وزنهایی از فونت که لازم داری رو لود کنی.
آموزش گام به گام شناسایی عنصر LCP در صفحه
اینکه بدونی LCP ضعیفه یه چیزه، اینکه بفهمی کدوم عنصر دقیقاً LCP توئه، یه چیز دیگهست. سادهترین راهش اینه:
- برو به سایت PageSpeed Insights گوگل.
- آدرس صفحهای که میخوای بررسی کنی رو وارد کن.
- صبر کن تا آنالیز تموم بشه.
- توی نتایج، بیا پایین تا به بخش «عیبیابیها» (Diagnostics) برسی.
- دنبال گزینهای بگرد که میگه: «Largest Contentful Paint element» یا «عنصر بزرگترین رندر محتوایی».
گوگل بهت میگه: «ببین! این عکس (یا این متن) همون عنصر LCP توئه که انقدر طولش داده تا لود بشه». حالا تو دقیقاً میدونی باید روی بهینهسازی کدوم بخش تمرکز کنی.
بخش دوم: FID (First Input Delay) چیست؟ سنجش اولین تجربه تعاملی کاربر
تا حالا شده دکمه آسانسور رو بزنی و چراغش روشن نشه؟ یا روی یه دکمه «خرید» تو یه سایت کلیک کنی و هیچی نشه؟ حتی یه چرخونک لود هم نیاد. تو اون یه ثانیه اول، اولین فکری که به ذهنت میرسه چیه؟ «اِ… خرابه؟»
این حس شک و تردید، این حس «نادیده گرفته شدن» توسط صفحه، دقیقاً همون چیزیه که FID (First Input Delay) یا «تأخیر در اولین ورودی» میخواد اندازهگیری کنه.
معنی FID: چقدر طول میکشد تا سایت به اولین کلیک یا تپ کاربر پاسخ دهد؟
FID به زبان ساده، فاصله زمانی بین «اولین» کاریه که کاربر تو صفحهات میکنه (مثلاً کلیک روی یه دکمه، باز کردن یه منوی کشویی، یا تپ روی یه لینک) و «شروع پاسخ» مرورگر به اون کاره.
نکته کلیدی: FID کل زمان انجام اون کار رو اندازه نمیگیره. فقط اون «تأخیر» اولیه رو حساب میکنه.
بیا یه مثال بزنم. فکر کن رفتی کافیشاپ. FID این نیست که چقدر طول میکشه تا قهوهات آماده بشه. FID اون فاصله زمانیه که تو میگی «سلام، یه لاته لطفاً» تا وقتی که باریستا سرش رو بلند میکنه و میگه «چشم، الان».
اگه باریستا سرش شلوغ باشه و همون «چشم» گفتن اولش ۳ ثانیه طول بکشه، تو حس میکنی کلاً نادیده گرفته شدی. FID همون «چشم» گفتنِ سایت توئه.
امتیازدهی FID و چرا TBT (Total Blocking Time) معیار دقیقتری در عمل است؟
گوگل میگه اون «چشم» گفتن باید چقدر سریع باشه؟
- خوب (Good): 💚 زیر ۱۰۰ میلیثانیه (تقریباً آنی. کاربر اصلاً حسش نمیکنه).
- نیاز به بهبود (Needs Improvement): 💛 بین ۱۰۰ تا ۳۰۰ میلیثانیه (یه لگ و تأخیر کوچیک ولی قابل درک. کاربر یه کم مکث میکنه).
- ضعیف (Poor): ❤️ بالای ۳۰۰ میلیثانیه (اینجاست که کاربر حس میکنه دکمه خرابه و احتمالاً دوباره کلیک میکنه).
اما یه مشکلی هست: FID یه معیاره که فقط میشه از «کاربران واقعی» (Field Data) گرفت. وقتی ما داریم سایت رو تو آزمایشگاه خودمون (Lab Data) با ابزارهایی مثل PageSpeed Insights تست میکنیم، که کاربری وجود نداره که کلیک کنه!
اینجاست که رفیق FID، یعنی TBT (Total Blocking Time)، وارد میشه.
TBT میاد کل زمانی که مرورگر «مشغول» بوده و نمیتونسته به کاربر جواب بده (مثلاً داشته یه کد جاوا اسکریپت سنگین رو اجرا میکرده) رو جمع میزنه.
برگردیم به مثال کافیشاپ: TBT کل زمانیه که باریستا سرش تو دستگاه اسپرسو بوده و اصلاً حواسش به پیشخوان نبوده. اگه TBT بالا باشه، یعنی باریستا خیلی سرش شلوغ بوده، و شانس اینکه اولین مشتری (کاربر) که میاد دقیقاً به همون لحظه شلوغی بخوره و «تأخیر» (FID) رو تجربه کنه، خیلی زیاده.
پس ما تو عمل TBT رو بهینه میکنیم تا FID کاربرامون خوب بشه.
خبر مهم: جایگزینی FID با INP (Interaction to Next Paint) در ۲۰۲۴ (چرا این تغییر حیاتی است؟)
خب، یه خبر داغ! FID بازنشسته شد. از مارس ۲۰۲۴، گوگل رسماً INP (Interaction to Next Paint) رو به عنوان یکی از هستههای حیاتی وب (Core Web Vital) جایگزین FID کرد.
چرا؟ چون FID یه کم خوشبین بود. فقط به اولین کلیک و فقط تأخیر اون نگاه میکرد.
ولی INP خیلی سختگیرتر و باهوشتره. INP به تمام تعاملهای کاربر تو صفحه (کلیکها، تپها، تایپ کردن) نگاه میکنه و کل فرآیند رو از لحظه کلیک تا لحظهای که کاربر تغییر بصری رو روی صفحه میبینه (مثلاً اون چرخونک لود شروع به چرخیدن میکنه یا محصول به سبد خرید اضافه میشه) اندازه میگیره.
چرا این تغییر حیاتیه؟
چون FID رو میشد راحتتر دور زد. شاید اولین کلیک سریع بود، ولی کلیک روی «افزودن به سبد خرید» که اصل کاری بود، ۵ ثانیه طول میکشید!
INP یعنی: «من به کل تجربه تعاملی کاربر تو صفحه اهمیت میدم، نه فقط سلام اولش.» این تغییر، ما متخصصهای سئو و برنامهنویسها رو مجبور میکنه که به کل سفر کاربر تو صفحه فکر کنیم و مطمئن بشیم همهچیز روان و سریع کار میکنه.
دلایل اصلی FID (و INP) بالا: مقصر همیشگی، جاوا اسکریپت (JavaScript)
بریم سراغ ریشهیابی. کی اون باریستا رو اونقدر مشغول کرده که جواب مشتری رو نمیده؟
تو ۹۹ درصد موارد، جوابش یه کلمهست: جاوا اسکریپت (JavaScript).
مرورگر یه چیزی داره به اسم «نخ اصلی» (Main Thread). این نخ اصلی مثل یه جاده یکطرفه میمونه که همهکارها باید از توش رد بشن: خوندن HTML، اعمال کردن استایلهای CSS، و اجرای کدهای جاوا اسکریپت.
حالا تصور کن یه کد JS سنگین (مثلاً مال یه اسلایدر خفن، یا یه ابزار آمارگیر، یا یه چتباکس) میاد و این جاده رو کامل میبنده. تو این مدت، مرورگر قفله. اصطلاحاً میگیم «Main Thread بلاک شده».
اگه کاربر دقیقاً تو همون لحظه روی یه دکمه کلیک کنه، اون کلیک میره ته صف. مرورگر اول باید اون کد JS سنگین رو تموم کنه، بعد برسه به کلیک کاربر. و این یعنی… FID و INP داغون!
راهکارهای عملی بهبود FID/INP: از Defer/Async کردن اسکریپتها تا Code Splitting
خب، چطوری این جاده یکطرفه رو باز کنیم؟
- اسکریپتها رو به تعویق بنداز (Defer و Async):
- Defer: این بهترین دوست ماست. به مرورگر میگه: «این فایل JS رو دانلود کن، ولی فعلاً اجراش نکن. برو اول کل صفحه رو بساز (HTML رو بخون)، بعد که کارت تموم شد، اینو اجرا کن.» این برای اکثر اسکریپتها عالیه.
- Async: این به مرورگر میگه: «این فایل رو همزمان دانلود و اجرا کن، کاری هم به بقیه صفحه نداشته باش.» این برای اسکریپتهایی خوبه که به هیچی وابستگی ندارن (مثل گوگل آنالیتیکس)، ولی اگه زیاد استفاده بشه میتونه باز هم جاده رو مسدود کنه.
- شکستن کد (Code Splitting):
- بهجای اینکه یه فایل JS غولپیکر ۱ مگابایتی برای کل سایتت داشته باشی، بیا بشکنش به تیکههای کوچیک.
- کاربر تو صفحهی «درباره ما»؟ خب فقط JS مورد نیاز همون صفحه رو بهش بده. چرا باید کد مربوط به «فرایند پرداخت» رو هم دانلود کنه؟ اینطوری حجم کدی که نخ اصلی رو درگیر میکنه، خیلی کمتر میشه.
- اولویتبندی کارها:
- از خودت بپرس: آیا این اسلایدر، این انیمیشن، این چتباکس واقعاً باید تو ثانیه اول لود بشه؟ یا میتونیم لود شدنش رو چند ثانیه عقب بندازیم تا اول کارهای اصلی (مثل کلیک کاربر) انجام بشه؟ خیلی وقتها با تأخیر در لود کدهای غیرضروری، میتونیم INP رو به شدت بهبود بدیم.
بخش سوم: CLS (Cumulative Layout Shift) چیست؟ کابوس ثبات بصری و تجربه کاربری
اوه… CLS! بذار همین اول یه اعتراف شخصی بکنم: هیچچیز، مطلقا هیچچیز به اندازه CLS بالا من رو به عنوان یه کاربر عصبی نمیکنه.
شده تا حالا با دقت تمام بخوای روی دکمه «حذف» کلیک کنی، اما درست تو کسری از ثانیه قبل از لمس صفحه، یه بنر تبلیغاتی بالای صفحه لود بشه، کل صفحه رو شوت کنه پایین، و انگشت تو بهجاش بخوره روی دکمه «تایید نهایی خرید»؟!
این فقط آزاردهنده نیست؛ این یه خیانت به اعتماده! این حس وحشتناک که «صفحه زیر دستم بازی میکنه» دقیقاً همون چیزیه که CLS اندازهگیریش میکنه.
معنی CLS با یک مثال: چرا عناصر صفحه جابجا میشوند (زلزله صفحه)؟
CLS یا «تغییر چیدمان تجمعی»، به زبان خودمونی یعنی «زلزله صفحه».
یعنی چقدر از محتوای صفحهات بدون اینکه کاربر خواسته باشه یا انتظار داشته باشه، جلوی چشمش جابجا میشه.
مثال معروفش همینه:
- تو وارد یه صفحه مقاله میشی.
- شروع میکنی به خوندن پاراگراف اول.
- همون موقع، مرورگر تازه یادش میاد که یه عکس بزرگ بالای اون پاراگراف بوده که هنوز لود نشده.
- عکس لود میشه و یهو… بوم! مثل یه آجر میافته وسط صفحهت و اون متنی که داشتی میخوندی رو ۵ سانت میفرسته پایینتر.
- تو که داشتی میخوندی، حالا گُم شدی. مجبوری دوباره دنبال خطی که بودی بگردی.
این جابجایی ناگهانی، این «لرزش» بصری، یه امتیاز منفی CLS برای تو ثبت میکنه.
چگونه گوگل CLS را محاسبه میکند و امتیاز خوب آن چند است؟
نمیخوام با فرمولهای پیچیده گیجت کنم، ولی درک کلیش سادهست. گوگل برای محاسبه CLS به دو تا چیز نگاه میکنه:
- چقدر از صفحه جابجا شد؟ (مثلاً ۳۰٪ از ارتفاع صفحه تحت تأثیر قرار گرفت).
- چقدر جابجا شد؟ (مثلاً اون بنره، کل محتوا رو ۱۰٪ به پایین هل داد).
بعد اینا رو تو یه فرمولی میذاره و یه عددی بهت میده. تو فقط باید این سه تا محدوده رو بشناسی:
- خوب (Good): 💚 زیر 0.1
- عالیه! یعنی صفحه تو مثل سنگ ثابته. کاربر با آرامش میتونه بخونه و کلیک کنه.
- نیاز به بهبود (Needs Improvement): 💛 بین 0.1 تا 0.25
- یعنی صفحه «لرزش»های محسوسی داره. کاربر متوجه میشه و یه کم اذیت میشه.
- ضعیف (Poor): ❤️ بالای 0.25
- این یعنی فاجعه! صفحهات یه زلزله تمامعیاره و کاربر رسماً نمیدونه داره چی رو میبینه و کجا کلیک میکنه.
شایعترین دلایل CLS بالا: تصاویر بدون ابعاد، تبلیغات، فونتها و محتوای داینامیک
کیا این زلزله رو راه میندازن؟ چهارتا مجرم اصلی داریم:
- تصاویر و ویدئوهای بدون ابعاد (Dimensions):
- این مقصر شماره یکه. وقتی تو به مرورگر نگی عکسی که میخوای لود کنی «دقیقاً چقدر جا میگیره» (یعنی عرض و ارتفاعش چقدره)، مرورگر هم براش جایی خالی نمیذاره. اول متن رو میاره، بعد که عکس لود شد، تازه میفهمه باید براش جا باز کنه و کل متن رو هل میده پایین.
- تبلیغات، Iframeها و Embedها:
- اینا مثل مهمون ناخوندهان. معمولاً دیرتر لود میشن و ابعادشون هم همیشه مشخص نیست. یهو یه بنر تبلیغاتی با یه سایز عجیب وسط محتوا ظاهر میشه و همهچیز رو به هم میریزه.
- فونتهای سفارشی (Web Fonts):
- گاهی اوقات مرورگر اول متن رو با یه فونت پیشفرض (مثلاً Arial) نشون میده. چند لحظه بعد، اون فونت خوشگل «وزیر» یا «ایران سنس» که تو میخواستی لود میشه. اگه این فونت جدیده یه کم بزرگتر یا کوچکتر از فونت قبلی باشه، کل پاراگراف «میلرزه» تا خودش رو با فونت جدید وفق بده.
- محتوای داینامیک (Dynamic Content):
- اون نوارهای «کوکیها رو بپذیر» یا «در خبرنامه ما عضو شو» که بعد از لود صفحه، یهو از بالا یا پایین میپرن وسط صفحه و محتوای اصلی رو جابجا میکنن، دقیقاً دارن CLS تولید میکنن.
چگونه CLS را برای همیشه نزدیک به صفر نگه داریم؟ (تکنیکهای رزرو فضا)
راه حل CLS یه کلمهست: «رزرو کردن فضا».
باید مثل یه کارگردان حرفهای باشی. قبل از اینکه بازیگر (محتوا) وارد صحنه (صفحه) بشه، باید دقیقاً جاش رو مشخص کنی.
- همیشه به تصاویر
widthوheightبده:- این سادهترین و حیاتیترین کاره. تو کد HTML عکسهات، همیشه عرض و ارتفاع رو مشخص کن.
<img src="example.jpg" width="600" height="400" ...>- اینطوری مرورگر میفهمه: «آها، اینجا قراره یه عکس ۶۰۰ در ۴۰۰ بیاد»، پس همون اول به اندازه یه مستطیل ۶۰۰ در ۴۰۰ جا براش خالی میذاره. حتی اگه عکس ۱۰ ثانیه دیگه لود بشه، متن بغلش تکون نمیخوره.
- از
aspect-ratioدر CSS استفاده کن:- این روش مدرنتره. میتونی به مرورگر بگی: «من نمیدونم عرض چقدره (چون صفحه ریسپانسیوه)، ولی نسبت عرض به ارتفاع این عکس همیشه ۱۶ به ۹ هست». مرورگر خودش فضا رو بر اساس اون نسبت رزرو میکنه.
- برای تبلیغات و Iframeها جای ثابت در نظر بگیر:
- اگه میدونی قراره یه بنر تبلیغاتی ۳۰۰ در ۲۵۰ پیکسلی داشته باشی، یه
divباmin-height: 250pxبراش بذار. اینطوری اون فضا از اول خالی میمونه تا تبلیغ لود بشه و چیزی رو هل نده.
- اگه میدونی قراره یه بنر تبلیغاتی ۳۰۰ در ۲۵۰ پیکسلی داشته باشی، یه
- مراقب لود شدن فونتها باش:
- از تکنیکهای
font-display: swapیاoptionalاستفاده کن. یا اگه میتونی، فونتها رو از سرور خودت لود کن وpreloadکن تا سریعتر حاضر بشن و اون جابجایی اتفاق نیفته.
- از تکنیکهای
- محتوای داینامیک رو بالای صفحه نپرون:
- اون نوار «عضویت در خبرنامه» رو بالای محتوای اصلی ظاهر نکن. اگه میخوای چیزی اضافه کنی، یه فضایی براش در نظر بگیر که از اول باشه یا طوری طراحیش کن که روی محتوا بیاد (Overlay) نه اینکه محتوا رو به پایین هل بده.
یادته گفتم CLS مثل خیانت به اعتماده؟ خب، «رزرو کردن فضا» دقیقاً برعکسشه. یعنی احترام به کاربر. یعنی بهش میگی: «راحت باش و بخون. من قول میدم این صفحه زیر پات تکون نخوره.»
خب، تا اینجای کار فهمیدیم که این سه تا غول (LCP, FID/INP, CLS) چطور میتونن حال کاربر ما رو بد کنن. مثل اینه که بدونیم مریض تب داره.
حالا وقتشه «دماسنج» رو برداریم و ببینیم تبش دقیقاً چنده و مهمتر از اون، علتش چیه. اینا ابزارهایی هستن که تو جعبهابزار من همیشه دم دستن:
جعبه ابزار شما: چگونه LCP, FID, و CLS را به درستی اندازهگیری کنیم؟
تفاوت کلیدی دادههای میدانی (Field Data) و آزمایشگاهی (Lab Data)
قبل از اینکه بریم سراغ ابزارها، باید یه تفاوت خیلی مهم رو درک کنی. این مهمترین بخش کاره.
۱. دادههای آزمایشگاهی (Lab Data):
- این چیه؟ این یعنی تو سایتت رو تو یه محیط کنترلشده تست میکنی. مثل اینکه یه ماشین رو ببری تو گاراژ، بذاری روی دستگاه و تستش کنی.
- مثال: وقتی با PageSpeed Insights یا Lighthouse «همین الان» یه تست میگیری. این تست معمولاً با یه اینترنت پرسرعت و یه دستگاه مشخص انجام میشه.
- خوبیش چیه؟ عالیه برای «عیبیابی» (Debugging). چون همون لحظه میتونی مشکل رو پیدا کنی و بعد از اینکه درستش کردی، دوباره تست کنی و ببینی بهتر شده یا نه.
۲. دادههای میدانی (Field Data):
- این چیه؟ این یعنی اطلاعاتی که از کاربران واقعی تو جمعآوری شده.
- تصور کن: این دیگه تست ماشین تو گاراژ نیست. این گزارش رانندگیِ هزاران نفر با اون ماشینه؛ یکی تو جاده خاکی با گوشی قدیمی و اینترنت 3G، یکی تو اتوبان با آیفون و 5G.
- خوبیش چیه؟ این همون چیزیه که گوگل برای رتبهبندی بهش نگاه میکنه. به این دادهها میگن CrUX (Chrome User Experience Report). گوگل براش مهمه که کاربر واقعیت چه حسی داشته، نه اینکه تو آزمایشگاه تو چقدر سریع بوده.
حرف خودمونی: Lab Data برای عیبیابی توئه، Field Data برای کارنامه نهایی پیش گوگل.
استفاده از Google Search Console (گزارش اختصاصی Core Web Vitals)
این «بیمارستان» اصلی ماست. جاییه که میفهمیم کدوم بخشهای سایت «مریض» هستن.
- کجاست؟ توی منوی سرچ کنسول، یه بخش داری به اسم Core Web Vitals (یا «هستههای حیاتی وب»).
- چطوری کار میکنه؟ این گزارش فقط بر اساس دادههای میدانی (Field Data) کار میکنه.
- چی به ما میگه؟ سرچ کنسول بهت نمیگه دقیقاً چرا صفحهات کُنده. ولی با صدای بلند بهت میگه: «هی! این ۱۰۰ تا صفحهات وضعیت LCP ضعیف (Poor) دارن!» یا «این ۵۰۰ تا صفحه CLS شون نیاز به بهبود (Needs Improvement) داره.»
- نگاه من: من روزم رو با چک کردن این گزارش شروع میکنم. این اولین سرنخ برای شروع عیب یابیه. این به من «لیست بیماران» رو میده.
تحلیل عملی و دریافت توصیهها با PageSpeed Insights
خب، حالا که از سرچ کنسول «لیست بیماران» (URL های ضعیف) رو درآوردیم، وقتشه یکیشون رو برداریم و ببریم پیش «پزشک عمومی». اون پزشک همین PageSpeed Insights یا PSI هست.
- چطوری کار میکنه؟ این ابزار، عشق منه. چرا؟ چون هر دو نوع داده رو بهت میده.
- ۱. گزارش میدانی (بالای صفحه): اول از همه بهت میگه: «ببین، کاربران واقعی تو ۲۸ روز گذشته این حس رو داشتن» (این همون Field Data یا CrUX هست).
- ۲. گزارش آزمایشگاهی (پایینتر): بعد خودش همون لحظه یه تست آزمایشگاهی (Lab Data) میگیره.
- جادوی اصلی (توصیهها): قشنگترین بخشش اینه که مثل یه دکتر خوب، بهت «نسخه» میده. زیر همون تست، بخش «عیبیابی» (Diagnostics) و «فرصتها» (Opportunities) رو داری.
- مثال: دقیقاً بهت میگه: «مشکل LCP تو به خاطر این عکسه. برو فشردهش کن.» یا «CLS تو داغونه چون به این
divابعاد ندادی.» یا «FID/INP ت بالاست چون این اسکریپت جاوا داره جاده رو میبنده.»
یافتن مشکلات به صورت زنده با Lighthouse و Chrome DevTools
گاهی اوقات PageSpeed Insights یه توصیه کلی میکنه، ولی مشکل پیچیدهتر از این حرفاست. مثلاً میگه «جاوا اسکریپت رو کم کن»، ولی کدومش؟ اینجاست که باید بریم سراغ «جراح متخصص» یا «کارآگاه صحنه جرم».
این ابزار همین الان توی مرورگر کروم خودته!
- کجاست؟ تو صفحهای که مشکل داره، راست کلیک کن و Inspect رو بزن (یا F12).
- ۱. تب Lighthouse:
- توی همون پنجره DevTools، یه تب داری به اسم Lighthouse. این دقیقاً همون تست «آزمایشگاهی» هست که PageSpeed Insights میگیره، ولی با این تفاوت که میتونی روی سیستم خودت و با تنظیمات مختلف (مثلاً شبیهسازی موبایل ضعیف) اجراش کنی.
- ۲. جادوی اصلی (تب Performance):
- این دیگه خود اتاق عمله. اگه FID/INP یا CLS خیلی پیچیدهای داری، میری تو تب Performance.
- یه ضبط (Record) از لود شدن صفحه میگیری.
- بعدش مثل یه نوار قلب، بهت نشون میده که تو هر میلیثانیه، مرورگر داشته دقیقاً چیکار میکرده.
- اینجا میتونی با چشم خودت ببینی کدوم اسکریپتِ مزاحم، «نخ اصلی» (Main Thread) رو قفل کرده (باعث FID/INP بالا شده) یا کدوم عنصر یهو پریده وسط صفحه و «زلزله» (CLS) ایجاد کرده.
کار با تب Performance یه کم تخصص فنیتر میخواد، ولی برای پیدا کردن مشکلات عمیق، هیچچیزی جاش رو نمیگیره.
استراتژی بهبود Core Web Vitals (تجربه عملی ما)
خب، حالا دماسنجها رو داریم، میدونیم LCP و CLS و INP چی هستن و چطوری اندازهگیریشون کنیم. حالا وقت «درمان» و کاره.
این همونجاییه که تئوری تموم میشه و «تجربه» واقعی ما تو «وزیر سئو» وسط میاد. تو از کجا باید شروع کنی؟
از کجا شروع کنیم؟ اولویتبندی هوشمندانه بهبودها (کدام را اول درست کنیم؟)
وقتی گزارش سرچ کنسول رو باز میکنی و با یه عالمه URL «ضعیف» (Poor) قرمز رنگ مواجه میشی، اولین حس، وحشته. میگی: «من چطوری این همه رو درست کنم؟»
آروم باش! نباید همینطوری از اول لیست شروع کنی. باید هوشمندانه اولویتبندی کنی. قانون من اینه: «بیشترین تأثیر، با کمترین (نسبتاً) تلاش».
بیا اینطوری اولویتبندی کن:
- اولویت ۱: رفع مشکلات «سراسری» (Site-Wide):
- اول از همه بگرد دنبال مشکلاتی که تو همه صفحاتت تکرار شدن. مثلاً چی؟
- یه لوگوی سنگین تو هدر (مشکل LCP)
- جابجایی (CLS) توی فوتر یا منوی اصلی
- یه فایل JS سنگین مربوط به چتباکس که تو همه صفحات لود میشه (مشکل INP)
- درست کردن این یه دونه مشکل، میتونه همزمان ۱۰۰۰ تا از URLهای «ضعیف» تو رو سبز کنه. این همیشه اولین قدمه.
- اول از همه بگرد دنبال مشکلاتی که تو همه صفحاتت تکرار شدن. مثلاً چی؟
- اولویت ۲: صفحات «پولساز» (Money Pages):
- بشین فکر کن. کدوم صفحات دارن برای تو پول میسازن؟ صفحات اصلی دستهبندی محصول؟ مهمترین لندینگ پیجهات؟
- برو تو PageSpeed Insights و آدرس دقیقاً همین صفحات رو تست کن. اینا ویترین مغازه تو هستن. حتی اگه درست کردنشون سخته، باید براشون وقت بذاری. مهم نیست صفحه «تاریخچه ما» کُنده، ولی صفحه «سبد خرید» باید پرواز کنه.
- اولویت ۳: رفع مشکلات «قالب» (Template Fix):
- برگرد به لیست قرمز سرچ کنسول. الگو رو پیدا کن.
- آیا همهشون «مقالات وبلاگ» هستن؟ آیا همهشون «صفحات محصول» هستن؟
- این یعنی مشکل از محتوای اون صفحه نیست، مشکل از «قالب» اون نوع صفحهست. مثلاً شاید قالبی که برای مقالهها طراحی کردی، عکس شاخص (LCP) رو بد لود میکنه. با درست کردن اون یه دونه فایل قالب (Template)، تمام صفحات محصول یا مقالههات با هم درست میشن.
تجربه ما: ۳ اشتباه رایجی که همه در بهینهسازی CWV مرتکب میشوند
تو این چند سال، من دیدم که چطور بهترین نیتها با اشتباهات ساده به باد میرن. اینا تجربههای واقعی منه. لطفاً تو این دامها نیفت:
- اشتباه ۱: وسواس روی صفحه اصلی (Homepage Obsession):
- تقریباً همهمون اول آدرس صفحه اصلیمون رو تو PageSpeed Insights میزنیم. بعد یه هفته وقت میذاریم تا نمرهاش بشه ۱۰۰.
- خبر بد: صفحه اصلی تو احتمالاً یکی از کماهمیتترین صفحات برای CWVئه. چرا؟ چون بیشتر کاربرهای تو از گوگل، مستقیم وارد مقالهها یا صفحات محصول میشن، نه صفحه اصلی! تمرکزت رو بذار جایی که کاربرهات فرود میان.
- اشتباه ۲: تست کردن با اینترنت و لپتاپ شخصی:
- این جمله معروف رو زیاد شنیدم: «ولی برای من که سریع باز میشه!»
- معلومه که سریع باز میشه! تو داری با یه لپتاپ قوی و اینترنت فیبر نوری تست میکنی. کاربر واقعی تو با یه گوشی سامسونگ ۳ سال پیش و اینترنت 4G داره سایتت رو میبینه.
- همیشه، همیشه، همیشه به تب «Mobile» تو PageSpeed Insights اعتماد کن. اون واقعیت توئه، حتی اگه تلخ باشه.
- اشتباه ۳: قربانی کردن تجربه کاربری (UX) برای نمره ۱۰۰:
- این بدترین اشتباهه. دیدم که طرف برای اینکه نمره INP بهتری بگیره، دکمه «چت آنلاین» که کلی به کاربراش کمک میکرده رو حذف کرده!
- یادت باشه، این نمرهها قرار بود «تجربه خوب» رو بسنجن. اگه تو برای گرفتن نمره ۱۰۰، یه قابلیت مفید رو حذف کنی و عملاً تجربه رو بدتر کنی، کل بازی رو باختی. یه سایت با نمره ۹۰ و تجربه عالی، هزار برابر بهتر از یه سایت با نمره ۱۰۰ ولی ناقص و بهدردنخوره.
Core Web Vitals یک پروژه تمامشدنی نیست (اهمیت مانیتورینگ دائمی)
و نکته آخر…
فرض کن همهچیز رو درست کردی. همه URLها سبز شدن، نمرههات عالیه. کار تمومه، نه؟ مطلقاً نه.
بهینهسازی Core Web Vitals مثل ساختن خونه نیست که تموم بشه و بری. مثل باغبونی میمونه. باید دائم بهش سر بزنی، هرس کنی، و علفهای هرز رو بکشی.
چرا؟ چون سایت تو «زنده»ست و دائم تغییر میکنه:
- تیم مارکتینگ یه کد اسکریپت آمارگیری جدید اضافه میکنه (INP خراب میشه).
- نویسنده جدیدت یه عکس ۳ مگابایتی برای مقاله آپلود میکنه (LCP داغون میشه).
- یه بنر تبلیغاتی برای «تخفیف یلدا» بالای سایت میذاری (CLS به هم میریزه).
- و خود گوگل استانداردهاش رو عوض میکنه (مثل جایگزینی FID با INP).
پس کارت این نیست که CWV رو «درست کنی». کارت اینه که «مانیتور کنی». حداقل ماهی یک بار به اون گزارش سرچ کنسول سر بزن و مطمئن شو که باغت هنوز سبز و مرتبه.
تو تیم شما، مسئولیت این «باغبونی» و مانیتورینگ دائمی با کیه؟ اصلاً بهش فکر کرده بودین؟
جمعبندی: چکلیست نهایی و سوالات متداول
خب، حس میکنم از یه سفر فنی ولی هیجانانگیز برگشتیم! با هم سه تا از مهمترین معیارهایی که «حس خوب» کاربر تو سایت ما رو میسازن، کالبدشکافی کردیم.
حالا وقتشه کل این دانش رو بریزیم تو یه چکلیست جمعوجور و کاربردی که بذاری دم دستت، و بعدش هم بریم سراغ سوالهایی که مطمئنم همین الان تو ذهنته.
چکلیست ۱۰ مرحلهای برای بهینهسازی کامل LCP, FID, و CLS
این چکلیست رو جایی ذخیره کن. هروقت خواستی یه صفحه جدید بسازی یا سایتت رو بهینه کنی، یه نگاه بهش بنداز:
- بیمارهات رو بشناس (مانیتورینگ): اول از همه برو تو گزارش Core Web Vitals سرچ کنسول. ببین کدوم گروه از URLها (مثلاً مقالات وبلاگ یا محصولات) وضعیت «ضعیف» (Poor) یا «نیاز به بهبود» دارن.
- صفحه رو ببر آزمایشگاه (اندازهگیری): آدرس یکی از اون URLهای قرمز رو بردار و ببر تو PageSpeed Insights. به توصیههایی که تو بخش «Mobile» میده دقت کن.
- عنصر LCP رو پیدا کن (LCP): تو گزارش PageSpeed Insights ببین دقیقاً کدوم عکس یا متن به عنوان LCP شناسایی شده.
- عکسها رو رژیم بده (LCP): اگه LCP یه عکسه، تا جایی که میتونی فشردهاش کن و با فرمت مدرن مثل WebP تحویلش بده.
- برای همه «جا» رزرو کن (LCP + CLS): این مهمترین قانونه! به همه عکسها، ویدئوها و Iframeها
widthوheightبده تا مرورگر قبل از لود شدنشون، جاشون رو خالی نگه داره و صفحه نپره. - جلوی زلزله تبلیغات رو بگیر (CLS): اگه تبلیغات یا محتوای داینامیک داری، براشون یه
divباmin-heightمشخص در نظر بگیر تا فضا از قبل براشون رزرو بشه. - آشپزخونه رو سریع کن (LCP/TTFB): اگه TTFB (Time to First Byte) بالاست، یعنی سرورت کُنده. روی یه هاست قویتر یا سیستم Caching (حافظه پنهان) سرمایهگذاری کن.
- جاده جاوا اسکریپت رو باز کن (INP/FID): مقصر اصلی تعامل پایین، JSئه. اسکریپتهای غیرضروری رو با
deferیاasyncبه انتهای صف لود بفرست. - کدهای غیرحیاتی رو عقب بنداز (INP/FID): از خودت بپرس: آیا این چتباکس، این پاپآپ خبرنامه، یا این اسلایدر واقعاً باید تو ثانیه اول لود بشe? لودشون رو چند ثانیه عقب بنداز (Delay) تا اول کارهای اصلی کاربر انجام بشه.
- باغبونی کن (مانیتورینگ): یادت نره! CWV یه پروژه نیست که تموم بشه؛ یه فرآینده. دائم سرچ کنسول رو چک کن، چون هر پلاگین جدید یا عکس بهینهنشدهای میتونه دوباره باغت رو خراب کنه.
سوالات متداول (FAQ) درباره هستههای حیاتی وب
۱. آیا حتماً باید نمرهام تو PageSpeed Insights بشه ۱۰۰؟
نه! لطفاً… خواهشاً… وسواس ۱۰۰ رو بذار کنار. تجربه من میگه این وسواس گاهی به قیمت حذف قابلیتهای مفید تموم میشه. هدف تو ۱۰۰ نیست؛ هدف تو «سبز» شدنه (Good). اگه نمرهات تو موبایل بالای ۹۰ باشه و هر سه تا معیار اصلیت تو محدوده «خوب» باشن، تو کارت رو عالی انجام دادی.
۲. چرا نمره PageSpeed من سبزه ولی گزارش سرچ کنسول هنوز قرمزه؟
این یه سوال کلاسیکه! جوابش تو تفاوت «داده آزمایشگاهی» و «داده میدانی»ئه.
- PageSpeed (آزمایشگاه): یه تست «لحظهای» تو یه محیط کنترلشدهست.
- Search Console (میدانی): گزارش ۲۸ روز گذشته از «کاربرای واقعی» توئه.
اگه سرچ کنسول قرمزه، یعنی کاربرای واقعی تو، با اون گوشیهای مختلف و اینترنتهای ضعیف، هنوز دارن تجربه بدی دارن. گوگل هم به همین «کارنامه واقعی» تو نگاه میکنه.
۳. اول LCP رو درست کنم یا CLS؟ کدوم مهمتره؟
بستگی داره کدوم داغونتره! ولی تجربه شخصی من میگه: اگه هر دوتاشون بدن، اول برو سراغ CLS.
چرا؟ چون CLS (پریدن صفحه) معمولاً خیلی سریعتر اعصاب کاربر رو خرد میکنه و حس «خراب بودن» سایت رو میده. از طرفی، درست کردنش هم اغلب سادهتره (همون رزرو کردن فضا با width و height).
۴. این INP چیه که جدیداً جای FID اومده؟
FID (که الان بازنشسته شده) فقط «تأخیر در اولین کلیک» رو اندازه میگرفت. یه کم خوشبین بود.
INP (Interaction to Next Paint) خیلی سختگیرتره. این میاد همه تعاملهای کاربر (همه کلیکها، تپها، تایپ کردنها) رو تو صفحه بررسی میکنه و کندترینشون رو به عنوان نمره تو در نظر میگیره. این معیار جدید ما رو مجبور میکنه که مطمئن بشیم کل تجربه کار با صفحه روونه، نه فقط کلیک اول.
۵. اگه محتوای من خیلی عالی باشه، دیگه Core Web Vitals مهم نیست؟
این یه تله بزرگه. «محتوای عالی تو یه سایت کُند و پر از پرش، مثل یه کتاب فوقالعادهست که جلدش باز نمیشه یا صفحاتش بههمریختهست.»
تجربه کاربری (UX) و محتوای عالی (Content) دوتا بال پروازن. اگه یکیشون ضعیف باشه، اون پرواز اتفاق نمیفته.
میدونم، به نظر یه عالمه کار فنی میاد. ولی ته همهشون یه چیزه: «احترام». احترام به وقت کاربر، به اعصابش و به اعتمادی که کرده و روی لینک تو کلیک کرده.
حالا تو بهم بگو، با توجه به چیزایی که گفتیم، اگه همین الان بری سراغ گزارش سرچ کنسولت، فکر میکنی بزرگترین چالش و بیشترین رنگ قرمزت مربوط به کدوم یکی از این سه تا معیاره؟ LCP (سرعت لود)، CLS (پریدن صفحه)، یا INP (گیر کردن دکمهها)؟
