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

روز ۲۵ مهر ۱۴۰۵ در یک فروشگاه آزمایشی با وردپرس ۷٫۱٫۲، ووکامرس ۱۱٫۲٫۱ و قالب Storefront، گزینه‌های افزونه راکت (WP Rocket، نگارش ۳٫۲۳٫۵٫۱) را یکی‌یکی روشن کردیم و بعد از هر کدام همان مسیر خرید را رفتیم. «تاخیر اجرای جاوا اسکریپت» (Delay JavaScript execution) اسکریپت‌های صفحه فروشگاه را از ۱۴ به ۱ رساند، ولی بازدیدکننده‌ای که با یک کالا در سبد برگشته بود، تا اولین حرکت ماوس «0 مورد» می‌دید، ۵ بار از ۵.

اگر فقط راه‌حل را می‌خواهید، در تب «بهینه‌سازی فایل» تنظیمات راکت تاخیر اجرا را روشن کنید و در «موارد استثنا با یک کلیک» تیک WooCommerce - Cart Fragments را بزنید. اگر قالبتان در همان فهرست مورد سبد خرید خودش را دارد، آن را به‌جای مورد ووکامرس بزنید. گزینه‌های دیگر فایل و رسانه در این فروشگاه چیزی را خراب نکردند. کوکی woocommerce_items_in_cart را، که کش را از سبد یک خریدار دور نگه می‌دارد، در بخش کش می‌بینید؛ شش بررسی کوتاه در بخش آخر است.

تنظیمات WP Rocket یکی‌یکی، با همان مسیر خرید

فروشگاه ۳۹ محصول دارد، ووکامرس فارسی ۱۰٫۰٫۵ نصب است و سبد و تسویه حساب کلاسیک‌اند. سرور آپاچی ۲٫۴٫۶۸ با PHP ۸٫۳٫۳۵ در Docker بود. هر آزمایش از یک پایگاه‌داده و پرونده‌های یکسان شروع شد: راکت را از زیپ فروشگاه نصب کردیم، یک بار صفحه تنظیمات آن را باز کردیم تا گزینه‌های پیش‌فرضش ساخته شود و بعد، از همان فرم، فقط گزینه‌ای را که نام ردیف می‌گوید روشن کردیم. کد افزونه را هم از زیپ خواندیم؛ هرجا نوشتیم «در کد»، از آن است.

بازدیدکننده در Chrome ۱۵۵ تازه و بی‌کوکی، با رویداد واقعی ماوس یا لمس، ۱۵ گام خرید را رفت، از افزودن به سبد در صفحه فروشگاه تا ثبت سفارش با پرداخت در محل. هر ردیف تنظیمات بعد از فعال‌سازی راکت است به‌اضافه گزینه یا گزینه‌هایی که نامش می‌گوید. «بارگذاری جاوا اسکریپت به صورت تاخیری» (Load JavaScript deferred) غیر از «تاخیر اجرا» است، و «همه» یعنی بارگذاری تاخیری، تاخیر اجرا، لیزی لود و ابعاد تصاویر با هم. ادغام را هم تیک زدیم، ولی راکت وقتی تاخیر اجرا روشن است خودش آن را خاموش می‌کند، پس «همه» ادغام ندارد. حجم‌ها از شبکه مرورگر است (هر ۱۰۰۰ بایت یک کیلوبایت) و نمره‌ها میانه ۵ اجرای Lighthouse ۱۳٫۵ با پیش‌فرض موبایل، در دوری جدا از شمارش‌ها.

