افزایش سرعت سایت‌ساز؛ Core Web Vitals، RUM و بودجه

امتیاز PageSpeed صفحه اصلی شما ۹۲ است، اما مشتری با اینترنت موبایل در ایران روی «افزودن به سبد» می‌زند و دو ثانیه پاسخی نمی‌بیند. مشکل لزوماً سرور یا حجم تصویر نیست؛ یک اپ گفت‌وگو، Tag تبلیغاتی یا کد قالب می‌تواند Main thread را در همان لحظه اشغال کند. در سایت‌ساز، بهینه‌سازی از تشخیص «کدام لایه تحت کنترل من است؟» شروع می‌شود، نه از نصب ابزار بیشتر.

این راهنما برای سایت‌های ساخته‌شده با پلتفرم‌های آماده داخلی و خارجی، فروشگاه‌ساز و Page builder نوشته شده است. Field و Lab، Core Web Vitals، تصویر، فونت فارسی، اسکریپت ثالث، قالب، Cache/CDN، فروشگاه، محدودیت پلتفرم و پایلوت را گام‌به‌گام بررسی می‌کنیم؛ بدون وعده امتیاز ۱۰۰ یا رتبه بهتر صرفاً با افزایش سرعت.

آیا سایت‌سازها ذاتاً کند هستند؟

خیر؛ اما «همه سریع‌اند» نیز درست نیست. خروجی واقعی از ترکیب Platform، قالب، محتوای شما، اپ‌ها و شرایط کاربر ساخته می‌شود. برخی پلتفرم‌ها CDN، Image pipeline و Cache خوبی دارند ولی JavaScript پایه یا کنترل Server محدود است. برخی قالب‌ها سبک‌اند اما با App و Section زیاد کند می‌شوند.

اگر در مرحله انتخاب پلتفرم هستید، خروجی واقعی و محدودیت فنی را با Pilot سنجش SEO Fit سایت‌ساز بسنجید؛ نام برند یا Demo عمومی نماینده سایت نهایی شما نیست.

Performance Contract را پیش از تست بنویسید

هدف «سایت سریع» مبهم است. Journey، Page type، Segment، Device/network، Metric، Budget و Owner را مشخص کنید. صفحه محصول روی موبایل با اینترنت ناپایدار، Checkout پس از بازگشت درگاه و داشبورد کاربر نیاز یکسان ندارند.

Journey: ورود از تبلیغ → محصول → افزودن → Checkout
Page types: landing, product, cart, checkout
Segments: mobile/desktop, new/returning, Iran ISP A/B
Metrics: LCP, INP, CLS + task success + error
Budget: JS/image/font/third-party by template
Owner: platform / theme / content / app / analytics

Core Web Vitals فعلی: LCP، INP و CLS

Core Web Vitals فعلی سه معیار Field هستند: LCP برای سرعت نمایش محتوای اصلی، INP برای پاسخ‌گویی تعامل‌ها و CLS برای پایداری بصری. FID دیگر عضو این مجموعه نیست. طبق آستانه‌های رسمی web.dev، سطح Good برای LCP حداکثر ۲٫۵ ثانیه، INP حداکثر ۲۰۰ میلی‌ثانیه و CLS حداکثر ۰٫۱ در صدک ۷۵ بازدیدهاست.

برای فرایند کامل LCP/INP/CLS و RUM، راهنمای Core Web Vitals مرجع Cluster است؛ این مقاله فقط کاربرد آن در محدودیت سایت‌ساز را توضیح می‌دهد.

Field data و Lab data را اشتباه نگیرید

PageSpeed Insights هم داده واقعی CrUX و هم اجرای Lab با Lighthouse نشان می‌دهد. Field، تجربه جمع‌شده کاربران واقعی در بازه زمانی را بازتاب می‌دهد؛ Lab یک اجرای کنترل‌شده برای عیب‌یابی است. ممکن است Lab سبز و Field ضعیف باشد یا برعکس.

• Field/CrUX یا RUM: برای تشخیص Page type، Device، Region و Long-tail واقعی؛
• Lab: برای Trace، Waterfall، Coverage و بازتولید قبل از Release؛
• Synthetic monitoring: برای روند و Availability از Location ثابت؛
• Business telemetry: برای Task، Add-to-cart، Checkout و Error.

