CRM/docs/PERFORMANCE_AUDIT_FA.md

# ممیزی کارایی CRM

تاریخ: ۱۴۰۵/۰۵/۰۱

## خط مبنا

- بارگذاری مسیرها از قبل به‌صورت code-split بود، اما loading محتوایی با spinner یا متن ساده نمایش داده می‌شد.
- داده‌های مرجع پرتکرار مانند کارشناسان، نتایج تماس و پایپ‌لاین در چند صفحه و حتی هم‌زمان دوباره درخواست می‌شدند.
- قیف، KPI، داشبورد و گزارش‌ها پس از mutation محلی از یک کانال مشترک invalidation استفاده نمی‌کردند.
- PDF.js به chunk مستقل محدود بود؛ این رفتار باید حفظ می‌شد تا مسیرهای عادی هزینه PDF را نپردازند.
- indexهای ترکیبی اصلی برای وظایف، پیگیری‌ها، تماس‌ها، اعلان‌ها و معاملات در migrationهای موجود حاضر بودند؛ index تکراری اضافه نشد.

## اصلاحات انجام‌شده

- cache حافظه‌ای ۶۰ ثانیه‌ای همراه با deduplication درخواست‌های هم‌زمان برای داده‌های مرجع اضافه شد.
- هر mutation موفق، cache را invalid می‌کند و رویداد مشترک `crm:data-changed` را در همان tab و tabهای دیگر منتشر می‌کند.
- قیف لید، برد فرصت، داشبوردها و گزارش‌ها با رویداد تغییر داده فوراً refresh می‌شوند؛ polling ده تا پانزده ثانیه‌ای نیز برای تغییرات کاربران دیگر باقی مانده است.
- KPI فرصت‌ها از همان `DealPipelineService` خوانده می‌شود و بعد از انتقال کارت به‌صورت optimistic و سپس با داده سرور اصلاح می‌شود.
- همه loadingهای محتوایی اصلی با Skeleton هم‌اندازه جایگزین شدند؛ spinner فقط برای اکشن‌های کوتاه باقی می‌ماند.
- فیلترها و داده‌های وابسته به‌صورت موازی دریافت می‌شوند و route-level lazy loading حفظ شد.

## کنترل بسته تولید

آخرین Build موفق:

- ورودی اصلی: حدود ۲۴۰ کیلوبایت خام و ۷۷ کیلوبایت gzip
- PDF.js: chunk مستقل حدود ۴۲۵ کیلوبایت خام و ۱۲۷ کیلوبایت gzip
- PDF worker: فایل مستقل و فقط در جریان قالب فاکتور
- ۱۸۴ ماژول با Build تولید بدون خطای TypeScript

## نتیجه قابل سنجش

- چند مصرف‌کننده هم‌زمان یک داده مرجع: یک درخواست شبکه به‌جای چند درخواست
- مراجعه به صفحات دارای داده مرجع در بازه cache: صفر درخواست تکراری
- mutation در همان مرورگر: refresh وابستگی‌ها بلافاصله، بدون انتظار برای polling بعدی
- تغییر از کاربر/مرورگر دیگر: حداکثر ۱۰ ثانیه در گزارش و ۱۵ ثانیه در داشبورد