آموزش جامع Core Web Vitals: از تحلیل گزارش تا بهینه‌سازی (LCP, INP, CLS)

درک معیارهای Core Web Vitals (هسته‌های حیاتی وب) دیگر یک انتخاب فنی نیست، بلکه یک ضرورت مستقیم برای سئو است. این معیارها، بخش اصلی و قابل اندازه‌گیری گزارش Experience (تجربه کاربری) گوگل در سرچ کنسول را تشکیل می‌دهند و مشخص می‌کنند که کاربران واقعی، سایت شما را چقدر سریع، پاسخ‌گو و پایدار می‌بینند.

این گزارش صرفاً چند عدد نیست؛ بلکه بازخورد مستقیم گوگل از نحوه تعامل کاربران با صفحات شماست. درک عمیق سه متریک LCP, INP و CLS، اولین گام برای اطمینان از این است که تجربه کاربری ضعیف، مانع رتبه‌بندی محتوای باکیفیت شما نشود. در این راهنما، به شکل تخصصی و مستقیم، هر آنچه برای تحلیل و بهینه‌سازی این سه معیار نیاز دارید را بررسی می‌کنیم.

جدول کاربردی (خلاصه سه متریک اصلی)

متریک (Metric)	چه چیزی را می‌سنجد؟ (Target)	امتیاز «خوب» (Good Score)
LCP (Largest Contentful Paint)	سرعت بارگذاری (Loading)	۲.۵ ثانیه یا کمتر
INP (Interaction to Next Paint)	سرعت پاسخ‌دهی (Interactivity)	۲۰۰ میلی‌ثانیه یا کمتر
CLS (Cumulative Layout Shift)	ثبات بصری (Visual Stability)	۰.۱ یا کمتر

 

Core Web Vitals (CWV) چیست و چرا یک انقلاب در سئو بود؟

Core Web Vitals (CWV) یا «هسته‌های حیاتی وب»، مجموعه‌ای از معیارهای استاندارد و قابل اندازه‌گیری هستند که توسط گوگل معرفی شدند تا تجربه واقعی کاربر (User Experience) در یک صفحه وب را ارزیابی کنند.

این معیارها فراتر از مفاهیم کلی مانند «سرعت سایت» عمل می‌کنند؛ آن‌ها به طور خاص سه جنبه کلیدی تجربه کاربری را می‌سنجند:

۱. سرعت بارگذاری (Loading)

۲. سرعت تعامل (Interactivity)

۳. ثبات بصری (Visual Stability)

چرا یک انقلاب بود؟

تا پیش از معرفی CWV، «تجربه کاربری» یک مفهوم کیفی و تا حدی مبهم در سئو بود. گوگل با معرفی این سه متریک مشخص، برای اولین بار تجربه کاربری را به یک سیگنال رتبه‌بندی مستقیم و قابل اندازه‌گیری تبدیل کرد.

این اقدام یک پیام واضح داشت: دیگر فقط کیفیت محتوا یا تعداد بک‌لینک‌ها مهم نیست؛ نحوه ارائه آن محتوا و حسی که کاربر هنگام تعامل با صفحه شما دارد نیز مستقیماً بر رتبه شما تأثیرگذار است. این موضوع، اهمیت بخش فنی سئو (Technical SEO) را به شکل قابل توجهی افزایش داد.

هسته حیاتی وب چگونه بر رتبه گوگل شما تأثیر می‌گذارد؟ (مفهوم Page Experience)

هسته‌های حیاتی وب (CWV) بخش اصلی و مرکزی سیگنال بزرگ‌تری به نام Page Experience (تجربه صفحه) هستند.

سیگنال Page Experience مجموعه‌ای از فاکتورهاست که گوگل برای درک کیفیت تجربه کاربر در یک صفحه، فراتر از ارزش محتوای آن، بررسی می‌کند. این سیگنال شامل موارد زیر است:

• Core Web Vitals (سه متریک اصلی)
• Mobile-Friendliness (سازگاری با موبایل)
• HTTPS (امن بودن سایت)
• No Intrusive Interstitials (نبود پاپ‌آپ‌ها یا تبلیغات مزاحم)

تأثیر مستقیم بر رتبه:

گوگل به صراحت اعلام کرده که در رقابت بین دو صفحه با محتوای مشابه و با کیفیت یکسان، صفحه‌ای که تجربه کاربری (و در نتیجه CWV) بهتری دارد، در رتبه‌بندی اولویت خواهد داشت.

بنابراین، CWV ضعیف می‌تواند مانند یک ترمز دستی برای محتوای عالی شما عمل کند. اگر کاربران هنگام ورود به سایت شما با بارگذاری کند، عدم پاسخ‌دهی به کلیک‌ها یا پرش ناگهانی عناصر مواجه شوند، گوگل این تجربه منفی را تشخیص داده و ممکن است رقبای شما را که تجربه روان‌تری ارائه می‌دهند، ترجیح دهد.

آشنایی با ۳ متریک سرنوشت‌ساز: LCP, INP و CLS

برای بهینه‌سازی CWV، ابتدا باید سه متریک تشکیل‌دهنده آن را به خوبی بشناسیم. هر کدام از اینها جنبه متفاوتی از تجربه کاربر را اندازه‌گیری می‌کنند:

متریک	نام کامل (انگلیسی)	هدف سنجش	توضیح ساده و کاربردی
LCP	Largest Contentful Paint	سرعت بارگذاری	مدت زمانی که طول می‌کشد تا بزرگترین عنصر (معمولاً یک تصویر اصلی، ویدئو یا بلوک متنی بزرگ) در دید کاربر بارگذاری شود. LCP بالا به معنای کند بودن بارگذاری محتوای اصلی صفحه است.
INP	Interaction to Next Paint	سرعت پاسخ‌دهی	مدت زمانی که طول می‌کشد تا صفحه به اولین تعامل کاربر (مانند کلیک روی دکمه، باز کردن منو یا پر کردن فرم) پاسخ بصری دهد. INP بالا یعنی سایت شما “گیر” می‌کند و واکنش نشان نمی‌دهد. (این متریک به تازگی جایگزین FID شده است).
CLS	Cumulative Layout Shift	ثبات بصری	میزان جابجایی یا “پرش” غیرمنتظره عناصر صفحه در حین بارگذاری. این اتفاق معمولاً زمانی رخ می‌دهد که تصاویر، تبلیغات یا فونت‌ها دیرتر بارگذاری شده و محتوای موجود را به پایین هل می‌دهند.

تفاوت حیاتی داده‌های میدانی (Field Data – CrUX) و داده‌های آزمایشگاهی (Lab Data)

این یکی از مهم‌ترین و فنی‌ترین بخش‌های درک Core Web Vitals است. داده‌های مربوط به CWV از دو منبع کاملاً متفاوت به دست می‌آیند:

۱. داده‌های آزمایشگاهی (Lab Data)