امتیاز Lighthouse KPI کسب‌وکار نیست و سبزشدن Lab تضمین Field خوب نیست. درباره اثر سرعت بر UX/SEO/Conversion نیز از رابطه احتمالی به‌جای وعده قطعی استفاده کنید؛ راهنمای اهمیت سرعت سایت این مرزبندی را شرح می‌دهد.

Baseline را بر Page type و سناریو بسازید

فقط Home را تست نکنید. Templateهای پرترافیک و پردرآمد را نمونه‌گیری کنید: Landing، دسته، محصول سبک/سنگین، جست‌وجو، مقاله، سبد، Checkout، Account و ۴۰۴. حالت Login، Consent، کمپین، موجودی، Chat باز و Cache سرد/گرم را نیز پوشش دهید.

اول Bottleneck را به Metric و Owner وصل کنید

فهرست عمومی «Minify و Cache» اغلب به علت اصلی نمی‌رسد. برای هر Template، Metric بد را به بخش‌های تشکیل‌دهنده و سپس Owner نگاشت کنید.

LCP = TTFB + resource load delay + resource load duration + render delay
INP = input delay + processing duration + presentation delay
CLS = مجموع shiftهای غیرمنتظره در session windowهای تعریف‌شده

اگر TTFB سهم اصلی LCP است و Server دست Platform است، فشرده‌سازی دوباره Hero مشکل را کامل حل نمی‌کند. اگر LCP resource دیر در HTML کشف می‌شود، CDN سریع نیز Delay کشف را جبران نمی‌کند.

تصویر را بر Slot و Priority بهینه کنید

برای هر Slot، عرض/ارتفاع نمایشی، DPR، Crop، نوع محتوا، Quality و فرمت را مشخص کنید. Responsive variants و srcset/sizes اجازه می‌دهند Browser فایل متناسب بگیرد. AVIF/WebP/JPEG/PNG را با Quality دیداری و پشتیبانی واقعی Pipeline انتخاب کنید؛ یک فرمت برای همه تصاویر بهترین نیست.

Hero یا LCP image را Lazy نکنید

راهنمای رسمی تصاویر Responsive در web.dev پیشنهاد می‌کند تصویر مهم بالای صفحه Lazy نشود و در صورت نیاز واقعی از fetchpriority="high" استفاده شود. این Priority را روی چند تصویر پخش نکنید؛ بالا بردن اولویت یک Resource، منابع دیگر را عقب می‌اندازد.

تصاویر زیر Fold را Lazy کنید

برای تصاویر و iframeهای پایین صفحه، Lazy loading بومی Browser می‌تواند دانلود غیرلازم را کم کند. در img عرض و ارتفاع یا Aspect ratio مشخص کنید تا Layout پیش از دریافت فایل فضا رزرو کند و CLS نسازد.

<img
  src="product-800.webp"
  srcset="product-400.webp 400w, product-800.webp 800w"
  sizes="(max-width: 600px) 100vw, 50vw"
  width="800" height="600"
  loading="lazy"
  alt="نمای روبه‌روی محصول">

در سایت‌ساز ممکن است HTML تولیدشده قابل ویرایش نباشد. خروجی واقعی را Inspect کنید؛ صرف انتخاب WebP در پنل تضمین نمی‌کند Variant، Dimension و Priority درست تولید شده‌اند. برای Strategy تصویر و ویدئو، راهنمای رسانه وب را ببینید.

ویدئو و Embed را با Facade مدیریت کنید

ویدئوی Autoplay و iframe پخش‌کننده می‌توانند Network، CPU، Cookie و Layout را تحت فشار بگذارند. Poster سبک، Click-to-load facade، ابعاد ثابت و Transcript را در نظر بگیرید. ویدئوی Background را روی موبایل یا Reduced data/motion حذف یا جایگزین کنید.

اپ‌ها و اسکریپت‌های ثالث را Inventory کنید

Chat، Heatmap، A/B، Review، Personalization، Ads و Tag manager هرکدام Request، JavaScript و Main-thread work می‌آورند. نام App، Owner، Purpose، Page scope، Load trigger، Consent، Data destination، وزن، CPU، Error و Renewal را ثبت کنید.

بارگذاری async یا defer به‌تنهایی CPU cost را حذف نمی‌کند و تغییر دلخواه Attribute ممکن است App را بشکند. قبل/بعد را در Build و Journey واقعی تست کنید.

INP را از Interaction واقعی عیب‌یابی کنید

