افزایش سرعت WooCommerce قبل و بعد چه تفاوتی می‌سازد؟

دو سال پیش، یک فروشگاه ووکامرسی با ۳۲۰۰ محصول و ترافیک ماهانه حدود ۹۰ هزار بازدید، با یک شکایت ساده تماس گرفت: سایت در موبایل بیش از شش ثانیه بار می‌شود و مشتری‌ها وسط خرید سایت را ترک می‌کنند. آن پروژه، به یکی از جامع‌ترین پروژه‌های بهینه‌سازی سرعت ووکامرس تبدیل شد که تا آن روز انجام داده بودم. نرخ تبدیل از ۱.۳ به ۲.۱ درصد رسید، ارزش میانگین سفارش حدود بیست‌و‌یک درصد بهبود یافت و سرعت بارگذاری صفحات محصول بیش از نصف کاهش پیدا کرد. این مقاله، گزارش کامل قبل و بعد آن پروژه است؛ با اعداد دقیق، تصمیم‌هایی که گرفتیم و درس‌هایی که در پروژه‌های بعدی به کار بردیم. اگر فروشگاه ووکامرس دارید و می‌خواهید بدانید بهینه‌سازی سرعت واقعاً چه تفاوتی می‌سازد، این گزارش تصویر واضحی به شما می‌دهد.

چرا سرعت ووکامرس یک مسئله متفاوت از وردپرس است؟

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

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

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

در فروشگاه ووکامرس، هر ثانیه تأخیر، نه‌فقط کاربر را می‌پراند، بلکه درآمد را از بین می‌برد. تفاوت بین سرعت خوب و سرعت ضعیف در فروشگاه، تفاوت بین درآمدِ ثابت و درآمدِ رو به کاهش است.

معرفی پروژه و وضعیت اولیه

پروژه روی یک فروشگاه لوازم آرایشی و بهداشتی ایرانی اجرا شد. سایت روی ووکامرس بود، حدود پنج سال سابقه داشت و تعداد محصولات فعال آن حدود ۳۲۰۰ بود. ترافیک ماهانه در ابتدای پروژه حدود ۹۰ هزار بازدید بود و در بازه شش‌ماهه حدود بیست درصد کاهش یافته بود. ترکیب ترافیک موبایل به دسکتاپ هفتاد‌و‌پنج به بیست‌و‌پنج بود.

وضعیت اولیه سایت

در ممیزی اولیه، سه یافته اصلی ظاهر شد. اول، صفحات محصول در موبایل بیش از شش ثانیه بار می‌شدند. دوم، برخی صفحات دسته‌بندی با تعداد زیاد فیلتر به بالای هشت ثانیه می‌رسیدند. سوم، در ساعات اوج که ترافیک به حدود صد‌و‌بیست بازدید همزمان می‌رسید، سایت به‌خاطر مصرف بالای منابع هاست، خطاهای ۵۰۳ می‌داد. علاوه بر این، در بازه نظرخواهی از کاربران، شکایت‌های تکرارشونده در مورد کندی بارگذاری، لغزش اسکرول در موبایل و تجربه خسته‌کننده در فیلتر محصولات دیده می‌شد.

اهداف اولیه پروژه

چهار هدف مشخص روی کاغذ آوردیم و هرکدام را به یک عدد متصل کردیم. هدف اول، کاهش LCP موبایل از پنج و هفت دهم به زیر دو و نیم ثانیه. هدف دوم، کاهش TTFB از نهصد و ده به زیر سیصد میلی‌ثانیه. هدف سوم، افزایش نرخ تبدیل از یک و سه به بالای یک و نه درصد. هدف چهارمی که در ماه دوم اضافه شد، کاهش نرخ رهاشدگی سبد خرید موبایل از هفتادو‌پنج به زیر شصت درصد.

خط پایه در نه شاخص کلیدی

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

سه عدد در این جدول، بحران را به‌وضوح نشان می‌داد. اول، LCP صفحه دسته‌بندی که در محدوده بسیار بحرانی قرار داشت. دوم، TTFB نزدیک یک ثانیه که در سایت‌های فروشگاهی حرفه‌ای، عدد قابل قبول زیر دویست میلی‌ثانیه است. سوم، مصرف CPU در ساعات اوج که به نودو‌دو درصد می‌رسید؛ این یعنی سایت در آستانه ریزش کامل بود و هر افزایش ترافیکی می‌توانست آن را از دسترس خارج کند.

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