گزینه	اسکریپت‌های صفحه فروشگاه	نمره Lighthouse موبایل	سربرگ سبد برای بازدیدکننده‌ای که با سبد پر برگشته
بدون راکت	۱۵ اسکریپت، ۶۱٫۸ کیلوبایت	۹۴	درست
تنظیمات بعد از فعال‌سازی	۱۴، ۶۵٫۳	۹۸	درست
ادغام فایل‌های جاوا اسکریپت	۲، ۵۶٫۹	۹۹	درست
بارگذاری جاوا اسکریپت به صورت تاخیری	۱۴، ۶۵٫۳	۹۸	درست
تاخیر اجرا	۱، ۸٫۵	۹۹	۵ بار از ۵ «0 مورد»
تاخیر اجرا و Cart Fragments	۴، ۴۱٫۹	۹۹	درست
تاخیر اجرا و چهار مورد ووکامرس	۶، ۵۱٫۱	۹۸	درست
تاخیر اجرا با حالت ایمن	۱۴، ۶۵٫۳	۹۸	درست
لیزی لود تصاویر	۱۵، ۶۸٫۷	۹۴	درست
افزودن ابعاد به تصاویر	۱۴، ۶۵٫۳	۹۸	درست
همه	۲، ۱۱٫۹	۹۸	۵ بار از ۵ «0 مورد»

در همه ردیف‌ها هر ۱۵ گام با ماوس درست رفت؛ ردیف‌های تاخیر اجرا و «همه» را با لمس هم رفتیم.

تاخیر اجرا اسکریپت‌ها را می‌برد و شمارنده سبد را هم دیر می‌آورد

تاخیر اجرا هر اسکریپتی را که در HTML صفحه است نگه می‌دارد تا بازدیدکننده ماوس را حرکت دهد، صفحه را لمس یا پیمایش کند یا کلیدی بزند. حجم صفحه فروشگاه از ۳۲۲ به ۲۶۹ کیلوبایت رسید، ولی نمره Lighthouse فقط از ۹۸ به ۹۹: فروشگاه سبک است و زمان مسدودشدن مرورگر (TBT) از اول ۰ بود.

اولین کلیک روی دکمه افزودن به سبد گم نمی‌شود: راکت آن را نگه می‌دارد و بعد از اجرای اسکریپت‌ها دوباره می‌فرستد. این را جدا از آن ۱۵ گام سنجیدیم، با ۳۰ بازدیدکننده تازه با ماوس و ۳۰ با لمس برای هر پیکربندی. در «تاخیر اجرا» اولین کلیک ماوس بعد از باز شدن صفحه، بدون حرکت قبلی، ۳۰ بار از ۳۰ همان‌جا کالا را به سبد اضافه کرد. اولین ضربه لمسی ۲۸ بار از ۳۰ همان‌جا اضافه کرد و ۲ بار صفحه با پیوند افزودن دوباره بارگذاری شد، که کالا را هم به سبد برد. چنین بارگذاری دوباره‌ای روی هم ۶ بار از ۲۴۰ بود، در چهار پیکربندی: «تاخیر اجرا»، «تاخیر اجرا و Cart Fragments»، «تاخیر اجرا و چهار مورد ووکامرس» و همان با تیک Storefront هم. در «بدون راکت» و «تنظیمات بعد از فعال‌سازی» ۰ بار از ۱۲۰ بود.

سربرگ فرق دارد. HTML کش‌شده «0 مورد» دارد و کدی که عدد را با سبد واقعی عوض می‌کند، یعنی cart-fragments.js ووکامرس، با jQuery جزو اسکریپت‌های نگه‌داشته‌شده است. بازدیدکننده‌ای که کالایی در سبد داشت و صفحه فروشگاه را از تب تازه باز کرد، بعد از ۶ ثانیه بی‌حرکتی هم «0 مورد» می‌دید؛ عدد درست حدود ۰٫۳۵ ثانیه بعد از چند حرکت ماوس آمد.

راکت برای همین «موارد استثنا با یک کلیک» دارد؛ قالب و افزونه فقط وقتی در آن می‌آیند که فعال باشند (در کد). در فروشگاه ما Storefront و چهار مورد ووکامرس بود، که Cart Fragments یکی از آن چهار است. تیک Cart Fragments به‌تنهایی کافی بود: ۱٫۵ ثانیه بعد از باز شدن صفحه و بدون هیچ حرکتی سربرگ درست بود، ۵ بار از ۵ با ماوس و ۵ از ۵ با لمس، و صفحه فروشگاه ۴ اسکریپت (۴۱٫۹ کیلوبایت) گرفت، به‌جای ۱.

