Core Web Vitals و Critical Rendering Path

۱. صفحه اول: یک اجرای سریع، توزیع کاربران واقعی نیست

یک صفحه محتوایی روی لپ‌تاپ توسعه‌دهنده سریع باز می‌شود. Hero تقریباً بدون مکث دیده می‌شود، دکمه جستجو جواب می‌دهد و در تست کوتاه چیزی هم جابه‌جا نمی‌شود. وسوسه‌کننده است که نتیجه بگیریم «Performance حل شده است». این نتیجه از شواهد بزرگ‌تر است. اجرای محلی برای پیدا کردن علت‌ها بسیار مفید است، اما Core Web Vitals درباره تجربه کاربر در مقیاس واقعی صحبت می‌کند. مجموعه فعلی شامل Largest Contentful Paint (LCP) برای Loading، Interaction to Next Paint (INP) برای Responsiveness و Cumulative Layout Shift (CLS) برای Visual Stability است. راهنمای فعلی، مقدار خوب را برای LCP برابر یا کمتر از ۲٫۵ ثانیه، برای INP برابر یا کمتر از ۲۰۰ میلی‌ثانیه و برای CLS برابر یا کمتر از ۰٫۱ می‌داند؛ ارزیابی روی percentile 75 و به‌صورت جداگانه برای Mobile و Desktop انجام می‌شود. [S-WEBDEV-VITALS]

مسئله مهندسی این درس عمداً محدود است. یک fixture قطعی دارید که سه خرابی مستقل ایجاد می‌کند: تأخیر در مسیر Hero، یک Interaction با long task، و تصویری که فضای آن از قبل رزرو نشده است. باید هر symptom را به یک علت محتمل در Rendering، Interaction یا Layout وصل کنید، همان علت را با کمترین تغییر تعمیر کنید و هیچ‌وقت فرض نکنید چون یک Metric بهتر شد دو Metric دیگر هم بهتر شده‌اند.

خروجی اصلی شما Core Web Vitals Diagnosis & Rendering-Path Record v1 است. در این سند Observation و Inference باید جدا باشند. سبز شدن lab فقط نشان می‌دهد fixture و استدلال شما با contract همین درس سازگارند؛ نه این‌که صفحه Production در CrUX حتماً Pass است و نه این‌که یک Trace مصنوعی نماینده percentile 75 کاربران واقعی است.

۲. مسیر یادگیری: توضیح را کم کن، سطح شواهد را نه

مسیر Foundation: با Matrix آماده شروع کنید و هر Metric را جدا بررسی کنید. در هر ردیف بنویسید symptom مشاهده‌شده چیست، کدام بخش Trace تغییر کرده، Cause Hypothesis چیست، کوچک‌ترین Repair کدام است و بعد از Repair چه Evidence دیگری هنوز لازم دارید. Thresholdهای جاری باید جلوی چشم باشند تا حس شخصی جای Measurement را نگیرد.

مسیر Repair: اگر اسم Metricها را می‌دانید، از یک Mutation خراب شروع کنید. قبل از اجرا پیش‌بینی کنید اولین Evidence Row که باید Fail شود کدام است. سپس Audit را اجرا کنید، تغییر Trace را توضیح دهید، فقط همان boundary را تعمیر کنید و دوباره اندازه‌گیری کنید. پیش از جدا کردن علت، «کل صفحه را Optimize» نکنید.

مسیر Experienced: تعریف‌های مقدماتی را رد کنید و fixture را مثل یک Performance Change Request بررسی کنید. ببینید آیا Diagnosis بین Metric Symptom و Cause تمایز می‌گذارد، آیا Repair واقعاً با Trace پشتیبانی می‌شود و آیا نتیجه از مرز Lab/Field خارج نشده است. بعد Transfer را بدون کپی‌کردن راه‌حل مثال اول انجام دهید.

در هر سه مسیر پنج بُعد ثابت‌اند: current_metrics، thresholds، lab_field_boundary، critical_path و measure_before_claim. تجربه بیشتر زمان توضیح را کم می‌کند، نه نیاز به Mutation، Transfer و Residual Limitation را.

