خطای کند شدن شدید سایت وردپرس

کندی سایت، بدترین نوع خطا در وردپرس است. چرا؟ چون هیچ پیام قرمزی نمی دهید، هیچ کد خطایی روی صفحه ظاهر نمی شود، و هیچ چیز در ظاهر «خراب» نیست. سایت شما باز می شود، صفحات لود می شوند، کاربر هم می تواند کارش را انجام دهد — اما همه چیز آهسته است. آهسته تر از آن چه که باید باشد، آهسته تر از رقبا، آهسته تر از چیزی که برای رشد کسب و کارتان لازم است. همین ویژگی، کندی را به یک خطای پنهان تبدیل می کند؛ چون شما متوجه می شوید که ترافیک کم شده، اما نمی دانید چه چیزی باعثش شده.

در سال ها کار روی سایت های وردپرسی، کندی شدید را در ده ها پرونده عیب یابی کرده ام. یک بار مقصر یک افزونه ی بکاپ بود که در ساعات پیک اجرا می شد، یک بار کوئری های بدون pagination در یک افزونه ی قدیمی، یک بار هاست اشتراکی با منابع تمام شده، و بارها ترکیبی از این ها. آن چه همه ی این موارد را به هم وصل می کند، یک نکته ی مشترک است: کندی هرگز از یک عامل واحد نمی آید. کندی، معمولا نتیجه ی تجمعی چند عامل کوچک است که هرکدام به تنهایی قابل تحمل اند، اما در ترکیب، سایت را به زانو در می آورند. در این مقاله، همان مسیری را باز می کنم که در پروژه های واقعی برای تشخیص و رفع این خطا طی می کنم. اگر با ساختار پایه ای وردپرس آشنایی ندارید، ابتدا وردپرس چیست و چگونه شروع کنیم را بخوانید؛ چون درک لایه بندی وردپرس، کلید تشخیص این نوع خطا است.

کندی شدید دقیقا چیست؟

کندی شدید در وردپرس، اصطلاحی کلی برای وضعیتی است که در آن، سایت شما در مقایسه با حالت عادی یا با رقبا، بسیار کندتر از حد قابل قبول لود می شود. اما «کندی» یک مفهوم نسبی است. یک سایت خبری با ترافیک روزانه ی صد هزار بازدید، اگر در ۲ ثانیه لود شود، کند است؛ همان سایت با ترافیک روزانه ی هزار بازدید، در ۲ ثانیه کاملا سریع است. بنابراین، تشخیص کندی همیشه باید در چارچوب زمینه ی خود سایت انجام شود.

در لایه ی فنی، سرعت سایت شما از مجموع چند مرحله ی متوالی می آید: زمان پاسخ سرور (TTFB)، زمان دانلود فایل های استاتیک، زمان پارس و اجرای کدهای JavaScript، و زمان رندر نهایی در مرورگر. هر یک از این مراحل، می تواند منبع کندی باشد. تفاوت بین یک عیب یابی سریع و یک سردرگمی طولانی، نه در دانش فنی، که در داشتن نقشه ی درست برای شناسایی این مراحل است.

نکته ی کلیدی اینجاست: کندی، تقریبا همیشه یک نشانه است، نه یک علت. یعنی وقتی می گویید «سایتم کند است»، در واقع دارید یک علامت را توصیف می کنید؛ اما علت واقعی می تواند در هر یک از ده ها نقطه باشد: از سرور هاست تا قالب، از افزونه ها تا دیتابیس، از تصاویر تا فونت ها. همین ویژگی، تشخیص را دشوار می کند؛ چون کاربر عادی معمولا نمی داند که از کدام نقطه شروع کند.

در تجربه ی خودم، سه نشانه ی مشخص وجود دارد که می گوید سایت شما در وضعیت کندی شدید است: زمان بارگذاری اولیه بیش از ۳ ثانیه، امتیاز PageSpeed کمتر از ۵۰ در موبایل، و نرخ پرش بالای ۷۰٪ در آمار تحلیلی. اگر یکی از این سه نشانه را دارید، این مقاله به شما کمک می کند ریشه را پیدا کنید. مفهوم Core Web Vitals و معیارهای دقیق آن را در Core Web Vitals چیست و چرا گوگل بر آن تاکید دارد به تفصیل باز کرده ام.

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