Lighthouse نمی‌تواند INP Field را بدون تعامل واقعی کامل اندازه بگیرد و معمولاً TBT را به‌عنوان Diagnostic نشان می‌دهد. طبق راهنمای Web Vitals، INP یک Field metric است. تعامل کند را با Element، Event، URL، Device و Long task ثبت کنید.

• Menu، Filter، Variant selector، Add-to-cart و Checkout را دستی Trace کنید.
• Long task را به Script/Third party/Component نسبت دهید.
• DOM بزرگ، Re-render، Synchronous storage و Layout thrash را بررسی کنید.
• Work را کوچک و Yield کنید؛ Feedback اولیه را زود نمایش دهید.

برای Profiling، Performance budget و امنیت زنجیره Script، راهنمای بهینه‌سازی اپلیکیشن JavaScript جزئیات فنی بیشتری دارد.

CLS را با رزرو فضا و State ثابت کم کنید

برای Image، Video، Ad، Banner، Review و App block اندازه یا حداقل فضا رزرو کنید. Banner رضایت یا تخفیف را بالای محتوا Inject نکنید مگر Layout از ابتدا جا داشته باشد. پیام خطا و Stock status نیز نباید صفحه را بی‌برنامه جابه‌جا کنند.

CLS Lab بیشتر Load shift را می‌بیند؛ Shift پس از Scroll یا Interaction ممکن است فقط در Field/RUM آشکار شود. تغییر Font و App را روی Session طولانی تست کنید.

فونت فارسی را مثل Dependency مدیریت کنید

هر خانواده، Weight و Style فایل و زمان Parse/Render دارد. تعداد Weightها را بر نیاز واقعی محدود کنید، WOFF2 و Subset مجاز را بسنجید، Fallback نزدیک به متریک فونت اصلی انتخاب کنید و رفتار font-display را با Brand/CLS/خوانایی آزمایش کنید.

Self-host همیشه ممکن یا بهتر نیست؛ License، CORS، Cache، CDN و دسترسی کاربر ایرانی مهم‌اند. راهنمای بهینه‌سازی فونت وب از Discovery و Preload تا CLS، RUM و Rollback را پوشش می‌دهد.

Theme را با خروجی نهایی ارزیابی کنید

Demo ممکن است محتوا، App، Tracking و Location متفاوتی داشته باشد. یک صفحه نماینده با تصاویر، فونت، Header، Product card، Variant، Review و Footer واقعی بسازید. تعداد DOM node، CSS/JS، Long task، LCP resource و Componentهای مخفی را مقایسه کنید.

زیبایی پرهزینه را به Outcome وصل کنید

Slider، Parallax، Video background، Animation و Mega menu را با فرضیه روشن نگه دارید. اگر به Task یا Brand outcome کمک نمی‌کند، حذف آن ساده‌ترین بهینه‌سازی است. Motion را برای Reduced motion و Device ضعیف نیز بررسی کنید.

CSS و Layout را بدون شکستن Builder سبک کنید

Sectionهای تکراری، Spacerهای زیاد، Nested columns و Global styleهای متعارض DOM/CSS را بزرگ می‌کنند. Componentهای بومی و Style token را جای Inline overrideهای انباشته استفاده کنید. تزریق Critical CSS یا حذف خودکار Unused CSS در محیط بسته می‌تواند Stateهای پویا را بشکند؛ با Coverage و Visual regression تست کنید.

Cache و CDN را اندازه‌گیری کنید، فرض نگیرید

CDN می‌تواند Latency و بار Origin را کم کند، اما HTML شخصی، Cart، Cookie، Query و Purge rule نیاز قرارداد دقیق دارند. هدرهای Cache-Control، Age، Vary و Hit/Miss را روی خروجی واقعی ببینید. CDN دوگانه یا Proxy اضافه ممکن است TLS/DNS/Cache invalidation را پیچیده کند.

برای سایت ایرانی، چند ISP و Location را تست کنید؛ «نزدیک‌ترین PoP» روی نقشه تضمین Route بهتر نیست. اگر Platform CDN را قفل کرده، ابتدا Support evidence و Domain/DNS constraint را بررسی کنید. برای Cache key، Origin shield، Purge و Failure، راهنمای CDN پیشرفته مرجع تخصصی است.

TTFB کند را تا مرز کنترل شما دنبال کنید

