Core Web Vitals برای فروشگاه‌های آنلاین: توضیح LCP، INP و CLS

LCP، INP و CLS چه چیزی را می‌سنجند، آستانه‌های خوب و ضعیف در صدک 75، تفاوت داده آزمایشگاهی و میدانی و راه‌حل‌های رایج در فروشگاه‌های Shopify و WooCommerce.

تیم تحریریه FixReports13 دقیقه مطالعه

Core Web Vitals (معیارهای حیاتی وب) سه معیار گوگل هستند که تجربه بازدیدکنندگان واقعی از یک صفحه را توصیف می‌کنند: Largest Contentful Paint (LCP) برای بارگذاری، Interaction to Next Paint (INP) برای پاسخ‌گویی و Cumulative Layout Shift (CLS) برای پایداری بصری. یک صفحه زمانی قبول می‌شود که دست‌کم 75 درصد بازدیدها در محدوده «خوب» باشند: LCP حداکثر 2.5 ثانیه، INP حداکثر 200 میلی‌ثانیه و CLS برابر 0.1 یا کمتر، که برای موبایل و دسکتاپ جداگانه سنجیده می‌شود. در فروشگاه‌های آنلاین، نمره‌های ردشده معمولاً به تصاویر بزرگ یا تنبل‌بارگذاری‌شده (lazy load) در بخش هیرو و صفحه محصول، اسکریپت‌های اپلیکیشن‌ها و ردیابی، فونت‌های وب و بنرها یا ابزارک‌های نقد و نظری برمی‌گردد که پس از نمایش صفحه، محتوا را به پایین هل می‌دهند.

نکات کلیدی

آستانه‌های Core Web Vitals چیست؟

یک صفحه زمانی Core Web Vitals را رعایت می‌کند که صدک 75 بارگذاری‌هایش در هر سه معیار در محدوده خوب باشد.

معیارچه چیزی را می‌سنجدخوبنیازمند بهبودضعیف
LCPزمان تا رندر شدن بزرگ‌ترین تصویر، ویدئو یا بلوک متنی در ناحیه دید (viewport)2.5 s یا کمتربیش از 2.5 s تا 4.0 sبیش از 4.0 s
INPزمان از کلیک، لمس یا فشردن کلید تا ترسیم فریم بعدی200 ms یا کمتربیش از 200 ms تا 500 msبیش از 500 ms
CLSمیزان جابه‌جایی غیرمنتظره محتوای قابل مشاهده0.1 یا کمتربیش از 0.1 تا 0.25بیش از 0.25

آستانه‌ها از راهنماهای LCP (در زبانه جدید باز می‌شود)، INP (در زبانه جدید باز می‌شود) و CLS (در زبانه جدید باز می‌شود) در web.dev، به وضعیت اکتبر 2026، گرفته شده‌اند.

صدک 75 یعنی نتیجه، تجربه بیشتر بازدیدکنندگان را بازتاب می‌دهد، نه فقط سریع‌ترین آن‌ها را، و گوگل موبایل و دسکتاپ را جداگانه بررسی می‌کند (در زبانه جدید باز می‌شود). PageSpeed Insights صفحه‌ای را قبول می‌کند که هر سه معیارش خوب باشد؛ اگر داده کافی برای INP وجود نداشته باشد، فقط LCP و CLS را ارزیابی می‌کند (مستندات PageSpeed Insights (در زبانه جدید باز می‌شود)). گوگل می‌گوید Core Web Vitals پایدار حداکثر سالی یک بار تغییر می‌کنند.

در فروشگاه، عنصر LCP اغلب بنر هیرو یا تصویر اصلی محصول است و به همین دلیل نحوه مدیریت تصاویر این‌قدر اهمیت دارد.

چرا INP در مارس 2024 جای FID را گرفت؟

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