• چیست؟ این داده‌ها در یک محیط شبیه‌سازی شده و کنترل‌شده جمع‌آوری می‌شوند.
• ابزارها: ابزارهایی مانند Lighthouse (که در بخش DevTools مرورگر کروم و ابزار PageSpeed Insights وجود دارد) از این نوع داده استفاده می‌کنند.
• کاربرد: این داده‌ها برای عیب‌یابی (Debugging) عالی هستند. شما می‌توانید قبل از انتشار یک تغییر، صفحه را تست کنید و بازخورد فوری بگیرید.
• محدودیت: این داده‌ها تجربه واقعی کاربران شما را نشان نمی‌دهند، بلکه یک شبیه‌سازی هستند.

۲. داده‌های میدانی (Field Data)

• چیست؟ این داده‌ها مستقیماً از کاربران واقعی که با مرورگر کروم از سایت شما بازدید کرده‌اند، جمع‌آوری می‌شوند. این گزارش به نام CrUX (Chrome User Experience Report) شناخته می‌شود.
• ابزارها: شما این داده‌ها را در بخش Core Web Vitals در سرچ کنسول و همچنین در بخش بالایی گزارش PageSpeed Insights مشاهده می‌کنید.
• کاربرد: این همان داده‌ای است که گوگل برای رتبه‌بندی به آن استناد می‌کند. این گزارش نشان می‌دهد که کاربران واقعی شما، با دستگاه‌های مختلف (موبایل، دسکتاپ) و سرعت‌های اینترنت متفاوت (3G, 4G, WiFi)، چه تجربه‌ای داشته‌اند.

نکته کلیدی: ممکن است سایت شما در تست آزمایشگاهی (Lab) امتیاز کامل سبز را بگیرد (چون با اینترنت پرسرعت شما تست شده)، اما در داده‌های میدانی (Field) به دلیل تجربه کاربران واقعی با اینترنت ضعیف‌تر، امتیاز قرمز یا زرد داشته باشد. ملاک نهایی برای گوگل، همیشه داده‌های میدانی (Field Data) است.

راهنمای کامل گزارش Core Web Vitals در سرچ کنسول (GSC)

گزارش Core Web Vitals در سرچ کنسول گوگل (GSC) یکی از مهم‌ترین ابزارهای فنی برای سئو است. دلیل اهمیت آن ساده است: این گزارش، بازخورد مستقیم گوگل از داده‌های میدانی (Field Data) یا همان (CrUX) را به شما نشان می‌دهد.

به عبارت دیگر، این گزارش نمی‌گوید سایت شما ممکن است چگونه عمل کند (مانند داده‌های آزمایشگاهی)، بلکه دقیقاً نشان می‌دهد که کاربران واقعی شما در عمل چه تجربه‌ای از نظر سرعت و پایداری در سایت داشته‌اند. این همان داده‌ای است که گوگل مستقیماً برای سیگنال Page Experience و رتبه‌بندی استفاده می‌کند.

چگونه گزارش هسته حیاتی وب را پیدا و باز کنیم؟

پیدا کردن این گزارش بسیار ساده است.

1. ابتدا وارد اکانت سرچ کنسول سایت مورد نظر خود شوید.
2. در منوی سمت چپ (Sidebar)، به دنبال بخشی به نام «تجربه» (Experience) بگردید.
3. زیرمجموعه آن، روی گزینه Core Web Vitals کلیک کنید.
4. با کلیک روی آن، دو گزارش مجزا برای موبایل (Mobile) و دسکتاپ (Desktop) خواهید دید.

نکته مهم این است که گوگل این دو گزارش را کاملاً مجزا ارزیابی می‌کند، اما اولویت و تأثیر اصلی در رتبه‌بندی (مخصوصاً پس از Mobile-First Indexing) با گزارش موبایل است.

تفسیر نمودارها: معنی دقیق رنگ‌های قرمز (Poor)، زرد (Needs Improvement) و سبز (Good)

وقتی گزارش را باز می‌کنید (چه موبایل و چه دسکتاپ)، گوگل تمام URLهای سایت شما را که داده کافی داشته‌اند، در سه دسته رنگی نمایش می‌دهد:

• سبز (Good): وضعیت ایده‌آل. به این معناست که URLهای این بخش در هر سه متریک LCP, INP و CLS عملکرد خوبی طبق استانداردهای گوگل داشته‌اند. هدف اصلی شما رساندن تمام URLها به این وضعیت است.
• زرد (Needs Improvement): وضعیت هشدار. یعنی حداقل یکی از سه متریک اصلی نتوانسته استاندارد “Good” را پاس کند، اما هنوز در وضعیت “Poor” هم قرار نگرفته است. این صفحات در خطر هستند و باید در اولویت بهینه‌سازی قرار گیرند.
• قرمز (Poor): وضعیت ضعیف. به این معناست که حداقل یکی از سه متریک اصلی، عملکرد بسیار ضعیفی داشته است. این URLها تجربه کاربری بدی ارائه می‌دهند و تأثیر منفی مستقیمی بر سیگنال Page Experience شما می‌گذارند.

نکته کلیدی: برای اینکه یک URL “سبز” (Good) محسوب شود، باید در هر سه متریک آستانه “Good” را رد کند. اگر حتی یک متریک “زرد” باشد، کل آن URL در دسته “Needs Improvement” قرار می‌گیرد.

درک مفهوم «گروه‌بندی URLها» (URL Groups) و اهمیت آن

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

در عوض، گوگل صفحاتی را که ساختار مشابهی دارند و مشکل یکسانی را تجربه می‌کنند، با هم «گروه‌بندی» می‌کند.