Redirect، DNS/TLS، Edge miss، Platform queue، Server render، App proxy و API می‌توانند TTFB را افزایش دهند. با Waterfall و Server-Timing اگر موجود است، سهم‌ها را جدا کنید. اگر Bottleneck در Platform است، Evidence شامل URL، زمان، Region، Cache state و Trace را به Support بدهید؛ نصب افزونه تصویر مشکل Server queue را رفع نمی‌کند.

فروشگاه: سرعت را با صحت سفارش معامله نکنید

Cart، قیمت، موجودی، Promotion، Shipping و Payment State باید Correct بمانند. Cacheکردن HTML شخصی یا Delayکردن Script حیاتی ممکن است Conversion را ظاهراً بهتر و سفارش را خراب کند. هر بهینه‌سازی در Product→Cart→Checkout→Return-from-gateway تست End-to-end می‌خواهد.

• Variant selector و Add-to-cart را برای INP و خطا تست کنید.
• Widget Review/Recommendation را Scope و Lazy کنید.
• Payment redirect، Callback و وضعیت نامشخص را خراب نکنید.
• Analytics را طوری کم نکنید که Reconciliation غیرممکن شود.

RTL، فارسی و کاربران ایران را در ماتریس تست بگذارید

فونت فارسی، آیکون جهت‌دار، ترکیب عدد/لاتین، ورودی شبا/موبایل، صفحه پرداخت و Chat فارسی می‌توانند Resource و Layout متفاوت بسازند. روی Device میان‌رده و ضعیف، چند ISP، Cache سرد و ساعات شلوغ تست کنید. RUM را بر Device/Network/Page type/Release بخش‌بندی کنید؛ میانگین کل Tail کاربران را پنهان می‌کند.

Performance Budget برای هر Template بسازید

Budget فقط Threshold CWV نیست. برای Resource و Complexity نیز حد بگذارید و افزایش را نیازمند Justification کنید.

عدد Budget را از Baseline، کاربران و هدف محصول تعیین کنید؛ آن را نسخه‌ای ثابت برای همه سایت‌ها ندانید.

چرخه بهینه‌سازی: Measure، Diagnose، Change، Verify

1. Measure: Field/RUM، Lab و Business outcome.
2. Segment: Page type، Device، Network، Country/ISP و Release.
3. Diagnose: Waterfall/Trace/Element/Script/Owner.
4. Hypothesis: تغییر، اثر هدف و Guardrail.
5. Change: کوچک، قابل Rollback و ترجیحاً یک متغیر.
6. Verify: Lab فوری، RUM/Cohort پس از حجم کافی و Error.
7. Standardize: Budget، Template و Editorial checklist.

تغییر App یا قالب را Canary کنید

اگر سایت‌ساز Preview، Duplicate theme یا درصد انتشار دارد، تغییر را روی نماینده Page type و سپس بخشی از ترافیک/زمان کم‌ریسک اجرا کنید. Screenshot، Metric، Error، Conversion guardrail و Rollback instruction را ثبت کنید. Update خودکار App/Theme نیز باید Regression monitor داشته باشد.

چه زمانی محدودیت پلتفرم مسئله اصلی است؟

پس از حذف/Scope App، اصلاح Media/Font/Theme و اثبات Bottleneck Platform، گزینه‌ها را مقایسه کنید: Plan/feature دیگر، پلتفرم دیگر، Headless/Custom یا پذیرش Risk. یک Audit منفرد دلیل مهاجرت نیست.

راهنمای مقیاس‌پذیری سایت‌ساز Workload، Quota، TCO، Pilot و Exit را برای این تصمیم پوشش می‌دهد.

برنامه ۳۰روزه بهینه‌سازی سایت‌ساز

1. روز ۱ تا ۵: Page inventory، RUM/CrUX، Lab matrix و Owner map.
2. روز ۶ تا ۱۰: App/Tag/Font/Media inventory و Quick wins کم‌ریسک.
3. روز ۱۱ تا ۲۰: اصلاح LCP/INP/CLS در دو Template پرترافیک.
4. روز ۲۱ تا ۲۵: Checkout/RTL/ISP/Consent/Cache regression QA.
5. روز ۲۶ تا ۳۰: Field cohort، Budget، Release gate و Platform escalation.

اشتباه‌های رایج در افزایش سرعت سایت‌ساز