گوگل در مه 2023 اعلام کرد که INP به یکی از Core Web Vitals تبدیل می‌شود و این تغییر از 12 مارس 2024 (در زبانه جدید باز می‌شود) اجرایی شد. FID فقط اولین تعامل را گزارش می‌کرد، آن هم فقط تأخیر ورودی آن را، نه زمان صرف‌شده برای اجرای کنترل‌کننده‌های رویداد (event handler) یا ترسیم نتیجه. INP کلیک‌ها، لمس‌ها و فشردن کلیدها را در طول کل بازدید زیر نظر می‌گیرد و طولانی‌ترین آن‌ها را، با نادیده گرفتن موارد پرت، گزارش می‌کند؛ اسکرول و نگه داشتن نشانگر ماوس روی عناصر (hover) حساب نمی‌شوند. کاربران APIهای CrUX و PageSpeed Insights تا 9 سپتامبر 2024 فرصت داشتند تا به معیار جدید منتقل شوند (web.dev (در زبانه جدید باز می‌شود)).

هر تعامل سه بخش دارد: تأخیر ورودی (انتظار برای اسکریپت‌های مشغول)، مدت پردازش (اجرای کنترل‌کننده‌ها) و تأخیر نمایش (ترسیم فریم بعدی) (web.dev (در زبانه جدید باز می‌شود)).

در فروشگاه، این تعاملات شامل انتخابگر گونه محصول (variant)، دکمه‌های تعداد، افزودن به سبد خرید، کشوی سبد خرید، فیلترها و منوها هستند. یک صفحه ممکن بود با یک لمس سریع اول، FID را با موفقیت بگذراند و باز هم وقتی کسی بعداً فیلترها را باز می‌کند، کند به نظر برسد.

تفاوت داده‌های آزمایشگاهی و داده‌های میدانی چیست؟

داده‌های آزمایشگاهی از یک آزمون در شرایط ثابت به دست می‌آیند، در حالی که داده‌های میدانی در طول زمان از بازدیدکنندگان واقعی جمع‌آوری می‌شوند، و گوگل توصیه می‌کند برای تعیین اولویت اصلاحات از داده‌های میدانی استفاده کنید (web.dev (در زبانه جدید باز می‌شود)).

داده‌های آزمایشگاهیداده‌های میدانی
منبعیک بارگذاری شبیه‌سازی‌شده صفحه (Lighthouse، Chrome DevTools، بخش آزمایشگاهی PageSpeed Insights)بازدیدکنندگان واقعی Chrome (Chrome UX Report)، یا سامانه پایش کاربران واقعی (RUM) خودتان
شرایطدستگاه و شبکه ثابت. آزمون پیش‌فرض موبایل Lighthouse (در زبانه جدید باز می‌شود) از پروفایل «Slow 4G» (رفت‌وبرگشت 150 ms، سرعت دانلود 1.6 Mbps) و کندسازی 4x برای CPU استفاده می‌کندهر دستگاه، شبکه و موقعیتی که بازدیدکنندگان شما دارند
INPدر یک بارگذاری ساده صفحه سنجیده نمی‌شود. Total Blocking Time (TBT) جایگزین تقریبی آن استاز تعاملات واقعی سنجیده می‌شود
مناسب برایاشکال‌زدایی و بررسی یک تغییر پیش از انتشاردانستن آنچه بازدیدکنندگان واقعاً تجربه می‌کنند

TBT بخشی از هر کار (task) رشته اصلی (main thread) را که از 50 ms فراتر می‌رود جمع می‌زند؛ web.dev مقدار کمتر از 200 ms را روی سخت‌افزار موبایل متوسط پیشنهاد می‌کند، اما می‌گوید این معیار جایگزین INP نیست (web.dev (در زبانه جدید باز می‌شود)).