سه چیز دیگر:

• منوی اصلی Storefront هم تا اولین حرکت جمع بود (ارتفاع ۰ به‌جای ۷۸ پیکسل)، و تیک «Storefront» آن را در لحظه بارگذاری عوض نکرد.
• گالری و برگه‌های محصول بدون هیچ تیکی درست کار کردند: در صفحه محصولی که تصویر گالری دارد، راکت اسکریپت‌های زوم، اسلایدر و single-product را خودش از تاخیر بیرون می‌گذارد (در کد).
• حالت ایمن چیزی را خراب نکرد، چون تقریباً هیچ اسکریپتی را به تاخیر نمی‌اندازد: ۱۴ اسکریپت، مثل حالت بدون تاخیر.

با قالب Woodmart (نگارش ۸٫۶٫۴، زیپ فروشگاه) همین رفتار با اثر بزرگ‌تر دیده شد: ۵۲ اسکریپت و نمره ۸۱ با تنظیمات بعد از فعال‌سازی، ۱ اسکریپت و نمره ۹۴ با تاخیر اجرا. وقتی کش را خریداری با یک کالا در سبد ساخته بود، بازدیدکننده‌ای با سبد خالی تا اولین حرکت «1 item» می‌دید. تیک Woodmart - Cart Fragments این را درست کرد (۶ اسکریپت، نمره ۹۱)، و تیک همه موارد Woodmart و چهار مورد ووکامرس اسکریپت‌ها را به ۴۰ و نمره را به ۸۳ برگرداند.

کش صفحه را همان کسی می‌سازد که اول می‌رسد

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

بعد از خالی کردن کش، خریداری با یک کالا (۱۲۵ هزار تومان) اول صفحه فروشگاه را باز کرد و بازدیدکننده بعدی، بی‌کوکی و با سبد خالی، در HTML همان «1 مورد» و ۱۲۵ هزار تومان را گرفت. با تنظیمات بعد از فعال‌سازی، کد ووکامرس تا ۱٫۵ ثانیه آن را به «0 مورد» برگرداند (۳ بار از ۳، با ماوس و با لمس). با تاخیر اجرا، بازدیدکننده تا اولین حرکت سبد یک نفر دیگر را می‌دید، ۳ بار از ۳ در هر دو حالت. تیک Cart Fragments این را هم درست کرد، با ماوس و با لمس.

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

ما woocommerce_items_in_cart را در «کوکی‌هایی که هرگز کش نخواهند شد» (قوانین پیشرفته) نوشتیم. فایل کش از بازدیدکننده بدون سبد ساخته شد و عدد از اولین لحظه درست بود، ۳ بار از ۳ با ماوس و با لمس، حتی با تاخیر اجرای بدون استثنا. بهایش این است که صفحه بازدیدکننده‌ای که کالا در سبد دارد دیگر از کش نمی‌آید و بهینه هم نمی‌شود: ۰ اسکریپت تاخیری و ۰ CSS فشرده در آزمایش ما.

سبد خرید، تسویه حساب و صفحه‌های با کوئری استرینگ بهینه نمی‌شوند

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

صفحه‌های با کوئری استرینگ هم همین‌طور بودند: صفحه فروشگاه با orderby=price، فیلتر قیمت با min_price، فیلتر filter_color=red و جستجو با s نه کش شدند و نه بهینه (۰ اسکریپت تاخیری، ۰ CSS فشرده)، و utm_source=x کش شد. با نوشتن orderby در «کش کردن کوئری استرینگ‌ها» (قوانین پیشرفته)، صفحه فروشگاه با orderby=price از درخواست دوم کش شد و بهینه بود. filter_color=red همچنان نه.

لیزی لود نمره را پایین آورد و بقیه گزینه‌ها چیزی را خراب نکردند