چرا این خطا فریبنده است؟

کندی شدید، سه ویژگی دارد که آن را از بقیه ی خطاهای وردپرس متمایز می کند:

• سایت در ظاهر سالم است: برخلاف خطای ۵۰۰ یا صفحه ی سفید، سایت شما باز می شود و کار می کند. کاربر عادی ممکن است چند ثانیه صبر کند و بعد کارش را انجام دهد. همین ویژگی، باعث می شود که کندی جدی گرفته نشود، تا زمانی که اثرش در آمار یا فروش ظاهر شود.
• ریشه در چند لایه پخش شده: ممکن است مسئله در هاست، قالب، افزونه، دیتابیس، تصاویر، یا کش باشد. هر لایه، مسیر تشخیص متفاوتی دارد و نگاه تک لایه ای، همیشه گمراه کننده است.
• علت اصلی، اغلب در نتیجه ی تجمعی چند عامل است: در بیش از نیمی از پرونده های خودم، مقصر یک عامل واحد نبود؛ ترکیبی از سه یا چهار عامل کوچک بود که هرکدام به تنهایی قابل تحمل بودند. همین تجمعی بودن، تشخیص را سخت می کند.

همین سه ویژگی باعث می شود که کندی، بیش از هر خطای دیگری وقت کاربران را بگیرد. تجربه ام می گوید داشتن یک نقشه ی لایه ای، تفاوت بین «حل در چند ساعت» و «چند هفته سردرگمی» است. اگر با خطاهای دیگری هم روبه رو هستید، خطای ۵۰۰ وردپرس چیست و چگونه رفع می شود دید جامعی به شما می دهد که در کنار این مقاله می تواند مفید باشد.

آناتومی سرعت در وردپرس

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

1. گام اول — زمان پاسخ سرور (TTFB): زمانی که بین درخواست کاربر و دریافت اولین بایت از سرور طول می کشد. این زمان، وابسته به هاست، PHP، و دیتابیس است. اگر TTFB بالای ۸۰۰ میلی ثانیه باشد، مسئله در این لایه است. تفسیر دقیق TTFB را در تاثیر TTFB بر سرعت بارگذاری صفحه باز کرده ام.
2. گام دوم — دانلود فایل های استاتیک: مرورگر باید CSS، JS، تصاویر و فونت ها را دانلود کند. اگر این فایل ها زیاد یا حجیم باشند، یا اگر مسیر شبکه کند باشد، این گام طول می کشد. راه حل های این لایه در CDN چگونه سرعت سایت را بهبود می دهد آمده است.
3. گام سوم — پارس و اجرای JavaScript: مرورگر باید کدهای JavaScript را پارس و اجرا کند. اگر JS سنگین باشد یا تعداد فایل ها زیاد باشد، این گام به تنهایی می تواند چند ثانیه طول بکشد.
4. گام چهارم — رندر نهایی و نمایش: مرورگر باید CSS را با DOM ترکیب کند و صفحه را نمایش دهد. اگر CSS پیچیده یا DOM عمیق باشد، این گام کند می شود. این همان چیزی است که در معیار LCP سنجیده می شود.
5. گام پنجم — تعامل و پاسخ گویی: بعد از نمایش صفحه، کاربر با آن تعامل می کند. اگر JS سنگین باشد یا main thread مسدود باشد، این تعاملات کند می شوند. این گام در معیار INP سنجیده می شود.

هر کندی، از ترکیب این پنج گام می آید. اگر سایت شما در ظاهر سریع است اما اولین کلیک روی یک دکمه، نیم ثانیه طول می کشد، مسئله در گام پنجم است. اگر TTFB بالا است، مسئله در گام اول. اگر همه چیز کند است، باید بفهمید که کدام گام، بیشترین سهم را دارد. این تشخیص، اولین کار شماست.

گام صفر: قبل از هر اقدامی، عدد بگیرید

بزرگ ترین اشتباهی که در پرونده های کندی دیده ام، این است که کاربر بدون عدد، شروع به تغییر می کند. یک افزونه نصب می کند، یک تنظیم را عوض می کند، یک قالب را تست می کند — و بعد نمی داند که آیا اثر داشته یا نه. راه درست، این است که اول پنج عدد کلیدی را ثبت کنید و بعد هر تغییری را با همان اعداد بسنجید.

