ممکن است Lighthouse موبایل شما ۹۸ باشد و کاربران واقعی هنوز از کندی شکایت کنند؛ یا برعکس، یک تست آزمایشگاهی قرمز باشد اما بخش بزرگی از کاربران تجربه خوبی داشته باشند. Core Web Vitals با «یک عدد از یک اجرا» مدیریت نمیشود. باید Field data را به Template، دستگاه، شبکه و Journey وصل کنید و سپس علت را در Lab بازتولید کنید.
این راهنما یک Workflow کامل برای LCP، INP و CLS میسازد: تعریف و آستانه، تفاوت CrUX/Lighthouse/RUM، تشخیص Root cause، اصلاح Frontend/Backend، کنترل Regression و ملاحظات WordPress و کاربران ایران. وضعیت Metricها و اسناد در ۶ اوت ۲۰۲۶ (۱۵ مرداد ۱۴۰۵) بازبینی شده است.
Core Web Vitals در سال ۲۰۲۶ کداماند؟
LCP، INP و CLS در چرخه Core Web Vitals هر سه Stable هستند. FID در مارس ۲۰۲۴ با INP جایگزین شد و دیگر Core Web Vital جاری نیست. Metricها میتوانند در آینده تغییر کنند؛ Dashboard و مستندات خود را Version کنید و وضعیت Stable/Pending/Experimental را از منبع رسمی کنترل کنید.
| Metric | چه چیزی را میسنجد؟ | خوب | نیازمند بهبود | ضعیف |
|---|---|---|---|---|
| LCP | زمان نمایش بزرگترین تصویر یا بلوک متن واجد شرایط در Viewport | ≤ ۲٫۵s | >۲٫۵ تا ۴s | >۴s |
| INP | Latency تعاملهای واجد شرایط در طول بازدید؛ معمولاً بدترین با مدیریت Outlier | ≤ ۲۰۰ms | >۲۰۰ تا ۵۰۰ms | >۵۰۰ms |
| CLS | مجموع Burstهای مهم جابهجایی غیرمنتظره Layout | ≤ ۰٫۱ | >۰٫۱ تا ۰٫۲۵ | >۰٫۲۵ |
آستانهها طبق روش رسمی تعریف آستانههای Core Web Vitals در صدک ۷۵ Page viewها ارزیابی میشوند. Threshold برای موبایل و دسکتاپ یکسان است، اما گزارش را به تفکیک Form factor بررسی کنید تا تجربه ضعیف یک گروه در میانگین پنهان نشود.
صدک ۷۵ یعنی چه؟
اگر ۱۰۰ تجربه را از سریعترین تا کندترین مرتب کنیم، مقدار حوالی تجربه ۷۵ام P75 است. برای «خوب» بودن یک Metric، دستکم ۷۵٪ تجربهها باید آستانه خوب را رعایت کنند. میانگین کافی نیست؛ ده تجربه بسیار کند میتواند برای گروه مهمی درد واقعی بسازد ولی در Average گم شود.
P75 را بر Page load و Metric محاسبه کنید، نه میانگین صدکهای روزانه. برای عیبیابی P90/P95 نیز مفید است، اما وضعیت رسمی Good/Needs improvement/Poor بر P75 است. Mobile و Desktop را جدا و Sample size را کنار عدد گزارش کنید.
Core Web Vitals همه تجربه کاربری نیست
CWV سه جنبه قابل اندازهگیری را پوشش میدهد؛ درباره مفیدبودن محتوا، دسترسپذیری کامل، جریان Checkout، Error message، حریم خصوصی یا رضایت کاربر حکم نهایی نمیدهد. صفحه میتواند LCP عالی و Copy گمراهکننده داشته باشد؛ یا CLS خوب اما فرم غیرقابل استفاده با Keyboard.
بهینهسازی باید در کنار Task success، Accessibility، Error rate و شاخص کسبوکار دیده شود. کاهش JavaScript اگر قابلیت ضروری را خراب کند، موفقیت نیست. Performance budget یک Guardrail محصول است، نه هدف مستقل.
رابطه CWV و رتبه گوگل؛ نه بیاثر، نه تضمین
طبق مستند رسمی Page experience گوگل، Core Web Vitals در سیستمهای رتبهبندی استفاده میشود، اما یک «سیگنال واحد Page experience» وجود ندارد و نمره خوب ابزار یا گزارش Search Console رتبه اول را تضمین نمیکند. گوگل همچنان محتوای مرتبطتر را حتی با تجربه ضعیفتر میتواند نمایش دهد.
بنابراین ROI را فقط با Position دنبال نکنید. Conversion، Bounce در Context، تکمیل Task، Revenue، Support complaint و مصرف منابع را قبل و بعد بسنجید. تلاش برای ۱۰۰ Lighthouse فقط به نیت SEO ممکن است بازده کمتری از رفع مشکل واقعی P75 داشته باشد.
Field، Lab و RUM را از هم جدا کنید
| منبع | چه میدهد؟ | مزیت | محدودیت |
|---|---|---|---|
| CrUX | تجربه کاربران واقعی Chrome واجد شرایط، تجمیعشده | Field عمومی و مبنای ابزارهای گوگل | Sample/Dimension محدود و Attribution کم |
| Search Console | گروه URLهای مشابه، Mobile/Desktop و روند | اولویتبندی SEO در سطح Template | عدد Debug تکURL و Real-time نیست |
| PageSpeed Insights | CrUX URL/Origin + یک اجرای Lighthouse | Field و Lab کنار هم | دو Dataset با Scope متفاوت |
| Lighthouse/DevTools | اجرای مصنوعی و Trace قابل تکرار | تشخیص Blocking، Request و Main thread | نماینده همه کاربران نیست؛ INP واقعی بدون Journey ندارد |
| RUM اختصاصی | Metric و Context کاربران خودتان | URL، Release، Region، Device و Target | نیازمند پیادهسازی، Privacy و کنترل Bias |
| Synthetic monitor | تست منظم از Location/Device ثابت | Regression سریع و Availability | توزیع کاربران واقعی را نشان نمیدهد |
CrUX در PageSpeed Insights پنجره لغزان ۲۸روزه را در صدک ۷۵ نمایش میدهد و روزانه بهروز میشود. Search Console داده را برای گروه URLهای دارای تجربه مشابه تجمیع میکند. تفاوت ابزارها لزوماً Bug نیست؛ Scope، Window، Form factor و Sample را مقایسه کنید. جزئیات در Workflow رسمی ابزارهای Web Vitals آمده است.
چرا Lighthouse سبز و CrUX قرمز است؟
- Lab یک دستگاه/شبکه/Location و اجرای کوتاه است؛ Field توزیع واقعی ۲۸روزه؛
- Lab معمولاً بارگذاری اولیه را میبیند، ولی CLS و INP میتوانند دیرتر رخ دهند؛
- کاربر لاگین، Cookie banner، تبلیغ، Personalization یا A/B variant متفاوت دارد؛
- Cache، CDN route، Service Worker و Third-party در زمانها تغییر میکنند؛
- PSI ممکن است Field داده URL یا در نبود Sample کافی Origin را نشان دهد؛
- Release جدید هنوز در Window ۲۸روزه با نسخه قدیم مخلوط است.
Lighthouse Performance score با «قبولی CWV» یکی نیست. آن Score وزندهی چند Lab metric است و برای Diagnostics مفید است؛ Field pass/fail را از LCP/INP/CLS واقعی بخوانید.
Workflow درست: Field → Hypothesis → Lab → Field
- Scope: Template، Device، کشور/شبکه، User state و Release را مشخص کنید.
- Field: CrUX/Search Console/RUM را بر P75 و Distribution بررسی کنید.
- Attribution: LCP element/resource، INP target/phases و CLS source را ثبت کنید.
- Reproduce: Journey و شرایط را در DevTools/WebPageTest یا Device واقعی بازسازی کنید.
- Hypothesis: یک علت و تغییر با Outcome عدددار بنویسید.
- Validate: Lab، Functional، Accessibility و Business guardrail را تست کنید.
- Rollout: Canary/A-B/Feature flag و Release annotation داشته باشید.
- Confirm: RUM سریع و CrUX پس از Window کافی را بررسی کنید.
از اجرای PSI روی Homepage و تعمیم به کل سایت پرهیز کنید. Product detail، Category، Article، Checkout، Search و Dashboard Runtime متفاوت دارند.
RUM حداقلی اما قابل اقدام
کتابخانه رسمی web-vitals میتواند LCP، INP و CLS و Attribution مرتبط را جمع کند. هر Event را با Metric ID، URL template، Navigation type، Device class، Release، Experiment، Connection/Region در حد مجاز و Target مناسب بفرستید. داده شخصی، متن فیلد، selector حاوی شناسه کاربر یا URL حساس را ثبت نکنید.
| Metric | Attribution مفید | سؤال |
|---|---|---|
| LCP | Element، Resource URL/type، TTFB و Subpartها | منبع دیر کشف شد یا دیر دانلود/رندر شد؟ |
| INP | Interaction target/type، Load state، Input/Processing/Presentation | تأخیر قبل، داخل Handler یا Render است؟ |
| CLS | Largest shift source، زمان و Session window | کدام عنصر حرکت کرد و عامل واردکننده فضا چه بود؟ |
راهنمای Debug عملکرد در Field از Attribution build برای اتصال Metric به عنصر و Interaction استفاده میکند. Sampling را مستند کنید، Bot/QA را جدا و ارسال را با sendBeacon یا مسیر مقاوم به خروج انجام دهید.
LCP را به چهار زیربخش بشکنید
برای LCP تصویری، زمان معمولاً از این اجزا میآید:
- TTFB: Redirect، اتصال و پاسخ HTML اولیه؛
- Resource load delay: فاصله TTFB تا شروع Request منبع LCP؛
- Resource load duration: زمان انتقال منبع؛
- Element render delay: فاصله پایان دانلود تا Paint عنصر.
اگر فقط تصویر را ۲۰٪ کوچک کنید اما Browser آن را پس از اجرای Bundle کشف کند، Load delay همچنان غالب میماند. اگر فایل سریع رسیده اما CSS/JS یا Font رندر را نگه داشته، Compression بیشتر مسئله را حل نمیکند.
TTFB را قبل از CDN تشخیص دهید
TTFB شامل Redirect و هزینه شبکه/Server است. Origin processing، Query، Cache miss، TLS/connection و مسیر CDN را جدا کنید. CDN میتواند Asset/HTML Cacheشونده را نزدیکتر یا اتصال را بهینه کند، اما Dynamic miss یا Origin کند را جادو نمیکند.
- Redirect chain و URL canonical مستقیم؛
- Full-page/edge cache با Cache key درست و Purge امن؛
- Query profiling، Index و حذف N+۱؛
- Connection reuse و فشردهسازی مناسب؛
- SSR/Streaming فقط با اندازهگیری و جلوگیری از Cache fragmentation؛
- پایش Hit ratio، Origin time و Region جدا.
HTTP/۳ در شبکههای خاص میتواند مزیت داشته باشد، اما نتیجه به مسیر و پیادهسازی بستگی دارد. راهنمای HTTP/۳ و QUIC روش ارزیابی و Rollback را پوشش میدهد.
منبع LCP باید زود قابل کشف باشد
برای Hero image، URL واقعی را در HTML اولیه با <img src/srcset/sizes> قرار دهید. پنهانکردن آن در data-src کتابخانه Lazy-load، CSS background یا Render پس از JavaScript، Preload scanner را عقب میاندازد. برای تصویر LCP loading="lazy" نگذارید.
fetchpriority="high" میتواند Priority را روشن کند؛ preload برای منبعی که Browser دیر کشف میکند مفید است. هر دو را کورکورانه روی چند تصویر اعمال نکنید؛ رقابت پهنای باند و Double fetch با srcset/type اشتباه ممکن است نتیجه را بدتر کند. راهنمای رسمی بهینهسازی LCP Discoverability و Subpartها را محور قرار میدهد.
تصویر LCP: اندازه، Format و Variant درست
- ابعاد Render واقعی و DPR را در
srcset/sizesپوشش دهید؛ - AVIF/WebP/JPEG XL یا JPEG را بر اساس Support، Encoder و کیفیت تست کنید؛
- Metadata غیرضروری را حذف، کیفیت را با نمونه بصری تأیید کنید؛
- از ارسال تصویر Desktop بزرگ به موبایل جلوگیری کنید؛
- URL Variant پایدار و Cacheable باشد؛
- Fallback و Content negotiation را از نظر Cache key تست کنید.
فرمت جدید ذاتاً کوچکتر یا سریعتر نیست؛ محتوا و Encoder مهماند. وضعیت پشتیبانی و Strategy فرمت را در راهنمای JPEG XL در وب مقایسه کنید.
Element render delay را کم کنید
اگر منبع LCP دانلود شده اما Paint دیر است، Render-blocking CSS، Font، Hydration، Client-side rendering یا پنهانبودن عنصر را بررسی کنید. Critical CSS باید کوچک و واقعی باشد؛ Inline کردن CSS بسیار زیاد HTML و Cache را بدتر میکند.
SSR یا Static HTML به Browser امکان کشف زودتر میدهد، ولی Hydration سنگین میتواند INP را خراب کند. Skeleton که محتوای اصلی را تا پایان JavaScript مخفی میکند شاید ظاهر Loading بدهد اما LCP را عقب میاندازد. Trade-off LCP/INP/CLS را همزمان ببینید.
فونت فارسی و LCP
اگر LCP یک بلوک متن است، Font loading روی Paint اثر دارد. Weight/Subset لازم را کم کنید، WOFF2 مناسب، Cache طولانی و Self-host قانونی/عملی را بررسی کنید. Preload فقط فونت واقعاً Above-the-fold با crossorigin درست؛ Preload همه Weightها Bandwidth را مصرف میکند.
font-display را با Brand و CLS تست کنید. Fallback metric متفاوت میتواند Shift بسازد؛ Size-adjust و Metric overrides در صورت پشتیبانی میتوانند Match را بهتر کنند. متن فارسی و اعداد را روی Android کمقدرت و شبکه ایران آزمایش کنید.
INP دقیقاً چه چیزی را اندازه میگیرد؟
INP پاسخگویی کلی صفحه را با مشاهده Latency تعاملهای Click، Tap و Keyboard در طول عمر بازدید میسنجد. مقدار نهایی معمولاً طولانیترین تعامل است، با سازوکاری برای کنارگذاشتن برخی Outlierها در صفحات با تعامل زیاد. Hover و Scroll مستقیم جزو Interactionهای INP نیستند، گرچه Handlerهای سنگین آنها میتوانند Main thread را اشغال و تعامل بعدی را کند کنند.
FID فقط Input delay اولین تعامل را میدید؛ INP سه فاز و تعاملهای طول Session را میبیند. عبارت «بدترین Delay» بدون این ظرافت کامل نیست.
سه فاز INP را جدا کنید
| فاز | تعریف | علتهای رایج | راه بررسی |
|---|---|---|---|
| Input delay | از ورودی تا شروع Callback | Long task قبلی، Script startup، Third-party | Main thread و LoAF پیش از Event |
| Processing duration | اجرای Callbackهای Interaction | Loop، Validation، State update، Sync work | Event callback و Call tree |
| Presentation delay | پایان Callback تا Paint بعدی | DOM بزرگ، Style/Layout، Render زیاد | Rendering track و DOM mutation |
راهنمای رسمی INP توصیه میکند از Field interaction مشکلدار به Lab بروید و هر سه فاز را جدا بهینه کنید. یک نسخه عمومی «JavaScript را defer کنید» برای همه علتها کافی نیست.
Input delay و Long task
فایل JavaScript بعد از Download باید Parse/Compile/Execute شود. Third-party timer یا Hydration هنگام Tap کاربر میتواند Input را در Queue نگه دارد. Coverage و Performance trace را برای Scriptهای First/Third-party بگیرید و Owner/ارزش هر Tag را ثبت کنید.
- کد و Polyfill غیرضروری را حذف؛ Bundle را بر Route و Feature تقسیم کنید؛
- Third-party را پس از Consent/Interaction یا در Worker فقط در صورت سازگاری؛
- Task طولانی را به کارهای کوتاهتر تقسیم و به Main thread Yield کنید؛
- Background CPU را با Idle/priority مناسب زمانبندی کنید؛
- CPU work مناسب را به Web Worker ببرید؛ DOM در Worker در دسترس نیست؛
- در Startup با Lazy code chunk رقابت پهنای باند تازه نسازید.
Handler را کوتاه و پاسخ بصری را زود کنید
در Event handler حداقل State لازم را بهروزرسانی و کار غیرحیاتی را بعداً انجام دهید. Validation سنگین کل فرم را روی هر Key stroke اجرا نکنید؛ Scope، Debounce و Incremental computation را بررسی کنید. Callback زنجیرهای و Layout read/write متناوب Forced reflow میسازد.
Feedback اولیه مانند حالت Loading باید در Frame بعد قابل Paint باشد؛ اگر همان Task بلافاصله کار سنگین را ادامه دهد، Spinner هم دیده نمیشود. Yield APIها را با Feature detection و Browser support بهکار ببرید و نتیجه Field را بسنجید.
Presentation delay و هزینه DOM
DOM بسیار بزرگ، Style پیچیده و Render هزار Node پس از Interaction میتواند Presentation را طولانی کند. Virtualization برای List بلند، Batch DOM updates و content-visibility برای محتوای Offscreen ممکن است کمک کند؛ Accessibility، Find-in-page و Scroll anchoring را تست کنید.
Framework memoization را کورکورانه اضافه نکنید؛ خود Memo و Dependency هزینه دارد. Profiler نشان دهد کدام Component بیدلیل Render میشود. در SPA، Route change و Modal/Filterهای واقعی را در RUM Target کنید.
Third-party budget برای INP
| اسکریپت | Owner | ارزش | هزینه | تصمیم |
|---|---|---|---|---|
| Analytics اصلی | Data | Measurement ضروری | KB/CPU/Request | Keep با Event محدود |
| Chat | Support | Lead/حل مسئله | Startup/DOM/Network | Load on intent |
| A/B tool | Growth | Experiment | Flicker/Blocking | Server/Edge یا Scope |
| Heatmap | UX | Research موقت | Event/CPU/Data | Sample/Time-box |
Tag manager ابزار Governance نیست. Approval، Expiry، Performance owner و Kill switch برای هر Vendor داشته باشید. Script کوچک هم اگر در زمان بد اجرا شود INP را خراب میکند.
CLS فقط هنگام Load رخ نمیدهد
CrUX CLS کل چرخه عمر صفحه را میبیند؛ Banner دیرهنگام، Infinite scroll، Font، SPA route، تبلیغ و بازگشت از Background میتوانند بعد از پایان Lighthouse Shift بسازند. به همین دلیل Lab سبز و Field قرمز برای CLS رایج است.
CLS مقدار بدون واحد است. Layout shift نزدیک تعامل کاربر ممکن است طبق تعریف Metric مستثنا شود، اما اگر تجربه بد است صرفاً به Exclusion تکیه نکنید. هدف، جلوگیری از حرکت غیرمنتظره و کلیک اشتباه است.
فضا را پیش از رسیدن محتوا رزرو کنید
- برای Image/Video از
width/heightیاaspect-ratioدرست استفاده کنید؛ - Ad/Embed/Iframe حداقل ارتفاع و حالت Empty داشته باشد؛
- Skeleton با اندازه محتوای نهایی نزدیک باشد؛
- Cookie/Promo bar را Overlay کنترلشده یا فضای از ابتدا رزروشده بسازید؛
- خطا/Validation فرم را در جای پیشبینیشده نشان دهید؛
- محتوا را بالای Viewport بدون اقدام کاربر Insert نکنید.
در Responsive layout، Ratio و Breakpoint واقعی را تست کنید. Dimension HTML فقط وقتی Aspect ratio فایل و CSS متناقض نباشد کمک میکند.
Animation و Font بدون Shift
برای حرکت بصری از transform و opacity استفاده کنید تا Layout بازچینی نشود؛ اما Animation سنگین میتواند GPU/CPU و Accessibility را آسیب بزند. prefers-reduced-motion را رعایت کنید.
Font swap ممکن است اندازه متن را تغییر دهد. Fallback نزدیک، Metric override، Subset و Preload محدود را در Field تست کنید. راهنمای رسمی CLS تصاویر بیابعاد، Ads/Embed، محتوای تزریقشده و Web font را از علتهای رایج میداند.
SPA، PWA و Navigationهای نرم
در SPA، Page load اولیه همه تجربه را نمایندگی نمیکند. Route change میتواند محتوای جدید، INP و Shift بسازد. RUM را Route-aware کنید، Navigation type و URL template را ثبت و Lifecycle Metric را درست Flush کنید. APIهای Soft navigation را فقط با توجه به وضعیت پشتیبانی جاری و بدون اتکا به یک Browser بهکار ببرید.
Service Worker میتواند Cache hit را بهتر یا Asset قدیمی و Update race ایجاد کند. Cache policy، Version، Rollback و Offline journey را همراه سئوی PWA در راهنمای PWA بررسی کنید.
WordPress و WooCommerce؛ از Plugin list به Request/CPU بروید
تعداد Plugin بهتنهایی علت نیست؛ یک Plugin کوچک میتواند Query/Script بد داشته باشد و چند Plugin سبک بیاثر باشند. برای هر Template Network، Query، Hook، JS execution و DOM را Profile کنید. Builder، Slider، Consent، Chat، Analytics و WooCommerce fragmentها را در Journey واقعی بسنجید.
| علامت | مظنون | آزمایش |
|---|---|---|
| TTFB بالا فقط Miss | Page cache/Query/PHP | Hit vs miss و Query monitor در Staging |
| LCP image دیر | Lazy loader/Builder/CSS background | HTML discovery و Priority waterfall |
| INP روی Menu/Filter | Theme bundle/DOM/Plugin listener | Interaction trace و Coverage |
| CLS Header/Product | Font، gallery، variation، banner | Layout shift track و RUM source |
| کاربر Login کند | Cache bypass/Personalization | RUM user-state بدون PII |
قالب Block یا Gutenberg خودکار سریعتر نیست؛ خروجی HTML/CSS/JS و Runtime مهم است. برای انتخاب و مهاجرت امن از راهنمای Gutenberg و FSE استفاده کنید.
Cache و CDN میتوانند کمک یا آسیب بزنند
Cache hit، TTFB و LCP را بهتر میکند؛ Cache key اشتباه، HTML شخصی، Variant دستگاه، Cookie و Purge ناقص میتواند Corruption یا Fragmentation بسازد. Image optimization CDN اگر Dimension/URL را ناسازگار کند CLS یا Double download ایجاد میکند.
Cache را بر نوع داده و Privacy طراحی کنید. Hit ratio، stale age، origin shield و Revalidation را ثبت کنید. مسیر CDN ایران را با RUM کاربران، نه نزدیکترین PoP ادعایی، بسنجید.
Performance برای کاربران ایران
CrUX Dimension کشور در PSI و Search Console در دسترس نیست؛ ممکن است عدد جهانی تجربه ایران را پنهان کند. RUM با Region تقریبیِ حداقلی و مطابق سیاست Privacy، اپراتور/connection proxy و Device class میتواند تفاوت را نشان دهد. IP خام را بیدلیل نگه ندارید.
- شبکه ثابت و موبایل، Android کمقدرت و حالت Data saver را تست کنید؛
- دسترسی Font، CDN، Tag و API خارجی را از داخل ایران بسنجید؛
- Timeout و Failure third-party را در Performance journey وارد کنید؛
- اندازه JS/Image و Request count را برای Data cost محدود کنید؛
- مسیر داخلی/خارجی و Cache hit را جدا گزارش کنید؛
- فونت و Asset حیاتی را با حقوق مناسب و Exit plan میزبانی کنید.
امنیت و CWV؛ ارتباط عملیاتی، نه فاکتور مستقیم
DDoS، Cryptominer، تزریق Script یا Bot load میتواند Server/Main thread را کند و CWV را بدتر کند؛ اما CWV معیار امنیت نیست و «امنیت ضعیف مستقیماً از مسیر CWV رتبه را کاهش میدهد» حکم دقیقی نیست. HTTPS و امنیت بخشی از تجربه و اعتمادند؛ Incident performance را با Metric و Timeline اثبات کنید.
WAF/Challenge هم میتواند JS، Redirect و Delay اضافه کند. Rule را با Bot/Abuse outcome و CWV/Conversion Guardrail Rollout کنید. امنیت را برای حفاظت کاربر انجام دهید، نه فقط برای Score.
Performance budget بر Template و Journey
| Budget | نمونه Gate | منبع تأیید |
|---|---|---|
| Field SLO | P75 LCP/INP/CLS برای کاربران هدف | RUM و CrUX |
| JS | Transfer/Execution بر Route | Build stats و Trace |
| Image | Hero و Total image bytes بر Viewport | CI image check |
| Third-party | CPU/Request و Expiry | Lab + RUM attribution |
| Backend | P75/P95 TTFB hit/miss | APM/RUM |
| Business guardrail | Conversion، Error و Task success | Analytics/Product data |
Lab gate باید Stable و Repeatable باشد: چند Run، Median، Device/Network profile و Tolerance. یک نوسان کوچک Build را بیدلیل Block نکند؛ Regression بزرگ نیز در Average پنهان نشود.
CI، Staging و Production هرکدام نقش دارند
- CI: Bundle diff، Asset dimension، Lazy LCP، HTML/Accessibility و Budget؛
- Preview/Staging: Synthetic Journey، Trace، Cache-disabled/enabled و Device matrix؛
- Canary: Release cohort با RUM، Error و Conversion؛
- Production: P75/P90، SLO، Template و Field attribution؛
- CrUX/Search Console: روند بیرونی پس از Window کافی.
Staging معمولاً CDN، Cache، داده و Third-party متفاوت دارد. «در Staging سریع بود» شاهد کافی Production نیست.
اولویتبندی بر اساس Reach × Pain × Confidence ÷ Effort
Fix صفحهای با ۵۰٪ ترافیک و LCP ضعیف معمولاً از اصلاح ۵۰ms روی صفحه کمدیدار ارزشمندتر است. امتیاز ساده:
Priority = Reach × Severity × Business value × Confidence ÷ Effort
Reach را با Page view/Template، Severity را با Distance تا Threshold و Tail، Business value را با Journey و Confidence را با Attribution بسنجید. Accessibility یا Checkout blocker را صرفاً به دلیل Reach پایین عقب نیندازید؛ Criticality Gate جدا داشته باشید.
برنامه ۳۰/۶۰/۹۰ روزه
| بازه | کار | خروجی |
|---|---|---|
| روز ۱–۳۰ | Inventory Template، CrUX/GSC، RUM پایه و Quick win ایمن | Baseline، Dashboard و Backlog اولویتدار |
| روز ۳۱–۶۰ | LCP subpart، INP journey، CLS source و Third-party governance | سه Fix با Canary و Before/After |
| روز ۶۱–۹۰ | Budget/CI، SLO، Runbook Regression و آموزش تیم | Gate پایدار و Roadmap فصلی |
نتیجه را با Release annotation و Cohort مقایسه کنید. CrUX برای دیدن اثر کامل زمان میخواهد؛ RUM میتواند زودتر جهت را نشان دهد. بهبود یک Metric را بدون Error/Conversion/Accessibility Guardrail منتشر نکنید.
اشتباههای رایج Core Web Vitals
- معرفی FID بهعنوان Core Web Vital جاری یا INP بهعنوان آینده؛
- یکیدانستن Lighthouse score، PSI Field و Search Console؛
- بهینهسازی فقط Homepage و یک Device؛
- تضمین رتبه با CWV یا دنبالکردن Score ۱۰۰؛
- Lazy-load عنصر LCP و Preload همه منابع؛
- فرض اینکه WebP/AVIF/CDN همیشه سریعتر است؛
- تقسیم JS بدون توجه به Interaction-time loading؛
- Fix کردن Handler وقتی Presentation delay علت INP است؛
- سنجش CLS فقط هنگام Load و نادیدهگرفتن Long-lived page؛
- حذف قابلیت یا Accessibility برای چند امتیاز Lab؛
- اعلام اثر مستقیم امنیت بر رتبه از مسیر CWV بدون داده؛
- انتظار تغییر فوری CrUX پس از Release.
چکلیست نهایی ممیزی
- LCP/INP/CLS و Thresholdهای جاری با تاریخ ثبت شدهاند.
- P75، Distribution، Sample و Mobile/Desktop جدا گزارش میشوند.
- Field، Lab، RUM و Synthetic با Label و Scope جدا هستند.
- URL/Origin fallback و Search Console URL group بررسی شده است.
- برای LCP چهار Subpart و عنصر/منبع مشخص است.
- برای INP Target و Input/Processing/Presentation جدا شدهاند.
- برای CLS رخدادهای پس از Load و Source اصلی دیده میشوند.
- WordPress/SPA/Third-party/Consent و User state در Matrix هستند.
- شبکه، Device و دسترسی کاربران ایران با RUM/Device واقعی آزموده شده است.
- Fix در Lab و Canary با Business/Accessibility guardrail تأیید شده است.
- Budget، CI gate، Owner، SLO و Regression runbook وجود دارد.
- نتیجه پس از Window کافی در RUM و CrUX بازبینی میشود.
جمعبندی؛ Metric را به علت و تجربه وصل کنید
Core Web Vitals زمانی مفید است که از Report به Debug loop تبدیل شود. CrUX و Search Console میگویند کدام گروه کاربر مشکل دارد؛ RUM Target و شرایط را نشان میدهد؛ Lab Trace علت را بازتولید میکند؛ و Canary نشان میدهد Fix واقعاً برای کاربر و کسبوکار بهتر بوده است.
از LCP/INP/CLS جاری و P75 شروع کنید، نه Score یا توصیه عمومی. بودجه عملکرد را در Delivery وارد کنید تا Regression از تولید خارج نشود. اگر برای پیادهسازی RUM، تحلیل Trace، WordPress performance یا برنامه ۹۰روزه نیاز به کمک دارید، درخواست مشاوره عملکرد Mindio را ثبت کنید.
سؤالات متداول Core Web Vitals
Core Web Vitals فعلی کداماند؟
LCP، INP و CLS سه Metric پایدار جاریاند. FID در مارس ۲۰۲۴ با INP جایگزین شد. هدف Good در صدک ۷۵: LCP حداکثر ۲٫۵ ثانیه، INP حداکثر ۲۰۰ میلیثانیه و CLS حداکثر ۰٫۱؛ Mobile و Desktop را جدا بررسی کنید.
چرا Lighthouse خوب است اما Search Console خطا نشان میدهد؟
Lighthouse یک تست Lab در شرایط مشخص است؛ Search Console داده واقعی CrUX را در پنجره ۲۸روزه و برای گروه URLهای مشابه نشان میدهد. کاربر، دستگاه، شبکه، Cookie، Session طولانی و نسخه قدیم/جدید متفاوتاند. از Field برای Scope و Lab برای تشخیص علت استفاده کنید.
آیا Core Web Vitals خوب رتبه گوگل را تضمین میکند؟
خیر. گوگل میگوید CWV در سیستمهای رتبهبندی استفاده میشود، اما نمره خوب ابزار رتبه برتر را تضمین نمیکند و محتوای مرتبط همچنان مهم است. CWV را برای تجربه و Outcome واقعی بهبود دهید و اثر SEO را در کنار عوامل دیگر تحلیل کنید.
برای بهبود INP فقط JavaScript را کم کنیم؟
کاهش JS غیرضروری اغلب کمک میکند، اما ابتدا Input delay، Processing duration و Presentation delay را جدا کنید. علت میتواند Script startup، Handler، DOM بزرگ، Style/Layout، Iframe یا Third-party باشد. RUM attribution و Interaction trace راهحل مناسب را مشخص میکند.
چه مدت بعد از اصلاح، نتیجه در CrUX دیده میشود؟
CrUX پنجره لغزان ۲۸روزه دارد و داده جدید با تجربههای قبلی مخلوط میشود؛ بنابراین تغییر کامل فوری نیست. RUM و Synthetic را برای جهت سریع، Release cohort و Canary بهکار ببرید و CrUX/Search Console را پس از جمعشدن Sample کافی تأیید کنید.
