افزونه‌های وردپرس چگونه روی سرعت سایت اثر می‌گذارند
افزونه‌ها چطور سرعت وردپرس را می‌خورند؟ مکانیزم اثر هر افزونه (PHP، دیتابیس، CSS/JS، cron) با روش عیب‌یابی مرحلهبهمرحله؛ چه چیزی را حذف کنیم و چه چیزی را هرگز نباید حذف کرد.
یک سندرمِ آشنا در وردپرس هست که به آن می‌گویم «مرگِ تدریجی»: سایتی که روزِ راه‌اندازی در یک‌ونیم‌ثانیه باز می‌شد، شش ماه بعد هشت‌ثانیه‌ای است — بدونِ آن‌که هیچ‌کس «کارِ بدی» کرده باشد. هر افزونه‌ای که نصب شد، تنها و موجه بود: فرم‌ساز، اسلایدر، افزونۀ اشتراک‌گذاری، بهینه‌سازِ تصویر، ضد‌هرزه‌نگاری… و جمعِ این «کم‌ها» شد آن هشت‌ثانیه. موضوع این مقاله نه «افزونه بد است» — که بدون افزونه، وردپرس یک قالبِ بی‌اراده است — بلکه فهمیدنِ مکانیزمِ اثر افزونه روی سرعت است: افزونه دقیقاً در کدام لایه از پروسۀ درخواست پول می‌گیرد، چطور باید مظنونِ کند شدن را پیدا کنیم، و وقتی پیدا کردیم، حذف کنیم یا جایگزین؟ اگر همین امروز سایتتان کند است، این نوشته نقشۀ عملیاتیِ عیب‌یابی شماست.
یک عدد را همین اول صاف کنم: «بیشتر از ۲۰ افزونه» افسانه است
قدیمی‌ترین توصیۀ وردپرسی دنیا این است: «بیش از ۲۰ افزونه نصب نکن!». عددِ بی‌پایه. من سایت‌هایی با ۱۲ افزونه اداره می‌کنم که در یک‌ثانیه باز می‌شوند و سایت‌هایی با ۴ افزونه که روی سرورِ نفس‌تنگ، پنج‌ثانیه‌اند. چون سرعت تابعِ کیفیتِ کد و تعدادِ ریکوئست‌هاست، نه شمارۀ افزونه در فهرست. افزونۀ بدِ تنها، صد افزونۀ خوب را شکست می‌دهد. پس سوالِ درست این نیست «چند تا دارم؟» سوال این است «هرکدام در هر بازدید، چه هزینه‌ای تحمیل می‌کند؟» — و این دقیقاً همان سوالی است که در «افزونه‌های ضروری وردپرس» به‌صورت مدلِ سه‌سوالیِ پیش‌از‌نصب گفتم؛ اینجا همان مدل را با آناتومیِ فنی بزرگ می‌کنیم. یک مقایسۀ ذهنی که زیاد استفاده می‌کنم: افزونه‌ها مثل مسافرِ یک ماشین‌اند؛ مهم نیست هفت‌نفرید یا دو‌نفر، مهم این است نفرِ هفتم کوله‌پشتیِ بیست‌کیلوئی داشته باشد و بگوید «ولی من فقط نشستم!». برای همین هم هست که مقالۀ «چرا بعضی قالب‌ها کند می‌کنند» را جدا نوشتم — قالب، بارِ اول ماشین است و افزونه‌ها مسافرانِ بعدی؛ هر دو را باید با هم سنحید نه جدا.
هیچ افزونه‌ای «کند» نیست؛ بعضی افزونه‌ها «گران‌تر از ارزششان»ند. تفاوت این دو جمله، کلِ این مقاله است.
افزونه در کدام لایه پول می‌گیرد؟
سرعتِ درکِ‌شدهِ یک صفحه، مجموعۀ چند زمان است: پاسخِ سرور (TTFB)، دانلودِ فایل‌ها، پارس و اجرای آن‌ها، و نهایی‌شدنِ تصویرِ بزرگ. افزونه می‌تواند در هر چهار مرحله دخالت کند و من اثر را در چهار لایه می‌شکنم — چون «عیب‌یابی» بدونِ دانستنِ لایه، حدس‌زدن است: PHP (اجرای کد در هر ریکوئست)، دیتابیس (کوئری و نوشتن)، فایل‌هایِ سمتِ مرورگر (CSS/JS/فونت)، و کارهایِ زمان‌بندی‌شده (cron/صف‌ها). در مقالۀ جامعِ افزایش سرعت وردپرس نقشۀ کلی این چهارلایه را داده‌ام؛ اینجا بزرگ‌نمایی‌شان می‌کنیم.
لایه ۱: PHP — مالیاتِ هر ریکوئست
بدترین نوعِ اثر، همان که کاربرِ کم‌تجربه هرگز نمی‌بیند. افزونه در وردپرس یعنی «کدِ من هم در هر ریکوئست اجرا می‌شود» — هوک‌ها (مثلاً init، wp_enqueue_scripts، the_content که مفصل‌شان در چیستی افزونه باز کرده‌ام) روی هسته می‌نشینند. افزونۀ «تغییرِ قیمت در سبد» در هر صفحه‌ای که بارگذاری می‌شود اجراست، حتی صفحه‌درباره‌ما! اثرش در TTFB می‌نشیند: سرور قبلِ ارسالِ اولین بایت، کدِ همه را اجرا کرده. نشانه‌های یک افزونۀ PHPگرا: TTFBِ بالا روی همه صفحات، افتِ محسوس در پیشخوان، خطاهای «max_execution_time» در کمپین‌های پربازدید. ابزارِ سنجشِ TTFB و تفسیرش در تأثیر TTFB بر سرعت بارگذاری آمده؛ و پیش از سرزنشِ افزونه، یک بار هم سرور را متهم کنید — مرزِ «هاست یا افزونه» را در تأثیر هاست بر سرعت سایت با روشِ عددی جدا کرده‌ام. مثالِ واقعیِ خودم: افزونۀ اشتراک‌گذاریِ اجتماعی که برای هر پست در حلقۀ نمایشِ آرشیو، APIِ شبکه‌ها را برای شمارۀ اشتراک‌ها می‌زد — یعنی در صفحه‌دستۀ پانزده‌نوشته‌ای، پانزده درخواستِ همگامِ خروجی در PHP. همین افزونۀ بی‌آزار، سنگین‌ترین عضوِ میز بود.
لایه ۲: دیتابیس — کوئری‌های خاموش
لایۀ دوم از PHP جداست ولی به آن وصل: افزونه‌ای که در هر ریکوئست کوئری می‌زند یا می‌نویسد. بدترین الگوی رایج، «افزودنِ ستون/جدولِ خودسر + نوشتنِ درجۀ‌بالا» است: شمارندۀ بازدید که هر لود را UPDATE می‌کند، لاگِ فعالیت که هر کلیک را INSERT می‌کند، تنظیماتِ پر‌تکرارِ خوانده‌شدۀ wp_options با autoloadِ بزرگ. نشانه‌هایش: سایتِ front سالم ولی پیشخوانِ خفه؛ دیتابیسِ چندگیگابایتی در هاستِ اشتراکی؛ و در ساعات اوج، صفِ قفلِ جدول. دو کارِ عملی: اول — پایشِ مصرفِ منابع در کاهش مصرف منابع هاست آموزشش هست؛ دوم — درکِ این‌که حتی کش‌سازِ خوب هم جلوی «نوشتن» را نمی‌گیرد؛ کش، خواندن را نجات می‌دهد نه نوشتن را (تفکیکِ نقشِ کش در مقایسۀ افزونه‌های کش). و فراموش نکنید: همان‌طور که در «تأثیر دیتابیس بر سرعت» گفته‌ام، کوئری‌های بد، TTFB را می‌خورند؛ پس اگر لایۀ ۲ مشکوک است، اول جدول‌های تازه‌ساختۀ افزونه‌ها را در phpMyAdmin بشمارید — هر افزونۀ حذف‌شده‌ای که ردِ جدول باقی گذاشته، مالیاتِ ابدی است مگر پاکش کنید.
لایه ۳: CSS/JS — بارِ سمتِ مرورگر
لایۀ سوم تنها لایه‌ای است که «ابزار» مستقیمش را کاربر هم می‌بیند: سربرگ Network. افزونه‌ها فایل اضافه به صفِ قالب می‌ریزند — بعضی مودب، همه‌جا؛ بعضی هوشمند، فقط صفحه‌های لازم. اسلایدرِ سه‌صفحه‌ایِ سایتِ شما، JSِ صدوهشتادکیلوبایتی را در دویست صفحۀ دیگر هم enqueue می‌کند؛ افزونۀ فرم، فرم‌ساز را در برگۀ «درباره‌ما» هم صدا می‌زند؛ افزونۀ ترجمه، استایلِ سوئیچر را. نشانه‌اش: تعدادِ درخواست‌های استاتیک که از ده‌ها افزونۀ «کم‌حجم» ساخته شده. این همان فیلدی است که در مقالۀ قالب سبک برای قالب‌ها تعریف کردم — دقیقاً روی افزونه هم اعمالش کنید: CSS/JS اضافه، بایتِ مازاد، فونتِ لودشده. راهِ نجاتِ عملی دو چیز است: کش‌سازی که ترکیب/بهینه کند، و شجاعتِ خاموش‌کردنِ ماژول‌های enqueue روی صفحه‌های بی‌نیاز؛ بیشتر افزونه‌های معتبر، فیلترهای «load on pages» دارند و استفاده‌نکردن از آن‌ها تقصیرِ ابزار نیست. و اگر می‌خواهید عددِ قبل‌وبعد را ثبت کنید، پروتکلِ ابزارها در معرفی ابزارهای تست سرعت و معیارِ نهایی‌شان در Core Web Vitals چیست آمده — INP و LCP، دو قربانیِ همیشگیِ این لایه‌اند؛ هر JSِ بلوکه‌کننده که افزونه‌تان به head تزریق می‌کند، مستقیم روی این دو عدد می‌نشیند.
لایه ۴: cron و کارهای پس‌زمینه
کم‌سروصداترین و فریبنده‌ترین لایه. وردپرس cronِ رویداد-محور دارد؛ افزونه‌ها در آن «برنامه» می‌ریزند: همگام‌سازیِ قیمت، پاک‌سازیِ لاگ، بهینه‌سازیِ تصویر، ارسالِ خبرنامه، اسکنِ امنیتی. مشکل دو‌جانبه است: در سایتِ کم‌ترافیک، cron دیر اجرا می‌شود و کارها تلنبار می‌شوند؛ در سایتِ پُرتراکم، cron در میانِ ریکوئست‌های واقعی اجرا می‌شود و کاربرِ بیچاره تا نیم‌ثانیه معطلِ پاک‌سازیِ لاگِ یک افزونۀ فراموش‌شده می‌ماند. درکِ این مکانیزم و روشِ جایگزینی‌اش با cronِ واقعیِ سرور، موضوعِ عیب‌یابی مشکلات cron در وردپرس است — اگر TTFBِ‌تان در ساعاتِ تصادفی می‌پرد، همین‌جا را اول نگاه کنید. و در موردِ افزونه‌های امنیتی، نکته‌ای که در مقایسۀ افزونه‌های امنیتی گفتم را اینجا هم تکرار می‌کنم: اسکنِ real-time روی هاستِ اشتراکی، یا خاموشش کنید یا زمان‌بندی‌اش را به نیمه‌شب؛ امنیتِ همیشه‌بیدار، سایتِ خواب‌آلود می‌سازد.
افزونه‌ای که نمی‌دانید کجا پول می‌گیرد، دقیقاً همان مظنونِ همیشگی است؛ عیب‌یابی یعنی همین که «نمی‌دانم» را به «می‌دانم و اندازه می‌گیرم» تبدیل کنید.
عیب‌یابی: چطور مقصر را پیدا کنیم؟
بخشِ عملیاتیِ مقاله؛ روشِ من در هر پرونده، به همین ترتیب است و کمتر از یک ساعت وقت می‌گیرد. گام صفر: سه عددِ مرجع ثبت کنید — TTFB، مجموعۀ بایت‌های CSS/JS، و تعداد درخواست‌ها؛ سه عددی که ابزارهای تست سرعت همه می‌دهند. گام ۱ — حذفِ سیستماتیک: روی استجینگ (همان محیطِ لوکالی که در راهنمای راه‌اندازیِ مبتدیان معرفی کرده‌ام) افزونه‌ها را دسته‌ای خاموش کنید — نه یکی‌یکی که طول می‌کشد، در پنج دسته: سئو/امنیت، کش/بهینگی، فرم/ارتباط، نمایشی (اسلایدر/گالری)، و «یادتان نیست چرا نصبش کردید». بعد هر دسته، سه عدد را دوباره بگیرید؛ دسته‌ای که پرشِ عدد داشت، خانۀ مظنون است. گام ۲ — تک‌نفره درونِ دسته: در همان دسته، افزونه‌ها را یکی‌یکی روشن کنید تا مقصر مشخص شود؛ الگوی من می‌گوید در دو‌سومِ موارد، «بازیگرِ سوم» همان افزونۀ کوچکِ نمایشی است که کسی جدی نمی‌گیرد. گام ۳ — نگاه به cron و دیتابیس: اگر با حذف‌ها front درست شد ولی پیشخوان هنوز خفه است، پروندۀ لایه‌های ۲ و ۴ است؛ جدول‌هایِ بزرگ‌ِ افزونه‌ها و رویدادهایِ cron را همان‌طور که گفتم بشمارید. گام ۴ — آزمونِ تکرار: افزونۀ مظنون را روشن کنید و ببینید عدد برمی‌گردد یا نه؛ اثباتِ تکرارپذیر، فاصلهٔ حدس از تشخیص است. کلِ این پروتکل را در «عیب‌یابی سرعت سایت» هم به‌صورت چک‌لیست آورده‌ام؛ روشِ رفع تدریجی کندی خواهرِ همین مراحل است. یک هشدارِ حرفه‌ای: هرگز عیب‌یابی را روی سایتِ زندهٔ پُرتراکم انجام ندهید؛ خاموش‌شدنِ ناگهانیِ یک افزونۀ حیاتی در اوجِ فروش، از کندیِ چندصد‌میلی‌ثانیه‌ای بدتر است. یک الگویِ آماریِ شخصی هم برای سرعتِ عیب‌یابی به کارم آمده: در ده پروندهٔ اخیر، مظنونِ اولِ من (افزونۀ سئو یا امنیتیِ گران) در نیمی از موارد بی‌گناه از پرونده بیرون آمد و مقصرِ واقعی، یکی از «همان افزونه‌های کوچیکِ قدیمی» بود که سال‌ها روی سایت خوابیده بودند؛ به‌خصوص افزونه‌های «یک‌بار تنظیم و فراموش». پس در گام یک، دستهٔ «یادتان نیست چرا نصبش کردید» را اول از همه بردارید؛ ارزان‌ترین حذفِ تاریخ وردپرس ایران همین دسته است. و اگر دسته‌ای را خاموش کردید و هیچ عددی تکان نخورد، آن دسته نامزدِ حذفِ دائمی است — افزونه‌ای که حتی در خاموشی هم اثری بر اعداد ندارد، احتمالاً کاری هم نمی‌کند؛ فقط حضور دارد و ریسکِ امنیتی‌اش را می‌پردازید.
چه چیزی را هرگز حذف نکنیم
معکوسِ فهرست هم مهم است؛ عیب‌یابیِ سریع می‌تواند به حذفِ ضرری ختم شود. چهار ردیف در فهرست «حذف‌نکردنی» من‌اند حتی اگر سایت را صد‌میلی‌ثانیه کند کنند: افزونۀ بکاپ — همان‌طور که در معرفی افزونه‌های بکاپ استدلال کردم، بیمه‌نامۀ بی‌مذاکره است. افزونۀ سئوی فعالِ سایت — حذفش یعنی sitemap و meta و schema در هوا معلق؛ نسخهٔ بهینهٔ همان افزونه را بگیرید، نه حذفش (نقطۀ سرعتِ افزونه‌های سئو را بخوانید). افزونۀ کش — بله، خودش چند‌میلی‌ثانیه CPU می‌گیرد ولی هزار‌ها برابرش را نجات می‌دهد؛ فقط کشِ درستِ هاست‌تان را انتخاب کنید. و هر افزونه‌ای که داده تولید می‌کند — فرم‌ساز با آرشیوِ پیام‌ها، ووکامرس، عضویت؛ حذف این‌ها نه‌تنها کندی را درمان نمی‌کند، داده‌تان را هم در معرض می‌گذارد؛ اگر لازم شد غیرفعالِ موقت کنید با بکاپِ کامل، نه حذف. در تقابلِ «سرعت در برابر کارکرد»، قانونم یکی است: سرعت را از چیزهایِ تزئینی بگیر، نه از ستون‌ها — همان تفکیکِ «نیاز/قابلیت» که در افزونه‌های ضروری گفتم. یادآوریِ ظریفِ آخر: گاهی «حذفِ درست» یعنی مهاجرتِ آگاهانه — مثلاً اگر بین دو افزونۀ سئو گیر کرده‌اید، پروتکلِ ویزاردیِ مهاجرت را در مقایسۀ Yoast و Rank Math خوانده‌اید؛ حذفِ بی‌نقشه، خودش یک حادثه است.
جایگزین‌های ارزان‌تر از حذف
قبلِ حذفِ هر افزونه، سه مسیرِ کم‌هزینه‌تر را امتحان کنید که تجربه نشان داده در نیمی از موارد، مقصرِ اصلی را بی‌آزار می‌کنند. یک — تنظیماتِ داخلی: نیمی از افزونه‌ها گزینه‌های «load on specific pages»، «disable front-end assets» و «defer scripts» دارند که پیش‌فرض خاموش‌اند؛ اول آن‌ها را روشن کنید. دو — انتقال به چایلد تم: افزونه‌ای که کارکردش دو خط کد است (شورت‌کدِ تزئینی، تغییرِ متنی، فیلترِ کوچک) را در چایلد تم منتقل کنید و خود افزونه را حذف؛ این «قانونِ بیست خط» نصفِ افزونه‌هایِ نمایشی سایت‌ها را بیکار می‌کند. سه — ادغامِ کارکرد: سه افزونهٔ مجزا برای «فرم، ضداسپم، لاگ» اغلب با یکی قابل‌جایگزین‌اند — هر افزونه یعنی یک ستونِ اضافه در لایه‌های ۱ تا ۳. و برای مواردِ سنگین‌ترِ رسانه، فراموش نکنید که تصویر، رقیبِ افزونه‌هاست: قبلِ آن‌که افزونۀ بهینه‌سازیِ دیگری اضافه کنید، فشرده‌سازیِ درستِ تصاویر و ابزارِ خودکارش در بهترین افزونه‌های بهینه‌سازی تصویر را یک‌بار برای همیشه تنظیم کنید؛ و اگر مخاطبتان سراسری/جهانی است، یک CDN (همان‌طور که در نقش CDN در سرعت سنجیده‌ام) بیشتر از سه افزونۀ بهینگی اثر دارد — چون فایل‌ها را از دوشِ PHP و دیتابیسِ شما برمی‌دارد. نقشۀ کلِ جایگزین‌ها همان «بهینۀ گام‌به‌گام» است که در بهینۀ سرعت سایت چیست چیده‌ام؛ افزونه‌ها فقط یکی از خانه‌های آن نقشه‌اند.
جمع‌بندی
تأثیر افزونه‌ها بر سرعت در چهار لایه خلاصه می‌شود: PHP (مالیاتِ هر ریکوئست)، دیتابیس (کوئری و نوشتنِ خاموش)، فایل‌هایِ مرورگر (CSS/JS اضافی)، و cron (کارِ پس‌زمینه در زمانِ اشتباه). ابزارِ تشخیص: سه عددِ مرجع، حذفِ دسته‌ای روی استجینگ، و آزمونِ تکرار. قانونِ حذف: تزئینی‌ها را ببر، ستون‌ها را نه؛ و قبلِ هر حذف، سه جایگزینِ ارزان را امتحان کن. یادتان باشد سرعت، مقصد نیست؛ محصولِ کناریِ معماریِ درست است — همان‌طور که در «سئو چیست» گفتیم سایتِ سریع هم شرطِ رتبه است هم نشانهٔ احترام به کاربر. قدمِ امشب‌تان: به فهرست افزونه‌هایتان نگاه کنید و جلوی هرکدام بنویسید «لایۀ هزینه‌اش کدام است؟»؛ سه تا که جوابشان «نمی‌دانم» شد، اول از همه همان‌ها را در استجینگ آزمایش کنید. اگر پروندۀ عیب‌یابیِ جالبی داشته‌اید — مقصرِ غیرمنتظره‌تان را بنویسید؛ فهرستِ لایه‌ها را با نمونه‌های واقعیِ شما کامل‌تر می‌کنم. ⏱️
نویسنده در وردپرس کار.