فاز تشخیص: کجا واقعاً گلوگاه بود؟

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

سه لایه تشخیص که اجرا شد

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

ل layer دوم، تحلیل کوئری‌های دیتابیس. با فعال‌سازی query monitor در محیط staging، مشخص شد که در هر صفحه محصول حدود ۱۲۰ کوئری اجرا می‌شود که بخش بزرگی آن‌ها تکراری یا بی‌استفاده بودند. علاوه بر این، جدول wp_postmeta که در ووکامرس حجم بسیار بالایی پیدا می‌کند، بدون ایندکس مناسب بود و کوئری‌های مربوط به فیلتر محصول بسیار کند اجرا می‌شدند. مکانیزم دقیق اثر دیتابیس روی سرعت در تأثیر دیتابیس بر سرعت سایت با جزئیات آمده است.

لایه سوم، تحلیل لایه فرانت‌اند. با بررسی سربرگ Network و پنل Performance، سه یافته اصلی پیدا شد. اول، حجم بالای JS و CSS که هم از قالب و هم از چند افزونه می‌آمد. دوم، تصاویر محصول با ابعاد بزرگ و بدون srcset که در موبایل باعث بارگذاری حجم زیاد می‌شد. سوم، تنظیمات نادرست lazy-load که روی تصویر LCP اعمال شده بود و زمان نمایش آن را افزایش می‌داد. چارچوب کامل این نوع تحلیل در عیب‌یابی مشکلات سرعت سایت آمده است.

خلاصه فاز تشخیص

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

هفت اقدام اصلی به‌ترتیب اثر

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

1. بازبینی هاست و زیرساخت
2. پاکسازی لایه ووکامرس و افزونه‌ها
3. بهینه‌سازی دیتابیس فروشگاهی
4. بهینه‌سازی تصاویر محصول
5. کش هوشمند برای فروشگاه
6. بازبینی قالب و لایه رندر
7. بهینه‌سازی لایه فرانت و تعامل

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

اقدام اول: بازبینی هاست و زیرساخت

اولین و مؤثرترین اقدام، ارتقای هاست بود. سایت روی یک هاست اشتراکی ارزان با منابع محدود بود که در ساعات اوج به مرز اشباع می‌رسید. تصمیم گرفتیم به یک پلن با مشخصات زیر مهاجرت کنیم: پردازنده نسل جدید، هشت گیگابایت رم، دیسک NVMe، سرور LiteSpeed و PHP نسخه ۸.۲.

اثر ارتقای هاست

اثر این تغییر به‌تنهایی چشمگیر بود. TTFB از نهصد و ده به چهارصد و بیست میلی‌ثانیه رسید که حدود پنجاه‌و‌چهار درصد کاهش است. مصرف CPU در ساعات اوج از نودو‌دو به چهل درصد رسید. تعداد خطاهای ۵xx ماهانه از بیش از هزار به کمتر از پنجاه کاهش یافت. زمان بارگذاری صفحات پر‌مخاطب مثل صفحه اصلی و صفحات دسته‌بندی حدود سی‌و‌پنج درصد کاهش یافت. انتخاب هاست مناسب برای وردپرس و ووکامرس، یک تصمیم تخصصی است که معیارهای دقیق آن در بهترین هاست وردپرس آمده است.

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

اقدام دوم: پاکسازی لایه ووکامرس

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

پروتکل حذف و بازبینی افزونه‌ها

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

بهینه‌سازی تنظیمات ووکامرس

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

اثر پاکسازی لایه ووکامرس

اثر این اقدام در بازه دو هفته‌ای ظاهر شد. تعداد درخواست‌های صفحه محصول از صد‌و‌شصت به هشتاد‌و‌دو کاهش یافت. مصرف RAM هاست در ساعات اوج حدود بیست درصد بهبود یافت. TTFB به‌تنهایی حدود شصت میلی‌ثانیه دیگر بهتر شد که بیشتر از کاهش فشار کوئری‌ها می‌آمد.

اقدام سوم: بهینه‌سازی دیتابیس فروشگاهی

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

سه اقدام کلیدی در دیتابیس

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

