چطور سرعت لود سایت را در طراحی جدید بهینه کنیم؟

بهینه‌سازی سرعت سایت فقط به معنی گرفتن امتیاز بالاتر در PageSpeed Insights نیست. ممکن است یک صفحه در تست آزمایشگاهی Score مناسبی داشته باشد اما بخشی از کاربران واقعی همچنان روی موبایل، اینترنت ضعیف‌تر یا دستگاه‌های میان‌رده تجربه کندی داشته باشند.

از طرف دیگر، پایین بودن یک Score نیز به این معنی نیست که باید تمام تصاویر، Trackingها، انیمیشن‌ها و قابلیت‌های سایت را حذف کنیم. هدف Performance ایجاد تعادل میان سرعت، تجربه کاربر و قابلیت‌های واقعی سایت است.

برای همین بهتر است به جای جستجوی «یک افزونه افزایش سرعت» یا تعویض فوری Hosting، ابتدا بفهمیم Bottleneck اصلی کجاست.

مسیر منطقی بررسی معمولاً این است:

اندازه‌گیری → تشخیص Bottleneck → اولویت‌بندی → اصلاح → تست مجدد

اگر Performance از همان مرحله طراحی و توسعه سایت در معماری صفحات، تصاویر، Componentها و سرویس‌های جانبی دیده شود، معمولاً کنترل آن بسیار ساده‌تر از زمانی است که بعد از تکمیل پروژه بخواهیم یک صفحه سنگین را با اصلاحات پراکنده سریع کنیم.

سرعت سایت را با تجربه واقعی کاربر بسنجید، نه فقط یک Score

برای ارزیابی Performance باید دو نوع داده را از یکدیگر جدا کنیم: Lab Data و Field Data.

Lab Data برای پیدا کردن مشکل مناسب است

Lab Data در یک محیط کنترل‌شده و با شرایط مشخص دستگاه و شبکه تولید می‌شود. ابزارهایی مانند Lighthouse از این مدل برای تحلیل صفحه و پیدا کردن مشکلات فنی استفاده می‌کنند.

مزیت آن این است که می‌توانید چند بار یک شرایط تقریباً مشابه را تکرار کنید و اثر تغییرات را مقایسه کنید. به همین دلیل Lab Data برای Debugging بسیار مفید است.

اما یک تست آزمایشگاهی نماینده همه کاربران سایت نیست.

Field Data تجربه کاربران واقعی را نشان می‌دهد

Field Data از تجربه واقعی کاربران در دستگاه‌ها، شبکه‌ها و شرایط مختلف به دست می‌آید.

ممکن است لپ‌تاپ توسعه‌دهنده با اینترنت سریع صفحه را بدون مشکل نمایش دهد اما کاربری با موبایل ضعیف‌تر، CPU محدودتر و شبکه موبایل تجربه متفاوتی داشته باشد.

به همین دلیل یک نتیجه منفرد PageSpeed Insights نباید مبنای تمام تصمیم‌های Performance باشد. بهتر است Lab Data را برای تشخیص و Field Data را برای درک تجربه واقعی کاربران کنار هم ببینید.

Core Web Vitals چه چیزی را اندازه‌گیری می‌کنند؟

سه معیار اصلی فعلی Core Web Vitals عبارت‌اند از:

• LCP یا Largest Contentful Paint: سرعت نمایش محتوای اصلی قابل مشاهده صفحه
• INP یا Interaction to Next Paint: پاسخ‌گویی صفحه هنگام تعامل کاربر
• CLS یا Cumulative Layout Shift: پایداری بصری Layout

این سه Metric فقط عدد نیستند؛ هرکدام می‌توانند نشانه نوع متفاوتی از مشکل باشند.

LCP ضعیف معمولاً ما را به کجا هدایت می‌کند؟

اگر بزرگ‌ترین محتوای ابتدای صفحه دیر نمایش داده می‌شود، باید مشخص کنید LCP Element چیست.

در بسیاری از صفحات ممکن است Hero Image، تصویر محصول، Banner یا یک بلوک بزرگ متن باشد.

مشکلاتی که می‌توانند LCP را تحت تأثیر قرار دهند شامل این موارد هستند:

• Hero Image بسیار سنگین
• Server Response کند
• Render-blocking CSS
• منابعی که دیر کشف می‌شوند
• Fontهای ضروری که دیر بارگذاری می‌شوند
• JavaScriptی که نمایش محتوای اصلی را به تأخیر می‌اندازد