• مثال: فرض کنید تمام صفحات «محصول» شما (که از یک قالب یا Template واحد استفاده می‌کنند) همگی مشکل LCP (مثلاً به دلیل کند بودن بارگذاری تصویر اصلی محصول) دارند. سرچ کنسول همه این ۱۰۰۰ صفحه محصول را در یک گروه، مثلاً تحت عنوان /products/* یا مشابه آن، دسته‌بندی می‌کند و یک نمونه از URLها را به شما نشان می‌دهد.

اهمیت این موضوع: این گروه‌بندی به شما کمک می‌کند تا به جای حل مشکل به صورت موردی برای هزاران صفحه، مستقیماً به سراغ مشکل ریشه‌ای در قالب (Template) یا سیستم اصلی سایت بروید.

چگونه مشکلات را بر اساس «گروه‌های URL مشابه» اولویت‌بندی کنیم؟

استفاده بهینه از این گزارش به معنای اولویت‌بندی هوشمندانه است:

1. شروع با رنگ قرمز (Poor): همیشه ابتدا روی گروه‌های URL که در بخش “Poor” قرار دارند تمرکز کنید. این‌ها بیشترین آسیب را به تجربه کاربری شما می‌زنند.
2. بررسی تعداد URLها: در مرحله بعد، به سراغ گروهی بروید که بیشترین تعداد URLهای آسیب‌دیده (Affected URLs) را دارد. حل کردن مشکل این گروه، بیشترین تأثیر مثبت را با کمترین زحمت خواهد داشت.
3. کلیک روی گروه مشکل‌دار: روی یکی از گروه‌های قرمز یا زرد کلیک کنید. در صفحه بعد، گوگل دقیقاً مشخص می‌کند که مشکل اصلی کدام متریک است (مثلاً: “LCP issue: longer than 2.5s”).
4. شناسایی مشکل ریشه‌ای: با بررسی URLهای نمونه (Examples) در آن گروه، باید الگوی مشترک را پیدا کنید. آیا همگی صفحه محصول هستند؟ آیا همگی مقاله بلاگ هستند؟ مشکل ریشه‌ای (مثلاً یک افزونه سنگین، یک فایل CSS/JS بهینه نشده، یا تصاویر بدون سایزبندی) که در قالب آن صفحات مشترک است را پیدا کنید.
5. اعتبارسنجی (Validate Fix): پس از رفع مشکل ریشه‌ای در سطح قالب یا سایت، به سرچ کنسول برگردید و روی دکمه “Validate Fix“ کلیک کنید. این کار به گوگل اطلاع می‌دهد که شما مشکل را حل کرده‌اید و باید فرآیند بررسی مجدد داده‌های میدانی را آغاز کند (این فرآیند ممکن است تا ۲۸ روز طول بکشد).

تحلیل تخصصی LCP (Largest Contentful Paint): هنر بارگذاری سریع

متریک LCP یا «بزرگترین ترسیم محتوایی»، یک معیار کلیدی برای سنجش سرعت بارگذاری درک شده (Perceived Load Speed) است. این متریک مستقیماً به کاربر می‌گوید که محتوای اصلی و احتمالاً مهم‌ترین بخش صفحه چقدر سریع قابل مشاهده است.

برخلاف معیارهای قدیمی‌تر مانند «زمان بارگذاری کامل صفحه» (Page Load Time)، گوگل روی LCP تمرکز کرد زیرا این متریک ارتباط بسیار نزدیک‌تری با تجربه واقعی کاربر دارد. کاربری که به سرعت عنصر اصلی صفحه (مثلاً تصویر شاخص یک مقاله یا بنر یک محصول) را می‌بیند، سایت را «سریع» ارزیابی می‌کند، حتی اگر عناصر کم‌اهمیت‌تر در پس‌زمینه هنوز در حال بارگذاری باشند.

LCP دقیقا چیست و امتیاز «خوب» چه عددی است؟

LCP به زبان ساده، مدت زمان بارگذاری بزرگترین عنصر محتوایی (مانند تصویر اصلی، پوستر ویدئو یا یک بلوک متنی بزرگ) در محدوده دید اولیه کاربر (Viewport) است. این زمان از لحظه کلیک کاربر روی لینک تا لحظه رندر شدن آن عنصر بزرگ محاسبه می‌شود.

گوگل این زمان‌بندی‌ها را برای ارزیابی LCP مشخص کرده است:

امتیاز	آستانه زمانی	تفسیر
سبز (Good)	۲.۵ ثانیه یا کمتر	عملکرد ایده‌آل؛ کاربر سرعت خوبی را تجربه می‌کند.
زرد (Needs Improvement)	بین ۲.۵ تا ۴ ثانیه	نیاز به بهینه‌سازی دارد. کاربر ممکن است کندی را حس کند.
قرمز (Poor)	بیشتر از ۴ ثانیه	عملکرد ضعیف؛ تجربه کاربری به شدت آسیب می‌بیند و بر رتبه تأثیر منفی دارد.

دلایل اصلی LCP ضعیف: از زمان پاسخ کند سرور (TTFB) تا منابع مسدودکننده رندر

مشکل LCP معمولاً یک دلیل واحد ندارد، بلکه زنجیره‌ای از اتفاقات است که منجر به کندی می‌شوند. ریشه‌یابی اهمیت زیادی دارد. چهار دلیل اصلی عبارتند از:

۱. زمان پاسخ کند سرور (TTFB – Time to First Byte):

این اولین و پایه‌ای‌ترین مشکل است. TTFB مدت زمانی است که طول می‌کشد تا مرورگر اولین بایت داده را از سرور دریافت کند. اگر سرور شما (به دلیل هاست ضعیف، عدم Caching یا دیتابیس کند) دیر پاسخ دهد، تمام مراحل بعدی، از جمله LCP، به تأخیر می‌افتند.

۲. منابع مسدودکننده رندر (Render-Blocking Resources):

فایل‌های JavaScript و CSS حجیم، مخصوصاً آن‌هایی که در <head> صفحه بارگذاری می‌شوند، می‌توانند رندر شدن صفحه را مسدود کنند. مرورگر تا زمانی که پردازش این فایل‌ها را تمام نکند، شروع به نمایش محتوا (از جمله عنصر LCP) نخواهد کرد.

۳. کند بودن بارگذاری خود عنصر LCP:

گاهی سرور سریع است و CSS/JS هم بهینه هستند، اما خود عنصر LCP (مثلاً یک تصویر) بسیار حجیم است. استفاده از تصاویر با فرمت قدیمی (PNG/JPG) و ابعاد بسیار بزرگ، زمان زیادی برای دانلود شدن نیاز دارد.

۴. رندر سمت کلاینت (Client-Side Rendering):

سایت‌هایی که به شدت به JavaScript (مانند فریم‌ورک‌های React یا Angular) برای نمایش محتوا متکی هستند، ممکن است با LCP ضعیف مواجه شوند. در این حالت، مرورگر ابتدا باید فایل‌های JS سنگین را دانلود و اجرا کند تا بتواند محتوا را ساخته و نمایش دهد.

چگونه عنصر LCP صفحه را با ابزارهایی مانند PageSpeed پیدا کنیم؟

پیدا کردن عنصر LCP ساده است. بهترین ابزار برای این کار PageSpeed Insights (PSI) گوگل است:

1. URL صفحه مورد نظر را در PageSpeed Insights وارد کنید.
2. پس از اجرای تحلیل، به پایین صفحه اسکرول کنید تا به بخش «Diagnostics» (عیب‌یابی) برسید.
3. در این بخش، گزینه‌ای به نام «Largest Contentful Paint element» وجود دارد.
4. PSI به طور واضح به شما نشان می‌دهد که کدام عنصر (مثلاً یک تگ <img> یا یک تگ <p>) به عنوان LCP شناسایی شده است.

همچنین در بخش “Performance” ابزار Chrome DevTools نیز می‌توانید با فعال کردن گزینه “Core Web Vitals” در حین ضبط، این عنصر را شناسایی کنید.

راهکارهای عملی: بهینه‌سازی تصاویر (WebP/AVIF)، فعال‌سازی Caching و استفاده از Preload

بعد از شناسایی عنصر و مشکل ریشه‌ای، این راهکارها باید بررسی شوند:

• بهبود TTFB (مشکل سرور):
  • فعال‌سازی Caching: استفاده از کش در سطح سرور (Server-side Caching) یا افزونه‌های کش وردپرس.
  • استفاده از CDN (شبکه توزیع محتوا): برای کاهش فاصله فیزیکی سرور تا کاربر و تحویل سریع‌تر فایل‌ها.
  • ارتقای هاست: گاهی هاست اشتراکی توان پاسخگویی سریع را ندارد.
• بهینه‌سازی عنصر LCP (اگر تصویر بود):
  • استفاده از فرمت‌های مدرن: تبدیل تصاویر به فرمت‌های WebP یا AVIF که حجم بسیار کمتری نسبت به JPG/PNG دارند.
  • فشرده‌سازی و تغییر سایز: اطمینان حاصل کنید که ابعاد تصویر دقیقاً همان ابعادی است که نمایش داده می‌شود و بیهوده بزرگتر نیست.
  • Lazy Loading (بارگذاری تنبل): هشدار: هرگز تصویر LCP را Lazy Load نکنید. این کار نتیجه معکوس دارد. این تصویر باید بلافاصله بارگذاری شود.
• استفاده از Preload (پیش‌بارگذاری):
  • اگر عنصر LCP شما یک تصویر یا فونت کلیدی است، می‌توانید با قرار دادن تگ link rel=”preload” در <head>، به مرورگر دستور دهید که این منبع را با اولویت بالا و زودتر از بقیه دانلود کند. این کار تأثیر مستقیمی بر بهبود LCP دارد.
• بهینه‌سازی CSS و JS (مشکل مسدودکنندگی):
  • Minify (فشرده‌سازی): حذف کاراکترهای اضافه از کدهای CSS و JS.
  • Defer یا Async: به تعویق انداختن بارگذاری فایل‌های JS غیرضروری تا پس از رندر شدن محتوای اصلی.
  • Critical CSS: استخراج CSS حیاتی (کدهای لازم برای نمایش بخش بالایی صفحه) و قرار دادن آن به صورت Inline در <head>.

بهبود LCP یک فرآیند فنی دقیق برای بهینه‌سازی زنجیره رندر (Critical Rendering Path) است. با تمرکز بر سه بخش اصلی یعنی سرعت سرور (TTFB)، بهینه‌سازی منابع مسدودکننده (CSS/JS) و بهینه‌سازی خود عنصر (Image/Text)، می‌توانید تجربه بارگذاری بهتری برای کاربران خود فراهم کنید.

تحلیل تخصصی INP (Interaction to Next Paint): آینده پاسخ‌دهی صفحه

متریک INP، یا «تعامل تا ترسیم بعدی»، جدیدترین استاندارد طلایی گوگل برای سنجش پاسخ‌دهی (Responsiveness) یک صفحه وب است. این متریک نشان می‌دهد که یک صفحه چقدر سریع به تعاملات کاربر (مانند کلیک، ضربه زدن، یا تایپ کردن) واکنش بصری نشان می‌دهد.

اهمیت INP در این است که برخلاف معیارهای قبلی، فقط به اولین برداشت کاربر اهمیت نمی‌دهد، بلکه کل تجربه کاربر در طول بازدید از صفحه را زیر نظر می‌گیرد. INP ضعیف مستقیماً به کاربر حس «گیر کردن» یا «کند بودن» سایت را منتقل می‌کند و یکی از دلایل اصلی نارضایتی و خروج کاربر است.

INP چیست و چرا رسماً جایگزین FID (First Input Delay) شد؟

INP (Interaction to Next Paint):

این متریک، تأخیر تمام تعاملات کاربر در طول بازدید از صفحه را اندازه‌گیری می‌کند و در نهایت، یکی از طولانی‌ترین تعاملات (یا نزدیک به طولانی‌ترین) را به عنوان امتیاز نهایی گزارش می‌دهد. به زبان ساده، INP می‌سنجد که از لحظه کلیک کاربر تا زمانی که اولین بازخورد بصری (مثلاً باز شدن منو، لود شدن یک بخش) نمایش داده شود، چقدر طول می‌کشد.

چرا جایگزین FID شد؟

FID (First Input Delay) فقط تأخیر اولین تعامل کاربر را اندازه‌گیری می‌کرد. این یک معیار خوب بود، اما ناقص. بسیاری از صفحات در ابتدا (وقتی FID اندازه‌گیری می‌شود) سریع هستند، اما پس از بارگذاری کامل اسکریپت‌ها و افزونه‌ها، سنگین و کند می‌شوند.

کاربر ممکن است روی منو یا فیلتر محصول کلیک کند (که تعامل اول نیست) و صفحه برای چند ثانیه “خشک” شود. FID این تجربه بد را ثبت نمی‌کرد، اما INP دقیقاً برای شناسایی همین مشکلات طراحی شده است.

امتیازدهی INP:

• سبز (Good): ۲۰۰ میلی‌ثانیه یا کمتر.
• زرد (Needs Improvement): بین ۲۰۰ تا ۵۰۰ میلی‌ثانیه.
• قرمز (Poor): بیشتر از ۵۰۰ میلی‌ثانیه (نیم ثانیه).

چگونه «تعاملات کند» (Slow Interactions) را در صفحه شناسایی کنیم؟ (مثال عملی)

از آنجایی که INP یک «داده میدانی» (Field Data) است، بهترین مکان برای دیدن امتیاز کلی، گزارش Core Web Vitals در سرچ کنسول یا داده‌های CrUX در PageSpeed Insights است.

اما برای پیدا کردن اینکه کدام تعامل کند است، باید از ابزارهای آزمایشگاهی (Lab Tools) مانند Chrome DevTools استفاده کنید:

1. در مرورگر کروم، DevTools را باز کنید (F12 یا Ctrl+Shift+I).
2. به تب Performance بروید.
3. روی دکمه ضبط (Record) کلیک کنید.
4. شروع به تعامل با صفحه کنید: روی دکمه‌ها کلیک کنید، منوهای کشویی را باز کنید، موارد را به سبد خرید اضافه کنید، فرم‌ها را پر کنید.
5. ضبط را متوقف کنید.

در نوار زمانی (Timeline)، به دنبال «Long Tasks» (وظایف طولانی) بگردید که با نوارهای قرمز مشخص شده‌اند. اگر یکی از این Long Task ها دقیقاً بعد از کلیک شما رخ داده باشد، شما عامل اصلی INP ضعیف را پیدا کرده‌اید.

• مثال عملی: کاربر روی دکمه «اعمال فیلترها» در یک صفحه دسته‌بندی کلیک می‌کند. یک اسکریپت سنگین جاوا اسکریپت برای پردازش فیلترها اجرا می‌شود که ۴۰۰ میلی‌ثانیه طول می‌کشد (یک Long Task). در این ۴۰۰ میلی‌ثانیه، مرورگر قفل است و نمی‌تواند حتی یک انیمیشن لودینگ ساده را نشان دهد. این تأخیر، مستقیماً به عنوان INP ضعیف ثبت می‌شود.

راهکارهای عملی: شکستن تسک‌های طولانی (Long Tasks) و بهینه‌سازی جاوا اسکریپت

تقریباً تمام مشکلات INP ریشه در JavaScript (JS) دارند که «رشته اصلی» (Main Thread) مرورگر را مسدود می‌کند. مرورگر فقط یک رشته اصلی دارد؛ اگر این رشته مشغول اجرای یک کد JS سنگین باشد، نمی‌تواند به کلیک کاربر پاسخ دهد.

راهکار اصلی: شکستن تسک‌های طولانی (Breaking up Long Tasks)

به جای اجرای یک اسکریپت طولانی و یکپارچه، باید آن را به بخش‌های کوچکتر تقسیم کنید.

• مفهوم Yielding: شما باید به مرورگر «فرصت تنفس» بدهید. این کار با استفاده از توابعی مانند setTimeout(…, 0) انجام می‌شود. با این تکنیک، شما اجرای ادامه اسکریپت را به صف (Queue) بعدی مرورگر منتقل می‌کنید. این وقفه کوتاه (حتی در حد ۱ میلی‌ثانیه) به مرورگر اجازه می‌دهد تا بررسی کند آیا ورودی کاربر (مثل کلیک) وجود داشته یا نه. اگر وجود داشت، ابتدا به آن پاسخ می‌دهد و سپس ادامه اسکریپت شما را اجرا می‌کند.

این کار مستقیماً INP را بهبود می‌بخشد، زیرا مرورگر هرگز برای مدت طولانی قفل نمی‌ماند.

نقش اسکریپت‌های Third-Party (مانند ابزارهای چت) در تخریب INP

یکی از دلایل اصلی INP ضعیف که اغلب نادیده گرفته می‌شود، اسکریپت‌های شخص ثالث (Third-Party Scripts) هستند. اینها کدهایی هستند که شما ننوشته‌اید اما در سایت خود بارگذاری می‌کنید.

• مثال‌های رایج: ابزارهای چت زنده (Live Chat)، ابزارهای تحلیل رفتار کاربر (مانند Hotjar)، اسکریپت‌های تبلیغاتی، و تگ‌های مختلف از Google Tag Manager.

چگونه INP را تخریب می‌کنند؟

این اسکریپت‌ها اغلب برای اجرا شدن، منابع زیادی از رشته اصلی (Main Thread) را اشغال می‌کنند. آن‌ها همزمان با اسکریپت‌های اصلی سایت شما برای جلب توجه مرورگر رقابت می‌کنند.

اغلب اتفاق می‌افتد که کاربر روی یک دکمه کلیک می‌کند، اما مرورگر در همان لحظه مشغول اجرای یک اسکریپت سنگین از ابزار چت زنده است. در نتیجه، پاسخ به کلیک کاربر به تعویق می‌افتد و INP به شدت آسیب می‌بیند.

راهکارها:

1. حسابرسی اسکریپت‌ها: آیا واقعاً به همه این ابزارها نیاز دارید؟ ابزاری که ارزش افزوده قابل توجهی ندارد و صرفاً منابع را مصرف می‌کند، باید حذف شود.
2. بارگذاری تأخیری (Lazy Loading): ابزار چت زنده نیازی نیست در ثانیه اول بارگذاری شود. آن را طوری تنظیم کنید که پس از اولین اسکرول کاربر یا پس از گذشت ۵ ثانیه بارگذاری شود. این کار باعث می‌شود رشته اصلی در لحظات اولیه (که کاربر شروع به تعامل می‌کند) آزاد باشد.
3. استفاده از async و defer: اطمینان حاصل کنید که این اسکریپت‌ها حداقل رندر اولیه صفحه را مسدود نکنند.

بهبود INP یک فرآیند فنی دقیق برای مدیریت اجرای جاوا اسکریپت و اولویت‌بندی تعاملات کاربر است. این کار مستقیماً به رضایت کاربر و ارائه یک تجربه کاربری حرفه‌ای کمک می‌کند.

تحلیل تخصصی CLS (Cumulative Layout Shift): خلق تجربه بصری پایدار

متریک CLS یا «تغییر تجمعی چیدمان»، معیاری برای سنجش ثبات بصری (Visual Stability) یک صفحه وب است. این متریک، میزان پرش‌ها و جابجایی‌های غیرمنتظره عناصر صفحه را در حین بارگذاری اندازه‌گیری می‌کند.

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

CLS چیست و چرا پرش ناگهانی صفحه، کاربران (و گوگل) را آزار می‌دهد؟

CLS (Cumulative Layout Shift) مجموع امتیاز تمام جابجایی‌های غیرمنتظره‌ای است که در طول عمر یک صفحه رخ می‌دهد. یک جابجایی (Layout Shift) زمانی اتفاق می‌افتد که یک عنصر قابل مشاهده، موقعیت خود را بین دو فریم تغییر می‌دهد.

چرا این موضوع آزاردهنده است؟

تجربه کاربری را تصور کنید:

• شما در حال خواندن یک پاراگراف متن هستید. ناگهان، یک تصویر در بالای آن بارگذاری می‌شود و متنی که می‌خواندید به پایین صفحه پرتاب می‌شود. شما رشته کلام را گم می‌کنید.
• شما قصد دارید روی دکمه «افزودن به سبد خرید» کلیک کنید. درست در لحظه کلیک، یک بنر تبلیغاتی بالای آن دکمه ظاهر می‌شود، دکمه را به پایین هل می‌دهد و شما به اشتباه روی تبلیغ کلیک می‌کنید.

این تجربیات به شدت منفی، باعث سردرگمی و نارضایتی کاربر می‌شوند. گوگل این نارضایتی را تشخیص داده و به همین دلیل CLS را به عنوان یک فاکتور رتبه‌بندی مهم در نظر می‌گیرد.

امتیازدهی CLS:

• سبز (Good): ۰.۱ یا کمتر
• زرد (Needs Improvement): بین ۰.۱ تا ۰.۲۵
• قرمز (Poor): بیشتر از ۰.۲۵

دلایل رایج CLS بالا: تصاویر بدون ابعاد، تبلیغات، و فونت‌ها (FOIT/FOUT)

مشکلات CLS تقریباً همیشه به دلیل بارگذاری ناهمزمان منابع و عدم تخصیص فضای کافی برای آن‌ها رخ می‌دهند. رایج‌ترین دلایل عبارتند از:

۱. تصاویر و ویدئوهای بدون ابعاد مشخص:

شایع‌ترین دلیل. اگر شما در تگ <img> یا <video>، مقادیر width و height را مشخص نکنید، مرورگر در ابتدا نمی‌داند چقدر فضا باید برای آن رزرو کند. در نتیجه، ابتدا متن را نمایش می‌دهد و پس از دانلود شدن تصویر، ناگهان فضا را باز کرده و متن را به پایین جابجا می‌کند.

۲. تبلیغات، Embedها و Iframeها:

ابزارهای شخص ثالث مانند بنرهای تبلیغاتی، ویدئوهای آپارات/یوتیوب یا نقشه‌های گوگل، اغلب با تأخیر بارگذاری می‌شوند و ابعاد مشخصی ندارند. وقتی بالاخره بارگذاری می‌شوند، محتوای اطراف خود را هل می‌دهند.

۳. بارگذاری فونت‌ها (FOIT/FOUT):

• FOIT (Flash of Invisible Text): مرورگر متن را تا زمان دانلود شدن فونت سفارشی شما، نامرئی نگه می‌دارد. وقتی فونت دانلود شد، متن ناگهان ظاهر می‌شود.
• FOUT (Flash of Unstyled Text): مرورگر ابتدا متن را با یک فونت پیش‌فرض سیستم (مثلاً Arial) نمایش می‌دهد. پس از دانلود شدن فونت سفارشی شما (مثلاً Vazir), متن با فونت جدید جایگزین می‌شود. از آنجایی که ابعاد این دو فونت متفاوت است، کل پاراگراف دچار پرش و بازچینی می‌شود.

۴. محتوای داینامیک:

بنرهای «کوکی»، نوارهای «اخبار فوری» یا بخش «محصولات مرتبط» که با تأخیر و توسط جاوا اسکریپت به بالای محتوای موجود اضافه می‌شوند، باعث جابجایی کل صفحه به پایین می‌شوند.

راهکارهای عملی: تعریف دقیق ابعاد (width/height) تصاویر و ویدئوها

ساده‌ترین و مؤثرترین راهکار برای بخش بزرگی از مشکلات CLS، احترام به فضای عناصر است:

• استفاده از width و height در HTML:

همیشه برای تگ‌های <img> و <video> خود ابعاد را مشخص کنید.

<img src=”image.jpg” width=”800″ height=”450″ alt=”…”>

حتی اگر با CSS ابعاد آن را ریسپانسیو می‌کنید (مثلاً width: 100%)، مرورگر با داشتن این دو عدد می‌تواند «نسبت ابعاد» (Aspect Ratio) را محاسبه کرده و قبل از دانلود شدن تصویر، فضای صحیح (مثلاً با نسبت ۱۶:۹) را رزرو کند.

• استفاده از CSS aspect-ratio:

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

CSS

.image-container {

aspect-ratio: 16 / 9; /* فضای ۱۶:۹ را رزرو می‌کند */

}