۳. مدل ذهنی: Metric علامت است، نه علت ریشه‌ای

این زنجیره را مبنا بگیرید:

navigation → document response → render-critical resources → content paint → interaction task → next paint / layout stability → lab evidence ↔ field evidence boundary

LCP زمان Render شدن بزرگ‌ترین عنصر واجدشرایط داخل Viewport را نسبت به Navigation گزارش می‌کند. خود LCP به شما نمی‌گوید چرا این Render دیر اتفاق افتاده است. علت می‌تواند تأخیر Server/Document، کشف دیرهنگام Resource، انتقال کند Resource، کار Render-blocking یا Element Render Delay باشد. fixture این درس چند مرحله را جدا می‌کند تا به‌جای جمله کلی «LCP کند است چون عکس بزرگ است» بتوانید مسیر تأخیر را ببینید. [S-WEBDEV-LCP]

INP Metric مربوط به Responsiveness است. Latency تعامل‌های Click، Tap و Keyboard را در طول عمر صفحه می‌بیند و یک مقدار نماینده بخش کند تجربه تعامل ارائه می‌کند؛ در صفحات با Interaction زیاد نیز منطق حذف Outlier دارد. یک long task روی Main Thread می‌تواند Processing یا Next Paint را عقب بیندازد، اما Diagnosis درست باید از Evidence Interaction بیاید، نه صرفاً از دیدن JavaScript و حدس زدن علت. [S-WEBDEV-INP]

CLS Visual Instability را اندازه می‌گیرد. نداشتن width/height برای Image یا فضای رزرو برای Embed علت رایجی است چون Layout ابتدا بدون فضا ساخته می‌شود و با رسیدن Resource محتوای قابل‌دیدن جابه‌جا می‌شود. با این حال هر تغییر ظاهری دقیقاً یکسان حساب نمی‌شود و یک Trace کوتاه زمان Load ممکن است Shiftهای دیرتر یک Session طولانی را نبیند. [S-WEBDEV-CLS]

پس Metric سطح Observation است و Rendering Path محل بررسی Cause. Evidence Record این دو لایه را از هم جدا نگه می‌دارد.

۴. پایه فنی: Metricهای جاری، Threshold و معنی percentile

Core Web Vitals جاری عبارت‌اند از LCP، INP و CLS. FID دیگر Responsiveness Core Web Vital جاری نیست. چون خود مجموعه Metricها می‌تواند در آینده تغییر کند، این گزاره Freshness-bound است و نباید آن را حقیقت ابدی فرض کرد. [S-WEBDEV-VITALS]

Threshold فعلی برای وضعیت Good چنین است:

این مرزها در 75th Percentile Page Loadها و با تفکیک Mobile/Desktop ارزیابی می‌شوند. همین موضوع شکل Claim را عوض می‌کند. اگر یک اجرای محلی LCP model = 1.4s نشان دهد، فقط درباره همان run یا state آزمایش Evidence دارید؛ نه این‌که ۷۵ درصد Visitهای Production زیر ۲٫۵ ثانیه هستند. [S-WEBDEV-VITALS]

به همین دلیل fixture دو نوع Evidence دارد. deterministic_fixture_trace از ورودی‌های کنترل‌شده ساخته می‌شود تا اثر Mutation تکرارپذیر باشد. supplied_field_sample یک نمونه ثابت از Distribution ازپیش‌جمع‌آوری‌شده برای تمرین مقایسه است. هیچ‌کدام به‌دروغ «CrUX زنده» نامیده نمی‌شوند و Audit هر رکوردی را که lab_equals_field=true بگذارد رد می‌کند.

Lab برای Diagnosis، Reproduction و جلوگیری از Regression عالی است. Field Data نشان می‌دهد کاربران واقعی روی دستگاه‌ها، شبکه‌ها و وضعیت‌های مختلف چه Distributionی داشته‌اند. این دو مکمل هم‌اند، اما قابل‌جایگزینی نیستند.

۵. توضیح عمیق: برای هر Metric یک Evidence Path بساز

LCP: Late Paint را تجزیه کن