یکی از اشتباهات مهم این است که تصویر اصلی بالای صفحه را نیز مانند تصاویر پایین صفحه Lazy Load کنیم. اگر همان تصویر LCP باشد، به تعویق انداختن درخواست آن می‌تواند نمایش محتوای اصلی را کندتر کند.

INP ضعیف یعنی صفحه فقط «لود» نشده؛ کند پاسخ می‌دهد

ممکن است صفحه ظاهراً باز شده باشد اما وقتی کاربر روی Menu، Filter، Button یا Form کلیک می‌کند، واکنش سایت با تأخیر انجام شود.

در چنین حالتی باید بیشتر به مواردی مانند این نگاه کرد:

• JavaScript سنگین
• Event Handlerهای پرهزینه
• Main Thread شلوغ
• Componentهای پیچیده
• Third-party Scriptها

این موضوع به‌خصوص در فروشگاه‌ها، Dashboardها و صفحاتی که Interaction زیادی دارند مهم است.

CLS ضعیف یعنی صفحه زیر دست کاربر جابه‌جا می‌شود

فرض کنید کاربر می‌خواهد روی یک دکمه کلیک کند اما در همان لحظه Banner یا تصویر دیگری لود می‌شود و دکمه جابه‌جا می‌شود.

دلایل رایج Layout Shift می‌توانند شامل موارد زیر باشند:

• تصاویر بدون Width و Height مشخص
• Bannerهایی که بعداً وارد صفحه می‌شوند
• Font و تغییر ابعاد متن هنگام Load
• تبلیغات با فضای رزروشده نامناسب
• Widgetها یا عناصر Inject شده بعد از Load

بهینه‌سازی این موارد بخشی از کیفیت فنی و همچنین تجربه کاربری و طراحی UI/UX است؛ چون Performance فقط مسئله Backend یا Server نیست.

چطور علت واقعی کندی سایت را پیدا کنیم؟

قبل از اصلاح، مشخص کنید دقیقاً کدام صفحه و کدام مرحله تجربه کاربر مشکل دارد.

این Workflow می‌تواند نقطه شروع مناسبی باشد:

۱. صفحات مشکل‌دار را مشخص کنید

به جای تست تصادفی Homepage، صفحات مهم کسب‌وکار را جداگانه بررسی کنید.

مثلاً:

• صفحه اصلی
• Landing Page اصلی
• صفحه خدمات
• Product Page
• Category
• Cart و Checkout
• فرم درخواست یا رزرو

ممکن است Homepage سریع باشد اما Product Page یا Checkout مشکل جدی داشته باشد.

۲. Mobile و Desktop را جدا بررسی کنید

Performance روی Desktop قوی الزاماً به معنی تجربه مناسب روی Mobile نیست.

قدرت پردازشی، اندازه نمایشگر، کیفیت شبکه و نوع Interaction متفاوت هستند و باید صفحات مهم روی دستگاه واقعی نیز تست شوند.

۳. مشخص کنید مشکل LCP، INP یا CLS است

اگر محتوای اصلی دیر ظاهر می‌شود، مسیر عیب‌یابی با زمانی که صفحه هنگام کلیک Freeze می‌شود متفاوت است.

Metric باید شما را به سمت سؤال درست هدایت کند؛ نه اینکه صرفاً عدد آن را سبز کنید.

۴. Resourceهای اصلی صفحه را بررسی کنید

تصاویر، Fontها، CSS، JavaScript و درخواست‌های شبکه را بررسی کنید.

گاهی یک فایل بزرگ به‌وضوح Bottleneck است و گاهی مشکل از ده‌ها Resource کوچک و Scriptهایی ایجاد می‌شود که Main Thread را مشغول نگه می‌دارند.

۵. Third-party Scriptها را جدا کنید

ببینید چه منابعی از سرویس‌های خارجی وارد صفحه می‌شوند و کدام‌یک واقعاً لازم هستند.

۶. Server و Cache را بررسی کنید

اگر HTML اولیه دیر دریافت می‌شود، فقط به Front-end نگاه نکنید. Hosting، Application، Database و Cache نیز باید بررسی شوند.

۷. اصلاحات پراثر را اول انجام دهید

یک Hero پنج مگابایتی روی Landing Page اصلی احتمالاً اولویت بیشتری از Warning جزئی مربوط به چند خط CSS دارد.

