چرا سایت WordPress من اینقدر کند است؟

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

چرا باید قبل از هر تغییری عدد بگیرید؟

وقتی مشتری می‌گوید سایت کند است، اولین واکنش طبیعی نصب افزونه کش است. اما اگر بپرسم عدد فعلی چقدر است، معمولاً هیچ پاسخی وجود ندارد. این نقطه شروع اشتباه است. سرعت سایت را با چند معیار مستقل می‌سنجیم که هرکدام یک لایه از تجربه کاربر را می‌گیرد: TTFB (Time To First Byte) سرعت پاسخ سرور را نشان می‌دهد، LCP (Largest Contentful Paint) زمان نمایش بزرگ‌ترین عنصر قابل‌مشاهده را اندازه می‌گیرد، و INP (Interaction to Next Paint) کیفیت پاسخ‌گویی به تعامل کاربر را بررسی می‌کند. مفهوم دقیق این اعداد در مقاله Core Web Vitals چیست و چرا گوگل بر آن تاکید دارد آمده است و اگر می‌خواهید ابزار سنجش را بشناسید، فهرست ابزارهای تست سرعت سایت نقطه شروع خوبی است.

پنج عددی که در هر پروژه ثبت می‌کنم: TTFB، LCP، مجموع بایت CSS و JS صفحه اصلی، تعداد درخواست‌ها و مصرف CPU (Central Processing Unit) پنل هاست در ساعت پیک. بعد از هر تغییر، این پنج عدد را دوباره می‌گیرم. اگر عددی تکان نخورد، آن تغییر بی‌اثر بوده و باید حذف شود. این انضباط ساده، بزرگ‌ترین تفاوت بین تیم فنی حرفه‌ای و آماتور است. یک تعریف دقیق‌تر از این فرآیند را در بهینه‌سازی سرعت سایت چیست شرح داده‌ام.

سرعت بدون اندازه‌گیری، فرضیه است؛ با اندازه‌گیری، مهندسی می‌شود.

هاست؛ بستری که همه‌چیز رویش سوار است

هاست اولین لایه‌ای است که باید بسنجید. اگر TTFB شما روی همه صفحات بالای ۸۰۰ میلی‌ثانیه است، بقیه بهینه‌سازی‌ها فقط میوه‌های نزدیک را می‌چینند و ریشه سر جایش می‌ماند. هاست‌های ارزان اشتراکی معمولاً روی سرورهایی کار می‌کنند که ده‌ها مشتری دیگر هم روی همان پردازنده می‌دوند و اگر یکی از آن‌ها بکاپ ساعتی سنگین بگیرد، درخواست شما در صف می‌نشیند. نشانه این وضعیت، نوسان TTFB در ساعات مختلف روز است: صبح ۲۰۰ میلی‌ثانیه، شب ۲۰۰۰ میلی‌ثانیه. جزئیات فنی این پدیده و نحوه سنجش آن در تأثیر هاست بر سرعت سایت با عدد بررسی شده است.

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

قالب؛ سقفِ سرعتِ سایت شما

قالب، جاده است. اگر جاده پرپیچ و باریک باشد، بهترین خودرو هم کُند می‌راند. ساده‌ترین آزمایش تشخیص: قالب فعلی را روی نصب تمیزی بدون افزونه‌های نمایشی راه بیندازید و در Network مرورگر تعداد درخواست‌های استاتیک و مجموع بایت CSS/JS را ببینید. اگر تعداد درخواست بالای ۴۰ و مجموع بایت بالای ۵۰۰ کیلوبایت باشد، مقصر اصلی قالب است. تحلیل دقیق دلایل کندی قالب‌ها در چرا بعضی قالب‌های وردپرس باعث کندی سایت می‌شوند آمده است.

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

کش، بایت اضافه قالب را حذف نمی‌کند؛ فقط کمی دیرتر تحویلش می‌دهد.

افزونه‌ها؛ مالیات پنهان هر بازدید

هر افزونه در هر بازدید چهار نوع هزینه دارد: اجرای PHP، کوئری دیتابیس، فایل CSS/JS اضافه در سمت مرورگر، و کارهایی که در cron انجام می‌دهد. تشخیص این لایه با کندی انتخابی شروع می‌شود: صفحه‌هایی که افزونه مربوطه در آن‌ها فعال است کند هستند، بقیه نسبتاً سریع. تحلیل چهارگانه این مکانیزم در افزونه‌های وردپرس چگونه روی سرعت سایت اثر می‌گذارند با مثال‌های واقعی آمده است.

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

کش؛ موتور تحویل صفحه

کش، ارزان‌ترین برد در سرعت است، اما نه به این معنی که هر افزونه‌ای را نصب کنید. سه نوع کش که باید از هم تفکیک کنید: کش صفحه برای HTML خروجی، کش مرورگر برای فایل‌های استاتیک و کش آبجکت برای نتایج کوئری‌های دیتابیس. اکثر افزونه‌های معروف فقط دو مورد اول را می‌دهند و برای سوم نیاز به Redis یا Memcached دارید که در هاست‌های وردپرس مدیریت‌شده رایج است.

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

CDN؛ فاصله‌ای که دیگر مهم نیست