اقدام دوم، بهینه‌سازی ایندکس‌ها. جدول wp_postmeta که در ووکامرس حجیم می‌شود، بازبینی و ایندکس‌گذاری مجدد شد. علاوه بر این، جدول wp_wc_order_stats و جداول مرتبط با تحلیل فروش هم بهینه شدند. این تغییر، سرعت کوئری‌های مربوط به فیلتر محصول و گزارش‌های فروش را به‌طور میانگین حدود چهل درصد بهبود داد.

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

اثر بهینه‌سازی دیتابیس

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

اقدام چهارم: بهینه‌سازی تصاویر محصول

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

سه اقدام کلیدی در تصاویر

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

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

اقدام سوم، تنظیم درست lazy-load. یافته فاز تشخیص نشان داد که lazy-load روی تصویر LCP صفحه محصول اعمال شده بود که زمان نمایش آن را افزایش می‌داد. این تنظیم اصلاح شد تا تصویر شاخص بدون تأخیر بار شود. چارچوب کامل بهینه‌سازی تصاویر در بهینه‌سازی تصاویر سایت و تأثیر تصاویر بهینه بر سرعت سایت آمده است.

اثر بهینه‌سازی تصاویر

اثر این اقدام در بازه دو هفته‌ای ظاهر شد. حجم صفحه محصول در موبایل از پنج و چهار دهم به دو و دو دهم مگابایت کاهش یافت. LCP موبایل حدود یک ثانیه به‌تنهایی از این اقدام بهبود یافت. علاوه بر این، نرخ پرش صفحه محصول موبایل حدود دوازده درصد کاهش یافت.

اقدام پنجم: کش هوشمند برای فروشگاه

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

سه لایه کش که پیاده شد

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

لayer دوم، کش آبجکت با Redis. برای کاهش کوئری‌های تکراری دیتابیس، Redis به‌عنوان کش آبجکت پیاده شد. این تغییر، بار کوئری روی دیتابیس را حدود سی‌و‌پنج درصد کاهش داد که مستقیماً روی TTFB اثر گذاشت.

لایه سوم، کش مرورگر با تنظیمات دقیق. کش مرورگر با هدرهای Cache-Control تنظیم شد تا کاربران بازگشتی، فایل‌های ثابت را بدون دانلود مجدد دریافت کنند. این تغییر، زمان بارگذاری بازدیدهای دوم به بعد را حدود چهلو‌پنج درصد کاهش داد. مقایسه افزونه‌های کش در بهترین افزونه‌های کش وردپرس آمده است.

اثر لایه کش

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

اقدام ششم: قالب و لایه رندر

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

سه اقدام کلیدی در قالب

اقدام اول، بازبینی enqueue‌ها. با بررسی دقیق کد قالب، مشخص شد که چند فایل CSS و JS در همه صفحات بار می‌شوند حتی وقتی صفحه به آن‌ها نیازی ندارد. این enqueue‌ها بازنویسی شدند تا فقط در صفحات مرتبط بار شوند. این تغییر، تعداد درخواست‌های استاتیک صفحه محصول را از چهلو‌دو به بیست‌و‌شش کاهش داد.

اقدام دوم، بهینه‌سازی CSS بحرانی. برای بهبود LCP، بخشی از CSS که برای رندر اولیه صفحه لازم است به‌صورت inline اضافه شد و بقیه به‌تأخیر بار می‌شود. این تغییر، زمان نمایش اولیه صفحه را حدود هفتصد میلی‌ثانیه کاهش داد.

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

اثر بازبینی قالب

اثر این اقدام در بازه دو هفته‌ای ظاهر شد. LCP صفحه محصول موبایل حدود هشتصد میلی‌ثانیه دیگر بهبود یافت. حجم کل CSS و JS صفحه محصول از حدود پانصد کیلوبایت به دویست و چهل کیلوبایت کاهش یافت.

اقدام هفتم: بهینه‌سازی لایه فرانت و تعامل

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

سه اقدام کلیدی در لایه فرانت

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

اقدام دوم، بهبود INP. مقدار INP در موبایل پانصد و بیست میلی‌ثانیه بود. با کاهش JS اضافی و بهینه‌سازی رویدادهای لمس، این عدد به یکصد و چهل میلی‌ثانیه کاهش یافت. اثر این تغییر در پاسخ‌گویی سریع‌تر به تعامل کاربر مثل باز کردن منوی موبایل و انتخاب واریانت محصول به‌طور محسوس دیده شد.

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

اثر لایه فرانت