۸. بعد از هر تغییر دوباره اندازه‌گیری کنید

Optimization بدون Measurement می‌تواند مشکل جدیدی ایجاد کند.

ممکن است Defer کردن یک Script عدد Performance را بهتر کند اما Form یا Tracking سایت دیگر درست کار نکند.

تصاویر، Font، JavaScript و Third-party Scriptها را هدفمند بهینه کنید

تصاویر؛ یکی از اولین نقاطی که باید بررسی شوند

در بسیاری از سایت‌ها تصاویر بخش قابل توجهی از حجم صفحه را تشکیل می‌دهند، اما راه‌حل فقط تبدیل تمام تصاویر به یک فرمت جدید نیست.

ابتدا اندازه‌ای که واقعاً در صفحه نمایش داده می‌شود را در نظر بگیرید.

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

موارد مهم عبارت‌اند از:

• استفاده از ابعاد متناسب با محل نمایش
• Compression بدون تخریب محسوس کیفیت
• انتخاب فرمت مناسب برای نوع تصویر
• استفاده از Responsive Images در صورت نیاز
• مشخص کردن Width و Height
• Lazy Loading تصاویر خارج از Viewport

اما قانون «همه تصاویر را Lazy Load کنید» درست نیست.

تصویر Hero یا تصویری که احتمالاً LCP صفحه است باید در زمان مناسب و با Priority کافی بارگذاری شود، نه اینکه صرفاً برای گرفتن یک Recommendation کمتر در ابزار، درخواست آن عقب بیفتد.

Fontها را کنترل کنید

Typography بخش مهمی از طراحی است، اما هر Font Family و Weight یک Resource دیگر به صفحه اضافه می‌کند.

اگر Design System فقط به Regular، Medium و Bold نیاز دارد، بارگذاری تعداد زیادی Weight که هیچ‌جا استفاده نمی‌شوند هزینه غیرضروری ایجاد می‌کند.

مواردی که ارزش بررسی دارند:

• تعداد Font Familyها
• Weightهای واقعاً موردنیاز
• حذف فایل‌های استفاده‌نشده
• استفاده از Local Font در صورت مناسب بودن
• Loading Strategy
• Fallback مناسب برای کاهش Layout Shift

هدف حذف هویت بصری سایت نیست؛ هدف این است که Fontهای موردنیاز را با هزینه منطقی ارائه کنیم.

مشکل JavaScript فقط اندازه فایل نیست

دو فایل JavaScript با حجم مشابه الزاماً تأثیر یکسانی روی Performance ندارند.

باید ببینیم Browser برای Parse و Execute کردن کد چقدر کار انجام می‌دهد و Main Thread تا چه حد مشغول می‌شود.

مواردی مانند این‌ها می‌توانند اثرگذار باشند:

• JavaScript غیرضروری
• کد استفاده‌نشده روی همان صفحه
• Event Handlerهای سنگین
• Componentهایی که Render پرهزینه دارند
• Scriptهای Render-blocking
• Dependencyهای بزرگ برای قابلیت بسیار کوچک

در CSS نیز مسئله فقط Minify کردن نیست. Styleهای بزرگ، منابع Render-blocking و CSSهایی که برای صفحه فعلی ضروری نیستند می‌توانند در مسیر نمایش محتوا اثر بگذارند.

Third-party Scriptها را مانند یک هزینه Performance ببینید

بسیاری از سایت‌ها در روز اول سریع هستند اما بعد از چند ماه به‌تدریج کند می‌شوند.

دلیل ممکن است اضافه شدن سرویس‌هایی مانند این باشد:

• Analytics
• Tag Manager
• Chat Widget
• Heatmap
• Advertising Scripts
• Marketing Pixelها
• Social Widgetها
• Video Embedها
• A/B Testing Tools

هر سرویس جانبی می‌تواند Request، JavaScript و Main Thread Work بیشتری ایجاد کند.

فرض کنید سایت هنگام Launch سرعت مناسبی داشته، اما بعداً Chat Widget، چند Tag تبلیغاتی، Heatmap، Pixel و دو Plugin بازاریابی به آن اضافه شده‌اند.

اگر امروز صفحه کند شده، منطقی نیست بدون بررسی همه تقصیر را به Theme یا Hosting نسبت دهیم.

باید Timeline تغییرات را ببینیم و اثر هر Resource را اندازه‌گیری کنیم.