ادغام فایل‌های جاوا اسکریپت، صفحه فروشگاه را از ۱۴ به ۲ اسکریپت و از ۶۵٫۳ به ۵۶٫۹ کیلوبایت رساند و هر ۱۵ گام درست رفت. خود راکت در توضیح این گزینه می‌نویسد برای سایتی که HTTP/2 دارد توصیه نمی‌شود، و هشدار می‌دهد که ممکن است بعضی چیزها را خراب کند. بارگذاری تاخیری و افزودن ابعاد به تصاویر تعداد و حجم را عوض نکردند.

لیزی لود تصاویر، تصویرهایی را که هنگام باز شدن صفحه فروشگاه گرفته می‌شوند، از ۹ به ۴ رساند و حجم کل را از ۳۲۲ به ۲۹۷ کیلوبایت. ولی نمره Lighthouse از ۹۸ به ۹۴ رسید: بزرگ‌ترین محتوای صفحه (LCP) از ۲٫۱ به ۲٫۷ ثانیه رسید. در ردیف «همه» که لیزی لود هم دارد نمره ۹۸ ماند (LCP ۲٫۳ ثانیه) و علتش را نسنجیدیم.

فشرده‌سازی CSS و جاوا اسکریپت را راکت بعد از فعال‌سازی خودش روشن می‌کند و در این فروشگاه چیزی کم نکرد: CSS ۴۰٫۸ کیلوبایت با آن و ۴۰٫۸ بدون آن، جاوا اسکریپت ۶۵٫۳ هر دو. مستندات ووکامرس برای راکت توصیه می‌کند از فشرده‌سازی فایل‌های جاوا اسکریپت پرهیز کنید، و در آزمایش ما با روشن بودنش چیزی خراب نشد. گزینه‌های «حذف CSS استفاده‌نشده» و بقیه گزینه‌های ابری راکت را آزمایش نکردیم: در محیط محلی خاموش‌اند.

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

1. فروشگاه را از پنجره ناشناس مرورگر ببینید، نه با حساب مدیر، و هر بار فقط یک گزینه را روشن کنید (روش خود راکت).
2. فشرده‌سازی را همان‌طور که راکت گذاشته نگه دارید، ولی اگر چیزی خراب شد فشرده‌سازی جاوا اسکریپت را اول خاموش کنید، چون ووکامرس از آن پرهیز را توصیه می‌کند. لیزی لود را فقط اگر نمره LCP بعد از آن بدتر نشد نگه دارید.
3. تاخیر اجرا را با تیک Cart Fragments یا مورد سبد خرید قالبتان روشن کنید. مورد دیگری را فقط برای چیزی که خراب دیدید اضافه کنید و دوباره بسنجید، چون در Woodmart تیک همه موارد Woodmart و چهار مورد ووکامرس اسکریپت‌ها را از ۱ به ۴۰ برگرداند.
4. اگر Cart Fragments کافی نبود و عدد سبد قالبتان را PHP می‌سازد، woocommerce_items_in_cart را در «کوکی‌هایی که هرگز کش نخواهند شد» بنویسید، با بهایی که در بخش کش گفتیم.
5. کوئری استرینگ‌هایی را که فروشگاهتان می‌سازد، مثل orderby، در «کش کردن کوئری استرینگ‌ها» بنویسید.

بعد از هر گام این شش را امتحان کنید:

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

اگر چیزی خراب شد، همان آدرس را با کوئری استرینگ nowprocket=1 باز کنید: راکت آن را بدون هیچ بهینه‌سازی نشان می‌دهد (در آزمایش ما هیچ اسکریپتی تاخیر نداشت و CSS فشرده نبود). اگر با آن درست بود، گزینه‌ای که روشن کرده‌اید مقصر است. خطای کنسول مرورگر اسکریپتی را که باید از تاخیر بیرون بگذارید نشان می‌دهد (مستندات راکت). اگر نمی‌خواهید خودتان دنبال مقصر بگردید، درخواست پشتیبانی را ثبت کنید.

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

پرسش‌های متداول