اثر این اقدام در بازه سه هفته‌ای ظاهر شد. CLS صفحه محصول موبایل از سی‌و‌دو صدم به نُه صدم کاهش یافت. INP از پانصد و بیست به یکصد و چهل میلی‌ثانیه بهبود یافت. نرخ تعامل با گالری محصول حدود چهل درصد افزایش یافت که نشان می‌دهد کاربران راحت‌تر با گالری تعامل می‌کنند.

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

نتایج بعد از سه ماه

پس از سه ماه اجرای مداوم هفت اقدام، شاخص‌ها را مجدداً سنجیدیم. نتایج در جدول زیر آمده است.

نتایج در همه شاخص‌ها فراتر از هدف‌گذاری اولیه بود. چهار یافته کلیدی در این جدول وجود دارد.

یافته اول: بهبود چشمگیر در شاخص‌های Core Web Vitals

سه شاخص اصلی Core Web Vitals، همه به محدوده سبز رسیدند. LCP موبایل حدود شصت‌و‌هفت درصد، CLS هفتادو‌دو درصد و INP هفتادو‌سه درصد بهبود یافتند. این بهبود، مستقیماً از ترکیب هفت اقدام می‌آید و در Google Search Console هم به‌عنوان بهبود کلی سایت ثبت شد.

یافته دوم: رشد معنادار در نرخ تبدیل

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

یافته سوم: افزایش ارزش میانگین سفارش

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

یافته چهارم: اثر هم‌افزایانه لایه‌ها

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

تفکیک اثر هر اقدام

برای اینکه بدانید کدام اقدام بیشترین اثر را داشته، اثر هر اقدام را در جدول زیر تفکیک کرده‌ام.

یافته کلیدی این جدول، توزیع نامتقارن اثر است. برای TTFB، هاست و کش بیشترین سهم را داشتند. برای LCP، تصاویر، هاست و قالب. این یعنی اگر هدف اصلی شما کاهش TTFB است، روی هاست و کش تمرکز کنید. اگر هدف کاهش LCP است، سراغ تصاویر و قالب بروید.

نکته دوم این است که اثر هر اقدام در زمان متفاوتی ظاهر شد. هاست در بازه یک هفته، تصاویر و کش در بازه دو تا سه هفته، دیتابیس در بازه سه تا چهار هفته، و بهینه‌سازی‌های قالب و فرانت در بازه دو تا سه هفته. این تفاوت بازه‌ها نشان می‌دهد که باید صبر کرد و بر اساس داده‌های بلندمدت تصمیم گرفت.

اقداماتی که اثر مطلوب نداشتند

یکی از بخش‌هایی که در گزارش‌های بهینه‌سازی کمتر گفته می‌شود، اقداماتی است که زمان و هزینه بردند اما اثر مطلوب نداشتند. در این پروژه، سه اقدام چنین وضعی داشتند.

اقدام اول: نصب چند افزونه کش همزمان

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

اقدام دوم: فشرده‌سازی بیش از حد تصاویر محصول

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

اقدام سوم: حذف کامل ویژگی‌های ووکامرس

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

درباره اشتباهات رایج در این نوع پروژه‌ها، اشتباهات بهینه‌سازی سرعت سایت و اشتباهات نصب افزونه وردپرس منابع عملی هستند.

تفکیک اثر در بخش‌های مختلف فروشگاه

اثر بهینه‌سازی سرعت در بخش‌های مختلف فروشگاه یکسان نبود. این تفکیک برای تیم‌هایی که می‌خواهند بدانند سرمایه‌گذاری را کجا انجام دهند، ارزش عملی بالایی دارد.

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

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

پرسش‌های پرتکرار درباره افزایش سرعت ووکامرس

بهینه‌سازی سرعت ووکامرس چقدر می‌تواند نرخ تبدیل را افزایش دهد؟

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

کدام اقدام بهینه‌سازی بیشترین اثر را در ووکامرس دارد؟

در این پروژه، سه اقدام بیشترین اثر را داشتند: مهاجرت به هاست بهتر، بهینه‌سازی تصاویر و کش سروری. توزیع اثر این سه به هدف شما بستگی دارد. اگر TTFB مهم‌تر است، هاست و کش اولویت دارند. اگر LCP مهم‌تر است، تصاویر و قالب اولویت دارند.

آیا بهینه‌سازی سرعت ووکامرس با بهینه‌سازی سرعت وردپرس متفاوت است؟

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