سه نکته درباره Chrome UX Report (CrUX) برای فروشگاه‌ها اهمیت دارد:

  • این گزارش یک میانگین متحرک 28 روزه (در زبانه جدید باز می‌شود) است که روزانه به‌روز می‌شود.
  • Chrome دسکتاپ و Android را برای کاربرانی پوشش می‌دهد که شرایط گزارش‌دهی Chrome را دارند. Chrome در iOS مستثناست، بنابراین فروشگاهی که بیشتر خریدارانش از iPhone استفاده می‌کنند، داده میدانی را فقط از بخشی از مخاطبانش می‌بیند (روش‌شناسی (در زبانه جدید باز می‌شود)).
  • صفحه‌ها و منشأها (origin) فقط زمانی نمایش داده می‌شوند که به‌طور عمومی قابل کشف و به اندازه کافی پربازدید باشند، بنابراین ممکن است فروشگاهی کم‌بازدید فقط داده در سطح منشأ داشته باشد یا اصلاً داده‌ای نداشته باشد.

داشبورد عملکرد وب (در زبانه جدید باز می‌شود) در Shopify نیز LCP، INP و CLS کاربران واقعی را در صدک 75 گزارش می‌کند، اما برای 30 روز به‌جای 28 روز، پس انتظار تفاوت‌هایی با CrUX را داشته باشید.

چه چیزی LCP را در صفحه‌های فروشگاه کند می‌کند؟

LCP در فروشگاه‌ها معمولاً به این دلیل کند است که تصویر اصلی بیش از حد سنگین است، دیر کشف می‌شود یا عمداً با بارگذاری تنبل یا یک انیمیشن به تأخیر می‌افتد.

  • بارگذاری تنبل تصویر LCP. web.dev می‌گوید هرگز این کار را نکنید (web.dev (در زبانه جدید باز می‌شود)). تحلیل آن از صفحه‌های WordPress نشان داد که LCP در صدک 75 در سایت‌هایی که از بارگذاری تنبل بومی (native) استفاده می‌کنند کندتر است و بارگذاری نکردن تنبل تصاویر بالای صفحه (above the fold) این افت را برطرف کرد (web.dev (در زبانه جدید باز می‌شود)).
  • تصویری که دیر پیدا می‌شود. تصویر هیرویی که به‌صورت background-image در CSS تعریف شده یا با اسکریپت یک اسلایدر تزریق می‌شود، در HTMLای که مرورگر ابتدا بررسی می‌کند وجود ندارد. Shopify توصیه می‌کند برای محتوای هیرو از پس‌زمینه CSS و برای تصویر LCP از جلوه‌های ظاهرشدن تدریجی (fade-in) استفاده نکنید (Shopify (در زبانه جدید باز می‌شود)).
  • اولویت پایین. تصاویر تا کامل شدن چیدمان (layout) با اولویت پایین بارگذاری می‌شوند، بنابراین Shopify استفاده از fetchpriority="high" را روی تصویر LCP توصیه می‌کند (Shopify (در زبانه جدید باز می‌شود)). web.dev یادآوری می‌کند که تنظیم آن روی بیش از یک یا دو تصویر، از فایده‌اش می‌کاهد (web.dev (در زبانه جدید باز می‌شود)).
  • CSS و اسکریپت‌های مسدودکننده رندر. شیوه‌نامه‌های (stylesheet) بزرگ و اسکریپت‌های همگام در <head> حتی پس از رسیدن تصویر، رندر را به تأخیر می‌اندازند (web.dev (در زبانه جدید باز می‌شود)).
  • حجم فایل و فونت‌ها. از فرمت‌های مدرن، srcset و sizes و یک CDN استفاده کنید. برای فونت‌های وب، مقداری به‌جز auto یا block برای font-display به کار ببرید.
<!-- Main product image: real src in the HTML, eager, high priority -->
<img src="/images/linen-shirt-1200.webp"
     srcset="/images/linen-shirt-600.webp 600w, /images/linen-shirt-1200.webp 1200w"
     sizes="(min-width: 990px) 50vw, 100vw"
     width="1200" height="1500"
     fetchpriority="high"
     alt="Natural linen shirt, front view">

<!-- Gallery images below the first screen: lazy -->
<img src="/images/linen-shirt-back-600.webp" loading="lazy"
     width="600" height="750" alt="Natural linen shirt, back view">