مدیریت بارگذاری فونت‌ها و رزرو فضا برای محتوای داینامیک

برای مدیریت سایر دلایل CLS باید کمی دقیق‌تر عمل کرد:

۱. مدیریت بارگذاری فونت‌ها:

• استفاده از font-display: swap;: این دستور به مرورگر می‌گوید که متن را بلافاصله با فونت پیش‌فرض (FOUT) نشان دهد و پس از آماده شدن فونت سفارشی، آن‌ها را جابجا (Swap) کند. این کار بهتر از نامرئی بودن متن (FOIT) است اما همچنان CLS ایجاد می‌کند.
• راه‌حل بهتر (Preload): فونت‌های کلیدی (مثلاً فونت اصلی بدنه متن) را با link rel=”preload” در <head> پیش‌بارگذاری کنید. این کار شانس آماده بودن فونت قبل از نمایش متن را بسیار بالا می‌برد.
• تنظیمات font-face: سعی کنید فونت پیش‌فرض (fallback) را طوری انتخاب کنید که از نظر اندازه و ارتفاع خط، شباهت زیادی به فونت سفارشی شما داشته باشد تا میزان پرش در زمان FOUT به حداقل برسد.

۲. رزرو فضا برای محتوای داینامیک (تبلیغات و بنرها):