پنج عدد کلیدی که در پروژه های خودم ثبت می کنم:

1. TTFB: زمان پاسخ سرور. زیر ۲۰۰ میلی ثانیه عالی، بین ۲۰۰ تا ۸۰۰ قابل قبول، بالای ۸۰۰ مشکل است.
2. LCP: زمان نمایش بزرگ ترین عنصر دیدی. زیر ۲.۵ ثانیه عالی، بین ۲.۵ تا ۴ متوسط، بالای ۴ مشکل است.
3. INP: زمان پاسخ به تعاملات کاربر. زیر ۲۰۰ میلی ثانیه عالی، بین ۲۰۰ تا ۵۰۰ متوسط، بالای ۵۰۰ مشکل است.
4. مجموع بایت های CSS و JS: حجم کل این فایل ها در صفحه. زیر ۳۰۰ کیلوبایت عالی، بین ۳۰۰ تا ۶۰۰ قابل قبول، بالای ۶۰۰ مشکل است.
5. تعداد درخواست ها: تعداد درخواست های HTTP. زیر ۴۰ عالی، بین ۴۰ تا ۷۰ قابل قبول، بالای ۷۰ مشکل است.

این پنج عدد را می توانید از ابزارهای بهترین ابزارهای تست سرعت سایت بگیرید. توصیه می کنم این کار را روی سه الگوی صفحه انجام دهید: خانه، یک نوشته، و یک صفحه ی محصول (اگر فروشگاه دارید). حالا یک تصویر عینی از وضعیت فعلی دارید — این تصویر، مرجع همه ی تصمیم های بعدی شماست.

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

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

خانواده های اصلی کندی که در پروژه ها دیده ام

کندی شدید در وردپرس، در ظاهر دلایل متنوعی دارد اما در عمل، در چند خانواده ی مشخص جا می گیرد. جدول زیر، این خانواده ها را با نشانه هایشان دسته بندی می کند:

در ادامه، هر یک از این خانواده ها را با جزئیات باز می کنم.

هاست و منابع سرور

شایع ترین دلیل کندی شدید، در تجربه ی من، همان هاست است. اگر TTFB شما در همه صفحات بالای ۸۰۰ میلی ثانیه است، و این کندی در ساعات مختلف روز نوسان دارد، احتمال زیادی وجود دارد که مسئله در هاست باشد، نه در کد سایت.

سه نشانه ی مشخص که می گوید هاست مقصر است:

• TTFB نوسانی: صبح خوب، شب بد. این الگو، نشانه ی اشتراک منابع با سایت های دیگر روی همان سرور است.
• کندی نامتقارن: پیشخوان کند، فرانت اند معمولی. این نشانه، معمولا به دیسک و I/O مربوط است.
• خطاهای تصادفی: گاهی خطای ۵۰۳، گاهی خطای ۵۰۸ (Resource Limit)، گاهی صفحه ی سفید موقت. این الگو، نشانه ی فشار منابع است.

تشخیص: از پنل هاست، بخش «Resource Usage» یا «CPU Usage» را ببینید. اگر مصرف شما نزدیک سقف پلن است، مقصر پیدا شده. همچنین، از پشتیبانی هاست بپرسید که آیا سرور شما در چند ساعت اخیر مشکلی داشته یا نه.

رفع: سه مسیر دارید. اول، ارتقای پلن هاست به یک پلن با منابع بیشتر. دوم، مهاجرت به یک هاست با کیفیت تر و منابع بهتر — راهنمای دقیق در هاست چیست و چگونه انتخاب کنیم. سوم، اگر نمی توانید هاست را عوض کنید، با بهینه سازی سمت سایت (کش، حذف افزونه، کاهش کوئری) فشار را کم کنید. موضوع تاثیر هاست بر سرعت را در تاثیر هاست بر سرعت سایت چقدر است به تفصیل باز کرده ام.

قالب سنگین و کدهای اضافه

دومین دلیل شایع، قالب سنگین است. قالب های چندمنظوره، ده ها فایل CSS و JS با خودشان می آورند که نیمی شان اصلا در سایت شما استفاده نمی شوند. هر فایل اضافه، یک درخواست اضافه و یک بایت اضافه است. تجربه ی من می گوید در بیش از نیمی از پرونده های کندی، قالب یکی از سه مقصر اصلی بوده است.