وقتی LCP دیر است، ابتدا LCP Candidate را مشخص کنید و بعد مسیر لازم برای Render شدن آن را دنبال کنید. در fixture، ردیف Hero شامل Document Response، Resource Discovery Delay، Resource Duration و Element Render Delay است. LCP Model از همین stageهای کنترل‌شده ساخته می‌شود. اگر Mutation مربوط به Hero مقدار Discovery Delay را ۱۴۰۰ ms زیاد کند، Evidence باید نشان دهد دقیقاً همین stage بزرگ شده است. Repair درست باید Discovery یا dependency بحرانی را هدف بگیرد. کوچک‌کردن Image وقتی Bottleneck واقعی Discovery است، پاسخ Evidence-based نیست.

راهنمای LCP نیز توضیح می‌دهد چرا Field LCP می‌تواند با Lab محدود فرق داشته باشد: Setup اتصال، Redirect، Time to First Byte و بخش‌های دیگر مسیر واقعی کاربر در نتیجه Field اثر دارند. [S-WEBDEV-LCP] بنابراین جمله «Decode عکس ۳۰۰ ms شد، پس LCP حل شد» تا زمانی که کل مسیر دیده نشده باشد ناقص است.

INP: Interaction را تا Next Paint دنبال کن

fixture، Interaction Latency را به Input Delay، Processing Duration و Presentation Delay تقسیم می‌کند. Mutation مربوط به long task، Processing را بالا می‌برد و INP Model از ۲۰۰ ms عبور می‌کند. Diagnosis نباید «JavaScript بد است» باشد. Diagnosis درست می‌گوید «در این Interaction و این fixture، long task مشاهده‌شده Processing Segment را طولانی کرده است». بعد Repair می‌تواند Blocking Work را Split/Reduce کند و Trace دوباره اجرا شود.

INP برای Responsiveness در طول lifecycle صفحه طراحی شده، نه فقط اولین Input. [S-WEBDEV-INP] بنابراین جایگزین‌کردن FID در plan یک Contract Failure است.

CLS: قبل از رسیدن Resource، Geometry را رزرو کن

fixture تصویری دارد که width/height مشخص دارد. با حذف این ابعاد، مدل قطعی Layout Shift از ۰٫۱ عبور می‌کند. Repair یعنی Geometry قبل از رسیدن Image رزرو شود. این درس ادعا نمی‌کند همه مشکلات CLS از Image هستند؛ Ads، Embed، محتوای Inject شده، Font و تغییرات دیرهنگام دیگر هم می‌توانند Visual Stability را خراب کنند. [S-WEBDEV-CLS]

در هر سه Metric روش یکسان است: Symptom را ببین، Trace را بررسی کن، کوچک‌ترین Cause Hypothesis را بساز، Mechanism را تغییر بده، دوباره Measure کن و آنچه هنوز ندیده‌ای صریح بنویس.

۶. مثال کامل: سه خرابی را بدون ادغام علت‌ها تشخیص بده

Baseline fixture عمداً در هر سه مدل داخل مرز Good است:

{
  "lcp_model_ms": 1430,
  "inp_model_ms": 120,
  "cls_model_score": 0.04,
  "measurement_kind": "deterministic_fixture_trace"
}

این Baseline به معنی Field Pass نیست؛ فقط نقطه شروع پایدار است.

Hero-delay mutation. Resource Discovery Delay زیاد می‌شود، LCP Model از ۲٫۵ ثانیه عبور می‌کند و INP/CLS ثابت می‌مانند. بنویسید چه stageای تغییر کرده، علت inferred در همین fixture چیست، Repair چگونه Discovery را زودتر می‌کند و چه چیزی هنوز مشاهده نشده است: Production p75 LCP.

Long-task mutation. Processing کنترل‌شده ۲۶۰ ms می‌شود و Interaction Model از Good Threshold یعنی ۲۰۰ ms عبور می‌کند. LCP و CLS سر جای Baseline می‌مانند. نام Interaction و segment تغییرکرده را ثبت کنید و نگویید «کل صفحه کند است».