• هرگز اجازه ندهید یک بنر تبلیغاتی یا یک ویدئوی embed شده، محتوای شما را جابجا کند.
• راه‌حل: برای عنصری که قرار است با تأخیر بارگذاری شود (مثل جایگاه تبلیغ)، یک <div> نگهدارنده (Placeholder) با ارتفاع مشخص (min-height) در نظر بگیرید.

CSS

.ad-slot {

min-height: 250px; /* رزرو فضا برای بنر ۲۵۰*۳۰۰ */

width: 300px;

}

به این ترتیب، حتی اگر بارگذاری تبلیغ ۵ ثانیه طول بکشد، فضای آن از ابتدا رزرو شده و هیچ پرشی در صفحه رخ نخواهد داد.

 

فرآیند اعتبارسنجی (Validate Fix): چگونه به گوگل بگوییم مشکل حل شد؟

 

گام به گام استفاده از دکمه «Start Validation» در سرچ کنسول

استفاده از این دکمه ساده است، اما باید در زمان درستی انجام شود.

1. ابتدا، مشکل را واقعاً حل کنید: قبل از کلیک، مطمئن شوید که تغییرات فنی لازم (مانند بهینه‌سازی تصاویر، اصلاح CSS، تعریف ابعاد و…) روی سایت شما منتشر شده و کش (Cache) سایت پاک شده است.
2. ورود به گزارش: به گزارش Core Web Vitals در سرچ کنسول بروید.
3. انتخاب مشکل: روی یکی از گروه‌های مشکل‌دار (مثلاً در بخش ‘Poor’ یا ‘Needs Improvement’) که آن را رفع کرده‌اید، کلیک کنید.
4. شروع اعتبارسنجی: در بالای صفحه گزارش آن مشکل، دکمه ‘Validate Fix‘ (در فارسی ممکن است «اعتبارسنجی اصلاح» باشد) را پیدا و کلیک کنید.
5. تأیید اولیه: گوگل ابتدا یک بررسی سریع (شبیه به تست آزمایشگاهی) روی چند URL نمونه انجام می‌دهد تا ببیند آیا به نظر می‌رسد مشکل به طور کلی برطرف شده است یا خیر.
6. شروع نظارت: اگر تست اولیه موفقیت‌آمیز باشد، فرآیند نظارت ۲۸ روزه (که در بخش بعد توضیح می‌دهیم) آغاز می‌شود. شما می‌توانید وضعیت این فرآیند را (Pending, Started, Passed, Failed) در همان صفحه پیگیری کنید.