نشانه ی این نوع کندی: تعداد درخواست های استاتیک بالای ۶۰، حجم CSS و JS بالای ۵۰۰ کیلوبایت روی صفحه ی اول، و کندی که در همه صفحات وجود دارد حتی صفحات ساده. چرا؟ چون قالب، در همه صفحات، همه ی فایل هایش را لود می کند.

تشخیص: در DevTools مرورگر، سربرگ Network را باز کنید و صفحه را ریلود کنید. تعداد و حجم فایل های CSS و JS را ببینید. اگر بیش از حد انتظار است، مقصر پیدا شده. همچنین، قالب را به Twenty Twenty-Four تغییر دهید و سرعت را مقایسه کنید — اگر تفاوت چشمگیر بود، مقصر قالب فعلی است.

رفع: سه مسیر دارید. اول، اگر قالب فعلی امکان غیرفعال سازی ماژول ها را دارد، از آن استفاده کنید. دوم، اگر قالب بهینه شدنی نیست، به یک قالب سبک مهاجرت کنید — راهنمای دقیق در قالب وردپرس سبک چیست و چگونه سرعت سایت را افزایش می دهد. سوم، اگر نمی توانید قالب را عوض کنید، با افزونه های کش و بهینه سازی، بخشی از فشار را کم کنید. موضوع دقیق اینکه چرا قالب ها سایت را کند می کنند در چرا بعضی قالب های وردپرس باعث کندی سایت می شوند آمده است.

افزونه های پرمصرف

سومین دلیل، افزونه های پرمصرف است. هر افزونه ی فعال، در هر درخواست، بخشی از CPU را مصرف می کند. اگر تعداد افزونه ها زیاد باشد یا چند افزونه ی سنگین داشته باشید، مصرف پایه ی سایت می تواند از سقف هاست عبور کند — حتی بدون هیچ ترافیک قابل توجه.

نشانه ی این نوع کندی: کندی انتخاب — یعنی صفحات خاصی که ماژول دارند کند تر از بقیه هستند. یا افت محسوس در پیشخوان. یا کندی که بعد از نصب یک افزونه ی جدید ظاهر شد.

تشخیص: روش غیرفعال سازی نیمه ای، سریع ترین راه است. همه ی افزونه ها را غیرفعال کنید و بعد نیمی از آن ها را فعال کنید. اگر کندی برگشت، مسئله در نیمه ی فعال است. روش دقیق این کار در چگونه افزونه مشکل ساز وردپرس را پیدا کنیم آمده است. همچنین، برای درک دقیق مکانیزم اثر هر افزونه بر سرعت، افزونه های وردپرس چگونه روی سرعت سایت اثر می گذارند را ببینید.

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

کوئری های سنگین و دیتابیس

چهارمین دلیل، کوئری های سنگین است. حتی اگر تعداد افزونه ها کم باشد، یک کوئری بد در یک افزونه می تواند فشار زیادی به دیتابیس و CPU وارد کند. این نوع کندی، معمولا در صفحات خاص (مثل آرشیو، صفحه ی محصول، یا صفحه ی جستجو) بیشتر دیده می شود.

نشانه ی این نوع کندی: سایت در صفحات عادی سریع است اما در یک صفحه ی مشخص، TTFB جهش می کند. علت معمول، یک کوئری بدون pagination، یک حلقه ی تودرتو، یا یک کوئری بدون ایندکس است.

تشخیص: افزونه Query Monitor در اینجا بسیار کمک می کند. این افزونه، تعداد و زمان اجرای کوئری ها را در هر صفحه نشان می دهد. اگر در صفحه ای بیش از ۱۰۰ کوئری یا کوئری ای با زمان اجرای بیش از ۱ ثانیه می بینید، مقصر پیدا شده است. برای درک نقش دیتابیس در سرعت، سئو تکنیکال چیست و چرا مهم است را بخوانید.

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

تصاویر بدون بهینه سازی

پنجمین دلیل، در بیش از نیمی از سایت ها، تصاویر هستند. تصاویر بهینه نشده — با ابعاد بزرگ، فرمت قدیمی، و بدون فشرده سازی — می توانند بزرگ ترین بایت های صفحه باشند. من در پروژه های خودم دیده ام که یک تصویر هدر ۳ مگابایتی، به تنهایی LCP سایت را از ۲.۵ به ۶ ثانیه می رساند.

