آشنایی عمیق با Core Web Vitals
Core Web Vitals سه عدد است که سه چیز کاملا متفاوت را می سنجند: LCP سرعت دیده شدن بزرگ ترین عنصر صفحه، INP سرعت پاسخ به کلیک و لمس کاربر، و CLS مقدار جابه جایی ناخواسته چیدمان. گوگل هر سه را نه از تست شما، بلکه از صدک ۷۵ بازدیدکننده های واقعی و به تفکیک موبایل و دسکتاپ قضاوت می کند.
- درس ۳ از ۱۰
- میانی
- رایگان، بدون ثبت نام
عددی که تصمیم می گیرد قبول شده اید یا نه
نمره تست شما نیست. صدک ۷۵ بازدیدکننده های واقعی است، به تفکیک موبایل و دسکتاپ، و هر سه شاخص باید با هم به هدف برسند.
- LCPبزرگ ترین عنصر صفحه، ۲.۵ ثانیه یا کمتر
- INPپاسخ به کلیک و لمس، ۲۰۰ میلی ثانیه یا کمتر
- CLSجابه جایی ناخواسته چیدمان، ۰.۱ یا کمتر
عقربه روی مرز ناحیه هدف ایستاده و ادعا نمی کند شما کجایید. جای شما روی این صفحه را فقط داده میدانی خودتان می داند، و اگر سایتتان کم بازدید باشد ممکن است اصلا چنین داده ای نداشته باشید.
آخرین بررسی: فکت ها و نام ابزارهای این درس در همین تاریخ با منابعشان بازبینی شده اند.
هر کدام از این سه عدد چه چیزی را می سنجند
Core Web Vitals سه شاخص است، نه یک نمره. اسمشان کنار هم می آید و همین باعث می شود خیلی ها فکر کنند سه روایت از یک چیزند. نیستند. هر کدام لحظه متفاوتی از تجربه کاربر را می گیرند و هر کدام معمولا از جای متفاوتی خراب می شوند.
LCP یا Largest Contentful Paint زمانی است که بزرگ ترین عنصر محتوایی داخل کادر دید نمایش داده می شود. معمولا یک تصویر بزرگ است یا یک بلوک متن. مستندات گوگل می گوید سایت ها باید تلاش کنند LCP دو و نیم ثانیه یا کمتر داشته باشند. این عدد جواب سوال «آیا چیزی دیدم» است.
INP یا Interaction to Next Paint فاصله بین کاری که کاربر می کند و لحظه ای است که مرورگر فریم بعدی را می کشد. گوگل می نویسد صفحه باید INP دویست میلی ثانیه یا کمتر داشته باشد و بالای پانصد میلی ثانیه ضعیف حساب می شود. این عدد جواب سوال «وقتی زدم، چیزی شد» است.
اینجا همان جایی است که مدل های زبانی و مقاله های قدیمی هر دو غلط جواب می دهند. INP جانشین FID است، و صفحه خود گوگل همین را می نویسد. تفاوتشان کوچک نیست: FID فقط تاخیر ورودی اولین تعامل صفحه را می سنجید، در حالی که INP همه تعامل ها را در تمام مدت حضور کاربر می بیند، از تاخیر ورودی تا اجرای هندلرها تا لحظه ای که مرورگر فریم بعدی را نقاشی می کند. اگر جایی عدد صد میلی ثانیه دیدید، آن عدد مال شاخصی است که دیگر Core Web Vital نیست.
CLS یا Cumulative Layout Shift اصلا واحد زمان ندارد. عددی بی واحد است که می گوید محتوای صفحه چقدر بدون اینکه کاربر کاری کرده باشد جابه جا شده. گوگل می نویسد سایت ها باید CLS صفر و یک دهم یا کمتر داشته باشند. این عدد جواب سوال «چیزی که می خواستم بزنم، سر جایش ماند» است.
سه سوال متفاوت، سه جواب متفاوت. صفحه ای که در یکی عالی است می تواند در دیگری افتضاح باشد، و این حالت نادر نیست: یک صفحه متنی سبک با LCP خیلی خوب و یک اسکریپت چت سنگین، INP بدی دارد و LCP خوبی. توضیح ساده تر همین سه شاخص را در مقدمه ای که برای همین سه شاخص نوشته ایم آورده ایم و این درس از آنجا شروع نمی کند، ادامه اش می دهد.
چرا عدد شما با عددی که گوگل می بیند یکی نیست
این تفاوت را هم مبتدی ها اشتباه می گیرند و هم مدل های زبانی، و بیشتر بحث های بی نتیجه درباره سرعت از همین جا شروع می شود. دو نوع داده وجود دارد و اسمشان را باید یاد گرفت.
داده آزمایشگاهی از یک اجرای شبیه سازی شده می آید: یک دستگاه فرضی، یک شبکه فرضی، یک بار باز کردن صفحه. تکرارپذیر است، همین حالا در دسترس است، و برای پیدا کردن علت عالی است. اما تجربه هیچ کاربر واقعی نیست.
داده میدانی از بازدیدکننده های واقعی جمع می شود. گزارش تجربه کاربری کروم همین است: اندازه گیری ناشناس کاربران واقعی برای هر سه شاخص. این داده ای است که گوگل با آن قضاوت می کند.
و اینجا عددی است که همه چیز را عوض می کند. گوگل می نویسد برای اطمینان از رسیدن به هدف برای بیشتر کاربران، آستانه خوب برای اندازه گیری صدک ۷۵ بارگذاری صفحه است، به تفکیک موبایل و دسکتاپ. یعنی کندترین یک چهارم کاربران شما تعیین می کند قبول می شوید یا نه، و ابزاری که وضعیت Core Web Vitals را می سنجد صفحه را وقتی قبول حساب می کند که هر سه شاخص در صدک ۷۵ به هدف رسیده باشند.
پیامدش برای سایت ایرانی مستقیم است: تست روی لپ تاپ شما با اینترنت خوب، به احتمال زیاد بهترین حالت ممکن را نشان می دهد، در حالی که صدک ۷۵ شما از موبایل روی شبکه ای می آید که پایدار نیست. فاصله این دو عدد چیزی نیست که با حدس پر شود.
مشکل دوم که کمتر گفته می شود: ممکن است اصلا داده میدانی نداشته باشید. گوگل شرط های ورود به آن مجموعه داده را نوشته و یکی از آنها این است که صفحه یا دامنه به اندازه کافی پربازدید باشد، یعنی حداقلی از بازدیدکننده داشته باشد. آن حداقل عدد را گوگل منتشر نکرده. پس اگر جای داده میدانی سایتتان خالی است، خرابی نیست؛ حالت عادی یک سایت کم بازدید است، و تنها راه پیش رفتن این است که همین را بپذیرید و به داده آزمایشگاهی به عنوان سرنخ نگاه کنید نه به عنوان حکم.
دو عددی که هر دو درست اند و یکی نیستند
داده آزمایشگاهی
- یک اجرای شبیه سازی شده روی دستگاه و شبکه فرضی
- همین حالا در دسترس است، حتی برای سایت تازه
- تکرارپذیر است، پس برای پیدا کردن علت خوب است
- تجربه هیچ کاربر واقعی نیست
داده میدانی
- از بازدیدکننده های واقعی خود شما جمع می شود
- گوگل با همین قضاوت می کند، در صدک ۷۵
- موبایل و دسکتاپ جدا شمرده می شوند
- برای سایت کم بازدید ممکن است اصلا وجود نداشته باشد
هیچ کدام از این دو ستون بهتر از دیگری نیست؛ دو کار متفاوت می کنند. علت را در ستون راست پیدا می کنید و حکم را در ستون چپ می گیرید.
وقتی LCP بد است، وقت کجا رفته
«LCP بد است» یک تشخیص نیست، یک علامت است. گوگل خودش LCP را به چهار تکه شکسته و همین شکستن است که کار را از حدس زدن در می آورد.
تکه اول زمان تا اولین بایت است: از لحظه درخواست تا لحظه ای که سرور اولین بایت پاسخ را می فرستد. تکه دوم تاخیر شروع بارگذاری منبع است: فاصله بین همان اولین بایت و لحظه ای که مرورگر تازه شروع می کند به گرفتن منبع LCP. تکه سوم مدت بارگذاری منبع است، یعنی خود دانلود آن تصویر یا فونت. تکه چهارم تاخیر نمایش عنصر است: از پایان دانلود تا وقتی که عنصر کامل روی صفحه می آید.
گوگل برای این چهار تکه یک توزیع تقریبی هم منتشر کرده: زمان تا اولین بایت حدود ۴۰٪ از LCP، تاخیر شروع بارگذاری کمتر از ۱۰٪، مدت بارگذاری منبع حدود ۴۰٪ و تاخیر نمایش عنصر کمتر از ۱۰٪. خود گوگل بلافاصله می نویسد که این تقسیم راهنماست و نه قاعده سخت، و صریحا توصیه می کند این درصدها را به عدد مطلق تبدیل نکنید.
حتی با آن هشدار، همین تقسیم یک چیز را روشن می کند که در بازار ایران خیلی وقت ها برعکسش گفته می شود: حدود هشتاد درصد LCP یک صفحه معمولی در دو تکه ای می نشیند که هیچ کدام درباره افزونه های سایت شما نیستند. یکی زمان پاسخ سرور است و دیگری دانلود یک فایل. اگر کسی برای LCP بد شما نسخه کم کردن افزونه می پیچد بدون اینکه اول ببیند اولین بایت کی می رسد، دارد از وسط شروع می کند. رابطه هاست و همین عددها را در نوشته ای درباره اثر هاست بر Core Web Vitals جدا باز کرده ایم.
LCP از چهار تکه ساخته شده، و دو تای آنها بیشترش را می خورند
- حدود ۴۰٪
- کمتر از ۱۰٪
- حدود ۴۰٪
- کمتر از ۱۰٪
- زمان تا اولین بایت حدود ۴۰٪
- تاخیر شروع بارگذاری منبع کمتر از ۱۰٪
- مدت بارگذاری منبع حدود ۴۰٪
- تاخیر نمایش عنصر کمتر از ۱۰٪
خود گوگل نوشته این تقسیم راهنماست و نه قاعده سخت، و توصیه کرده این درصدها را به ثانیه تبدیل نکنید. برای سایت شما ممکن است کاملا فرق کند و فقط اندازه گیری خودتان جوابش را دارد.
INP و CLS معمولا از کجا خراب می شوند
INP از جاوااسکریپت خراب می شود، تقریبا همیشه. کاربر می زند، و مرورگر برای اینکه فریم بعدی را بکشد باید صبر کند تا کاری که همان لحظه در حال اجراست تمام شود. هر کاری که رشته اصلی را طولانی اشغال کند این صبر را می سازد: اسکریپت شمارنده، ویجت چت، اسلایدر، اسکریپت تبلیغاتی، یا کد خود قالب که در لحظه کلیک کار سنگینی می کند. نکته ای که در گزارش ها کم دیده می شود این است که INP کل عمر صفحه را نگاه می کند، نه فقط ثانیه های اول؛ پس اسکریپتی که سه ثانیه بعد از باز شدن صفحه بارگذاری می شود هم می تواند خرابش کند.
CLS از دو خانواده خراب می شود. اول چیزی که جا نگرفته: تصویر یا ویدیو یا آی فریمی که ابعادش اعلام نشده و وقتی می رسد بقیه صفحه را هل می دهد. دوم چیزی که دیر می آید: بنر، نوار اعلان، محتوایی که با جاوااسکریپت بالای صفحه تزریق می شود، یا فونتی که متن را بعد از نمایش دوباره می چیند.
و حالا قاعده ای که تقریبا هیچ آموزشی نمی نویسد و بدون آن CLS را غلط می خوانید: جابه جایی ای که ظرف ۵۰۰ میلی ثانیه بعد از ورودی کاربر رخ بدهد پرچم خورده و می شود آن را از حساب بیرون گذاشت. یعنی وقتی خودتان روی دکمه منو می زنید و منو باز می شود، آن جابه جایی به CLS شما اضافه نمی شود. این عمدی است: مرورگر بین «صفحه زیر دستم تکان خورد» و «من خودم باعثش شدم» فرق می گذارد. کسی که این را نداند، آکاردئون و منوی خودش را به عنوان مشکل CLS گزارش می کند و وقتش را جای اشتباه می گذارد.
یک مرز دیگر هم بگذاریم، چون بی آن این سه عدد بت می شوند: CLS خوب یعنی صفحه زیر دست کاربر نمی پرد، نه اینکه طراحی خوب است. سایتی با CLS صفر و متنی که هیچ کس نمی فهمد، همچنان سایت بدی است.
همه جابه جایی ها به حساب شما نوشته نمی شوند
به CLS شما اضافه می شود
- تصویری که ابعادش اعلام نشده و وقتی می رسد متن را هل می دهد
- بنر یا نوار اعلانی که با تاخیر بالای صفحه می نشیند
- فونتی که بعد از نمایش متن، دوباره همه چیز را می چیند
- محتوایی که جاوااسکریپت وسط صفحه تزریق می کند
شمرده نمی شود
- باز شدن منو بعد از اینکه خود کاربر روی دکمه زده
- باز شدن آکاردئون سوالات متداول با کلیک خود کاربر
- هر جابه جایی ظرف ۵۰۰ میلی ثانیه بعد از ورودی کاربر
ستون پایین را بدون خواندن قاعده ۵۰۰ میلی ثانیه نمی شود فهمید. اگر آن را ندانید، منوی خودتان را به عنوان مشکل CLS گزارش می کنید.
این سه عدد چه چیزی را به شما نمی گویند
سه شاخص سبز یعنی صفحه شما زیر دست کاربر بد رفتار نمی کند. یعنی همین و نه بیشتر. نمی گوید محتوایتان جواب سوال را می دهد، نمی گوید قیمتتان منطقی است، و نمی گوید صفحه ایندکس شده. خود گوگل هم در صفحه تجربه صفحه نوشته که نمره خوب رتبه بالا را تضمین نمی کند.
دو چیز هم هست که این سه عدد اصلا نمی بینند. یکی سرعت مسیرهای بعدی سایت است: Core Web Vitals روی بارگذاری صفحه تمرکز دارد و INP هرچند کل عمر صفحه را می بیند، باز هم چیزی درباره اینکه فرم شما چقدر طول می کشد تا ثبت شود نمی گوید. دیگری وضعیت کاربرانی است که به هر دلیل در آن مجموعه داده نیستند.
بنابراین ترتیب درست کار این است: اول ببینید صفحه ای که می خواهید سریع باشد اصلا برای کسی مهم است یا نه، بعد سراغ این سه عدد بروید. درس بعدی همین مسیر نشان می دهد این عددها را با چه ابزاری بگیرید و گزارش را چطور بخوانید؛ فهرست کامل درس ها روی صفحه همین مسیر آموزشی است.
مسیر سریع با هوش مصنوعی
راه معمولی پرسیدن درباره Core Web Vitals این است که سوال را مستقیم از یک چت بات بپرسید. برای این موضوع بدترین کار همین است، و دلیلش را در بخش بعدی می بینید: آستانه ها عوض شده اند و متن اینترنت هنوز پر از عددهای قدیمی است. راه سریع یک تغییر کوچک دارد که همه چیز را عوض می کند: به جای پرسیدن از حافظه مدل، خود صفحه های مستندات گوگل را به یک ابزار سندمحور بدهید و سوال را از داخل سند بپرسید. جواب آن وقت از متن گوگل می آید و شما می توانید هر جمله اش را به مرجعش برگردانید.
- سه صفحه مستندات گوگل را که پایین همین درس در منابع آمده به یک ابزار سندمحور بدهید: صفحه Web Vitals و صفحه های اختصاصی LCP و INP و CLS. اگر ابزارتان نشانی وب می گیرد، همان نشانی ها کافی است؛ اگر نه، متن صفحه را ذخیره و بارگذاری کنید.
- سه عدد خودتان را کنارش بگذارید، از داده میدانی و نه از تست. اگر داده میدانی ندارید همین را بنویسید و از مدل بخواهید همین کمبود را در جوابش لحاظ کند، نه اینکه از عدد آزمایشگاهی نتیجه میدانی بگیرد.
- دستور زیر را بدهید. قاعده مهمش این است که هر جمله باید به سندی که خودتان بارگذاری کرده اید برگردد، و هر چیزی که در سندها نیست باید صریحا نامعلوم اعلام شود. برای این کار مدل گران لازم نیست؛ کاری که می خواهید نقل دقیق از سند است و نه قضاوت، پس یک مدل سریع و ارزان از رده Gemini Flash هم جواب می دهد. انتخاب امروزی هر رده در مرجع هوش مصنوعی ما نگهداری می شود.
- جواب را با یک تست ساده بسنجید: از مدل بپرسید آستانه خوب INP چند است و منبعش کجاست. اگر عددی غیر از دویست میلی ثانیه گفت، یا نتوانست جمله اش را به سند برگرداند، سندها درست بارگذاری نشده اند و باقی جواب هم قابل اعتماد نیست.
نسخه آماده کپی
فقط از سندهایی که بارگذاری کرده ام جواب بده. هر ادعایی که در آن سندها نیست را با عبارت «در سندها نیست» علامت بزن و حدس نزن.
عددهای من (داده میدانی، صدک ۷۵):
LCP = {عدد یا «داده میدانی ندارم»}
INP = {عدد یا «داده میدانی ندارم»}
CLS = {عدد یا «داده میدانی ندارم»}
دستگاه: {موبایل | دسکتاپ | هر دو}
پنج چیز بنویس:
۱. برای هر سه شاخص، آستانه «خوب» را از سند نقل کن و بگو از کدام صفحه آمده.
۲. بگو کدام یک از سه عدد من رد شده و با چه فاصله ای از آستانه.
۳. برای هر شاخص رد شده، فهرست علت های محتملی را که سند خودش نام برده بنویس، و هیچ علتی از خودت اضافه نکن.
۴. اگر یکی از عددهای من «داده میدانی ندارم» بود، ننویس که آن شاخص سالم است؛ بنویس که قضاوتی درباره اش ممکن نیست و چه چیزی لازم است تا بشود.
۵. در آخر بنویس کدام جمله های جوابت را نتوانستی به سند برگردانی.
قاعده ها: هیچ آستانه ای را از حافظه ننویس. اگر جایی در سند عبارتی مثل «راهنماست و نه قاعده سخت» آمده، همان قید را در جواب بیاور. هیچ درصدی را به ثانیه تبدیل نکن. اگر متوجه شدی مدل اطلاعات قدیمی درباره شاخص FID دارد، آن را کنار بگذار و فقط از سند نقل کن.قبل از اعتماد به خروجی: این کار جواب را قابل ردیابی می کند و نه لزوما درست. دو چیز را خودتان باید نگه دارید. اول اینکه سند بارگذاری شده باید همان صفحه امروز باشد، نه نسخه ای که سه سال پیش ذخیره کرده اید؛ صفحه شاخص INP در شهریور ۱۴۰۴ به روزرسانی شده و همین نشان می دهد این صفحه ها زنده اند. دوم اینکه علت هایی که مدل از سند بیرون می کشد فهرست احتمالات است و نه تشخیص سایت شما؛ تشخیص از اندازه گیری خود صفحه می آید و درس بعدی همین مسیر دقیقا همان است.
هوش مصنوعی در این کار
موضع ما اینجا از بقیه درس ها سخت گیرانه تر است: برای عددهای Core Web Vitals، هیچ مدل زبانی را بدون سند جلویش نگذارید. دلیلش سلیقه نیست، تاریخ است. شاخص میانی این خانواده عوض شده، آستانه ها جابه جا شده اند، و متنی که مدل ها روی آن آموزش دیده اند سال ها همان عددهای قدیمی را تکرار کرده. مدل در این موضوع اجماع اینترنت را به شما می دهد و اجماع اینترنت اینجا کهنه است. همان مدل اما وقتی سند جلویش باشد ابزار خوبی است.
ابزارهایی که واقعا کمک می کنند
- NotebookLM ابزار درست همین کار است، چون جواب را از سندی می سازد که خودتان داده اید و ارجاع را نشان می دهد. صفحه های web.dev را بارگذاری کنید و سوال آستانه ها را از داخل سند بپرسید. روی حساب گوگل کار می کند و راهنمای خود گوگل می گوید همان جایی کار می کند که اپ جمنای کار می کند؛ ایران در فهرست کشورهای پشتیبانی شده اپ جمنای نیست.
- Gemini وقتی گزارش میدانی بلندی دارید و می خواهید جدول های بزرگ خوانده شود مفید است. برای پرسش آستانه ها باز هم بدون سند به آن اتکا نکنید. صفحه خود گوگل می گوید اپ وب جمنای در بیش از دویست و سی کشور و منطقه کار می کند و ایران در آن فهرست نیست.
- ChatGPT همان قاعده: با سند بارگذاری شده خوب کار می کند و بدون آن همان عددهای قدیمی را تکرار می کند. درباره دسترسی از ایران ادعایی نمی کنیم، چون صفحه کشورهای پشتیبانی شده اوپن ای آی مثل بقیه آن دامنه به این سرور پاسخ ۴۰۳ می دهد و ما ادعایی بدون پشتوانه نمی نویسیم.
کجا نتیجه معکوس می دهد
خطر اصلی این موضوع یک چیز مشخص است و اسم دارد: مدل به شما آستانه ای می دهد که دیگر درست نیست، و با همان لحن مطمئنی می دهد که آستانه درست را می داد. FID سال ها شاخص میانی این خانواده بود و صفحه خود گوگل می نویسد INP جانشین آن است. متن آموزشی اینترنت هنوز پر از عدد صد میلی ثانیه و اسم FID است، و مدلی که بی سند جواب می دهد از همان متن نقل می کند. عملا یعنی می توانید یک ماه روی بهینه سازی چیزی کار کنید که دیگر شمرده نمی شود. انتروپیک خودش در مستنداتش این را که مدل با اطمینان چیزی بگوید که پشتوانه ندارد، توهم می نامد. خطر دوم آرام تر است: مدل عدد آزمایشگاهی شما را می گیرد و درباره وضعیت میدانی حکم می دهد. موضع ما ساده است: سند بارگذاری شده، یا سکوت. برای این سه عدد، جوابی که به صفحه مستندات برنگردد جواب نیست.
منبع ها: web.dev: Interaction to Next Paint, the successor to FID Anthropic: reduce hallucinations Google: where Gemini Apps are available
حد این توصیه
این درس عددها را برای شما اندازه نمی گیرد و هیچ صفحه ای را سریع تر نمی کند؛ فقط کاری می کند که عددها را درست بخوانید. سه مرز دیگر هم دارد. اول اینکه هر عددی که اینجا آمده از مستندات امروز گوگل است و آن مستندات زنده اند؛ تاریخ بررسی بالای همین صفحه هست و اگر مدت زیادی از آن گذشته، خودتان یک بار لینک منابع را باز کنید. دوم اینکه هیچ کدام از این سه شاخص درباره اینکه سایت شما پول در می آورد یا نه چیزی نمی گوید و ما هم چنین ادعایی نمی کنیم. سوم اینکه تجربه ما از سایت های کسب و کارهای کوچک و متوسط ایرانی می آید؛ در مقیاس فروشگاه های بزرگ بین المللی، جایی که هر ده هزارم ثانیه با پول اندازه گیری می شود، تعادل این سه عدد فرق می کند و ما در آن مقیاس تجربه دست اولی نداریم.
از تجربه خود ما
سه شاخص را می شود بدون خرید هیچ افزونه ای هدف گرفت، اگر حاضر باشید بابتش چیزی بدهید. صفحه اول همین سایت را در ۱۷ شهریور ۱۴۰۵ اندازه گرفتیم و هر سه تصمیم روی سورس صفحه دیده می شود. برای LCP، بزرگ ترین عنصر صفحه اول ما عمدا متن است و نه تصویر: در کل سند صفر تگ img هست، چون هر چیزی که در این سایت شبیه اینفوگرافیک است با HTML و CSS کشیده شده. برای INP، در فایل استایل اصلی سایت فقط یک انیمیشن باقی مانده که همان چرخنده انتظار است و هیچ transition ای نمانده؛ در head هم صفر اسکریپت هست و هر هفت اسکریپت صفحه انتهای سند نشسته اند و اولینشان بعد از ۹۶ درصد سند شروع می شود. برای CLS، قاعده نوشته شده خودمان این است که هر تصویری که داخل متن می آید باید width و height صریح داشته باشد. حالا بهایی که واقعا دادیم: این تصمیم ها ظاهر سایت را محدود می کنند و سبک زدن انیمیشن از یک صفحه چیزی می گیرد. ما پذیرفته ایم چون معامله را می شناسیم، و نکته درس همین است که خودتان بتوانید همین معامله را قضاوت کنید نه اینکه از ما بپذیرید. همه این چیزها را می توانید همین حالا با دیدن سورس صفحه اول چک کنید.
سوال هایی که واقعا پرسیده می شوند
نمره سبز در ابزار تست یعنی Core Web Vitals من قبول است؟
نه لزوما. آن نمره از یک اجرای آزمایشگاهی می آید و قضاوت گوگل روی صدک ۷۵ بازدیدکننده های واقعی شماست، جدا برای موبایل و دسکتاپ. اگر داده میدانی دارید، تنها جایی که جواب واقعی را می دهد همان است؛ و اگر ندارید، نمره سبز فقط می گوید در آن یک اجرا چیزی خراب نبود.
چرا در گزارش من جای داده میدانی خالی است؟
چون به احتمال زیاد صفحه یا دامنه شما هنوز به آن حداقل بازدیدی که گوگل برای ورود به مجموعه داده لازم می داند نرسیده. گوگل شرط را نوشته ولی عدد آن حداقل را منتشر نکرده. این خرابی نیست و با تنظیمات هم درست نمی شود؛ تا آن وقت داده آزمایشگاهی را به عنوان سرنخ نگاه کنید.
INP همان FID است با اسم جدید؟
نه. صفحه خود گوگل می گوید INP جانشین FID است، اما آنچه می سنجد فرق دارد: FID فقط تاخیر ورودی اولین تعامل صفحه را می دید، در حالی که INP همه تعامل ها را در تمام مدت حضور کاربر می بیند و تا لحظه نقاشی فریم بعدی می شمارد. پس آستانه قدیمی و عدد قدیمی هیچ کدام دیگر به کار نمی آیند.