قابلیت مفید را فقط برای Score بالاتر حذف نکنید

هدف Performance این نیست که سایت را از تمام قابلیت‌هایش خالی کنیم.

مثلاً اگر Chat آنلاین برای کسب‌وکار Lead واقعی ایجاد می‌کند اما روی Performance اثر دارد، ابتدا بررسی کنید آیا می‌توان Load آن را تا بعد از محتوای اصلی به تأخیر انداخت، فقط در صفحات ضروری فعال کرد یا روش سبک‌تری برای پیاده‌سازی آن پیدا کرد.

حذف فوری آن فقط برای افزایش Score ممکن است از دید تجاری تصمیم اشتباهی باشد.

همین منطق درباره Analytics، Tracking، ابزارهای اعتمادسازی و Featureهای ضروری UX نیز وجود دارد.

هدف، Balance بین Functionality، Experience و Performance است.

Hosting، Cache، CDN و تکنولوژی سایت چه نقشی دارند؟

Hosting مهم است، اما همیشه مقصر نیست

اگر Server برای پاسخ دادن به درخواست زمان زیادی نیاز داشته باشد، Front-end نیز نمی‌تواند تمام مشکل را جبران کند.

در بررسی زیرساخت می‌توان به مواردی مانند این توجه کرد:

• Server Response
• CPU و Memory در شرایط واقعی
• Database در سایت‌های Dynamic
• Application Cache
• موقعیت جغرافیایی زیرساخت
• معماری سرویس

اما ارتقای Hosting زمانی که صفحه دارای تصاویر بسیار سنگین و چند مگابایت JavaScript است، لزوماً Bottleneck اصلی را از بین نمی‌برد.

Cache را در چند لایه ببینید

Cache کمک می‌کند اطلاعاتی که لازم نیست در هر درخواست دوباره تولید یا دانلود شوند، سریع‌تر در دسترس قرار بگیرند.

در سطح ساده می‌توان سه نوع رایج را از هم جدا کرد:

• Browser Cache: Resourceهایی مانند تصاویر، CSS و JavaScript برای استفاده مجدد در Browser ذخیره می‌شوند.
• Page Cache: خروجی آماده صفحه نگهداری می‌شود تا برای هر درخواست دوباره از ابتدا ساخته نشود.
• Object Cache: بعضی نتایج و داده‌های پرتکرار Application یا Database برای استفاده مجدد ذخیره می‌شوند.

هر پروژه الزاماً به همه این لایه‌ها نیاز ندارد. نوع Cache باید با معماری و ماهیت Dynamic سایت هماهنگ باشد.

CDN درمان همه مشکلات Performance نیست

CDN می‌تواند Resourceها را از Location مناسب‌تر به کاربر ارائه دهد و در بعضی معماری‌ها بار روی Origin را کاهش دهد.

اما اگر صفحه JavaScript سنگین دارد، تصویر چند مگابایتی ارسال می‌کند یا Main Thread برای مدت طولانی Block می‌شود، CDN به‌تنهایی این مشکلات را حل نمی‌کند.

CDN یک ابزار در معماری Performance است، نه نسخه عمومی برای هر سایت کند.

WordPress ذاتاً کند نیست و Custom هم ذاتاً سریع نیست

Performance یک سایت WordPress می‌تواند تحت تأثیر Theme، Page Builder، Pluginها، Database Query، تصاویر، Fontها، Hosting و Third-party Scriptها باشد.

یک WordPress تمیز و درست اجراشده می‌تواند تجربه بسیار مناسبی داشته باشد.

از طرف دیگر Custom Development نیز اگر JavaScript سنگین، Queryهای نامناسب، API کند یا معماری ضعیف داشته باشد می‌تواند Performance بدی ایجاد کند.

بنابراین انتخاب تکنولوژی را نباید صرفاً با ادعای «سرعت» انجام داد. در مقایسه WordPress و توسعه اختصاصی این موضوع باید در کنار Scope، نگهداری، قابلیت‌ها و معماری آینده بررسی شود.

Mobile Performance، SEO و Conversion را در Context واقعی بررسی کنید

نسخه موبایل فقط Desktop کوچک‌شده نیست

ممکن است یک Hero، Slider یا Animation روی مانیتور بزرگ تجربه مناسبی ایجاد کند اما روی موبایل هزینه زیادی داشته باشد.

در Mobile باید مواردی مانند این‌ها را جداگانه بررسی کنید:

• ابعاد و حجم تصاویر
• Sliderها و Animationها
• Menu
• Formها
• Chat Widget
• Sticky Elementها
• Network Condition
• Touch Interaction

حتماً مسیر واقعی کاربر را روی موبایل طی کنید، نه اینکه فقط عرض Browser دسکتاپ را کوچک کنید.

مثلاً در یک Landing Page باید Hero، CTA و Form روی موبایل سریع و قابل استفاده باشند. رابطه طراحی صفحه فرود و Performance را می‌توان در راهنمای طراحی Landing Page و بهینه‌سازی مسیر تبدیل دقیق‌تر دید.

سرعت و SEO چه ارتباطی دارند؟

Performance و Core Web Vitals بخشی از کیفیت تجربه صفحه هستند، اما نباید این نتیجه را گرفت که «اگر سرعت سایت را بالا ببریم، رتبه Google حتماً افزایش پیدا می‌کند».

SEO به عوامل بسیار بیشتری وابسته است:

• Search Intent
• کیفیت محتوا
• Crawl و Index
• Internal Linking
• معماری سایت
• اعتبار و ارتباط موضوعی

ممکن است صفحه Performance بسیار خوبی داشته باشد اما noindex باشد یا محتوای آن Search Intent را پاسخ ندهد.

برای همین Performance باید در کنار سایر لایه‌های Technical SEO و زیرساخت فنی سایت بررسی شود.

سرعت و Conversion چه ارتباطی دارند؟

بدون ارائه درصدهای عمومی و ساختگی نیز رابطه عملی سرعت و Conversion قابل درک است.

اگر کاربر برای دیدن Hero یک Landing Page منتظر بماند، Product Page دیر قابل استفاده شود، Filter فروشگاه بعد از Touch پاسخ ندهد، Form هنگام تایپ Freeze کند یا Layout هنگام Checkout جابه‌جا شود، اصطکاک بیشتری در مسیر کاربر ایجاد می‌شود.

اما اگر سایتی Conversion پایینی دارد، نباید خودکار نتیجه بگیریم علت فقط سرعت است.

Traffic نامرتبط، Offer، قیمت، Trust، UX، محتوا و Checkout نیز می‌توانند در Conversion نقش داشته باشند. برای تشخیص مرحله مشکل، چارچوب عیب‌یابی نرخ تبدیل سایت تصویر کامل‌تری ارائه می‌دهد.

اصلاحات Performance را چگونه اولویت‌بندی کنیم؟

یکی از اشتباهات رایج این است که تمام Warningهای ابزارها با اهمیت یکسان دیده شوند.

در عمل بهتر است هر مشکل را حداقل بر اساس چهار معیار بسنجید:

• اثر روی کاربران: آیا واقعاً تجربه را مختل می‌کند؟
• تعداد صفحات: مشکل فقط در یک URL است یا یک Template کامل؟
• اهمیت تجاری: صفحه اصلی خدمت است یا یک صفحه کم‌استفاده؟
• هزینه اصلاح: رفع مشکل چقدر زمان و ریسک دارد؟

مثلاً یک Hero پنج مگابایتی که در تمام Landing Pageهای اصلی استفاده شده احتمالاً ارزش بررسی بیشتری نسبت به Warning کوچک CSS روی یک صفحه کم‌ترافیک دارد.

همچنین اگر یک Script روی تمام صفحات Main Thread را Block می‌کند، ممکن است اصلاح آن اثر گسترده‌تری نسبت به Optimization بسیار جزئی یک Resource داشته باشد.

چک‌لیست Performance قبل از انتشار یا بعد از بازطراحی

• Hero Page بیش از حد سنگین نیست.
• تصاویر با ابعاد متناسب با محل نمایش ارائه می‌شوند.
• تصاویر خارج از Viewport در صورت مناسب بودن Lazy Load می‌شوند.
• تصویر اصلی LCP بی‌دلیل Lazy Load نشده است.
• Width و Height تصاویر مشخص است.
• Font Family و Weightهای غیرضروری حذف شده‌اند.
• Third-party Scriptهای صفحه شناسایی شده‌اند.
• Trackingهای قدیمی یا تکراری وجود ندارند.
• Mobile روی دستگاه و شبکه واقعی تست شده است.
• LCP بررسی شده است.
• INP یا رفتار واقعی Interaction بررسی شده است.
• CLS و Layout Shiftها بررسی شده‌اند.
• Server Response صفحات مهم مناسب است.
• Cache متناسب با معماری سایت کار می‌کند.
• خطای JavaScript بعد از Optimization ایجاد نشده است.
• Menu، Form و CTA بعد از تغییرات سالم هستند.
• Analytics و Conversion Tracking همچنان کار می‌کنند.
• Cart و Checkout در سایت فروشگاهی دوباره تست شده‌اند.
• صفحات مهم پس از اصلاح QA شده‌اند.
• Lab Data و تجربه واقعی کاربران هر دو در تصمیم لحاظ شده‌اند.