نشانه ی این نوع کندی: LCP بالا، بایت های زیاد در صفحه، و کندی که فقط در صفحات تصویردار دیده می شود.

رفع: تصاویر را با ابزارهای بهینه سازی فشرده کنید. سه حرکت ساده که در پروژه های خودم بسیار اثرگذار بوده: تبدیل به WebP، تعریف ابعاد درست (width و height) برای جلوگیری از CLS، و lazy-load برای تصاویر پایین صفحه (اما نه برای LCP). راهنمای دقیق در سئوی تصاویر برای سئو چیست و چگونه تصاویر سایت را فشرده کنیم آمده است.

نبود یا پیکربندی غلط کش

ششمین دلیل، نبود یا پیکربندی غلط کش است. کش، یکی از ارزان ترین و موثرترین راه های افزایش سرعت است. اگر سایت شما کش ندارد، هر بازدید، یک بار اجرای کامل PHP و دیتابیس است. اگر کش دارید اما پیکربندی غلط است، ممکن است اثر آن نصفه باشد.

نشانه ی این نوع کندی: TTFB بالا برای همه ی کاربران، به خصوص کاربران بدون لاگین. اگر با نصب کش، TTFB به شدت پایین بیاید، مقصر پیدا شده است.

تشخیص: از افزونه های بررسی HIT و MISS در هدر پاسخ استفاده کنید. اگر HIT پایین است، کش درست کار نمی کند. اگر با نصب کش، تفاوتی در TTFB نیست، ممکن است کش به درستی پیکربندی نشده باشد.

رفع: ابتدا یک افزونه ی کش معتبر را نصب کنید. انتخاب دقیق در بهترین افزونه های کش وردپرس برای افزایش سرعت آمده است. سپس تنظیمات آن را بازبینی کنید: کش صفحه فعال باشد، کش مرورگر برای فایل های استاتیک فعال باشد، و صفحات پویا (سبد، تسویه، حساب کاربری) مستثنا شده باشند. برای درک نقش کامل کش در بهینه سازی، بهینه سازی سرعت سایت چیست و چرا مهم است را ببینید.

فایل های CSS و JS اضافه

هفتمین دلیل، فایل های CSS و JS اضافه است. حتی اگر قالب شما سبک باشد، افزونه ها می توانند ده ها فایل اضافه به صفحه تزریق کنند. هر فایل اضافه، یک درخواست اضافه و یک بایت اضافه است. تجربه ی من می گوید در بیش از نیمی از سایت ها، حدود ۳۰ تا ۵۰ درصد از CSS و JS بارگذاری شده، در صفحه ی جاری استفاده نمی شود.

نشانه ی این نوع کندی: تعداد درخواست های بالا، کندی در زمان پارس و اجرای JavaScript، و افت امتیاز PageSpeed به خاطر «Unused CSS» یا «Unused JavaScript».

رفع: سه مسیر دارد. اول، ماژول های بلااستفاده ی افزونه ها را خاموش کنید — بخصوص افزونه هایی که در همه ی صفحات، فایل هایشان را لود می کنند. دوم، از افزونه ای مثل WP Rocket یا Autoptimize برای ترکیب و فشرده سازی فایل ها استفاده کنید. سوم، فایل های غیرضروری را با wp_dequeue_style و wp_dequeue_script در چایلد تم حذف کنید — راهنمای کد سفارشی در چگونه کد سفارشی به وردپرس اضافه کنیم و قالب وردپرس چایلد چیست آمده است.

فونت های فارسی سنگین

هشتمین دلیل، که مخصوص سایت های فارسی است، فونت های سنگین. یک فونت فارسی بدون بهینه سازی، می تواند بیش از ۳۰۰ کیلوبایت حجم داشته باشد. اگر سایت شما دو یا سه فونت مختلف لود می کند، حجم فونت ها می تواند به یک مگابایت برسد. همین فونت ها، بخش بزرگی از LCP را می بلعند.

نشانه ی این کندی: LCP بالا روی صفحات متنی، افت سرعت بعد از نصب یک قالب با فونت پیش فرض، و کندی که فقط در متن ها دیده می شود.