چرخه ۲۸ روزه داده‌های CrUX: چرا نتایج اعتبارسنجی بلافاصله سبز نمی‌شود؟

این بخش مهم‌ترین قسمتی است که باعث سردرگمی می‌شود. اعتبارسنجی Core Web Vitals یک تست آزمایشگاهی (Lab Test) مانند Lighthouse نیست که در لحظه نتیجه بدهد.

• وابستگی به CrUX: این گزارش بر اساس داده‌های میدانی (Field Data) یا همان CrUX (Chrome User Experience Report) کار می‌کند.
• دوره ۲۸ روزه: CrUX داده‌های ۲۸ روز گذشته کاربران واقعی شما را جمع‌آوری و میانگین‌گیری می‌کند.
• فرآیند اعتبارسنجی: وقتی شما ‘Validate Fix’ را می‌زنید، گوگل شروع به جمع‌آوری داده‌های جدید از کاربرانی می‌کند که نسخه اصلاح‌شده سایت شما را می‌بینند.
• چرا طول می‌کشد؟ گوگل باید منتظر بماند تا داده‌های بدِ ۲۸ روز گذشته، به تدریج از این میانگین متحرک خارج شوند و داده‌های خوبِ جدید جایگزین آن‌ها شوند. این فرآیند به طور طبیعی تا ۲۸ روز طول می‌کشد تا گوگل اطمینان حاصل کند که مشکل برای درصد قابل توجهی از کاربران (آستانه ۷۵ درصد) به طور پایدار حل شده است.

نکته کلیدی: شما برای سبز شدن، منتظر نتیجه یک تست فنی نیستید؛ منتظر جمع‌آوری داده‌های کافی از کاربران واقعی در یک بازه زمانی هستید.