آیا مهاجرت به VPS برای ووکامرس توصیه می‌شود؟

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

چه مدت طول می‌کشد تا اثر بهینه‌سازی سرعت روی نرخ تبدیل دیده شود؟

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

آیا بهینه‌سازی سرعت روی سئوی فروشگاه هم اثر دارد؟

بله، اما غیرمستقیم. گوگل سیگنال‌های Core Web Vitals را در رتبه‌بندی لحاظ می‌کند و در فروشگاه‌های ووکامرسی، بهبود سرعت معمولاً با افزایش ترافیک ارگانیک همراه است. در این پروژه، ترافیک ارگانیک در بازه سه‌ماهه حدود بیست و دو درصد افزایش یافت. چارچوب کامل این چرخه در تأثیر سرعت سایت بر سئو آمده است.

آیا کش سروری برای ووکامرس مشکل ایجاد می‌کند؟

در صورت تنظیم نادرست، بله. کش سروری باید به‌گونه‌ای تنظیم شود که صفحات سبد خرید، چک‌اوت و حساب کاربری هرگز کش نشوند و همیشه داینامیک بمانند. در این پروژه، لیست استثناها با دقت تنظیم شد و در بازه سه ماهه هیچ مشکل کش‌محوری مشاهده نشد. اگر در این زمینه مطمئن نیستید، ابتدا کش را در محیط staging تست کنید.

آیا بهینه‌سازی سرعت ووکامرس روی نرخ رهاشدگی سبد اثر دارد؟

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

آیا بهینه‌سازی سرعت روی ارزش میانگین سفارش اثر دارد؟

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

آیا باید همه اقدامات بهینه‌سازی همزمان اجرا شود؟

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

آیا باید همزمان با بهینه‌سازی سرعت، به‌روزرسانی هسته و افزونه‌ها هم انجام شود؟

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

آیا استفاده از افزونه‌های بهینه‌سازی سرعت مخصوص ووکامرس توصیه می‌شود؟

بله، اما با احتیاط. افزونه‌های تخصصی مثل LiteSpeed Cache یا WP Rocket که تنظیمات پیش‌فرض برای ووکامرس دارند، می‌توانند مفید باشند. اما افزودن چند افزونه بهینه‌سازی همزمان، معمولاً اثر معکوس دارد. بهترین رویکرد، استفاده از یک افزونه جامع و تنظیم دقیق آن است. مقایسه این افزونه‌ها در بهترین افزونه‌های کش وردپرس آمده است.

آیا بهینه‌سازی سرعت ووکامرس به‌تنهایی کافی است یا نیاز به بهینه‌سازی تجربه کاربری هم هست؟

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

آیا بهینه‌سازی سرعت روی نرخ بازگشت مشتریان هم اثر دارد؟

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

هزینه بهینه‌سازی سرعت ووکامرس چقدر است؟

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

پنج درس کلیدی این پروژه

از این پروژه، پنج درس کلیدی گرفتم که در همه پروژه‌های بهینه‌سازی ووکامرس بعدی به کار برده‌ام.

1. هاست، پایه همه چیز است. اگر TTFB بالای هشتصد میلی‌ثانیه است، اول این را اصلاح کنید، نه چیز دیگر.
2. بهینه‌سازی ووکامرس پروژه‌ای چندلایه است. تمرکز روی یک لایه، بخش بزرگی از ظرفیت را هدر می‌دهد.
3. تصاویر محصول، بزرگ‌ترین برد در LCP است. اگر LCP سایت شما بالای سه ثانیه است، اول تصاویر را بررسی کنید.
4. افت موقت در بازه دو هفته اول بهینه‌سازی، طبیعی است. تصمیم بر اساس داده‌های کوتاه‌مدت، معمولاً اشتباه است.
5. بهینه‌سازی سرعت پایان نیست؛ آغاز چرخه بهبود مداوم است. بدون پایش ماهانه، سایت در بازه یک سال به حالت قبلی برمی‌گردد.

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

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

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

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

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

برای مطالعه عمیق‌تر، بهینه‌سازی سرعت سایت، افزایش سرعت فروشگاه ووکامرس و بهینه‌سازی سرعت ووکامرس منابع عملی هستند. برای چرخه کامل بهبود فروشگاه، CRO برای فروشگاه‌های ووکامرس و افزایش نرخ تبدیل با تغییر طراحی را بخوانید.

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

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