رفع: سه راهکار موثر: اول، تعداد فونت ها را به حداقل کاهش دهید (معمولا دو فونت کافی است: یکی برای تیتر، یکی برای متن). دوم، از فونت های بهینه شده فارسی استفاده کنید — فونت هایی مثل وزیرمتن و ایران سنس، با ساب ست صحیح، حجم کمتری دارند. سوم، با font-display: swap، از نمایش سریع متن با فونت موقت اطمینان حاصل کنید. نکات دقیق RTL در چگونه قالب وردپرس را برای زبان فارسی آماده کنیم آمده است.

سرویس های خارجی کند

نهمین دلیل، سرویس های خارجی کند است. اگر سایت شما از سرویس هایی مثل Google Fonts، Google Analytics، سرویس های CAPTCHA، یا CDN های خارجی استفاده می کند، و اگر دسترسی به این سرویس ها از ایران کند باشد، مرورگر کاربران شما برای دریافت این منابع، تاخیر طولانی را تجربه می کنند. این نوع کندی، به خصوص برای کاربران ایرانی شایع است.

نشانه ی این کندی: تفاوت سرعت بین حالت عادی و حالت VPN، کندی که به نظر می رسد از یک منبع خاص می آید (مثلاً فونت ها یا اسکریپت های analytics).

رفع: منابع را از سرویس های داخلی یا سرور خودتان لود کنید. برای فونت ها، از نسخه ی لوکال استفاده کنید. برای analytics، از سرویس های داخلی یا analytics سمت سرور استفاده کنید. برای CDN، از سرویس هایی که در ایران دسترسی پایدار دارند استفاده کنید. اگر قالب شما به یک سرویس خارجی وابسته است، با یک اسنیپت کوچک می توانید آن را غیرفعال یا جایگزین کنید.

کندی مخصوص موبایل

دهمین دلیل، کندی مخصوص موبایل. گاهی سایت در دسکتاپ سریع است اما در موبایل کند. این اتفاق، معمولا به یکی از سه دلیل رخ می دهد: تصاویر با ابعاد دسکتاپ به موبایل ارسال می شوند، JavaScript سنگین روی main thread دستگاه های ضعیف تر مسدود می شود، یا چیدمان موبایل، در واقع دسکتاپ فشرده شده است بدون بازچینش واقعی.

نشانه ی این کندی: امتیاز PageSpeed در دسکتاپ بالای ۸۰ اما در موبایل زیر ۵۰. تجربه ی کاربران موبایل که می گویند «صفحه طول می کشد تا لود شود».

رفع: سه حرکت موثر. اول، از srcset و sizes برای تصاویر استفاده کنید تا مرورگر نسخه ی مناسب دستگاه را دانلود کند. دوم، JavaScript را با defer یا async بارگذاری کنید. سوم، CSS و DOM را سبک کنید تا رندر روی دستگاه های ضعیف تر سریع تر باشد. راهنمای دقیق در قالب وردپرس ریسپانسیو چیست و چرا اهمیت دارد آمده است.

سرعت در موبایل، سرعت واقعی سایت است. کاربری که با گوشی میان رده و اینترنت متوسط به سایت شما می آید، داور نهایی کیفیت فنی سایت شماست.

روش گام به گام تشخیص

ترتیبی که در پروژه های خودم طی می کنم، از سریع ترین به دقیق ترین است:

1. پنج عدد کلیدی را ثبت کنید. TTFB، LCP، INP، مجموع بایت های CSS و JS، و تعداد درخواست ها. این اعداد، قطب نمای شما هستند.
2. آیا TTFB بالا است؟ اگر بله، مقصر هاست، قالب یا کوئری است. سراغ لایه ی سرور بروید.
3. آیا LCP بالا است؟ اگر بله، مقصر تصویر یا فونت است. سراغ لایه ی منابع بروید.
4. آیا INP بالا است؟ اگر بله، مقصر JavaScript است. سراغ لایه ی JS بروید.
5. آیا تعداد درخواست بالا است؟ اگر بله، مقصر افزونه ها یا قالب است. سراغ لایه ی ماژول ها بروید.
6. آیا کندی فقط در برخی صفحات است؟ اگر بله، مقصر یک کوئری یا یک ماژول خاص است.
7. آیا کندی فقط در موبایل است؟ اگر بله، سراغ بهینه سازی ریسپانسیو بروید.

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