اشتباهات رایج در فرآیند اعتبارسنجی که باعث شکست آن می‌شود

شکست در اعتبارسنجی (Validation Failed) معمولاً به دلیل یکی از این اشتباهات رخ می‌دهد:

• حل نکردن مشکل ریشه‌ای: رایج‌ترین اشتباه. گزارش سرچ کنسول URLها را «گروه‌بندی» می‌کند. اگر شما فقط URL نمونه‌ای که گوگل نشان داده را اصلاح کنید، اما مشکل اصلی در قالب (Template)، افزونه یا CSS/JS مشترکی که روی تمام آن گروه از صفحات تأثیر می‌گذارد را حل نکنید، اعتبارسنجی شکست می‌خورد.
• کلیک زودهنگام: اعتبارسنجی را قبل از اینکه تغییرات به طور کامل روی سرور اعمال شوند و کش سایت (شامل CDN) به طور کامل پاک شود، شروع می‌کنید.
• اصلاح ناکافی (مرزی): شما مشکل را بهبود داده‌اید، اما نه به اندازه‌ای که به آستانه «خوب» (Good) برسد. برای مثال، LCP را از ۵ ثانیه به ۳ ثانیه کاهش داده‌اید. این هنوز در محدوده «Needs Improvement» است و اعتبارسنجی آن را «Passed» (قبول) در نظر نمی‌گیرد.
• عدم دریافت داده کافی: اگر آن گروه از URLها ترافیک کافی از کاربران کروم نداشته باشند، گوگل داده میدانی لازم برای تکمیل چرخه ۲۸ روزه را نخواهد داشت و فرآیند ممکن است متوقف شود یا اصلاً شروع نشود.

ابزارهای فراتر از سرچ کنسول برای عیب‌یابی Core Web Vitals

سرچ کنسول (GSC) مقصد نهایی شما برای دیدن نتایج داده‌های میدانی (Field Data) است. اما فرآیند عیب‌یابی (Debugging) در ابزارهای آزمایشگاهی (Lab Data) انجام می‌شود. برای رفع مشکلات گزارش‌شده در GSC، باید از این ابزارها برای شبیه‌سازی، شناسایی ریشه مشکل و تست راه‌حل استفاده کنید.

PageSpeed Insights: ترکیب طلایی داده‌های میدانی و آزمایشگاهی

PageSpeed Insights (PSI) مهم‌ترین ابزار شما پس از GSC است، زیرا تنها ابزاری است که هر دو نوع داده را در یک گزارش به شما می‌دهد.

• بخش بالایی (داده‌های میدانی – CrUX): این بخش به شما نشان می‌دهد که کاربران واقعی در ۲۸ روز گذشته چه تجربه‌ای داشته‌اند. این همان داده‌ای است که در سرچ کنسول می‌بینید. اگر این بخش قرمز یا زرد باشد، یعنی شما یک مشکل واقعی دارید.
• بخش پایینی (داده‌های آزمایشگاهی – Lighthouse): این بخش یک شبیه‌سازی لحظه‌ای از بارگذاری صفحه شماست. مهم‌تر از امتیاز، بخش “Diagnostics” (عیب‌یابی) آن است.

روند کاری:

۱. URL گزارش‌شده در سرچ کنسول را در PSI تست کنید.

۲. در بخش بالا تایید کنید که مثلاً LCP در داده‌های میدانی ضعیف است.

۳. به بخش پایین (آزمایشگاهی) بروید و در قسمت Diagnostics ببینید Lighthouse چه دلایلی پیدا کرده است (مثلاً: “Largest Contentful Paint element” را مشخص می‌کند، یا “Reduce initial server response time” را پیشنهاد می‌دهد).

استفاده از Lighthouse در Chrome DevTools برای تشخیص مشکلات (Lab Data)

Lighthouse موتوری است که داده‌های آزمایشگاهی PSI را تولید می‌کند. شما می‌توانید این موتور را مستقیماً در مرورگر کروم خود اجرا کنید.

• مکان: در مرورگر کروم، F12 (یا Ctrl+Shift+I) را بزنید تا DevTools باز شود. سپس به تب “Lighthouse” بروید.
• کاربرد: این ابزار برای تست تغییرات قبل از انتشار حیاتی است.
• روند کاری:

۱. تغییرات خود را روی سایت (یا بهتر از آن، روی یک محیط آزمایشی – Staging) اعمال می‌کنید.

۲. گزارش Lighthouse را در DevTools اجرا می‌کنید.

۳. بلافاصله می‌بینید که آیا تغییر شما (مثلاً بهینه‌سازی یک تصویر) امتیاز LCP را در محیط آزمایشگاهی بهبود داده است یا خیر.

این یک چرخه سریع عیب‌یابی و تست است که به شما اجازه می‌دهد راه‌حل‌های مختلف را امتحان کنید قبل از اینکه منتظر چرخه ۲۸ روزه داده‌های میدانی بمانید.

اکستنشن Web Vitals: نظارت زنده بر متریک‌ها در مرورگر

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

• کاربرد اصلی: این ابزار بهترین راه برای پیدا کردن مشکلات CLS و INP است.
• روند کاری:

۱. افزونه را نصب و فعال کنید.

۲. در سایت خود شروع به گشت‌وگذار کنید.

۳. برای CLS: همانطور که صفحه بارگذاری می‌شود، اگر پرشی رخ دهد، امتیاز CLS را به صورت زنده در آیکون افزونه می‌بینید.

۴. برای INP: روی دکمه‌ها، منوها و فرم‌ها کلیک کنید. اگر تعاملی کند باشد، افزونه آن را ثبت می‌کند.

این ابزار به شما کمک می‌کند دقیقاً بفهمید کدام عنصر در صفحه در حال پرش است یا کدام کلیک باعث کندی می‌شود، زیرا مشکل را در لحظه وقوع به شما نشان می‌دهد.

استفاده از WebPageTest (WPT) برای تحلیل‌های عمیق‌تر رندرینگ

وقتی PSI و Lighthouse دلایل واضحی ارائه نمی‌دهند، WebPageTest ابزار متخصصان برای تحلیل‌های عمیق است. این ابزار فقط امتیاز نمی‌دهد، بلکه فرآیند بارگذاری را کالبدشکافی می‌کند.

• ویژگی‌های کلیدی: «نمای نواری» (Filmstrip View) و «نمودار آبشاری» (Waterfall Chart).
• روند کاری:

۱. نمای نواری (Filmstrip): WPT یک ویدئوی فریم به فریم از بارگذاری سایت شما ضبط می‌کند. شما می‌توانید به صورت بصری ببینید که عنصر LCP دقیقاً در کدام ثانیه ظاهر می‌شود و چه عناصری قبل از آن بارگذاری شده و مسیر را مسدود کرده‌اند.

۲. نمودار آبشاری (Waterfall): این نمودار به شما نشان می‌دهد که هر فایل (CSS, JS, Image) چه زمانی شروع به دانلود شدن کرده و چقدر طول کشیده است. با این نمودار می‌توانید به سادگی منابع مسدودکننده رندر (Render-Blocking Resources) که مستقیماً LCP را به تأخیر می‌اندازند، شناسایی کنید.