چه چیزی INP را در صفحه‌های فروشگاه کند می‌کند؟

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

اگر خریدار در حالی روی «افزودن به سبد خرید» بزند که اسکریپت‌های نقد و نظر، گفت‌وگوی آنلاین و تحلیل آماری هنوز در حال اجرا هستند، آن لمس باید منتظر بماند. انتخابگر گونه‌ای که کل فرم محصول را دوباره رندر می‌کند، زمان پردازش را بیشتر می‌کند. مگامنوهای بسیار بزرگ و شبکه‌های مجموعه با تعداد زیادی نمونه رنگ (swatch) تأخیر نمایش را افزایش می‌دهند.

web.dev توصیه می‌کند کارهای طولانی را به کارهای کوچک‌تر بشکنید و کنترل را به رشته اصلی برگردانید (yield)، ابتدا صفحه را به‌روز کنید و بقیه کارها را به تعویق بیندازید، و DOM را کوچک‌تر نگه دارید (web.dev (در زبانه جدید باز می‌شود)). Shopify گام‌هایی مخصوص فروشگاه‌ها اضافه می‌کند: همه اپلیکیشن‌ها، پیکسل‌ها و اسکریپت‌های قالب را ممیزی کنید، آنچه را حیاتی نیست به تعویق بیندازید، امکانات را هنگام تعامل بارگذاری کنید و وقتی هیچ آزمون A/B در حال اجرا نیست، قطعه‌کدهای ضدچشمک (anti-flicker) آن را خاموش کنید (Shopify (در زبانه جدید باز می‌شود)).

چه چیزی باعث جابه‌جایی چیدمان در صفحه‌های محصول و مجموعه می‌شود؟

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

web.dev علت‌های رایج را این‌ها می‌داند: رسانه با ابعاد نامشخص، محتوایی که بالای محتوای موجود اضافه می‌شود، ابزارک‌های شخص ثالثی که اندازه خود را تغییر می‌دهند، و فونت‌های وبی که اندازه‌شان با فونت جایگزین (fallback) فرق دارد (web.dev (در زبانه جدید باز می‌شود)). در فروشگاه‌ها این یعنی نوار ارسال رایگانی که در بالای صفحه درج می‌شود، امتیاز ستاره‌ای که پس از عنوان بارگذاری می‌شود، پیام پرداخت اقساطی زیر قیمت و اسلایدرهای (carousel) پیشنهاد محصول. Shopify یادآوری می‌کند که محتوای پاپ‌آپ هم می‌تواند باعث جابه‌جایی شود (Shopify (در زبانه جدید باز می‌شود)).

جابه‌جایی‌هایی که تا 500 ms پس از ورودی کاربر رخ می‌دهند حساب نمی‌شوند، اما جابه‌جایی‌های هنگام اسکرول حساب می‌شوند و ابزارهای آزمایشگاهی اغلب آن‌ها را نمی‌بینند (web.dev (در زبانه جدید باز می‌شود)). به تصاویر width و height یا aspect-ratio در CSS بدهید، برای ابزارک‌ها فضا رزرو کنید، بنرها را به‌صورت لایه رویی (overlay) نمایش دهید، جابه‌جایی ناشی از تعویض فونت را با size-adjust کاهش دهید و انیمیشن‌ها را به‌جای top یا left با transform بسازید.

/* Reserve space for a reviews summary that loads after the page */
.product-reviews-summary { min-height: 24px; }

/* Keep product cards from jumping while images load */
.product-card img { width: 100%; height: auto; aspect-ratio: 4 / 5; }

چگونه Core Web Vitals را در Shopify بهبود دهیم؟

در Shopify، بیشترین بهبود از بارگذاری فوری اولین تصویر با اولویت بالا، کم کردن اسکریپت‌های اپلیکیشن‌ها و بررسی نتیجه در گزارش‌های عملکرد وب در پنل مدیریت به دست می‌آید.

داده‌ها را در پنل مدیریت بررسی کنید

