فهرست مقاله
آیا در انتخاب نوع جاسازی مناسب برای W3 Total Cache Minify مشکل دارید؟ این مقاله تجربه واقعی یک مدیر وب را به اشتراک میگذارد و یک راهنمای گام به گام برای انتخاب دقیق نوع جاسازی مناسب Minify ارائه میدهد تا از اشتباهات در طراحی وبسایت و خرابیهای بارگذاری جلوگیری شود. همچنین شامل یک راه حل راهاندازی بینقص است که حتی مبتدیان نیز میتوانند به راحتی آن را اعمال کنند و یک تجربه روان و سریع وردپرس را تضمین کنند!
من در حال بهینهسازی یک وبسایت بودم و وقتی تنظیمات Minify را در W3 Total Cache باز کردم، کاملاً مات و مبهوت شدم. منوی کشویی برای نوع جاسازیشده چهار گزینه داشت: پیشفرض (Block)، استفاده از JS برای غیر مسدودکننده، استفاده از "Asynchronous" برای غیر مسدودکننده و استفاده از "Delayed" برای غیر مسدودکننده.
یه لحظه به این فکر کردم که این همه دردسر برای چیه؟
باور کنید، شما تنها نیستید. این چهار گزینه احتمالاً حتی یک تازهکار را هم گیج میکند، چه برسد به کسی که سالهاست از وردپرس استفاده میکند. این مقاله، مشکلاتی را که من با آنها مواجه شدهام و درسهایی را که مستقیماً آموختهام، ارائه میدهد. نیازی به مراجعه به مستندات نیست؛ فقط دستورالعملهای من را دنبال کنید.
این چهار نوع جاسازی دقیقاً چیستند؟
بیایید ابتدا در مورد اینکه این چهار گزینه چه نوع شخصیتی هستند صحبت کنیم.
مسدود کردن پیشفرض ، سادهترین رویکرد است. وقتی مرورگر با یک اسکریپت مواجه میشود، آن را متوقف میکند، اسکریپت را بهطور کامل دانلود و اجرا میکند و سپس به رندر کردن صفحه ادامه میدهد. به نظر قابل اعتماد میرسد، درست است؟ اما در عوض، بارگذاری اولیه صفحه شما با تأخیر انجام میشود؛ کاربران باید منتظر بمانند تا اجرای اسکریپت تمام شود تا بتوانند چیزی ببینند.
استفاده از جاوا اسکریپت برای عدم انسداد بسیار جالب است. به جای نوشتن مستقیم تگهای `<script>` در صفحه، ابتدا یک اسکریپت کوچک را خروجی میدهد و سپس پس از اجرای صفحه، اسکریپتهای لازم را از طریق جاوا اسکریپت به صورت پویا به صفحه تزریق میکند. به این ترتیب، صفحه میتواند ابتدا رندر شود و اسکریپتها به تدریج بارگذاری شوند. عالی به نظر میرسد، درست است؟ با این حال، مشکل این است که این فرآیند تزریق پویا میتواند ترتیب اجرای اصلی اسکریپتها را مختل کند. اگر برخی از اسکریپتهای صفحه شما به شدت به ترتیب اجرا وابسته باشند، ممکن است مشکلاتی ایجاد شود.
استفاده از "asynchronous" برای اجرای غیر مسدودکننده، صرفاً شامل اضافه کردن ویژگی `async` به تگ `<script>` است. اسکریپت به صورت ناهمزمان در پسزمینه دانلود میشود و بلافاصله پس از اتمام، بدون اینکه صفحه منتظر آن باشد، اجرا میشود. با این حال، اشکال این است که ترتیب اجرا کاملاً غیرقابل کنترل است؛ هر چیزی که ابتدا دانلود شود، صرف نظر از ترتیبی که در کد مشخص میکنید، اجرا میشود.
استفاده از "delay" برای اجرای غیر مسدودکننده با اضافه کردن ویژگی `defer` محقق میشود. اسکریپت قبل از اجرا منتظر میماند تا کل صفحه تجزیه شود و از همه مهمتر، ترتیب اصلی که شما آن را نوشتهاید را حفظ میکند. این روش کاملاً کاربرپسند است، زیرا نه صفحه اول را مسدود میکند و نه ترتیب اسکریپت را به هم میزند.
کدام یک را باید انتخاب کنم؟
به عبارت ساده، این چهار گزینه مانند یک سوال چند گزینهای هستند: آیا سرعت میخواهید یا ترتیب؟
پیشنهاد من به شرح زیر است:
اگر وبسایت شما کوچک است، اسکریپتهای کمی دارد و الزامات سرعت بارگذاری خیلی بالایی ندارید، استفاده از تنظیمات پیشفرض (مسدود شده) سادهترین گزینه است. اگرچه کمی کندتر است، اما مشکلی ایجاد نمیکند.
اگر میخواهید سرعت نمایش اولیه را بهبود بخشید و اسکریپتهای شما وابستگیهای قوی مانند «A باید قبل از B اجرا شود» ندارند، استفاده از «defer» را برای اجرای بدون انسداد در اولویت قرار دهید . این تقریباً راهحل ایدهآلی است که در حال حاضر موجود است، زیرا از انسداد رندر جلوگیری میکند و در عین حال ترتیب اجرا را حفظ میکند.
اگر متوجه شدید که برخی از توابع پس از امتحان کردن defer هنوز مشکل دارند، استفاده از جاوا اسکریپت را برای non-blocking در نظر بگیرید . این رویکرد تهاجمیتر است، اما سازگاری آن کمی بدتر است.
استفاده از "async" برای عدم انسداد، گزینهای است که من کمترین توصیه را به آن میکنم. از آنجا که ترتیب اجرا کاملاً به هم میریزد، به راحتی ممکن است از کار بیفتد، مگر اینکه کاملاً مطمئن باشید که اسکریپتهای شما به طور مستقل اجرا میشوند.
دو دام بزرگی که در آنها افتادم
حرف زدن کار راحتی نیست. من دو اشتباهی که مرتکب شدم را یادداشت کردهام؛ میتوانید آنها را با تجربیات خودتان مقایسه کنید تا ببینید آیا میتوانید از آنها اجتناب کنید یا خیر.
اولین مشکل: قالبهای سفارشی وردپرس را نمیتوان به صورت زنده پیشنمایش کرد.
مدتی بود که هنگام سفارشیسازی یک قالب، پس از کلیک روی ذخیره، پیشنمایش بهروزرسانی نمیشد. من تغییراتی ایجاد میکردم، صفحه را بهروزرسانی میکردم و همچنان به همان شکل باقی میماند.
بعد از کمی تحقیق، متوجه شدم که تابع فشردهسازی Minify مقصر است. راه حل ساده است:
به تنظیمات عمومی افزونه W3 Total Cache بروید ، گزینه "فشردهسازی" را پیدا کنید و تیک آن را بردارید. سپس، روی فلش کوچک زیر "ذخیره تنظیمات" در گوشه بالا سمت راست کلیک کنید و " ذخیره تنظیمات و پاک کردن حافظه پنهان " را انتخاب کنید. این مرحله بسیار مهم است؛ بدون پاک کردن حافظه پنهان، همچنان نسخه قدیمی را مشاهده خواهید کرد.
بعد از اینکه کارتان تمام شد، به سفارشیسازی قالب برگردید و پیشنمایش زنده به حالت عادی برمیگردد.
مشکل دوم: کادر جستجوی قالب آسترا هنگام کلیک پاسخ نمیدهد.
مدتی پیش با این مشکل مواجه شدم. من از قالب آسترا استفاده میکردم و یک روز ناگهان متوجه شدم که کادر جستجو هر چقدر هم که روی آن کلیک میکردم، پاسخ نمیدهد. در ابتدا فکر کردم مشکل از خود قالب است، اما بعداً متوجه شدم که به دلیل تنظیمات Minify در W3TC است.
راه حل به شرح زیر است:
به W3 Total Cache → General Settings → Advanced Compression Settings → JS → Minify Engine Settings → Locale Settings بروید و نوع جاسازی را به یکی از این دو مورد تغییر دهید:
- پیش از این، عدم انسداد با استفاده از جاوا اسکریپت حاصل میشد.
- پس از آن، از JS برای عدم انسداد استفاده کنید
به طور مشابه، پاک کردن حافظه پنهان و رفرش کردن صفحه باعث میشود کادر جستجو به درستی کار کند.
در مورد اینکه چرا این دو گزینه به جای گزینههای دیگر انتخاب شدهاند، من کمی تحقیق کردهام. به عبارت ساده، اجزای front-end قالب Astra به زمان اجرای اسکریپت بسیار حساس هستند و برخی از روشهای non-blocking میتوانند باعث عدم موفقیت اتصال رویداد شوند. استفاده از حالت "non-blocking with JS" تضمین میکند که اسکریپت فقط پس از اتمام بارگذاری صفحه اجرا میشود، در حالی که از اجرای نامنظمی که با async مشاهده میشود، جلوگیری میکند.
فهرست مکانهای مورد بازدید
در نهایت، در اینجا یک چک لیست وجود دارد که میتوانید مستقیماً آن را دنبال کنید:
اولین قدم این است که هدف خود را مشخص کنید. آیا میخواهید سریعترین بارگذاری اولیه صفحه را داشته باشید یا اولویت شما ثبات و عملکرد بدون خطا است؟ این مشخص میکند که از کدام نوع جاسازی باید استفاده کنید.
قدم دوم این است که همه چیز را یکجا تغییر ندهید. ابتدا، یک صفحه کماهمیتتر را برای آزمایش پیدا کنید، آن را برای یک یا دو روز مشاهده کنید و فقط در صورتی که مطمئن شدید مشکلی وجود ندارد، آن را در کل سایت تبلیغ کنید.
سوم، همیشه بعد از هر تغییر، حافظه پنهان را پاک کنید. مکانیزم ذخیرهسازی W3TC مانع از مشاهده آخرین تغییرات میشود، بنابراین مرحله «پاک کردن حافظه پنهان و آزمایش مجدد» کاملاً ضروری است.
چهارم، از ابزارهای توسعهدهنده مرورگر خود یا ابزارهایی مانند PageSpeed Insights برای مقایسه سرعت بارگذاری قبل و بعد استفاده کنید. اجازه دهید دادهها خودشان گویای همه چیز باشند، نه فقط احساس درونی شما.
در پایان بنویسید
راستش را بخواهید، وقتی برای اولین بار این تنظیم نوع تعبیهشده را دیدم، مدت زیادی مبهوت ماندم. حالت مسدودکننده پیشفرض خیلی کند به نظر میرسید، در حالی که حالت ناهمزمان ترتیب را تضمین نمیکرد و به تعویق انداختن ممکن بود باعث مشکلات سازگاری شود. در مورد انتخاب گزینه مطمئن نبودم.
اما بعداً متوجه شدم که این یک بده بستان است. شما نمیتوانید هم سریعترین و هم پایدارترین را داشته باشید؛ همیشه باید یکی را فدا کنید. تجربه من این است که ابتدا از defer استفاده میکنم، که در حال حاضر امنترین راهحل غیر مسدودکننده است، و سپس در صورت بروز مشکل از callback استفاده میکنم.
اگر با مشکلات مشابهی روبرو شدید، یا اگر پس از دنبال کردن روش من هنوز مشکلات دیگری دارید، در مورد آن بحث کنید. توسعه وبسایت تماماً در مورد آزمون و خطا است؛ هیچکس از این قاعده مستثنی نیست.
ممنون که مقاله من را خواندید. دفعه بعد میبینمتان.
امیدوارم مقاله «تنظیمات افزونه W3 Total Cache Minify: چگونه نوع جاسازی را انتخاب کنیم؟ مشکلات و توصیههای نجاتبخش من» که در وبلاگ چن ویلیانگ ( https://www.chenweiliang.com/ ) به اشتراک گذاشته شده است، برای شما مفید باشد.
لینک این مقاله را به اشتراک بگذارید: https://www.chenweiliang.com/cwl-34003.html