• تعقیب امتیاز ۱۰۰: Field، Task و Business guardrail را محور کنید.
• FID در گزارش جدید: معیار فعلی پاسخ‌گویی INP است.
• Lazy برای همه تصاویر: LCP image را دیر نکنید.
• Preload و High priority زیاد: رقابت Resource می‌سازد.
• CDN دوم بدون قرارداد: Cache/DNS/TLS و Purge را پیچیده می‌کند.
• حذف Script کور: Checkout، Consent و Analytics حیاتی را تست کنید.
• تست فقط Home/Desktop: Template/State/Mobile/ISP را نمونه بگیرید.
• مهاجرت پیش از Evidence: Owner، Bottleneck، TCO و Exit را اثبات کنید.

چک‌لیست نهایی عملکرد سایت‌ساز

• Page type، Journey، Segment، Metric، Budget و Owner تعریف شده‌اند.
• Field و Lab جدا تفسیر و Mobile p75 بررسی شده است.
• LCP element و سهم TTFB/load-delay/duration/render معلوم است.
• تعامل‌های واقعی INP به Script/Component نسبت داده شده‌اند.
• برای Media/Widget/Font فضا رزرو و CLS پس از تعامل سنجیده شده است.
• Hero Responsive است و بی‌دلیل Lazy نیست؛ تصاویر پایین صفحه Lazy هستند.
• App/Tagها Purpose، Scope، Owner و هزینه CPU/Network دارند.
• فونت فارسی، RTL، Device ضعیف و چند ISP تست شده‌اند.
• Cache/CDN با Header و Hit/Miss بررسی شده، نه با فرض.
• Product→Checkout، Consent و Analytics پس از تغییر سالم‌اند.
• Budget و Regression gate برای App/Theme/Content برقرار است.
• محدودیت Platform با Evidence، TCO و Pilot تصمیم‌گیری می‌شود.

جمع‌بندی: در سایت‌ساز، همه لایه‌ها قابل تغییر نیستند؛ اما تقریباً همیشه می‌توان علت را دقیق‌تر از «پلتفرم کند است» پیدا کرد. Field data را بر Page type و کاربران ایران ببینید، Bottleneck را به Owner وصل کنید، تغییر کوچک و قابل Rollback بدهید و سپس اثر را در Journey واقعی بسنجید. اگر پس از اصلاح لایه‌های تحت کنترل، Platform مانع SLO باقی ماند، آن‌گاه Upgrade یا Migration یک تصمیم مبتنی بر Evidence است.

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

آیا سایت‌ساز برای Core Web Vitals مناسب است؟

بستگی به خروجی Platform، قالب، App، محتوا و مخاطب دارد. با یک سایت واقعی و Page typeهای نماینده، LCP/INP/CLS Field و محدودیت کنترل را در Pilot بسنجید؛ Demo یا نام برند پاسخ قطعی نمی‌دهد.

مهم‌ترین کار برای افزایش سرعت سایت‌ساز چیست؟

مهم‌ترین اقدام جهانی وجود ندارد. ابتدا Metric و Bottleneck را پیدا کنید. برای یک سایت Hero بزرگ مشکل است، برای دیگری Third-party JavaScript و INP، و برای سومی TTFB قفل‌شده Platform. اولویت را از Field impact و Owner بگیرید.

آیا باید تصویر LCP را Lazy load کنیم؟

معمولاً خیر. تصویر اصلی بالای صفحه باید زود قابل کشف باشد؛ Lazy loading می‌تواند درخواست آن را عقب بیندازد. Responsive source، ابعاد، Quality و در صورت نیاز محدود fetchpriority="high" را تست کنید.

چرا PageSpeed Lab سبز ولی Core Web Vitals ضعیف است؟

Lab یک اجرای شبیه‌سازی‌شده است؛ Field تجربه کاربران واقعی در Device، Network، State و زمان‌های گوناگون را جمع می‌کند. تعامل‌های INP، Shift پس از Load یا Segment موبایل ضعیف ممکن است در اجرای Lab دیده نشوند.

چه زمانی برای سرعت از سایت‌ساز مهاجرت کنیم؟

وقتی Bottleneck Platform با Field/Trace و Support evidence ثابت شده، اهرم‌های محتوا/قالب/App جواب نداده‌اند و گزینه جایگزین در Pilot با TCO، ریسک، SEO، عملیات و Exit بهتر است. یک امتیاز ضعیف به‌تنهایی دلیل مهاجرت نیست.