خلاصه‌ای در صفحه Online Store > Themes نمایش داده می‌شود و گزارش‌های کامل LCP، INP و CLS در Analytics > Reports قرار دارند. داده‌ها ممکن است تا 36 ساعت تأخیر داشته باشند و حالت خصوصی (private mode) باید خاموش باشد (مرکز راهنمای Shopify (در زبانه جدید باز می‌شود)).

بارگذاری تصاویر را در Liquid کنترل کنید

فیلتر image_tag تصاویر بخش‌های پایین‌تر صفحه را به‌صورت تنبل بارگذاری می‌کند، مگر اینکه preload را تنظیم کنید (مرجع image_tag (در زبانه جدید باز می‌شود)): فوری برای بخش‌های 1 تا 3 و تنبل از بخش 4 به بعد. چون section.index در ویرایشگر قالب برابر nil است، در شرط به‌جای <= 3 از > 3 استفاده کنید:

{%- if section.index == 1 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'eager', fetchpriority: 'high', widths: '600, 900, 1200, 1600', sizes: '100vw' }}
{%- elsif section.index > 3 -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: loading: 'lazy', sizes: '100vw' }}
{%- else -%}
  {{ section.settings.image | image_url: width: 1600 | image_tag: sizes: '100vw' }}
{%- endif -%}

در شبکه‌های محصول، Shopify پیشنهاد می‌کند فقط چند کارت اول به‌صورت فوری بارگذاری شوند (برای مثال forloop.index <= 4) (Shopify (در زبانه جدید باز می‌شود)). از preload: true با احتیاط استفاده کنید؛ Shopify توصیه می‌کند فقط یک یا دو منبعی را که دیر کشف می‌شوند پیش‌بارگذاری کنید.

آنچه اپلیکیشن‌ها به جا می‌گذارند حذف کنید

جاسازی‌های بلااستفاده اپلیکیشن‌ها (app embeds) را از مسیر Online Store > Edit theme > App embeds خاموش کنید (مرکز راهنمای Shopify (در زبانه جدید باز می‌شود)). حذف یک اپلیکیشن، بلوک‌های آن را هم حذف می‌کند، اما اپلیکیشن‌هایی که فایل‌های قالب را مستقیماً ویرایش کرده‌اند ممکن است «کد شبح» (ghost code) به جا بگذارند که به گفته Shopify می‌تواند مشکلات کیفیت و عملکرد ایجاد کند (Shopify (در زبانه جدید باز می‌شود)). Shopify همچنین می‌گوید تگ‌های اسکریپت (script tags) از 1 مارس 2027 دیگر اجرا نمی‌شوند. برای فونت‌ها، Shopify استفاده از CDN خودش یا فونت‌های سیستمی را به سرویس‌های فونت خارجی ترجیح می‌دهد (Shopify (در زبانه جدید باز می‌شود)).

چگونه Core Web Vitals را در WooCommerce بهبود دهیم؟

در WooCommerce مطمئن شوید افزونه‌ها اولویت‌بندی تصاویر WordPress را لغو نمی‌کنند، همه‌چیز به‌جز سبد خرید و تسویه حساب را کش کنید و اسکریپت‌هایی را که بی‌دلیل در همه صفحه‌ها بارگذاری می‌شوند حذف کنید.

  • مدیریت تصاویر هسته را حفظ کنید. از WordPress 6.3 (منتشرشده در 8 اوت 2023)، هسته وردپرس fetchpriority="high" را به تصویری که احتمالاً LCP است (به‌طور پیش‌فرض دست‌کم 50,000 پیکسل مربع) اضافه می‌کند و بارگذاری تنبل را برای سه تصویر محتوایی نخست اعمال نمی‌کند (Make WordPress Core (در زبانه جدید باز می‌شود)). اگر یک افزونه بهینه‌سازی، بارگذاری تنبل خودش را اضافه می‌کند، بررسی کنید که تصویر هیرو و تصویر اصلی محصول را مستثنا کند.
  • صفحه‌ها را کش کنید، نه سبد خرید را. راهنمای WooCommerce کش صفحه در سطح سرور یا با افزونه و استفاده از CDN را توصیه می‌کند، در حالی که صفحه‌های سبد خرید و تسویه حساب نباید کش شوند (مستندات توسعه‌دهندگان WooCommerce (در زبانه جدید باز می‌شود)).
  • cart fragments را بررسی کنید. از WooCommerce 7.8، اسکریپت cart fragments فقط در جایی بارگذاری می‌شود که ابزارک Cart وجود داشته باشد، اما برخی قالب‌ها این ابزارک را به‌صورت ثابت در کد گنجانده‌اند. بلوک Mini-Cart از cart fragments استفاده نمی‌کند (وبلاگ توسعه‌دهندگان WooCommerce (در زبانه جدید باز می‌شود)).
  • افزونه‌های سنگین را پیدا کنید. WooCommerce برای پیدا کردن افزونه‌های کند، Query Monitor را پیشنهاد می‌کند و توصیه می‌کند JavaScript غیرحیاتی را به تعویق بیندازید.