Missing-dimensions mutation. Slot تصویر دیگر Geometry رزرو نمی‌کند و Shift Model از ۰٫۱ عبور می‌کند. این اتفاق به‌تنهایی ثابت نمی‌کند LCP یا INP هم بد شده‌اند. ابعاد را برگردانید و دوباره Audit کنید.

در پایان Baseline Lab را با supplied field sample مقایسه کنید. نمونه Field دارای p75_lcp_ms=3100، p75_inp_ms=240 و p75_cls=0.07 است. نتیجه درست این نیست که «Lab اشتباه بود». نتیجه درست این است که یک reproduction کنترل‌شده و یک field distribution دو سؤال متفاوت را جواب می‌دهند. حالا باید دنبال Contextهای Production بگردید که در fixture محلی حضور ندارند.

۷. Failure Modeها: Shortcutهایی که Audit باید رد کند

Failure A — FID به‌عنوان Metric جاری. Plan مجموعه LCP/FID/CLS را تعریف می‌کند. Audit باید رد کند، چون Responsiveness Core Web Vital فعلی INP است. [S-WEBDEV-VITALS]

Failure B — Threshold دستکاری‌شده. Dashboard محلی INP=240ms را Good نشان می‌دهد چون Threshold را بدون توضیح 250ms گذاشته است. Team می‌تواند Budget داخلی جدا داشته باشد، اما حق ندارد آن را به‌عنوان Threshold رسمی جاری جا بزند.

Failure C — Lab مساوی Field. رکورد می‌گوید «Local/Lighthouse پاس شد، پس Core Web Vitals کاربران واقعی Pass است». این Inference مردود است. Lab برای علت‌یابی و Regression مفید است؛ Field Claim به Field Evidence نیاز دارد.

Failure D — یک Fix برای همه Metricها. Hero فشرده شده و بدون اجرای دوباره Interaction/Layout اعلام می‌شود LCP/INP/CLS همگی Repair شده‌اند. برای Metricهایی که دوباره Measure نشده‌اند Evidence ندارید.

Failure E — تضمین با Architecture Label. صفحه static-first است، پس حتماً سریع است. Audit باید این Claim را رد کند. Architecture می‌تواند بعضی شرایط Delivery را تغییر دهد، ولی به‌تنهایی outcomeهای LCP/INP/CLS را ثابت نمی‌کند.

Mutation وقتی ارزش دارد که بتواند Conclusion را عوض کند. اگر validator بعد از جایگزینی INP با FID یا بعد از lab_equals_field=true همچنان سبز بماند، خود validator ضعیف است.

۸. پل Experienced: Performance Review به‌عنوان Causal Change Control

در محصول واقعی، Regressionهای Performance اغلب بین چند Team پخش‌اند. Design ممکن است LCP Candidate را عوض کند. CMS می‌تواند Discovery یک Resource را عقب بیندازد. Third-party widget می‌تواند long task وارد کند. Font Policy ممکن است روی Text Rendering یا Layout اثر بگذارد. Personalization نیز می‌تواند محتوای دیرهنگام Inject کند. بنابراین واحد Review مفید «Lighthouse Score» نیست؛ یک Causal Performance Diff است.

برای هر Release، Route تحت‌تأثیر، Candidate Element، Environment Trace، Metric Symptom، Resource/Task تغییرکرده و Field Signal موردنیاز بعد از Deploy را ثبت کنید. Artifact این درس نسخه کوچک همین Change Record است و Implementation، Mutation، Repair و Residual Uncertainty را کنار هم نگه می‌دارد.

یک نکته فعلی درباره SPA باید Freshness-bound بماند. بر اساس Update آگوست ۲۰۲۶ web.dev، Chrome 151 APIهایی برای Measurement Core Web Vitals روی Soft Navigationهای SPA معرفی کرده است. در همان وضعیت انتشار، این APIها تازه وارد Libraryها و Toolها می‌شدند؛ زمان‌بندی ادغام در CrUX اعلام نشده بود و Browser Engineهای دیگر نیز پشتیبانی نداشتند. [S-WEBDEV-SPA-2026] این وضعیت Chrome-specific را به Claim عمومی Cross-browser تبدیل نکنید.

۹. Alternative و Trade-off: Bottleneck مشاهده‌شده را Optimize کن

