دو سایت ممکن است در یک تست هر دو «سه ثانیه» ثبت شوند، اما برای کاربر یکسان نباشند. در اولی، عنوان و دکمه اصلی زود دیده میشود و کلیک فوراً بازخورد دارد؛ در دومی، صفحه سفید میماند، دکمه جابهجا میشود یا پس از لمس چند لحظه هیچ اتفاقی نمیافتد. سرعت سایت یک عدد واحد نیست؛ کیفیت زمانیِ یک مسیر واقعی کاربر است.
برای یک فروشگاه ایرانی، مسئله فقط دانلود صفحه اول هم نیست. جستوجوی محصول، انتخاب تنوع، افزودن به سبد، ورود با رمز یکبارمصرف، انتقال به درگاه و بازگشت از پرداخت همگی بخشی از تجربه عملکرد هستند. اگر فقط امتیاز صفحه خانه را سبز کنیم، ممکن است گلوگاه اصلی کسبوکار دستنخورده بماند.
این راهنما کمک میکند اهمیت سرعت سایت را بدون وعدههای قطعی درباره رتبه یا فروش بسنجید: ابتدا تجربه را تعریف میکنیم، تفاوت داده آزمایشگاهی و واقعی را میبینیم، بودجه عملکرد میسازیم، اصلاحات را با اثر اقتصادی اولویت میدهیم و بعد از انتشار بررسی میکنیم آیا نتیجه واقعاً بهتر شده است یا نه. جزئیات فنی رفع LCP، INP و CLS در راهنمای Core Web Vitals و RUM آمده است.
خلاصه اجرایی: از کجا شروع کنیم؟
- مسیر مهم را انتخاب کنید: مثلاً ورود از گوگل به صفحه محصول تا پرداخت موفق؛ نه «کل سایت» بهصورت مبهم.
- خط مبنا بسازید: داده واقعی کاربران، تست آزمایشگاهی تکرارپذیر و KPI کسبوکار را در یک بازه و Segment مشخص کنار هم بگذارید.
- گلوگاه را به مالک آن وصل کنید: Backend، قالب، تصویر، JavaScript، فونت، سرویس ثالث یا درگاه هرکدام مالک و روش اصلاح متفاوت دارند.
- بودجه عملکرد تعیین کنید: برای هر Template و مسیر، حد قابلقبول زمان، حجم، درخواست و تجربه واقعی را تعریف کنید.
- با ریسک و ارزش اولویت بدهید: شدت درد کاربر × تعداد کاربران درگیر × اهمیت مرحله × اطمینان شواهد، در کنار هزینه و ریسک تغییر.
- اثر را پس از Release بسنجید: تغییر فنی، معیار تجربه و نتیجه کسبوکار را جدا ثبت کنید؛ «بعد از تغییر بهتر شد» بهتنهایی اثبات علت نیست.
سرعت سایت دقیقاً چیست؟
عبارت «زمان بارگذاری کامل» برای گزارش مدیریتی وسوسهکننده است، اما تجربه کاربر را کامل توضیح نمیدهد. صفحه ممکن است هنوز فایلهایی در پسزمینه بگیرد، در حالی که کاربر محتوای اصلی را دیده و کارش را شروع کرده است. برعکس، ممکن است ظاهر صفحه کامل باشد اما دکمه بهدلیل مشغول بودن Thread اصلی پاسخ ندهد.
| لایه تجربه | پرسش کاربر | نمونه شاهد |
|---|---|---|
| دسترسی | آیا صفحه اصلاً باز میشود؟ | خطای DNS، TLS، 5xx، Timeout و نرخ موفقیت درخواست |
| پاسخ سرور | شروع دریافت محتوا چقدر طول میکشد؟ | TTFB و زمانهای Backend/Cache |
| نمایش اولیه | آیا میفهمم صفحه در حال کار است؟ | FCP، Skeleton هدفمند و بازخورد Loading |
| نمایش محتوای اصلی | آیا چیزی که برایش آمدهام دیده میشود؟ | LCP و زمان نمایش عنوان، تصویر یا بلوک اصلی |
| تعامل | آیا کلیک، تایپ و انتخاب سریع پاسخ میدهد؟ | INP، Long Task و تأخیر پاسخ رابط |
| پایداری | آیا چیزی زیر انگشت یا چشم من جابهجا میشود؟ | CLS و مشاهده Session |
| تکمیل کار | آیا میتوانم هدفم را بدون انتظار و خطا تمام کنم؟ | زمان تا افزودن به سبد، ارسال فرم یا پرداخت موفق |
پس تعریف عملی سرعت باید شبیه این باشد: «کاربران موبایل صفحه محصول، در شبکه و دستگاههای متداول، محتوای اصلی را پایدار میبینند، انتخاب تنوع پاسخگو است و افزودن به سبد با نرخ خطای کنترلشده تمام میشود.» این تعریف هم قابلاندازهگیری است و هم به تصمیم کسبوکار وصل میشود.
چرا سرعت برای تجربه کاربری مهم است؟
کندی هزینه شناختی ایجاد میکند. کاربر نمیداند درخواست ثبت شده، اینترنت قطع است یا سایت خراب شده است؛ دوباره کلیک میکند، مرحله را ترک میکند یا به پشتیبانی پیام میدهد. جابهجایی ناگهانی نیز ممکن است باعث لمس دکمه اشتباه شود. بنابراین درد عملکرد فقط «صبر کردن» نیست؛ ابهام، خطا، از دست رفتن کنترل و گاهی اقدام مالی ناخواسته است.
اثر این درد به زمینه بستگی دارد. کاربر برای دیدن نتیجه پرداخت یا ثبت سفارش معمولاً حساستر از خواندن یک مقاله بلند است. بازدیدکنندهای که از شبکه ناپایدار و گوشی اقتصادی استفاده میکند تجربه متفاوتی از عضو تیم روی Wi-Fi و لپتاپ قدرتمند دارد. به همین دلیل، میانگین کل میتواند گروهی را که بیشترین مشکل را دارد پنهان کند.
سرعت ادراکشده را با عملکرد واقعی اشتباه نگیریم
Skeleton، Progress indicator و Optimistic UI میتوانند انتظار را قابلفهمتر کنند، اما جای اصلاح گلوگاه را نمیگیرند. اگر پرداخت واقعاً شکست میخورد یا کلیک ثبت نمیشود، انیمیشن زیبا مسئله را پنهان میکند. از سوی دیگر، یک پاسخ کوتاه و مشخص مانند «در حال بررسی پرداخت؛ صفحه را نبندید» میتواند از کلیک تکراری و سفارش مبهم جلوگیری کند. راه درست ترکیب کاهش زمان واقعی با بازخورد صادقانه است.
سرعت سایت چه اثری بر سئو دارد؟
گوگل میگوید Core Web Vitals در سیستمهای رتبهبندی استفاده میشود، اما Page Experience یک سیگنال واحد نیست و نتیجه خوب در ابزارها رتبه برتر را تضمین نمیکند. ارتباط و مفید بودن محتوا همچنان اهمیت اساسی دارند. پس دو گزاره افراطی را کنار بگذارید: «سرعت هیچ اثری بر سئو ندارد» و «سبز شدن امتیاز حتماً رتبه را بالا میبرد» هر دو گمراهکنندهاند. منبع رسمی: راهنمای Page Experience گوگل.
همچنین نباید Bounce rate، مدت حضور یا Pages per session را بدون سند بهعنوان سیگنال مستقیم رتبهبندی معرفی کرد. این شاخصها برای شناخت تجربه و Funnel خود کسبوکار مفیدند، اما تغییر آنها ممکن است از نیت جستوجو، کمپین، نوع صفحه، کیفیت محتوا یا طراحی اندازهگیری ناشی شود. از داده رفتاری برای تشخیص استفاده کنید، نه برای ادعای قطعی درباره الگوریتم.
اولویت سئویی سرعت را چگونه تعیین کنیم؟
- صفحات Organic با Impression و Conversion بالا را زودتر بررسی کنید.
- Template را واحد تحلیل بگیرید؛ مشکل مشترک همه صفحات محصول معمولاً ارزش بیشتری از اصلاح یک URL کمترافیک دارد.
- مشکل دسترسی، خطای سرور، Mobile usability یا محتوای اصلی را پشت امتیاز Performance پنهان نکنید.
- پس از اصلاح، رتبه و کلیک را در کنار Release، تغییر محتوا، فصل فروش و بهروزرسانیهای دیگر تفسیر کنید.
برای جداسازی مسائل عملکرد از نمایش موبایل، از چکلیست Mobile-friendly برای سئو و UX استفاده کنید.
آیا سایت سریعتر حتماً نرخ تبدیل را بالا میبرد؟
خیر؛ «حتماً» واژه درستی نیست. مطالعات موردی شرکتهای بزرگ نشان میدهند بهبود عملکرد میتواند با رشد Conversion یا درآمد همراه شود، اما درصد یک برند را نمیتوان به سایت دیگر منتقل کرد. ترکیب ترافیک، قیمت، اعتماد، موجودی، UX، روش پرداخت و کیفیت اندازهگیری متفاوت است. حتی ممکن است یک Release همزمان سرعت را بهتر و قیمت را بدتر کند و اثرها یکدیگر را بپوشانند.
سرعت یک عامل توانمندساز است: اصطکاک را کم میکند تا پیشنهاد ارزش، محتوا و جریان خرید فرصت اثرگذاری داشته باشند. اگر محصول ناموجود، فرم گیجکننده یا هزینه ارسال نامشخص باشد، چند صد میلیثانیه بهبود مشکل اصلی را حل نمیکند.
برای ادعای اثر تجاری چه شواهدی لازم است؟
| سطح شواهد | چه چیزی میگوید؟ | محدودیت |
|---|---|---|
| همبستگی Segmentها | Sessionهای سریعتر Conversion بیشتری داشتهاند | کاربران وفادار، Cache، دستگاه و ارزش سفارش میتوانند عامل مشترک باشند |
| قبل و بعد Release | پس از تغییر فنی KPI بهتر شده است | کمپین، فصل، قیمت و تغییرات همزمان مخدوشکنندهاند |
| انتشار مرحلهای | گروه دریافتکننده تغییر با گروه مرجع مقایسه میشود | تقسیم Traffic و یکسانی گروهها باید معتبر باشد |
| آزمایش A/B معتبر | اثر علی با Guardrail و حجم نمونه مناسب بررسی میشود | برای سایت کمترافیک یا تغییر زیرساختی همیشه عملی نیست |
اگر آزمایش ممکن نیست، یک سری زمانی با Annotation دقیق Releaseها، کمپینها و خطاها بسازید؛ نتیجه را با بازه اطمینان و سناریو گزارش کنید، نه یک عدد قطعی. راهنمای UX دادهآگاه برای Event taxonomy، Funnel، Cohort و کیفیت داده مسیر کاملتری ارائه میکند.
معیارهای فعلی Core Web Vitals
در زمان بازبینی این مقاله (مرداد ۱۴۰۵)، سه معیار اصلی عبارتاند از LCP، INP و CLS؛ FID دیگر Core Web Vital جاری نیست. برای ارزیابی «خوب»، صفحه باید در صدک ۷۵ تجربهها و جداگانه برای موبایل و دسکتاپ، به آستانههای زیر برسد. مرجع: Core Web Vitals در Google Search.
| معیار | چه چیزی را تقریب میزند؟ | آستانه خوب | برداشت نادرست رایج |
|---|---|---|---|
| LCP | زمان نمایش بزرگترین محتوای قابلمشاهده | حداکثر ۲٫۵ ثانیه | معادل «بارگذاری کامل صفحه» نیست |
| INP | پاسخگویی کلیک، لمس و ورودی در طول بازدید | حداکثر ۲۰۰ میلیثانیه | با یک کلیک مصنوعی یا TBT یکی نیست |
| CLS | پایداری بصری و جابهجایی ناخواسته | حداکثر ۰٫۱ | هر حرکت یا انیمیشنی Layout Shift بد نیست |
این آستانهها هدف مشترک مفیدیاند، نه قرارداد SLA یا تضمین درآمد. یک Checkout ممکن است علاوه بر آنها به نرخ خطا و زمان پاسخ API حساس باشد؛ یک سایت خبری به زمان نمایش تیتر و خوانایی؛ و یک اپلیکیشن تعاملی به Long Taskها و پاسخ عملیات داخلی.
داده آزمایشگاهی، داده میدانی و RUM چه تفاوتی دارند؟
مستندات PageSpeed Insights دو تصویر متفاوت را توضیح میدهد: داده Lab از Lighthouse در محیط شبیهسازیشده برای عیبیابی، و داده Field از CrUX برای تجربه واقعی کاربران Chrome واجد شرایط طی ۲۸ روز گذشته. کمبود نمونه ممکن است باعث نمایش داده سطح Origin یا نبود Field data شود. اختلاف این دو خطا نیست؛ هرکدام سؤال دیگری را پاسخ میدهند.
| روش | پاسخ مناسب | مزیت | محدودیت |
|---|---|---|---|
| Lab / Lighthouse | در شرایط کنترلشده چه گلوگاهی دیده میشود؟ | تکرارپذیر، دارای Trace و Audit فنی | یک دستگاه/شبکه شبیهسازیشده و معمولاً یک Page load |
| CrUX / Field | کاربران واقعی Chrome در ۲۸ روز چه تجربهای داشتهاند؟ | واقعی، مناسب Core Web Vitals و روند | تجمیعی، تأخیردار، بدون جزئیات کسبوکار و نیازمند نمونه کافی |
| RUM اختصاصی | کدام مسیر، Template، Release یا Segment مشکل دارد؟ | قابل اتصال به Context و KPI داخلی | نیازمند طراحی، کیفیت داده، Consent و کنترل Privacy |
| Synthetic monitoring | آیا مسیر مشخص از نقطه مشخص هنوز کار میکند؟ | پایش مداوم، Alert و مقایسه Release | نماینده همه دستگاهها و شبکههای واقعی نیست |
داده Lab برای یافتن علت عالی است، اما نمره ۱۰۰ هدف کسبوکار نیست. داده Field نتیجه واقعی را بهتر نشان میدهد، اما برای یافتن دقیق فایل یا تابع کند کافی نیست. RUM این شکاف را پر میکند، به شرط آنکه Sampling، Version، Route، Device class و کیفیت رویدادها روشن باشند.
میانگین کافی نیست
میانگین میتواند دنباله کند را پنهان کند. P75 برای Core Web Vitals زبان مشترک است، اما برای عملیات حساس P90/P95، نرخ Timeout و نرخ خطا نیز مهماند. داده را دستکم بر اساس نوع صفحه، Mobile/Desktop، مرورگر، کلاس دستگاه، نوع اتصال قابلاتکا، Region تقریبی و نسخه Release بررسی کنید. Segmentهای بسیار کوچک یا قابلشناسایی را گزارش نکنید.
Baseline معتبر در هفت گام
- هدف و بازه را ثبت کنید: مثلاً «کاهش اصطکاک صفحه محصول موبایل در چهار هفته»، نه «افزایش سرعت سایت».
- Inventory مسیر بسازید: Landing، Listing، Product، Cart، Login، Checkout، Gateway return و Success/Error.
- دوره عادی انتخاب کنید: حراج، قطعی گسترده یا مهاجرت همزمان را بهعنوان Baseline معمول جا نزنید.
- Field data را ثبت کنید: P75 و توزیع LCP/INP/CLS، نرخ خطا، Timeout و زمان تکمیل Task.
- Lab را چندبار اجرا کنید: روی Template نماینده، با Profile ثابت و Median چند اجرا؛ نه بهترین نتیجه یک Run.
- KPI و Guardrail را وصل کنید: Add-to-cart، Submit موفق، Conversion، Revenue per session، خطای JS، 5xx و Ticket پشتیبانی.
- نسخه و تغییرات را Annotation کنید: Deploy، Tag جدید، کمپین، افزونه، تغییر درگاه و Cache purge در خط زمانی ثبت شوند.
برای اینکه هشدارها و Traceها بعد از انتشار قابلاتکا باشند، راهنمای Observability و مانیتورینگ سایت را کنار برنامه Performance قرار دهید.
Performance budget چیست و چطور آن را بسازیم؟
بودجه عملکرد مجموعهای از حدهاست که مانع پسرفت بیصدا میشود. این بودجه میتواند برای زمان، حجم، تعداد درخواست، JavaScript، سرویس ثالث یا تجربه واقعی تعریف شود. منبع آموزشی رسمی web.dev نیز Budget را نقطه مرجع تصمیم درباره طراحی، فناوری و افزودن Feature میداند: Performance Budgets 101.
یک عدد جهانی برای همه سایتها تعیین نکنید. صفحه مقاله، محصول و Checkout محتوا و ریسک یکسان ندارند. ابتدا Baseline و نیاز کاربر را بسنجید، سپس حدی بسازید که هم معنادار و هم قابلاجرا باشد.
| نوع Budget | نمونه برای Template محصول | کاربرد |
|---|---|---|
| تجربه واقعی | P75 موبایل برای LCP/INP/CLS در محدوده هدف مصوب | نتیجهای که کاربر تجربه میکند |
| زمان Lab | عدم پسرفت LCP آزمایشگاهی بیش از آستانه تیم | گیت قبل از Merge یا Release |
| حجم | حد برای JS اولیه، فونت و تصویر Hero | کنترل رشد Payload |
| تعداد | حد درخواستهای Third-party و فایلهای Render-blocking | کنترل پیچیدگی و Dependency |
| عملیاتی | نرخ Timeout و 5xx کمتر از SLO مسیر | حفاظت از قابلیت تکمیل Task |
| تجاری | عدم افت Add-to-cart و Checkout completion | Guardrail نتیجه کسبوکار |
قانون تصمیم هنگام عبور از Budget
عبور از Budget نباید فقط یک نمودار قرمز باشد. تیم باید پیشاپیش بداند چه میکند: اصلاح Asset یا Code، حذف Dependency کمارزش، Lazy-load بخش غیراساسی، پذیرش استثنای زماندار با Owner، یا توقف Release. هر استثنا باید دلیل، تاریخ انقضا و Issue پیگیری داشته باشد؛ وگرنه Budget بهتدریج بیمعنا میشود.
گلوگاه را در کدام لایه پیدا کنیم؟
قبل از نسخهپیچی، Trace، Waterfall، Server timing، Query log و داده RUM را کنار هم بگذارید. «سایت کند است» میتواند شش علت کاملاً متفاوت داشته باشد.
| لایه | نشانه محتمل | اقدام تشخیصی |
|---|---|---|
| Backend و پایگاه داده | TTFB بالا، 5xx یا کندی متغیر زیر بار | Trace درخواست، Query کند، Hit ratio کش، Saturation و Dependencyها |
| HTML و Rendering | محتوای اصلی دیر کشف یا Paint میشود | Critical path، ترتیب Resource، Server rendering و Priorityها |
| تصویر و Media | Hero سنگین، ابعاد نامتناسب یا Shift | اندازه واقعی، Format، Responsive image، Dimensions و Preload هدفمند |
| فونت فارسی | متن دیر دیده میشود یا پس از Load جابهجا میشود | Subset، تعداد Weight، WOFF2، Cache، Preload و Fallback metric |
| CSS و JavaScript | Long task، INP ضعیف یا Main thread شلوغ | Coverage، Bundle/Chunk، Execution profile و Hydration |
| سرویس ثالث | تغییرپذیری زیاد، Request خارجی یا خطای Script | Dependency map، Timeout، Consent، Facade و حذف آزمایشی |
| شبکه و CDN | تفاوت Region/ISP، Cache miss یا TLS/DNS کند | PoP/Route واقعی، Headerها، Hit ratio، Purge و تست چندشبکهای |
بهینهسازیهای عمومی که ممکن است نتیجه معکوس بدهند
- ترکیب همه CSS و JS: در HTTP/۲ یا HTTP/۳ همیشه بهترین پاسخ نیست و میتواند Cache granularity یا اجرای ضروری را بدتر کند.
- Lazy-load همه تصاویر: Lazy-load کردن تصویر LCP بالای Fold میتواند نمایش محتوای اصلی را دیرتر کند.
- Preload گسترده: رقابت برای پهنای باند میسازد؛ فقط Resource واقعاً حیاتی را با نوع و Priority درست Preload کنید.
- حذف بیقاعده Script: ممکن است Analytics، Accessibility، Consent یا جریان درآمد را بشکند. Dependency و Owner را اول مشخص کنید.
- ارتقای هاست بدون شاهد: اگر گلوگاه JavaScript یا تصویر است، CPU یا NVMe بیشتر الزاماً تجربه کاربر را اصلاح نمیکند.
- نصب چند افزونه سرعت: همپوشانی Cache، Minify و Delay میتواند Conflict، داده کهنه یا شکست Checkout بسازد.
برای طراحی Layer و Invalidation از راهنمای جامع کش سایت و برای تنظیم وردپرس از راهاندازی و عیبیابی کش وردپرس استفاده کنید.
سناریوهای مهم برای کاربران ایران
محل سرور یا نام یک CDN بهتنهایی پاسخ نمیدهد. تجربه کاربران ایران میتواند با ISP، شبکه ثابت یا همراه، Device، Browser، DNS، مسیر بینالملل و ساعت ترافیک تغییر کند. تصمیم زیرساختی را با اندازهگیری روی مخاطب واقعی بگیرید و از دور زدن محدودیت سرویسدهندگان یا ثبت موقعیت غیرواقعی پرهیز کنید.
چکهای بومی قبل از هر Release
- صفحه و مسیر حیاتی را روی چند شبکه و گوشی نماینده، نه فقط اینترنت دفتر، آزمایش کنید.
- فونت فارسی را از نظر تعداد Weight، Subset حروف موردنیاز، Fallback و جابهجایی متن بررسی کنید.
- نقشه، چت، کپچا، ویدئو، Analytics و فونت خارجی را در Dependency map بیاورید؛ شکست هرکدام نباید محتوای اصلی را متوقف کند.
- ورود با OTP را با تأخیر پیامک، Resend، شمارنده و Rate limit تست کنید؛ Performance فقط Frontend نیست.
- درگاه و Redirect برگشت را روی موفق، ناموفق، انصراف، Refresh و بازگشت دیرهنگام بسنجید؛ عملیات باید Idempotent باشد.
- Cache/CDN را با Hit ratio، Header و Purge واقعی ارزیابی کنید؛ «نزدیکترین سرور» را از روی بروشور فروشنده فرض نکنید.
- داده Segment را حداقلسازی و تجمیع کنید؛ نام ISP یا Device نباید به Fingerprint کاربر تبدیل شود.
راهنمای انتخاب و ارزیابی CDN برای ایران معیارهای PoP، Route، Cache، Purge، WAF، Failover و قرارداد خروج را تفکیک میکند.
چطور اصلاحات سرعت را اولویتبندی کنیم؟
فهرست Lighthouse را بهصورت کور اجرا نکنید. هر اقدام را با پنج عامل امتیاز دهید:
- شدت درد: تأخیر جزئی است، Task را مختل میکند یا به خطای مالی میرسد؟
- Reach: چند کاربر و چند Template درگیرند؟
- اهمیت مسیر: مقاله کمترافیک است یا Checkout و Lead form؟
- اطمینان: Trace و داده واقعی داریم یا فقط حدس ابزار؟
- هزینه و ریسک: زمان اجرا، احتمال Regression، هزینه سرویس و بار عملیاتی چیست؟
یک روش ساده این است:
امتیاز فرصت = (شدت × Reach × اهمیت × اطمینان) ÷ (هزینه × ریسک)
مقیاسها میتوانند ۱ تا ۵ باشند؛ عدد خروجی حقیقت علمی نیست، بلکه تصمیم تیم را قابلبحث میکند. اصلاح مشترک در Header همه صفحات ممکن است از بهینهسازی دقیق یک Landing کمترافیک ارزشمندتر باشد. یک مشکل پرداخت با Reach کمتر نیز ممکن است بهدلیل شدت و اهمیت، اولویت نخست شود.
سنجش اثر بعد از انتشار
قبل از Release، فرضیه را بنویسید: «کاهش اجرای JavaScript انتخاب تنوع، P75 INP موبایل صفحه محصول را بهتر میکند و بدون افزایش خطا، Add-to-cart موفق را بالا میبرد.» سپس معیارهای فنی، تجربهای و تجاری را جدا بررسی کنید.
| لایه نتیجه | نمونه معیار | پرسش تصمیم |
|---|---|---|
| تغییر فنی | حجم JS، Long task، Cache hit، Query time | آیا چیزی که ساختیم واقعاً تغییر کرد؟ |
| تجربه کاربر | INP/LCP/CLS، Task time، Timeout و Error | آیا کاربر تجربه بهتری داشت؟ |
| کسبوکار | Add-to-cart، Lead submit، Conversion و Support contact | آیا نتیجه ارزشمند تغییر کرد؟ |
| Guardrail | Accessibility، خطای پرداخت، Refund و هزینه زیرساخت | آیا جای دیگری را خراب کردیم؟ |
بازه مقایسه را درست انتخاب کنید
CrUX پنجره متحرک ۲۸روزه دارد؛ انتظار تغییر آنی پس از Release منطقی نیست. RUM اختصاصی سریعتر سیگنال میدهد، اما باید Sample و Mix ترافیک را کنترل کرد. روزهای مشابه هفته، Campaign source، Device mix، موجودی و قیمت را مقایسه کنید. اگر چند تغییر همزمان منتشر شدهاند، Attribution را محدود و نتیجه را با زبان احتمالی گزارش کنید.
محاسبه ROI بدون وعدهسازی
بودجه Performance را با سناریو بسازید، نه با جمله «هر یک ثانیه برابر X درصد فروش است». یک مدل ساده:
منفعت خالص = (اقدام موفق افزایشی × حاشیه مشارکت) + هزینه عملیاتی اجتنابشده − هزینه اجرا − هزینه نگهداری
سه سناریوی محافظهکارانه، میانه و خوشبینانه تعریف کنید. «اقدام افزایشی» را از آزمایش یا دامنهای مبتنی بر داده خودتان بگیرید. هزینه توسعه، QA، ابزار RUM، CDN، پشتیبانی و On-call را فراموش نکنید. اگر Confidence پایین است، ابتدا یک PoC محدود روی Template پرترافیک انجام دهید.
مالکیت و حاکمیت عملکرد
Performance یک پروژه یکباره نیست. بدون Owner و گیت، هر کمپین، Tag، فونت یا Feature تازه میتواند پسرفت ایجاد کند.
| نقش | مسئولیت نمونه |
|---|---|
| Product owner | انتخاب Journey و Trade-off میان Feature و Performance |
| Frontend | Rendering، JS، CSS، تصویر، فونت و Instrumentation مرورگر |
| Backend/Platform | Latency، Cache، Database، Capacity، CDN و SLO |
| Design/Content | Hierarchy، Media، فونت، Feedback و جلوگیری از Shift |
| Marketing/Data | حاکمیت Tag، تعریف KPI، کیفیت Event و تحلیل Experiment |
| QA/Accessibility | Regression مسیر، Device matrix، Keyboard و Reduced motion |
Dashboard باید Trend و Distribution را نشان دهد، نه فقط یک چراغ سبز. Alert را بر SLO و تغییر پایدار تنظیم کنید تا تیم در نویز غرق نشود. پس از Incident، علت ریشهای و گیت پیشگیرانه را ثبت کنید.
برنامه ۳۰، ۶۰ و ۹۰ روزه
روز ۱ تا ۳۰: دیدپذیری و توقف پسرفت
- سه Journey و Template اصلی را بر اساس Traffic و ارزش انتخاب کنید.
- خط مبنای Lab، Field/RUM، خطا و KPI را ثبت کنید.
- دو Quick win با شواهد بالا و یک گلوگاه ساختاری را مشخص کنید.
- Release annotation و مالک سرویسهای ثالث را اجباری کنید.
- یک Budget اولیه و Alert فقط برای مسیرهای حیاتی بسازید.
روز ۳۱ تا ۶۰: اصلاح و اثبات
- گلوگاه مشترک Templateها را رفع و روی Device/Network matrix تست کنید.
- Third-partyهای بدون Owner یا ارزش روشن را محدود کنید.
- انتشار مرحلهای یا طرح Before/After کنترلشده اجرا کنید.
- نتیجه فنی، تجربهای و تجاری را همراه Guardrail گزارش کنید.
- بودجهها را بر پایه داده واقعی بازتنظیم کنید.
روز ۶۱ تا ۹۰: تبدیل به قابلیت سازمانی
- گیت Regression را به CI/CD و Definition of Done اضافه کنید.
- RUM را به Release، Route و Template وصل کنید.
- SLO، Runbook و مسیر Escalation برای Performance incident تعریف کنید.
- گزارش ماهانه فرصتهای اقتصادی و بدهی عملکرد بسازید.
- مالکیت Budget و استثناهای زماندار را در تیم تثبیت کنید.
چکلیست نهایی سرعت سایت
- آیا Journey و Segment هدف مشخص است؟
- آیا Lab، Field/RUM و KPI کسبوکار کنار هم دیده میشوند؟
- آیا P75 و دنباله کند بهجای میانگین تنها بررسی شدهاند؟
- آیا LCP، INP و CLS جاریاند و FID بهاشتباه استفاده نمیشود؟
- آیا Template نماینده و چند URL بررسی شدهاند؟
- آیا شبکه، Device، مرورگر و مسیر پرداخت کاربران ایران تست شده است؟
- آیا گلوگاه با Trace/Waterfall/Log تأیید شده است؟
- آیا Budget فنی و Guardrail تجاری برای Release وجود دارد؟
- آیا Third-party، فونت و Tag مالک مشخص دارند؟
- آیا Cache، CDN و Purge در عمل و نه فقط در تنظیمات تأیید شدهاند؟
- آیا Accessibility، خطا و هزینه زیرساخت قربانی سرعت نشدهاند؟
- آیا Releaseها Annotation و اثر پس از انتشار سنجیده میشوند؟
- آیا نتیجه با محدودیت داده و بدون وعده قطعی گزارش میشود؟
سؤالات متداول
سرعت ایدهآل سایت چند ثانیه است؟
یک عدد واحد برای «بارگذاری کامل» همه سایتها وجود ندارد. برای Core Web Vitals، هدف خوب در صدک ۷۵ برابر LCP حداکثر ۲٫۵ ثانیه، INP حداکثر ۲۰۰ میلیثانیه و CLS حداکثر ۰٫۱ است. در کنار آن، زمان و نرخ موفقیت Task حیاتی خودتان مانند پرداخت یا ارسال فرم را بسنجید.
آیا امتیاز ۱۰۰ PageSpeed باعث رتبه بهتر میشود؟
خیر. PageSpeed برای تشخیص و پایش مفید است، اما امتیاز کامل تضمین رتبه نیست. گوگل Core Web Vitals را در سیستمهای رتبهبندی به کار میگیرد و همزمان بر ارتباط، مفید بودن محتوا و تجربه کلی تأکید دارد. دنبال رفع درد واقعی کاربر باشید، نه فقط سبز کردن یک Run آزمایشگاهی.
چرا داده Field و Lab با هم فرق دارند؟
Lab یک بارگذاری شبیهسازیشده با شرایط کنترلشده است؛ Field تجربه تجمیعی کاربران واقعی در دستگاهها و شبکههای مختلف را نشان میدهد. تفاوت طبیعی است. Lab برای یافتن علت و Regression، Field برای ارزیابی نتیجه واقعی و RUM اختصاصی برای Segment و Journey داخلی مناسبتر است.
آیا CDN همیشه سایت را برای کاربران ایران سریعتر میکند؟
نه لزوماً. نتیجه به Route، PoP، نوع محتوا، Cache hit، Purge، Origin، TLS/DNS و شبکه کاربران بستگی دارد. PoC چندشبکهای اجرا کنید، Header و Hit ratio را ببینید و مسیرهای Dynamic و پرداخت را جدا بسنجید.
اول تصاویر را بهینه کنیم یا هاست را ارتقا دهیم؟
از روی حدس انتخاب نکنید. اگر TTFB و Backend زیر بار مشکل دارند، زیرساخت و Cache محتملترند؛ اگر LCP با تصویر Hero سنگین است، Media اولویت دارد؛ و اگر INP ضعیف است، JavaScript و Main thread را بررسی کنید. Trace و داده واقعی باید تصمیم را تعیین کنند.
جمعبندی
اهمیت سرعت سایت در «عدد کمتر» خلاصه نمیشود. هدف این است که کاربرِ واقعی بتواند محتوای اصلی را ببیند، بدون جابهجایی و ابهام تعامل کند و مسیر ارزشمند را با خطای کمتر تمام کند. Core Web Vitals زبان مشترک خوبی است، اما کافی نیست؛ باید آن را با RUM، Task success، Error، KPI کسبوکار و زمینه کاربران ایران ترکیب کرد.
از یک Journey مهم شروع کنید، Baseline قابلاعتماد بسازید، Budget را به Release متصل کنید و اثر را با روش متناسب با Traffic بسنجید. نتیجهای که فقط در یک تست سریعتر است هنوز موفقیت نیست؛ نتیجهای ارزش دارد که برای کاربر بهتر، برای کسبوکار قابلدفاع و در Releaseهای بعدی پایدار بماند.