این ابزار برای تشخیص مشکلات پیچیده در زنجیره رندر (Critical Rendering Path) ضروری است.

استراتژی بلندمدت برای حفظ نمرات سبز CWV

چک‌لیست نهایی بهینه‌سازی Core Web Vitals

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

بخش ۱: بهینه‌سازی LCP (سرعت بارگذاری)

• TTFB (سرور): اطمینان از فعال بودن Caching در سطح سرور و استفاده از CDN. زمان پاسخ سرور باید پایین بماند.
• تصاویر:
  • استفاده از فرمت‌های مدرن (WebP یا AVIF) به جای JPG/PNG.
  • فشرده‌سازی تصاویر بدون افت کیفیت محسوس.
  • اطمینان از اینکه تصویر LCP (عنصر اصلی) هرگز Lazy-Load نمی‌شود.
• منابع مسدودکننده (Render-Blocking):
  • به تعویق انداختن (Defer) فایل‌های JavaScript غیرضروری.
  • استخراج و درون‌ریزی (Inline) کدهای CSS حیاتی (Critical CSS) برای رندر بخش بالایی صفحه.
• پیش‌بارگذاری (Preload): استفاده از rel=”preload” برای منابع کلیدی که LCP به آن‌ها وابسته است (مانند تصویر اصلی یا فایل فونت اصلی).

بخش ۲: بهینه‌سازی INP (پاسخ‌دهی)

• حسابرسی جاوا اسکریپت:
  • شناسایی و بهینه‌سازی «تسک‌های طولانی» (Long Tasks) با شکستن آن‌ها به بخش‌های کوچکتر.
  • بررسی و حذف کدهای JS بلااستفاده (Code Splitting).
• اسکریپت‌های Third-Party:
  • حسابرسی منظم ابزارهای شخص ثالث (چت زنده، آنالیتیکس، تبلیغات).
  • بارگذاری تأخیری (Lazy-Load) این اسکریپت‌ها تا زمانی که واقعاً به آن‌ها نیاز باشد (مثلاً پس از اولین اسکرول کاربر).

بخش ۳: بهینه‌سازی CLS (ثبات بصری)

• تصاویر و ویدئوها: تعریف width و height مشخص برای تمام رسانه‌ها در HTML.
• CSS aspect-ratio: استفاده از این ویژگی CSS برای رزرو فضای عناصر قبل از بارگذاری.
• محتوای داینامیک:
  • رزرو فضای مشخص (مثلاً با min-height) برای جایگاه تبلیغات، بنرها یا iframeها.
  • جلوگیری از تزریق محتوا به بالای صفحه (مثل نوار کوکی یا بنر عضویت) که باعث جابجایی محتوای موجود شود.
• فونت‌ها (Fonts):
  • میزبانی فونت‌ها در سرور خود (Self-Hosting) به جای فراخوانی از سرور دیگر.
  • استفاده از font-display: swap به همراه preload برای فایل فونت اصلی جهت کاهش پرش متن (FOUT).

چگونه CWV را بخشی از فرآیند دائمی توسعه محصول کنیم؟

تبدیل CWV از یک «پروژه سئو» به یک «بخشی از فرآیند» (Process) کلید موفقیت بلندمدت است. این کار نیازمند تغییر در فرهنگ تیم محصول و توسعه است.

۱. تعریف بودجه عملکرد (Performance Budgets)

قبل از اینکه هر ویژگی جدیدی توسعه یابد، باید مشخص شود که این ویژگی چقدر «بودجه» برای مصرف منابع دارد.

• مثال: «هر صفحه جدید نباید بیشتر از ۲۰۰ کیلوبایت JS داشته باشد» یا «اضافه شدن این فیلتر جدید نباید INP را بیش از ۵۰ میلی‌ثانیه افزایش دهد.»
• این کار از اضافه شدن ویژگی‌های سنگین که عملکرد را تخریب می‌کنند، جلوگیری می‌کند.

۲. ادغام تست‌ها در فرآیند توسعه (CI/CD)

نباید منتظر گزارش سرچ کنسول ماند. ابزارهایی مانند Lighthouse باید در فرآیند توسعه (Pipeline) ادغام شوند.

• روند کاری: توسعه‌دهنده یک کد جدید را ثبت می‌کند. قبل از اینکه کد روی سایت اصلی منتشر شود، یک تست Lighthouse خودکار اجرا می‌شود.
• نتیجه: اگر کد جدید باعث افت شدید امتیازات CWV (مثلاً CLS را از ۰ به ۰.۲ برساند)، سیستم باید هشدار دهد یا حتی از انتشار آن جلوگیری کند.

۳. نظارت مستمر (RUM – Real User Monitoring)

داده‌های ۲۸ روزه سرچ کنسول برای واکنش سریع بسیار کند هستند. شما به ابزارهای نظارت بر کاربر واقعی (RUM) نیاز دارید که داده‌ها را به صورت آنی‌تری نشان دهند.

• کاربرد: شما یک ویژگی جدید را امروز منتشر می‌کنید. با ابزارهای RUM می‌توانید فردا ببینید که آیا LCP یا INP کاربران واقعی در مرورگرهای مختلف دچار مشکل شده است یا خیر، و در صورت نیاز به سرعت آن را اصلاح کنید.

۴. مسئولیت‌پذیری مشترک

Core Web Vitals فقط وظیفه تیم سئو یا تیم فنی نیست.

• تیم مارکتینگ باید بداند که اضافه کردن یک اسکریپت سنگین جدید (مثلاً برای یک پاپ‌آپ) مستقیماً بر INP و CLS تأثیر می‌گذارد.
• تیم تولید محتوا باید بداند که آپلود تصاویر حجیم و بهینه نشده بر LCP تأثیر می‌گذارد.

وقتی عملکرد (Performance) به یک شاخص کلیدی (KPI) مشترک برای همه تیم‌ها تبدیل شود، حفظ نمرات سبز به یک نتیجه طبیعی تبدیل خواهد شد.

جمع‌بندی 

جمع‌بندی: Core Web Vitals یک فرآیند دائمی است

بهینه‌سازی Core Web Vitals یک پروژه یک‌باره نیست، بلکه یک بخش دائمی از نگهداری و توسعه وب‌سایت است. دریافت نمره سبز در LCP, INP و CLS پایان کار نیست؛ چالش اصلی در حفظ این نمرات است.

هر ویژگی جدید، هر افزونه یا هر قطعه محتوای تازه‌ای که به سایت اضافه می‌شود، پتانسیل تخریب این معیارها را دارد. موفقیت بلندمدت نیازمند نظارت مستمر از طریق گزارش سرچ کنسول (داده‌های میدانی) و تست مداوم تغییرات با ابزارهای آزمایشگاهی (مانند Lighthouse) است. در نهایت، CWV فقط مجموعه‌ای از اعداد فنی نیست؛ این معیارها نشان‌دهنده میزان احترام شما به زمان و تجربه مخاطب هستند و گوگل دقیقاً به همین تجربه پایدار پاداش می‌دهد.