دسته‌بندی نشدهسئومقالات وبوردپرس

چگونه هشدار Specify a Cache Validator را در وردپرس برطرف کنیم؟

تا به حال برایتان پیش آمده است بخواهید  سایت خود را در ابزارهایی همچون جی تی متریکس یا پیج اسپید گوگل مورد بررسی قرار دهید؟ اگر با این سایت ها کار کرده باشید حتما می دانید که ممکن است به خاطر مشکلات موجود در سایت هشدارهایی را دریافت کنید. یکی از این مشکلات و هشدارهایی که ممکن است با آن مواجه شوید هشدار Specify a Cache Validator است.  این هشدار به خاطر نبود هدر کش کردن HTTL است که باید در هر پاسخ سرور وجود داشته باشد.  اگر این هدر یافت نشود، هر بار درخواست جدیدی برای هر منبع ایجاد می شود و همین امر بار سرور را بیشتر می کند. استفاده از هدر کش کردن شما را مطمئن می سازد که درخواست های پی در پی بار زیادی بر روی سرور ایجاد نمی کند و سرور را مجبور به انجام کارهای اضافی نمی نماید. همین امر باعث می شود پهنای باند سایت ذخیره شود و  عملکرد آن برای کاربر بهبود یابد. در این مقاله قصد داریم به همین موضوع بپردازیم و روش هایی را برای برطرف کردن آن بیان کنیم. پس همراه وب ایده باشید.

چگونه هشدار Specify a Cache Validator را برطرف کنیم؟

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

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

بیشتر مطالعه کنید: بررسی جامع و کامل ابزار تست سرعت جی تی متریکس(GTmetrix)

هدرهایی که کش را تایید می کنند:

دو هدر اولی که در موردش بحث خواهیم کرد شامل last-modified و ETag هستند. این هدرها به مرورگر شما کمک می کنند تغییر فایل از آخرین باری که درخواست شده است را تعیین کند. آیا فایل از اخرین بار درخواستی دچار تغییر یا اصلاحی شده است؟ این هدرها دقیقا به همین سوال پاسخ می دهند.

هدر Last-Modified:

هدر Last-Modified معمولا به صورت خودکار از سرور ارسال می شوند. این هدری است که شما معمولا نیازی به اضافه کردن دستی آن نخواهید داشت. چنین هدری برای بررسی اصلاحات یا تغییرات ایجاد شده بر روی فایل از اخرین باری که درخواست شده ارسال می گردد. شما می توانید از ابزار devtools کروم برای دیدن مقادیر این هدر استفاده کنید.

هدر ETag:

این هدر نیز بسیار شبیه هدر Last-Modified است. این گزینه هم برای تایید فرایند کش شدن فایل به کار می رود. اگر از آپاچی 2.4 یا بالاتر استفاده می کنید این هدر به صورت خودکار اضافه خواهد شد.

از سال 2016 برای وب سرور NGINX این هدر به طور پیش فرض فعال شده است. اگر در این وب سرور هدر ETag فعال نبود می توانید آن را به طور دستی به  کمک دستور زیر فعال کنید:

etag on

 

هدرهایی که طول کش شدن را تعیین می کنند:

دو هدر بعدی که در موردشان صحبت خواهیم کرد شامل Cache-Control و  Expiresهستند. این هدرها به تعیین مدت زمانی که فایل باید قبل از گرفتن یک کپی جدید از سرور،نگهداری شود کمک می کنند. به خاطر داشته باشید که برای برطرف کردن هشدارهایی که بر روی جی تی متریکس یا pingdom می بینید باید مطمئن شوید هدرهایی دارید که کش را تایید می کنند و طول کش شدن را تعیین می نمایند.

هدر Cache-Control:

هدر Cache-Control هدری است که از Directive های مختلفی تشکیل شده و همین امر به شما اجازه می دهد طول کش شدن یک فایل را تعیین کنید. برخی از این Directive های مهم و رایج را در ادامه مشاهده می کنید:

  • max-age: این گزینه مدت زمانی که فایل باید کش شود را نشان می دهد
  • Public: اجازه می دهد هر کشی به طور عمومی پاسخ را ذخیره کند
  • Private: تنها توسط مرورگر برای دسترسی به فایل قابل کش است.

در مثال بالا می توانید ببینید که فایل موجود از Directive  تعریف شده به صورت max-age استفاده می کند. 604800 ثانیه معادل کش شدن به مدت 7 روز خواهد بود. برای پیکربندی این گزینه در آپاچی کافیست کد زیر را به فایل .htaccess خود اضافه کنید:

<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">

Header set Cache-Control "max-age=604800, public"

</filesMatch>

 

برای پیکربندی این گزینه بر روی وب سرور NGINX کافیست کد زیر را به فایل config اضافه نمایید. همه فایل های پیکربندی NGINX در دایرکتوری /etc/nginx/  قرار دارند. فایل پیکربندی اولیه در /etc/nginx/nginx.conf قرار دارد:

location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {

 add_header Cache-Control "public";

}

 

هدر Expires:

آخرین هدری که باید به آن توجه داشته باشید هدر Expire است. بر اساس گفته های گوگل،  هدر cache-control به عنوان بخشی از مشخصه HTTP/1.1 تعریف می شد و برای تعیین سیاست های کش شدن فایل مورد استفاده قرار می گرفت. همه مرورگرهای مدرن از این هدر پشتیبانی می کنند.پس این همه آن چیزی است که شما نیاز دارید. با اینحال اگر شما هر دوی این هدرها را داشته باشید مشکلی ایجاد نمی شود اما به خاطر داشته باشید که تنها یکی از آن ها مورد استفاده قرار خواهد گرفت. هدر expire از تاریخ واقعی استفاده می کند. برای اینکه بتوانید هدر Expire را در آپاچی اضافه کنید کافیست کد زیر را به فایل .htaccess اضافه نمایید:

## EXPIRES HEADER CACHING ##

 <IfModule mod_expires.c>

 ExpiresActive On

 ExpiresByType image/jpg "access 1 year"

 ExpiresByType image/jpeg "access 1 year"

 ExpiresByType image/gif "access 1 year"

 ExpiresByType image/png "access 1 year"

 ExpiresByType text/css "access 1 month"

 ExpiresByType application/pdf "access 1 month"

 ExpiresByType application/javascript "access 1 month"

 ExpiresByType application/x-javascript "access 1 month"

 ExpiresByType application/x-shockwave-flash "access 1 month"

 ExpiresByType image/x-icon "access 1 year"

 ExpiresDefault "access 7 days"

 </IfModule>

 ## EXPIRES HEADER CACHING ##

 

مطمئن شوید که هدر expire را زیر مواردی همچون mod_rewrite و gzip قرار می دهید. انتهای فایل برای گنجاندن این هدر جایگاه امن تری است.

برای اضافه کردن هدر expire در NGINX کافیست کد زیر را به فایل پیکربندی خود اضافه نمایید:

location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {

    expires 7d;

}

 

در بیشتر موارد در NGINX، هدر Cache-Control و expire به همراه هم به کار می روند هر چند این موضوع از لحاظ فنی لازم نیست:

location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {

    expires 7d;

    add_header Cache-Control "public";

}

 

Rate this post
برچسب ها

نوشته های مشابه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

بستن