آموزش راه اندازی و تنظیمات افزونه W3 Total Cache در وردپرس – ناجیان وب | دانلود اسکریپتناجیان وب
[ad_1]
عجیب است که هرچقدر سرعت و کیفیت اینترنت بالا تر میرود، کاربران اینترنت، بی حوصله تر شده و کمتر از همیشه حاضرند برای بارگذاری یک وبسایت منتظر بمانند. واقعیت این است که امروز، سرعت بارگذاری یک وبسایت میتواند نقش مهمی را در جذب تعداد مخاطبین بیشتر و داشتن ترافیک بالاتر برای یک سایت ایفا میکند. داشتن یک وبسایت سریع، جدا از انتخاب یک هاستینگ مناسب و انتخاب پلاگین هایی به شکل مناسبی طراحی شده اند، به استفاده از CDN و پلاگین های کش نیز بستگی دارد. هدف ما هم از نوشتن این مقاله، دقیقا همین است. قرار است در آموزش امروز، نحوه ی راه اندازی و اعمال تنظیمات صحیح بر روی یکی از بهترین پلاگین های کش وردپرس را با هم بررسی نماییم.
اما کاری که لازم است پیش برداشتن هر قدم دیگر انجام دهید این است که وبسایت خود را با مراجعه به یکی از دو سایت Google Page Speed یا Pingdom Tools مورد بررسی قرار داده و ببینید این دو سرویس به سایت شما چه رتبه ای میدهند. در پایان میخواهیم از همین دو سرویس برای سنجش مقدار موفقیتمان در بهینه سازی سایت استفاده کنیم. در زیر میتوانید نمونه ای از نتیجه ی سنجش وبسایت MrCode را توسط Pingdom Tools مشاهده نمایید :
![آموزش راه اندازی و تنظیمات افزونه W3 Total Cache در وردپرس - نتیجه تست سایت در پینگدام تولز]()
خوب، حالا دیگر به سراغ اصل ماجرا میرویم …
W3 Total Cache دقیقا چه نوع افزونه ای است؟
W3 Total Cache که از اینجا به بعد آن را W3TC صدا خواهیم کرد، یکی از قدرتمند ترین و سریع ترین افزونه کش و بهینه سازی کارکرد سایت، برای وردپرس است. این افزونه در سراسر جهان محبوبیت بسیاری دارد و وبسایت های بزرگی مثل AT&T, Mashable و Smashing Magazine از آن استفاده میکنند. (نتیجه هم که کاملا قابل مشاهده و بررسی است) کار این افزونه این است که با بهینه سازی سایت شما میتواند کارکرد سایت را بهبود بخشیده و در واقع به کاربر تجربه ی بهتری از کار با سایت ارائه کند. در عین حال این پلاگین با به کار گیری متد های caching و استفاده از CDN میتواند باری که سایت شما بر روی سرور میگذارد را به شکل چشمگیری کاهش دهد. یکی از امتیازات دیگر این افزونه، این است که در واقع تنظیمات آن بسیار آسان است. تا حدی که پس از آشنایی با بخش های مختلف آن، میتوانید سایت های جدید خود را طی کمتر از ۱۵ دقیقه با استفاده از آن بهینه سازی کنید!
نصب افزونه W3 Total Cache
نصب این افزونه هم مانند نصب تمامی افزونه های دیگر در وردپرس بسیار ساده است. فقط باید به یک نکته ی مهم توجه داشته باشید و آن نکته این است که اگر افزونه کش دیگری مثلا WP Super Cache را از پیش روی سایتتان نصب کرده اید، باید حتما قبل از نصب W3TC آن افزونه را غیر فعال کرده و از وردپرس حذف نمایید. وگرنه در هنگام فعالسازی W3TC با مشکل مواجه خواهید شد.
برای نصب W3TC از منوی افزونه ها، افزودن را انتخاب نمایید و سپس در باکس مربوط به جستجو، عبارت “W3 Total Cache” را تایپ نمایید.
![آموزش راه اندازی و تنظیمات افزونه W3 Total Cache در وردپرس]()
در اینجا فقط کافی است روی دکمه “نصب” کلیک کنید تا پلاگین بر روی سیستم شما نصب شود و در پایان پلاگین را بر روی سیستم خود فعال کنید.
تنظیمات پلاگین W3 Total Cache
افزونه W3 Total Cache، افزونه ای بی نهایت پر قدرت است. و از آنجایی که در سیستم های کامپیوتری و سیستم های تحت وب، معمولا قدرت مساوی تنظیمات پیچیده است، این پلاگین نیز پر از تنظیماتی است که یک کاربر تازه کار ممکن است در نگاه اول به این تنظیمات، واقعا گیج شده و احساس سردرگمی کند. اما واقعیت این است که شما با معدنی از طلا روبرو هستید که در صورت اعمال تنظیمات صحیح، میتواند برای شما کاری در حد معجزه انجام دهد. بنابراین نگران نباشید و خودتان را سردرگم نکنید. در ادامه مفصلا به شرح این تنظیمات خواهیم پرداخت.
تنظیمات عمومی – General Settings
پیش از هر چیز خدا ایرانی های عزیز را خیر بدهد که این یک پلاگین را ترجمه نکردند. ( دو نقطه دی!!) چون بعضی از ترجمه هایی که برای پلاگین های حرفه ای ارائه میشود واقعا بیش از حد نامفهوم و گیج کننده است!
برای مشاهده بخش تنظیمات عمومی، کافی است از منوی Performance، به زیر منوی General Settings بروید. در اینجا حواستان باشد که اشتباها به داشبورد پلاگین نرفته باشید و دقیقا در صفحه تنظیمات عمومی قرار داشته باشید.
![آموزش راه اندازی و تنظیمات افزونه W3 Total Cache در وردپرس]()
خوب؛ همانطور که از نام این بخش کاملا مشخص است، در اینجا کلیه ی تنظیمات پایه ای و عمومی این افزونه در اختیار ما قرار میگیرند. با هم به مرور این تنظیمات میپردازیم. توجه داشته باشید که تنظیم اول در این صفحه همان تب اصلی “General” است که برای فعال یا غیر فعال کردن همزمان تمامی تنظیمات به کار میرود و ما به آن کاری نداریم. کار ما از Page Cache آغاز میشود.
Page Cache
تنظیمات Page Cache یا کش صفحات یا مخزن صفحات وظیفه اش این است که تمامی صفحاتی که بارگذاری میشوند، یک نسخه ایستا (static) ایجاد نماید. فایده ی این کار این است که وقتی از یک صفحه، یک نسخه ی ایستا تولید شده باشد، کاربران برای مشاهده آن نیازی به بارگذاری داینامیک آن ندارند و صفحه به عنوان یک محتوای static به آنها ارسال خواهد شد. این امکان میتواند به شکل چشمگیری زمان لود صفحات شما را کاهش دهد. به عنوان یک مثال خوب و قابل درک، میتواند تصویر زیر را مشاهده کنید :
![کاربرد کش کردن صفحات و سرو به صورت استاتیک]()
همانطور که میبینید، در حالت عادی اتفاقی که می افتد این است که وقتی کاربری به وبسایت شما مراجعه کرده و درخواست خودش را برای مشاهده یک صفحه به وردپرس ارسال کند، وردپرس ابتدا اسکریپت PHP مربوط به درخواست را اجرا کرده و اسکریپت اجرا شده، درخواست های لازم را به MySQL ارسال میکند، سپس کد های صفحه ای که کاربر درخواست کرده تبدیل به محتوای HTML قابل درک برای مرورگر میشود و بعد صفحه به کاربر ارسال میشود تا کاربر آن را مشاهده کند. همانطور که میبینید این پروسه زمانبر بوده و از ریسورس زیادی بر روی سرور استفاده میکند. استفاده از page cache باعث میشود که وردپرس یک محتوای ایستا از صفحات مورد درخواست را در محلی ذخیره کند و سپس در هنگام درخواست صفحه توسط کاربر، محتوای ایستا را برای کاربر ارسال کند.
![تنظیمات کش و مخزن صفحات]()
همانطور که حتما تا حالا متوجه شده اید و تصویر بالا هم مشخص است، صفحات به شیوه های مختلفی قابل کش کردن هستند (Page Cache Method). در اکثر هاستینگ های اشتراکی و برای اکثر کاربران، بهترین انتخاب همان انتخاب پیشفرض، یعنی Disk: Enhanced است. بعضی از هاستینگ ها ممکن است شیوه های دیگری را نیز در اختیار شما بگذارند ولی توصیه میشود که با دقت و توجه زیاد این شیوه ها را انتخاب کنید. یکی از بهترین انتخاب ها در این میان استفاده از APC خواهد بود. متاسفانه در عین بالا بودن کارائی APC، این شیوه بر روی سرورهایی که مجبور به ارائه Zend Optimizer هستند، قابل فعالسازی و ارائه نیست اما اگر قرار است خودتان یک سرور را برای خودتان کانفیگ کنید، این یکی از جالب ترین و موثرترین شیوه ها خواهد بود.
در اینجا به فعال کردن گزینه ی Page Cache اکتفا کنید و روش کش را نیز بر روی Disk: Enhanced قرار دهید.
در ادامه برای اعمال تنظیمات دلخواه برای بخش Page cache از منوی Performance به زیرمنوی Page Cache مراجعه کنید.
![تنظیمات کش صفحات در افزونه w3 total cache]()
در این بخش تنظیمات متعددی وجود دارند که در ادامه به طور مختصر به شرح آنها خواهیم پرداخت:
Cache posts page : در اکثر سایت ها و بلاگ ها، برگه ی نوشته ها، پر بازدید ترین بخش سایت است، با فعال کردن این گزینه میتوانید کش را برای این صفحه فعال کنید.
Don’t Cache front page : اگر مایل نیستید صفحه ی اصلی سایت شما کش شود، این گزینه را فعال کنید.
Cache feeds : در صورتی که مایلید فید بخش های مختلف سایت از جمله فید اصلی، دسته ها، برچسب ها و دیدگاه ها از کش در اختیار کاربران قرار بگیرد، از این گزینه استفاده کنید. استفاده از این گزینه حتی در صورت استفاده از سرویس های واسطه مثل فید برنر نیز پیشنهاد میشود و میتواند بار روی سایت را کاهش دهد.
Cache SSL Requests : برای کش کردن درخواست های انجام شده روی SSL این گزینه را فعال کنید. به طور کلی استفاده از این گزینه توصیه میشود.
Cache URIs with query string variables : این گزینه به شما اجازه میدهد که صفحاتی که دارای رشته های کوئری هستند را کش کنید. مثلا فرض کنید در یک بازه ی زمانی کوتاه، تعداد زیادی افراد (یا حتی ربات ها) در حال مشاهده ی نتایج جستجو برای یک عبارت خاص هستند. این مسئله ممکن است در آن بازه ی زمانی، بار بسیار زیادی را بر روی سایت شما بگذارد. کش کردن این درخواست ها و پاسخ دادن به آنها به صورت استاتیک میتواند بار روی سایت را کاهش داده و در عین حال باعث افزایش سرعت پاسخدهی به این نوع درخواست ها شود.
Cache 404 Pages : اگر مایلید در صورت موجود نبودن یک صفحه، پاسخ ۴۰۴ آن از طریق افزونه کش شود، میتوانید از این گزینه استفاده کنید. این گزینه بار روی سرور را کاهش میدهد ولی در حالتی که کش صفحه را روی disk: enhanced قرار داده باشید، بجای پاسخ ۴۰۴ پاسخ ۲۰۰ را باز میگرداند که در واقع ایده آل نیست. بنابراین به طور عمومی، استفاده از این گزینه را به شما پیشنهاد نمیکنیم، مگر اینکه دلیل خاصی داشته باشید و از تنظیم خاص دیگری در بخش تنظیمات دیسک در کش صفحه استفاده کرده باشید.
Don’t cache pages for logged in users : اگر میخواهید هیچ یک از بخش های سایت برای کاربرانی که وارد اکانت کاربری خود شده اند، کش نشود، میتوانید از این گزینه استفاده کنید. طبعا این گزینه برای سایت هایی که تعداد کاربر زیادی دارند توصیه نمیشود اما برای سایت های دارای چند نویسنده/چند مدیر، میتواند گزینه ی مفیدی باشد.
Don’t cache pages for the following user roles : در این قسمت میتوانید تعیین کنید که سایت برای نقش خاصی از کاربران، کش نشود. مثلا میتوانید تعیین کنید که مدیران یا نویسندگان، سایت را به صورت کش نشده مشاهده نمایند.
پس از اعمال تنظیمات دلخواه در این بخش، ذخیره تنظیمات و خالی کردن کش را فراموش نکنید.
راستی تا یادمان نرفته! در پایین همین صفحه در بخش Purge Policy: Page Cache میتوانید تعیین کنید که وقتی کش سایت را خالی میکنید، کش کدام بخش ها تازه سازی شود.
در این قسمت از مقاله از گزینه های Database Cache و Object Cache میگذریم چون بسیاری از سرور ها ممکن است با استفاده از این تنظیمات، نتیجه های دلخواه را به شما ندهند. در انتهای این مطلب، چند خطی هم درباره ی این امکانات توضیح خواهیم داد. همچنین به مبحث Opcode Cache نیز نمیپردازیم چون این بخش نیاز به وجود برخی تنظیمات و امکانات سفارشی روی سرور میزبانی خواهد داشت و برای اکثر کاربران عادی وردپرس، کاربردی ندارد.
Minify
مینیفای کردن به مفهوم کاهش حجم و تعداد فایل های css و js سایت شماست. در این جا لازم است به این نکته اشاره کنیم که هرچند گزینه ی minify میتواند تعداد درخواست هایی که جهت بارگذاری سایت شما لازم است را به شکل چشمگیری کاهش دهد اما استفاده از آن ممکن است دو تاثیر منفی برای شما در بر داشته باشد.
اول اینکه استفاده از این گزینه ممکن است مصرف سی پی یو را در سایت شما افزایش دهد. بنابراین استفاده از این گزینه دست کم در هاست های اشتراکی توصیه نمیشود. دوم اینکه هرچند با مینیفای کردن، زمان بارگذاری کلی سایت شما کاهش میابد اما گاهی ممکن است این امر به قیمت افزایش زمان انتظار برای بارگذاری اولیه ی سایت شما منجر شود.
اجازه بدهید در این زمینه یک مثال هم بزنیم. (توجه داشته باشید که اعداد ارقام ارائه شده در این بخش صرفا مثال هستند و آمار و ارقام دقیق و واقعی نیستند. همچنین دقت داشته باشید که این مسئله الزاما همیشه به این صورت نیست و بر اساس نوع وب سرور، سخت افزار در دسترس، افزونه ها و قالب استفاده شده در سایت و … نتیجه ای که شما دریافت میکنید ممکن است کاملا متفاوت باشد)
فرض کنید در حالت عادی زمان پاسخدهی اولیه ی سایت شما معادل ۰٫۵ ثانیه بوده. یعنی پس از ارسال درخواست به سرور، سرور پس از ۰٫۵ به کاربر پاسخ میداده و شروع به بارگذاری سایت میکرده است و مثلا پس از ۵ ثانیه بارگذاری سایت به پایان میرسیده است. پس از مینیفای ممکن است این زمان پاسخدهی اولیه به ۱ ثانیه برسد ولی بارگذاری کامل سایت طی ۳ ثانیه صورت بگیرد. یعنی درست است که زمان بارگذاری کلی سایت پایین می آید ولی بسته به محیط و تنظیمات سرور میزبانی و همچنین نوع کارکرد قالب و افزونه های سایت شما، ممکن است زمان انتظار برای اولین بارگذاری افزایش پیدا کند.
![تنظیمات مینیفای در افزونه w3 total cache کاهش حجم فایل های css و js کوچک کردن فایل استایل و جاوااسکریپت]()
حالا اگر همه چیز را سبک و سنگین کردید و باز هم تصمیم داشتید که از امکانات این بخش بهره بگیرید، برای فعال کردن آن کافی است گزینه ی Enable را تیک زده و تغییرات را ذخیره کنید. افزونه W3 Total Cache دو حالت مختلف را برای مینیفای کردن در اختیار شما قرار میدهد. حالت اول Manual بوده و حالت دوم Auto است. (توجه داشته باشید که در نسخه ی فارسی جای دکمه رادیویی این دو تنظیم برعکس است!) اگر حالت Manual را برگزینید، میبایست خودتان به صورت دستی کلیه ی فایل های css و js به کار رفته در سایت خود را جهت فشرده سازی و تلفیق به تنظیمات افزونه اضافه کنید. این کار بسیار وقت گیر و طولانی است و فقط در شرایطی انجام آن توصیه میشود که روش Auto در سایت شما باعث ایجاد خطا و مشکل شده باشد.
پس از فعال کردن این بخش حالا از منوی Performance به زیرمنوی Minify مراجعه کنید. در اینجا برای اینکه از برخورد کردن با هشدار Eliminate render-blocking JavaScript and CSS in above the fold content در تست سرعت گوگل (Google PageSpeed Insights) جلوگیری شود، در بخش JS مقدار embed type را برای قسمت before head روی Non-blocking using async قرار دهید. (توجه داشته باشید که اگر حالت Manual را برای مینیفای انتخاب کرده باشید باید در همین صفحه، کلیه ی فایل های css و js خود را با ترتیب مورد نظر خود اضافه کنید.)
![در بخش JS مقدار embed type را برای قسمت before head روی Non-blocking using async قرار دهید]()
مجددا ذخیره ی تغییرات و خالی کردن کش را فراموش نکنید (save settings and Purge Caches).
در اینجا لازم است به یک نکته ی مهم هم اشاره کنیم. گاهی پیش می آید که پس از انتخاب تنظیم Non-blocking using async برای فایل های جاوااسکریپت سایتتان، اجرای برخی اجزای سایت، خصوصا اجزایی که نیازمند جی کوئری هستند دچار مشکل میشود. (ممکن است این اجزا پیش از بارگذاری کامل محتوای js بارگذرای شوند و به درستی کار نکنند) در چنین حالتی ممکن است لازم باشد که این تنظیم را به حالت اول یعنی blocking برگردانید.
Browser Cache
خوب، حتما میدانید که هر بار یک کاربر از یک وبسایت دیدن میکند، محتوای آن وبسایت، از جمله تصاویر، CSS فایل های جاوا اسکریپت و … درون یک فولدر موقتی بر روی کامپیوترش ذخیره میشود. این کار باعث میشود در بارگذاری های بعدی و یا در مراجعه به صفحات دیگر سایت که از محتوای یکسانی با صفحه ای که کاربر قبلا مشاهده کرده استفاده میکنند، صفحه با سرعت بیشتری برای کاربر بارگذاری شود. دلیل این قضیه هم مشخص است، چون در اینجا مرورگر محتوای ایستای صفحات را بجای بارگذاری از روی سرور، از روی کامپیوتر کاربر بارگذاری میکند.
این همان چیزی است که ما میتوانیم از آن به نفع خود استفاده کنیم. تنظیمات بخش Browser Cache دقیقا همین امکان را در اختیار ما میگذارد ولی بخش مهم ماجرا این است که ما میتوانیم بگوییم فایلهایی که بر روی کامپیوتر کاربر ذخیره میشوند، برای چه مدت معتبر هستند. مثلا لوگوی وبسایت خود را در نظر بگیرید. آیا این تصویر به طور مرتب آپدیت میشود؟ طبیعی است که پاسخ منفی است. شما لوگوی وبسایت خود را هر روز به روز رسانی نمیکنید. فایل های بسیاری در وبسایت شما دقیقا همین وضعیت را دارند. بنابراین منطقی است که کش چنین فایل هایی را بر روی ۲۴ ساعت قرار دهیم. برای فعال کردن این امکان، باید ابتدا Browser Cache را در بخش تنظیمات عمومی فعال کنید و سپس از منوی Performance به بخش Browser Cache مراجعه کنید. در این بخش میتوانید کلیه ی تنظیماتی را که لازم میبینید اعمال نمایید. مثلا ما این بخش را به شکل زیر تنظیم کرده ایم :
![آموزش تنظیم Browser Cache]()
برای این بخش ما فعال کردن تنظیمات زیر را به شما توصیه میکنیم :
- Set last-modified header
- Set expires header
- Set cache control header
- Set entity tag (Etag)
- Enable HTTP (gzip) Compression
- Remove query Strings from static resources
- Don’t set cookies for static files (یا Disable cookies for static files)
- Do not process 404 errors for static objects with WordPress
همانطور که میبینید تقریبا از اکثر گزینه های موجود در این بخش استفاده کرده ایم.
راستی در مورد گزینه Prevent caching of objects after settings change باید به این نکته توجه داشته باشید که فعال کردن این گزینه منجر به اضافه شدن یک کوئری به انتهای آدرس فایلها سایت شما میشود. بنابراین در صورتی که این مسئله برای شما ایده آل نیست و مایلد نیستید این کوئری را در پایان آدرس ها مشاهده کنید، حتما آن را غیر فعال کنید.
و در مورد گزینه Remove query Strings from static resources. این گزینه رشته ی کوئری را از پایان فایل های استاتیک حذف میکند. حتما دقت کرده اید که در وردپرس در پایان فایل هایی مثل فایل های css رشته ای وجود دارد که در آن ورژن وردپرس یا گاهی ورژن خود فایل و … به چشم میخورد. فعال کردن این گزینه، این رشته ها را از پایان این ریسورس ها حذف کرده و اجازه میدهد که این منابع به درستی کش شوند. فرضا اگر قبلا با شیوه ای دیگری خودتان این مسئله را روی سایتتان اعمال کرده باشید (مثلا با افزونه های دیگر یا اضافه کردن کد) دیگر لازم نیست که این گزینه را فعال کنید.
در مورد گزینه ی Do not process 404 Errors for static objects with wordpress باید بگویم که انتخاب با خود شماست. چیزی که این گزینه میگوید این است که اگر برای آبجکت های ایستا، مثلا فایل های نوشتاری یا تصاویر و … خطای ۴۰۴ رخ داد، اجازه بده سرور بجای وردپرس نمایش و مدیریت خطا را به عهده بگیرد. در زیر این گزینه برخی از فایلها، مانند فایل های robots.txt و فایل های sitemap به عنوان استثنا مشخص شده اند. استفاده یا عدم استفاده از این گزینه به تصمیم خود شما باز میگردد و بهترین کار در اینجا همان آزمون و خطای قدیمی خومان است.
در این صفحه علاوه بر بخش General که به آن پرداختیم، اگر به پایین اسکرول کنید، بخش های دیگری با عنوان CSS & JS، بخش HTML & XML و بخش Media & Other Files نیز به چشم میخورند. این بخش ها را نیز میتوانید با راهنمایی که برای بخش اول ذکر شد تنظیم نمایید. (گزینه ها اکثرا در این بخش ها مشترک هستند و اصلا نیازی نیست که علاوه بر مواردی که برای بخش general ذکر شد، تغییرات خیلی خاصی در این بخش ها اعمال کنید. همه چیز را میتوانید بر اساس آنچه برای بخش General توضیح داده شده، انجام دهید.)
استفاده از CDN
CDN مخفف عبارت Content Delivery Network یا شبکه تحویل محتوا (یا یک همچین چیزی!) است. اگر تا اینجا خوب دقت کرده باشید متوجه شده اید که وقتی شما تنظیمات کش را برای صفحات خود فعال میکنید، به هر حال محتوای شما باید توسط سروری که سایت شما را میزبانی میکند به کاربران ارسال شود. برای وبسایتهایی که واقعا بزرگ هستند، این مسئله اصلا کافی نیست و ممکن است هزینه های بسیار زیادی را برای تامین ریسورس لازم بر روی سرور به آنها وارد کند. اینجاست که CDN ها وارد ماجرا میشوند. کار CDN ها این است که محتوای ایستای صفحات وبسایت شما را از روی چندین سرور ابری در اختیار کاربران قرار میدهند. در واقع اتفاقی که می افتد این است که CDN نسخه ی استاتیک صفحات شما را بر روی سرور های خود نگهداری میکند، و در زمانی که کاربری درخواست مشاهده آن صفحات را میدهد، بجای اینکه درخواست توسط سرور شما پاسخ داده شود، CDN با استفاده از محتوایی که از پیش فراهم کرده، درخواست را پاسخ میدهد. این کار فواید بسیار زیادی دارد. دو تا از واضح ترین فواید آن، کاهش بار روی سرور و کاهش استفاده از پهنای باند است. و فایده ی دیگر آن این است که CDN ها، خصوصا CDN های غیر رایگان پیشرفته، میتوانند تا حد قابل قبولی جلوی حملات DDOS را هم بگیرند.
CDN های معروف بسیاری وجود دارند که میتوانید به دلخواه خود یکی از آنها را انتخاب کرده و تنظیمات آنها را بر روی افزونه ی W3TC اعمال کنید. در این میان حتما اسم CloudFlare به گوشتان خورده است. البته Incapsula نیز سرویس جالبی است ولی متاسفانه به نظر میرسد که توسط W3TC ساپورت نمیشود. (و من هم زیاد دوستش ندارم!)
هر CDN ای را که انتخاب کنید، لازم است ابتدا در آن ثبت نام کرده و مراحل راه اندازی آن را طی کنید. گرچه راه اندازی آنها با یکدیگر تفاوت هایی دارد، اما ماجرای کلی این است که پس از ثبت نام، به شما یک سری آدرس داده میشود که یا باید آنها را به عنوان CNAME یا DNS بر روی دامنه هایی که به CDN اعلام کرده اید تنظیم کنید و با تنظیمات جلو بروید.
در اینجا چون مبحث راه اندازی Varnish خودش ماجرایی طولانی و هزارتویی پیچ در پیچ است، بنابراین به مبحث Reverse Proxy نخواهیم پرداخت. (مرسی. ولی نه! مرسی.)
Fragment Cache
این امکانات در میان امکانات افزونه W3TC تقریبا جزو امکانات جدید به شمار میرود. با استفاده از fragment cache میتوانید کاری کنید که تنها بخش هایی از کدهای یک صفحه ی خاص از کش بارگذاری شده و بخش هایی دیگر به صورت مستقیم در هر بار فراخوانی اجرا شوند. در این حالت خروجی بخشی انتخابی شما به صورت کش شده نگهداری خواهد شد و در هر بار اجرای صفحه مورد نظر، تا زمانی که کش معتبر باشد، بجای اجرای بخش مورد نظر از کد، تنها از خروجی کش شده ی آن استفاده خواهد شد. این در حالی است که سایر بخش های صفحه که برای کش شدن انتخاب نشده اند، به صورت عادی اجرا میشوند.
توضیح نحوه استفاده از این امکان کمی طولانی بوده و در واقع کاربرد و جایگاهی در این آموزش ندارد. شاید مسترکد بعدا در آموزشی جداگانه به توضیح این بخش و نحوه راه اندازی آن بپردازد. ولی فعلا از آن عبور خواهیم کرد.
خوب، حالا سراغ دو مورد از موارد مهمی که از آنها گذشته بودیم میرویم :
DataBase Cache
این امکان هم همانطور که از نامش معلوم است، کوئری های ارسال شده به دیتابیس را کش میکند تا بعدا بدون ارسال کوئری به دیتابیس بتواند به درخواست های کاربران پاسخ دهد. دقیقا مثل Minify، این آپشن هم ممکن است بجای سبکتر کردن سایت شما، بار روی سرور را افزایش دهد و یا حتی منجر به مصرف بی رویه دیسک شود. بنابراین در بیشتر مواقع شاید بهتر باشد از این امکان هم بگذرید. در واقع استفاده از این امکان به هیچ وج بر روی هاست های اشتراکی توصیه نمیشود.
Object Cache
کاری که این امکان انجام میدهد دقیقا مشابه database cache است. فقط مشکلی که هست این است که W3TC اینجا در واقع خیلی هم خوب عمل نمیکند و با پلاگین های بکاپ اصلا سر سازش ندارد. توصیه میکنم این گزینه را خاموش نگهدارید.
بعد از اعمال تنظیمات …
اگر تا اینجا فقط تغییرات را ذخیره کرده اید و کش را خالی نکرده اید، همین حالا با استفاده از گزینه ی performance در نوار مدیریت و کلیک کردن روی Purge All Caches کش کلیه ی بخش های سایت را خالی کنید.
![Purge All Caches]()
به طور کلی استفاده از این گزینه را پس از اعمال هر نوع تغییر ظاهری و ساختاری در سایت به شما توصیه میکنیم تا بتوانید مطمئن باشید که کلیه ی کاربران، نسخه ی به روز سایت شما را مشاهده میکنند. (مثلا حتی اگر صفحه ای را ویرایش میکنید که از قبل در سایت وجود داشته، ممکن است لازم باشد که پس از ویرایش یک بار کش را خالی کنید، چرا که ممکن است بعضی از کاربران برای مدت کوتاهی هنوز نسخه ی قدیمی صفحه را مشاهده کنند.)
و در پایان
بعد از توضیحات بالا حتما متوجه شدید که منظور ما این است که به هیچ عنوان در محیط هاست اشتراکی از گزینه های Database cache و Object Cache و حتی الامکان حتی از گزینه ی مینیفای استفاده نکنید. نه؟ موارد بسیاری را مشاهده کرده ایم که به علت فعال کردن این گزینه ها توسط کاربر، مصرف دیسک و بار سایت روی سرور به شدت افزایش یافته و به علت ایجاد تعداد بسیار زیادی فایل های موقتی، حتی بکاپ گیری از هاست کاربر نیز به مشکل برخورد کرده است. بنابراین در تنظیم افزونه بسیار دقت کنید و حتما در محیط های اشتراکی از فعال کردن این گزینه ها خودداری نمایید. طبعا در محیط های اختصاصی (مثل سرور اختصاصی یا سرور مجازی) میتونید این گزینه ها را بر روی سایت خود آزمایش کنید و تاثیر مثبت یا منفی آنها را بر روی سایتتان بسنجید.
همین! البته به قول معروف : به پایان آمد این دفتر، حکایت همچنان باقی است …
راستی تجربیات خود را حتما در بخش نظرات با ما و کاربران دیگر به اشتراک بگذارید.
همانطور که میبینید، در حالت عادی اتفاقی که می افتد این است که وقتی کاربری به وبسایت شما مراجعه کرده و درخواست خودش را برای مشاهده یک صفحه به وردپرس ارسال کند، وردپرس ابتدا اسکریپت PHP مربوط به درخواست را اجرا کرده و اسکریپت اجرا شده، درخواست های لازم را به MySQL ارسال میکند، سپس کد های صفحه ای که کاربر درخواست کرده تبدیل به محتوای HTML قابل درک برای مرورگر میشود و بعد صفحه به کاربر ارسال میشود تا کاربر آن را مشاهده کند. همانطور که میبینید این پروسه زمانبر بوده و از ریسورس زیادی بر روی سرور استفاده میکند. استفاده از page cache باعث میشود که وردپرس یک محتوای ایستا از صفحات مورد درخواست را در محلی ذخیره کند و سپس در هنگام درخواست صفحه توسط کاربر، محتوای ایستا را برای کاربر ارسال کند.