Preload/Priority برای Hero زمانی مفید است که Evidence نشان دهد Discovery یا Priority Bottleneck است. اگر Resource واقعاً Critical نباشد، همین کار می‌تواند Bandwidth را هدر دهد. Inline Critical CSS ممکن است یک Request را حذف کند ولی Document را بزرگ‌تر و Cache Reuse را کمتر کند. Split کردن long task می‌تواند Responsiveness را بهتر کند اما Scheduling ضعیف ممکن است Complexity یا Work دیگری را به پنجره مهم کاربر منتقل کند. رزرو Geometry برای Stability خوب است، ولی ابعاد رزروشده باید با Responsive Design واقعی هم‌خوان باشد.

قانون تصمیم این نیست که «سریع‌ترین Technique را انتخاب کن». قانون این است: «کوچک‌ترین Mechanismی را انتخاب کن که Bottleneck مشاهده‌شده را رفع کند و Contract صفحه را حفظ کند.» بعد دوباره Measure کن.

Metricها را هم جداگانه و کورکورانه Optimize نکنید. Repair مربوط به LCP ممکن است Work بیشتری روی Main Thread ایجاد کند؛ Interaction Optimization می‌تواند Work را عقب بیندازد و بعداً Layout را تحت‌تأثیر قرار دهد. درس فرض نمی‌کند این Trade-off همیشه رخ می‌دهد؛ فقط اجازه نمی‌دهد بدون Evidence نتیجه بگیرید رخ نداده است.

Toolها نیز Evidence متفاوت می‌دهند. Lighthouse، DevTools، web-vitals، RUM و CrUX یک سؤال واحد را با یک نوع داده جواب نمی‌دهند. Tool درست، Toolی است که Claim موردنظر شما را پشتیبانی کند. Diagnostic Lab Trace و p75 Field Distribution مکمل هم‌اند، نه Substitute.

۱۰. تمرین هدایت‌شده و مستقل

داخل learner fixture دستور node --test test/public-contract.test.mjs را اجرا کنید. سپس node src/audit-vitals.mjs را اجرا کنید تا Audit Output قطعی دوباره ساخته شود.

ترتیب کار:

1. performance-plan.json را بخوانید و Metric Set و Thresholdهای جاری را تأیید کنید.
2. traces/baseline.json را بررسی کنید و همه Valueها را Observed Fixture Evidence بنامید، نه Production Field Evidence.
3. Hero-delay trace را بخوانید و قبل از دیدن Diagnosis پیش‌بینی کنید کدام stage باید LCP را خراب کرده باشد.
4. Long-task trace را بررسی کنید و مشخص کنید Input Delay، Processing یا Presentation کدام تغییر کرده است.
5. No-dimensions trace را با Geometry حذف‌شده و Shift Evidence وصل کنید.
6. Baseline را با field-sample.json مقایسه کنید و توضیح دهید چرا Lab خوب می‌تواند کنار Field Distribution ضعیف‌تر وجود داشته باشد.
7. Core Web Vitals Diagnosis & Rendering-Path Record v1 را با جداسازی Observation، Inference، Repair و Residual Limitation کامل کنید.
8. هر Mutation را فقط بعد از نوشتن Prediction اجرا کنید.
9. Repair و Rerun را تا Pass شدن Public Checkها ادامه دهید.
10. Transfer مربوط به Context جدید را مستقل انجام دهید.

صفحه Transfer یک Web Font، Third-party Widget و Client-rendered Search Panel دارد. از «Optimize هر سه» شروع نکنید. Measurementهایی را انتخاب کنید که اثر محتمل روی LCP/INP/CLS را از هم جدا کنند. مشخص کنید کدام Evidence را در Lab می‌گیرید و برای Claim درباره کاربران واقعی چه Field Evidence لازم است.

۱۱. Verification و Evidence Record

Evidence Record شش بُعد اجباری دارد: Implementation Artifact، Observable Generated-output Behavior، Failure Mutation Result، Repair Result، Changed-context Transfer و Residual Limitation.