CDN (Content Delivery Network) یا شبکه توزیع محتوا، نسخه‌های کش‌شده صفحات و فایل‌های استاتیک سایت شما را از نزدیک‌ترین نقطه جغرافیایی به کاربر تحویل می‌دهد. برای سایت‌هایی که مخاطبشان در چند کشور یا چند قاره پخش است، این لایه تفاوت چشمگیری در حس سرعت ایجاد می‌کند. اصول فنی و معیارهای انتخاب CDN را در CDN چگونه سرعت سایت را بهبود می‌دهد باز کرده‌ام.

اشتباهی که زیاد می‌بینم: نصب CDN بدون purge کردن کش قدیمی بعد از هر تغییر محتوا. کاربر بعد از انتشار یک پست جدید، همچنان نسخه دیروز را می‌بیند و شکایت می‌کند سایت آپدیت نمی‌شود. تعریف درست سیاست purge، بخش جدایی‌ناپذیر تنظیم CDN است.

تصاویر؛ بزرگ‌ترین بایت‌های روزمره

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

یک نکته فنی مهم: تصویر بالای صفحه که در LCP نقش دارد نباید lazy-load شود. lazy-load برای تصاویر زیر خط دید است، نه عنصری که کاربر در همان ثانیه اول می‌بیند. اشتباه بزرگ، اعمال یک‌دست lazy-load روی همه تصاویر است که یکی از رایج‌ترین دلایل کندی LCP در وردپرس است.

دیتابیس و کرون؛ کارهای خاموش

سایت‌های چندساله معمولاً با بدهی دیتابیس دست‌وپنجه نرم می‌کنند. ردیف‌های باقی‌مانده افزونه‌های حذف‌شده، نسخه‌های پیش‌نویس به‌جامانده، ترنزینت‌های منقضی و اتولودهای سنگین در جدول wp_options. تأثیر این پدیده بر سرعت در تأثیر دیتابیس بر سرعت سایت با مثال‌های عملی بررسی شده است.

کرون (Cron) نیز بخشی از همین لایه است. اجرای wp-cron در لحظه بازدید کاربر، به‌جای زمان‌بندی سرور، یکی از رایج‌ترین دلایل کندی متناوب است. راه‌حل درست این است که wp-cron را در wp-config.php غیرفعال و زمان‌بندی را به کرون واقعی سرور منتقل کنید. علامت این مشکل، کندی تصادفی در بعضی بازدیدهاست، بدون اینکه الگوی مشخصی داشته باشد.

ترتیب درست اقدامات

پس از تشخیص لایه گلوگاه، ترتیب پیشنهادی این است:

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

اشتباهاتی که کندی را بدتر می‌کنند

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

پرسش‌های پرتکرار درباره کندی سایت وردپرسی

آیا کش به‌تنهایی کندی سایت را حل می‌کند؟

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

چرا عدد PageSpeed من پایین است ولی سایت واقعاً سریع باز می‌شود؟

PageSpeed آزمایشگاهی روی بارگذاری اول اجرا می‌شود و شرایط شبکه را سخت‌گیرانه شبیه‌سازی می‌کند. تست میدانی CrUX معیار نزدیک‌تری به تجربه کاربر است و باید بر همان تمرکز کنید.

آیا VPS همیشه سریع‌تر از هاست اشتراکی است؟

خیر. VPS مدیریت‌نشده و بد تنظیم، می‌تواند از یک هاست اشتراکی بهینه کندتر باشد. تفاوت در مدیریت است، نه در نوع سرویس.

چرا کندی من فقط روی موبایل حس می‌شود؟

احتمالاً قالب شما ساختار دسکتاپ‌محور دارد و مدیاکوئری‌های آن ضعیف تنظیم شده‌اند یا تصاویر به‌درستی برای اندازه موبایل تولید نمی‌شوند.

کدام عدد بیشترین تأثیر را روی رتبه گوگل دارد؟

در عمل، هر سه معیار Core Web Vitals به‌عنوان بخشی از سیگنال تجربه کاربری مؤثرند. اگر مجبور به انتخاب باشید، LCP و INP روی موبایل بیشترین وزن را دارند.

سخن پایانی متفاوت: سرعت، یک فرآیند است نه یک تنظیم

پس از سال‌ها کار روی سایت‌های پربازدید، به این باور رسیده‌ام که کندی وردپرس تقریباً هیچ‌وقت یک علت واحد ندارد. مجموعه‌ای از تصمیم‌های کوچک که هرکدام توجیه‌پذیر بوده‌اند، به‌مرور کندی می‌سازند. کسی که افزونه را نصب کرده، دلیل داشته؛ کسی که قالب را عوض کرده هم دلیل داشته. مشکل در تصمیم‌های فردی نیست، در نبودِ سنجشِ دوره‌ای است. اگر ماهی یک‌بار پنج عدد کلیدی را ثبت کنید و نمودارشان را ببینید، قبل از اینکه کاربر شکایت کند، تفاوت را متوجه می‌شوید. سرعت واقعی، عدد نیست؛ حسی است که کاربر در سه ثانیه اول تجربه می‌کند و شما با انضباط ماهانه از آن مراقبت می‌کنید. اگر تجربه‌ای از یک لایه غیرمنتظره که کندی سایت شما را می‌ساخت دارید، در دیدگاه‌ها بنویسید؛ همین پرونده‌های واقعی به من یاد دادند هیچ‌گاه از قبل به مقصر احتمالی اعتماد نکنم.