ابزارهای معتبر برای تحلیل سرعت

پنج ابزاری که در پروژه های خودم زیاد استفاده می کنم و در تشخیص کندی نقش کلیدی داشته اند:

یک — PageSpeed Insights: ابزار مرجع برای تحلیل سرعت. گزارش میدانی و آزمایشگاهی می دهد و پیشنهادهای مشخصی برای بهبود دارد. این اولین جایی است که باید ببینید. راهنمای کامل در ابزارهای تست سرعت سایت کدامند آمده است.

دو — GTmetrix: ابزار دیگری که تحلیل عمیق تری از فایل ها و درخواست ها ارائه می دهد. گزارش آبشاری درخواست ها در این ابزار، یکی از دقیق ترین ابزارها برای شناسایی مقصر است.

سه — WebPageTest: ابزار حرفه ای برای تست سرعت از لوکیشن های مختلف. اگر مخاطب سایت شما پراکنده است، این ابزار دقیق ترین اطلاعات را می دهد.

چهار — Chrome DevTools: ابزار داخلی مرورگر برای تحلیل عمیق. سربرگ Performance و سربرگ Network، ابزارهای اصلی شما برای تشخیص دقیق هستند. برای پیدا کردن خطاهای JavaScript، چگونه خطاهای JavaScript را در کنسول مرورگر پیدا کنیم مفید است.

پنج — Query Monitor (افزونه): ابزار داخلی وردپرس برای تحلیل کوئری ها، هوک ها و بارگذاری فایل ها. در بیش از نیمی از پرونده ها، این افزونه، مقصر واقعی را لو می دهد.

رفع امن و راستی آزمایی

بعد از این که ریشه را پیدا و رفع کردید، سه لایه راستی آزمایی انجام دهید تا مطمئن شوید مسئله در ریشه حل شده و برنمی گردد:

1. مقایسه ی پنج عدد کلیدی: بعد از رفع، همان پنج عددی که در گام صفر ثبت کرده بودید، دوباره اندازه بگیرید. اگر بهبود محسوس دیدید، رفع موفق بوده است.
2. تست با ترافیک بالا: اگر مسئله در ترافیک بالا بود، در ساعات اوج دوباره چک کنید که آیا سرعت در محدوده ی مجاز باقی می ماند.
3. تست در موبایل واقعی: با گوشی خودتان، در شبکه ی موبایل، سایت را باز کنید. اگر سرعت قابل قبول بود، رفع موفق بوده است.

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

اشتباهات رایج در مواجهه با کندی

یک اشتباه ظریف که در دیدگاه ها زیاد می بینم: کاربران با دیدن کندی، فورا یک افزونه ی بهینه سازی جدید نصب می کنند. اما در بیش از نیمی از موارد، افزونه ی جدید، خودش بخشی از مسئله می شود؛ چون افزونه های بهینه سازی، خودشان بخشی از CPU را مصرف می کنند. پیش از نصب افزونه ی جدید، اول تشخیص دهید که مسئله واقعا کجاست.

پیشگیری بلندمدت

پنج عادتی که در پروژه های خودم، نرخ این خطا را به کمترین حد رسانده است:

• پایش ماهانه ی پنج عدد کلیدی: هر ماه، همان پنج عدد گام صفر را اندازه بگیرید. اگر روند صعودی است، پیش از بحران اقدام کنید.
• بازبینی فصلی افزونه ها: هر سه ماه، فهرست افزونه ها را بازبینی کنید. هر افزونه ای که در این سه ماه «دست نخورده» باقی مانده، کاندیدای حذف است.
• کش و CDN را از همان ابتدا راه اندازی کنید: این دو ابزار، ارزان ترین و موثرترین راه های افزایش سرعت هستند. اگر تا امروز راه اندازی نکرده اید، همین هفته انجام دهید.
• از قالب سبک و استاندارد استفاده کنید: قالب های سبک، سقف سرعت سایت شما را بالا می برند. معیارهای تشخیص قالب استاندارد در چگونه یک قالب وردپرس استاندارد را تشخیص دهیم آمده است.
• تصاویر را از همان لحظه ی آپلود بهینه کنید: با یک قانون ساده، هر تصویر بیشتر از ۲۰۰۰ پیکسل بازسازی شود. این رویکرد، در بلندمدت، از انباشت تصاویر سنگین جلوگیری می کند.