یک ردیف قوی LCP می‌گوید: «Observed: Hero Discovery Delay از 30ms به 1430ms رسید و Fixture LCP Model از 1430ms به 2830ms رفت. Inference: در این Mutation، Late Hero Discovery علت غالب fixture است. Repair: Early Discovery برگردانده شد. Not observed: Production p75 LCP یا Live Browser Trace.»

ردیف ضعیف می‌گوید: «با preload LCP حل شد.» Technique را نام می‌برد اما Bottleneck، Before/After و Uncertainty را نشان نمی‌دهد.

برای INP نام Interaction و latency segment تغییرکرده را ثبت کنید. برای CLS Element/Layout Event و Shift Evidence را بنویسید. هیچ Cross-metric Success Claim بدون Rerun مربوطه پذیرفته نیست.

Lab از Trace Recordهای قطعی استفاده می‌کند تا Acceptance بدون Account خارجی تکرارپذیر باشد. Valueها داده آموزشی fixture هستند و به‌دروغ DevTools، Lighthouse، CrUX یا RUM نامیده نمی‌شوند. اگر HTML موجود را دستی در Browser باز کنید، آن Evidence اکتشافی اضافه است و شرط Macro-A deterministic acceptance نیست.

Residual Limitation اجباری: Pass شدن این Lab، Production p75 Core Web Vitals، Distribution دستگاه/شبکه، رفتار Sessionهای طولانی، CrUX eligibility یا Soft-navigation coverage بین Browserها را ثابت نمی‌کند.

۱۲. Assessment و Transfer

Retrieval: Metricهای Core Web Vitals فعلی و Good Threshold هرکدام را بگویید و توضیح دهید 75th Percentile چه محدودیتی برای Claim ایجاد می‌کند.

Application: Baseline Diagnosis و Core Web Vitals Diagnosis & Rendering-Path Record v1 را کامل کنید بدون این‌که علت سه Metric را یکی فرض کنید.

Diagnosis: یک Regression عمدی را قبل از اجرا پیش‌بینی و بعد توضیح دهید. پاسخ باید Trace Change مشاهده‌شده، Cause Hypothesis و Repair Boundary داشته باشد.

Decision: یک Optimization را در برابر Alternative محتمل دفاع کنید. دفاع باید به Evidence Path همان Bottleneck متکی باشد، نه شعار کلی Performance.

Transfer: برای صفحه Font/Widget/Client-search، پیش از Optimization Measurement Pointها را انتخاب کنید. بگویید هر Symptom چگونه می‌تواند روی LCP/INP/CLS اثر بگذارد و بعد از Repair محلی برای Claim درباره Real User چه Field Evidence لازم است.

پاسخ وقتی Fail می‌شود که FID را Metric جاری بداند، Threshold رسمی را بی‌برچسب تغییر دهد، Lab Pass را Field Pass اعلام کند یا بدون Rerun Metric مربوطه ادعای Repair کند.

۱۳. References و مرز Freshness

External scope این درس دقیقاً همان پنج Source رسمی Frozen Bible است. در Recheck تاریخ 2026-09-13، web.dev همچنان LCP، INP و CLS را Core Web Vitals جاری و Good Thresholdها را 2.5s، 200ms و 0.1 در 75th Percentile معرفی می‌کند. [S-WEBDEV-VITALS] صفحات جاری LCP، INP و CLS نیز با همین semantics و boundary سازگارند. [S-WEBDEV-LCP] [S-WEBDEV-INP] [S-WEBDEV-CLS]

راهنمای SPA آگوست ۲۰۲۶ یک Claim محدود و Tool-volatile باقی می‌ماند: Chrome 151 Soft-navigation Measurement API را معرفی کرده، اما در همان publication state زمان CrUX Integration اعلام نشده و Browser Engineهای دیگر هنوز پشتیبانی نداشتند. [S-WEBDEV-SPA-2026]

این Claimهای Freshness-bound باید حداکثر تا 2026-12-31 دوباره Review شوند یا زودتر، اگر Official Guidance تغییر کند. Bible immutable است؛ تغییر بعدی باید از Governed Freshness/Change-request Path انجام شود، نه با Rewrite خاموش authority.