اگر چیدمان شما بیش از سه تصویر را در بالای صفحه (above the fold) نشان می‌دهد، می‌توانید آستانه WordPress را افزایش دهید:

// functions.php: skip lazy loading for the first 4 content images (default is 3)
add_filter( 'wp_omit_loading_attr_threshold', function () {
    return 4;
} );

چقدر طول می‌کشد تا اثر اصلاحات دیده شود؟

آزمون‌های آزمایشگاهی اثر یک اصلاح را بلافاصله نشان می‌دهند، اما داده‌های میدانی تا حدود چهار هفته زمان لازم دارند تا آن را به‌طور کامل بازتاب دهند، چون CrUX میانگین 28 روز گذشته را محاسبه می‌کند.

آزمون آزمایشگاهی را پیش و پس از هر تغییر چند بار اجرا کنید، چون نتایج یک اجرای منفرد متغیر است، سپس اعداد میدانی را در PageSpeed Insights، گزارش Core Web Vitals در Search Console یا گزارش‌های Shopify دنبال کنید. یک اسکن رایگان در حدود یک دقیقه، نخستین ارزیابی را به شما می‌دهد. گزارش عملکرد یک آزمون آزمایشگاهی موبایل با محدودسازی (slow 4G، کندسازی 4x برای CPU) اجرا می‌کند و داده‌های میدانی Chrome UX Report را هم اضافه می‌کند، از جمله INP، اگر گوگل داده کافی برای فروشگاه شما داشته باشد.

پرسش‌های متداول

آیا Core Web Vitals بر رتبه‌بندی گوگل اثر دارند؟

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

چرا PageSpeed Insights برای فروشگاه من داده میدانی نشان نمی‌دهد؟

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

آیا برای قبولی به نمره 90 یا بالاتر در Lighthouse نیاز دارم؟

خیر. نمره عملکرد Lighthouse یک نتیجه آزمایشگاهی است، در حالی که ارزیابی Core Web Vitals از داده‌های میدانی در صدک 75 استفاده می‌کند، بنابراین یک صفحه می‌تواند با نمره متوسط Lighthouse قبول شود و با نمره بالا رد شود.

آیا باید همه تصاویر محصول را تنبل بارگذاری کنم؟

خیر. تصاویر زیر صفحه نخست را تنبل بارگذاری کنید، اما تصویر هیرو و تصویر اصلی محصول را فوری بارگذاری کنید و fetchpriority="high" را روی یکی از آن‌ها بگذارید.

چرا نتایج موبایل من از دسکتاپ بدتر است؟

گوگل موبایل و دسکتاپ را جداگانه می‌سنجد و تلفن‌های همراه پردازنده‌ها و شبکه‌های کندتری دارند. آزمون موبایل Lighthouse این شرایط را با پروفایل Slow 4G و کندسازی 4x برای CPU شبیه‌سازی می‌کند.

منابع

همه راهنماها