و یک عادت عملی که در پروژه های خودم پیاده کرده ام: مستندسازی رفتار سرعت. یک فایل ساده داشته باشید که در آن، پنج عدد کلیدی هر ماه ثبت شده باشد. اگر روزی کندی جهش کرد، این سند، تفاوت بین تشخیص سریع و گم شدن در حدس ها است. همین یک عادت کوچک، در بلندمدت، سرمایه گذاری ارزشمندی است.

نگاه عمیق تر به سرعت به عنوان قرارداد معماری

برای کسی که وردپرس را به عنوان یک پلتفرم تولیدی می بیند، سرعت فقط یک ویژگی فنی نیست؛ یک قرارداد معماری است که چند لایه باید با هم به آن پایبند باشند. سه تفکیک در این نگاه، به تشخیص و پیشگیری بلندمدت کمک می کند:

یک — سرعت، حاصل جمع سهم چند لایه است. در سیستم های بالغ، مفهوم «بودجه ی کارایی» (Performance Budget) به عنوان یک اصل معماری پذیرفته شده است. یعنی برای هر لایه از سیستم، یک سهم مشخص از بودجه ی کلی سرعت تعریف می شود: مثلاً هاست می تواند ۲۰٪ بودجه را مصرف کند، قالب ۱۵٪، افزونه ها ۳۰٪، تصاویر ۲۰٪، و فونت ها ۱۵٪. اگر یکی از این لایه ها از سهمش عبور کند، لایه های دیگر باید سهم خودشان را کم کنند. در وردپرس، چون این مفهوم به طور پیش فرض وجود ندارد، سرعت سایت به طور اتفاقی بالا یا پایین می رود. راه حل معماری این است که در انتخاب هر جزء سایت، سهم مصرف سرعت آن را به عنوان یک معیار انتخاب در نظر بگیریم. تجربه ی من این است که سایت هایی که با این معیار ساخته شده اند، در بلندمدت سرعت پایدارتری دارند.

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

سه — سرعت، در عصر موبایل، یک اولویت غیرقابل مذاکره است. در سال های اخیر، گوگل به طور صریح اعلام کرده که ایندکس سایت ها بر پایه ی نسخه ی موبایل انجام می شود. این یعنی سرعت در موبایل، نه یک «مزیت»، که یک «الزام» است. اگر سرعت سایت شما در موبایل پایین است، در ایندکس گوگل و در تجربه ی کاربر، بازنده اید. جالب است که در پروژه های خودم دیده ام که بیش از نیمی از سایت ها، سرعت دسکتاپ را بهینه می کنند و سرعت موبایل را نادیده می گیرند. اما در عمل، این سرعت موبایل است که ۸۰٪ کاربران شما را می سازد. اگر می خواهید سایت شما پایدار و موفق باشد، باید اولویت سرعت موبایل را در تمام تصمیم های معماری خود داشته باشید.

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

جمع بندی و مسیر پیش رو

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

تجربه ی من این است که در این خطا، «عدد» از «حدس» بسیار ارزشمندتر است. پنج عدد کلیدی گام صفر (TTFB، LCP، INP، بایت های CSS و JS، تعداد درخواست ها) نقشه ی راه شما هستند. هر تغییری باید با این اعداد سنجیده شود و هر بهبودی باید در همان اعداد ظاهر شود. این رویکرد، در پروژه های خودم، بیشترین صرفه جویی در وقت و هزینه را داشته است.

اگر این خطا را روی سایت خودتان دیده اید و یکی از خانواده های این مقاله مقصر بوده، خوشحال می شوم در دیدگاه ها بخوانم. به ویژه اگر سناریوی نادری کشف کرده اید — مثلا یک افزونه ی خاص با یک رفتار غیرمعمول، یا یک تنظیم سروری که کمتر دیده می شود — همان جزئیات برای خواننده ی بعدی که در همان موقعیت گرفتار است، از هر راهنمای عمومی ارزشمندتر است. اگر هم پس از خواندن این مقاله به این نتیجه رسیدید که زیرساخت فعلی سایت شما سقف این نوع مسائل است، دو مقاله ی راهنمای انتخاب هاست و تاثیر هاست بر سرعت سایت مسیر بعدی شما هستند. 🚀