سوالات متداول درباره افزایش سرعت سایت

آیا Score صد در PageSpeed Insights لازم است؟

خیر. Score آزمایشگاهی یک ابزار تشخیص و مقایسه است. هدف اصلی باید تجربه مناسب کاربران واقعی و رفع Bottleneckهایی باشد که روی صفحات مهم اثر دارند.

آیا CDN همیشه سایت را سریع می‌کند؟

CDN در شرایط مناسب می‌تواند زمان انتقال Resourceها و بار Origin را کاهش دهد، اما JavaScript سنگین، Main Thread Work، تصویر غیربهینه یا معماری ضعیف را به‌تنهایی اصلاح نمی‌کند.

آیا همه تصاویر را Lazy Load کنیم؟

خیر. Lazy Loading بیشتر برای تصاویری مناسب است که هنگام ورود کاربر خارج از Viewport هستند. تصاویر اصلی بالای صفحه، به‌خصوص LCP Image، معمولاً باید زودتر در دسترس Browser قرار بگیرند.

آیا افزونه‌های زیاد باعث کندی WordPress می‌شوند؟

تعداد افزونه به‌تنهایی معیار دقیقی نیست. کیفیت Plugin، Queryها، JavaScript، CSS و کاری که هر افزونه انجام می‌دهد اهمیت بیشتری دارد. یک Plugin ضعیف می‌تواند بیشتر از چند افزونه سبک روی Performance اثر بگذارد.

آیا تعویض Hosting اولین راه افزایش سرعت است؟

نه همیشه. اگر Server Response مشکل دارد، Hosting یا زیرساخت باید بررسی شود؛ اما اگر Bottleneck اصلی تصاویر، Third-party Script یا JavaScript سنگین باشد، تعویض سرور ممکن است تأثیر محدودی داشته باشد.

Core Web Vitals خوب باعث افزایش قطعی رتبه می‌شود؟

خیر. Performance بخشی از تجربه صفحه است، اما Ranking به مجموعه بسیار بزرگ‌تری از عوامل وابسته است و هیچ وضعیت Core Web Vitals رتبه مشخصی را تضمین نمی‌کند.

چرا PageSpeed موبایل و دسکتاپ متفاوت است؟

شرایط دستگاه و شبکه در تست Mobile متفاوت است و کاربران واقعی نیز ممکن است سخت‌افزار و اتصال ضعیف‌تری داشته باشند. به همین دلیل Mobile Performance باید مستقل بررسی شود.

بعد از Optimization چه چیزی را تست کنیم؟

فقط Score را دوباره اجرا نکنید. Formها، CTA، Navigation، Tracking، Payment، Interactionهای JavaScript و صفحات کلیدی را نیز QA کنید تا Performance بهتر باعث شکستن قابلیت دیگری نشده باشد.

قبل از تعویض Theme یا Hosting، Bottleneck را پیدا کنید

وقتی سایت کند است، واکنش سریع معمولاً تعویض Hosting، نصب Plugin Cache جدید یا حذف چند Feature است. اما بدون تشخیص علت ممکن است زمان زیادی صرف بخشی شود که مشکل اصلی نیست.

در یک پروژه Bottleneck می‌تواند Hero Image باشد، در پروژه دیگر JavaScript و Third-party Scriptها، و در سایت دیگری Server، Database یا معماری صفحه.

اگر کندی بخشی از مشکلات بزرگ‌تر طراحی، Mobile UX یا ساختار فنی سایت است، بهتر است Performance همراه با معماری صفحه در فرآیند طراحی و بازطراحی سایت بررسی شود. اگر مسئله بیشتر به Core Web Vitals، Rendering یا مشکلات فنی مؤثر بر Search مربوط است، بررسی آن در چارچوب سئو و بهینه‌سازی فنی سایت منطقی‌تر خواهد بود.

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