تنظیمات افزونه W3 Total Cache Minify: چگونه نوع جاسازی را انتخاب کنیم؟ تجربه عیب‌یابی و توصیه‌های نجات‌بخش من

آیا در انتخاب نوع جاسازی مناسب برای W3 Total Cache Minify مشکل دارید؟ این مقاله تجربه واقعی یک مدیر وب را به اشتراک می‌گذارد و یک راهنمای گام به گام برای انتخاب دقیق نوع جاسازی صحیح Minify ارائه می‌دهد تا از ناهماهنگی‌های سبک وب‌سایت و خرابی‌های بارگیری جلوگیری شود. همچنین شامل یک راه حل راه‌اندازی بی‌نقص است که حتی مبتدیان نیز می‌توانند به راحتی از آن استفاده کنند.وردپرس بدون تصادف شتاب بگیرید!

من در حال بهینه‌سازی یک وب‌سایت بودم و وقتی تنظیمات Minify را در W3 Total Cache باز کردم، کاملاً مات و مبهوت شدم. منوی کشویی برای نوع جاسازی‌شده چهار گزینه داشت: پیش‌فرض (Block)، استفاده از JS برای غیر مسدودکننده، استفاده از "Asynchronous" برای غیر مسدودکننده و استفاده از "Delayed" برای غیر مسدودکننده.

یه لحظه به این فکر کردم که این همه دردسر برای چیه؟

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

این چهار نوع جاسازی دقیقاً چیستند؟

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

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

استفاده از JS برای عدم انسداداین کاملاً جالب است. به جای نوشتن مستقیم تگ‌های `<script>` در صفحه، ابتدا یک اسکریپت کوچک را خروجی می‌دهد و سپس اسکریپت‌هایی را که باید پس از اجرای صفحه از طریق جاوا اسکریپت بارگذاری شوند، به صورت پویا تزریق می‌کند. به این ترتیب، صفحه می‌تواند ابتدا رندر شود و اسکریپت‌ها می‌توانند به تدریج بارگذاری شوند. عالی به نظر می‌رسد، درست است؟ با این حال، مشکل این است که این فرآیند تزریق پویا ممکن است ترتیب اجرای اصلی اسکریپت‌ها را مختل کند. اگر برخی از اسکریپت‌های صفحه شما به شدت به ترتیب اجرا وابسته باشند، ممکن است مشکلاتی ایجاد شود.

برای عدم انسداد از "ناهمزمان" استفاده کنیداین شامل اضافه کردن ویژگی `async` به تگ `<script>` است. اسکریپت به صورت غیرهمزمان در پس‌زمینه دانلود می‌شود و بلافاصله پس از دانلود، بدون اینکه صفحه منتظر آن باشد، اجرا می‌شود. با این حال، نکته منفی این است که ترتیب اجرا کاملاً غیرقابل کنترل است؛ هر اسکریپتی که دانلودش زودتر تمام شود، صرف نظر از ترتیبی که در کد مشخص کرده‌اید، زودتر اجرا می‌شود.

استفاده از "تأخیر" برای عدم انسداداین همان چیزی است که اضافه کردن ویژگی `defer` به آن معنی می‌دهد. اسکریپت قبل از اجرا منتظر می‌ماند تا کل صفحه تجزیه شود و مهمتر از همه، ترتیب اصلی که شما آن را نوشته‌اید را حفظ می‌کند. این کاملاً کاربرپسند است، زیرا نه صفحه اول را مسدود می‌کند و نه ترتیب را مختل می‌کند.

کدام یک را باید انتخاب کنم؟

به عبارت ساده، این چهار گزینه مانند یک سوال چند گزینه‌ای هستند:سرعت می‌خواهید یا نظم؟

پیشنهاد من به شرح زیر است:

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

اگر می‌خواهید سرعت نمایش در صفحه اول را بهبود بخشید و اسکریپت‌های شما وابستگی‌های قوی مانند «A باید قبل از B اجرا شود» ندارند، اولویت‌بندی کنید...استفاده از "تأخیر" برای عدم انسداد(به تعویق انداختن). این تقریباً ایده‌آل‌ترین راه‌حل در حال حاضر است، زیرا نه رندر را مسدود می‌کند و نه ترتیب را مختل می‌کند.

اگر امتحان کردید و متوجه شدید که برخی از توابع مشکل دارند، در نظر بگیرید...استفاده از JS برای عدم انسداداین راه حل رادیکال تر است، اما سازگاری آن کمی بدتر است.

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

دو دام بزرگی که در آنها افتادم

حرف زدن کار راحتی نیست. من دو اشتباهی که مرتکب شدم را یادداشت کرده‌ام؛ می‌توانید آنها را با تجربیات خودتان مقایسه کنید تا ببینید آیا می‌توانید از آنها اجتناب کنید یا خیر.

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

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

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

دسترسی به افزونه W3 Total Cache常规设置، ظهور کن"فشرده سازی"تیک آن گزینه را بردارید. سپس روی فلش کوچک زیر «ذخیره تنظیمات» در گوشه بالا سمت راست کلیک کنید و «...» را انتخاب کنید.تنظیمات را ذخیره کنید و حافظه پنهان را پاک کنیداین مرحله بسیار مهم است؛ اگر حافظه پنهان را پاک نکنید، همچنان نسخه قدیمی را مشاهده خواهید کرد.

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

مشکل دوم: کادر جستجوی قالب آسترا هنگام کلیک پاسخ نمی‌دهد.

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

راه حل به شرح زیر است:

به W3 Total Cache → General Settings → Advanced Compression Settings → JS → Minify Engine Settings → Locale Settings بروید و نوع جاسازی را به یکی از این دو مورد تغییر دهید:

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

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

در مورد اینکه چرا این دو گزینه به جای گزینه‌های دیگر انتخاب شده‌اند، من کمی تحقیق کرده‌ام. به عبارت ساده، اجزای front-end قالب Astra به زمان اجرای اسکریپت بسیار حساس هستند و برخی از روش‌های non-blocking می‌توانند باعث عدم موفقیت اتصال رویداد شوند. استفاده از حالت "non-blocking with JS" تضمین می‌کند که اسکریپت فقط پس از اتمام بارگذاری صفحه اجرا می‌شود، در حالی که از اجرای نامنظمی که با async مشاهده می‌شود، جلوگیری می‌کند.

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

در نهایت، در اینجا یک چک لیست وجود دارد که می‌توانید مستقیماً آن را دنبال کنید:

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

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

سوم، همیشه بعد از هر تغییر، حافظه پنهان را پاک کنید. مکانیزم ذخیره‌سازی W3TC مانع از مشاهده آخرین تغییرات می‌شود، بنابراین مرحله «پاک کردن حافظه پنهان و آزمایش مجدد» کاملاً ضروری است.

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

در پایان بنویسید

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

اما بعداً متوجه شدم که این یک بده بستان است. شما نمی‌توانید هم سریع‌ترین و هم پایدارترین را داشته باشید؛ همیشه باید یکی را فدا کنید. تجربه من این است که ابتدا از defer استفاده می‌کنم، که در حال حاضر امن‌ترین راه‌حل غیر مسدودکننده است، و سپس در صورت بروز مشکل از callback استفاده می‌کنم.

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

ممنون که مقاله من را خواندید. دفعه بعد می‌بینمتان.