رفع خطاهای GTmetrix برای افزایش سرعت بارگذاری – بخش سی و نهم

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

رفع خطای Specify a cache validator و Configure entity tags

یکی از خطاهای رایجی که هنگام تست سرعت سایت با GTmetrix با آن روبرو می‌شویم، خطایSpecify a cache validator و Configure entity tags است که در بخش Yslow جی تی متریکس نمایش داده می‌شود و مربوط به کش سرور است. فایل‌هایی که در سرور کش می‌شود، بستگی به نوع کش سرور دارند که به چه شکلی بتوانند به مرورگر اعلام کند که فایل‌ها در حالت کش هستند. یعنی وقتی شما فایل‌های یک صفحه که شامل چندین فایل مختلف است را کش می‌کنید، باید از طریق مرورگر به صورت صحیح در بازدیدهای بعدی اعلام کنید که آیا تغییری روی فایل‌ها یا این صفحه که کاربر در آن قرار دارد، صورت گرفته یا خیر؟ اگر تغییری صورت گرفته مربوط به چی بوده است و چه فایل‌هایی باید از ابتدا از سرور درخواست شوند تا با نسخه‌ای که به صورت کش شده داخل سیستم کاربر قرار دارد، آپدیت شوند. همان‌طور که در چند مورد از مجموعه مقالات آموزش GTmetrix که در مورد کش بیان کردیم، فرآیند کش درخواستی هست که تحت HTTP بین سرور و مرورگر رد و بدل می‌شود و در آن مشخص می‌شود که چه فایل‌هایی برای چه مدتی کش شوند. این مدت زمان کش شدن رو با استفاده از Expires و فرآیندی که در هر بازدید بررسی می‌کند تا ببیند آیا تغییری در فایل‌ها ایجاد شده یا نه را Cache-Control مشخص می‌کند. این دو مورد در واقع درخواستی هستند که در هدر اجرا می‌شوند و در نهایت وضعیت Cache Length را مشخص می‌کنند.

Cache Validate و اهمیت آن در GTmetrix

پس از این که وضعیت Cache Length توسط دو درخواست هدر Cache-Control و Expires مشخص شد، حالا باید توسط Cache Validate که این هم توسط دو هدر HTTP با نام‌های Last-Modified و Etag مشخص می‌شوند، تعیین کنید که فایل کش شده برای چه تاریخ و چه ورژنی است! اگر این دو مورد هم مشخص نشده باشند در این صورت با خطای Specify a cache validator در GTmetrix مواجه خواهید شد. این دو درخواست را به عنوان درخواست شرطی می‌شناسیم که بر اساس برخی شروط باید وضعیت کش صفحات را مشخص کنند. اولین موضوعی که باید به آن توجه داشته باشید این است که شما تنها می‌توانید این خطا را برای درخواست هایی برطرف کنید که بر روی سرور خودتان قرار دارند. اگر درخواست‌های ثالثی دارید، هیچ کنترلی بر روی آن ها نخواهید داشت.

• فعال‌سازی کش وردپرس و افزایش سرعت سایت با افزونه W3 Total Cache – بخش اول

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

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

هدر Last-Modified چیست؟

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

هدر ETag چیست؟

این هدر نیز بسیار شبیه هدر Last-Modified است. این گزینه هم برای تایید فرایند کش شدن فایل به کار می رود. اگر از آپاچی ۲٫۴ یا بالاتر استفاده می کنید این هدر به صورت خودکار اضافه خواهد شد. از سال ۲۰۱۶ برای وب سرور NGINX این هدر به طور پیش فرض فعال شده است. اگر در این وب سرور هدر ETag فعال نبود می‌توانید آن را به طور دستی به  کمک دستور زیر فعال کنید:

etag on

درخواست شرطی Last-Modified

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

Last-Modified: Mon, 11 Jan 2017 13:17:22 GMT

حالا که این تاریخ در اولین بازدید به صورت کش شده مشخص شد، در بازدید بعدی کاربر از این صفحه ابتدا درخواستی ارسال می‌شود که مشخص کند این صفحه تغییراتی داشته‌اند یا خیر! این تغییرات می‌تواند همان ویرایش محتوای صفحه یا فایل‌ها باشد که با استفاده از Last-Modified مشخص می‌شود. پس هنگامی که شما مثلاً پس از ۳ روز تغییری در صفحه دهید، مقدار بالا به صورت زیر در هدر مرورگر نمایش داده می‌شود.

Last-Modified: Mon, 14 Jan 2017 10:55:14 GMT

در این صورت وقتی بازدیدکننده وارد سایت می‌شود، ابتدا درخواستی به سرور ارسال می‌کند که ببیند صفحه تغییر داشته است یا خیر. در این بخش چون صفحه ما ویرایش شده و تغییراتی را داشته، در این صورت پاسخ مثبت با کد ۲۰۰ به مرورگر ارسال می‌شود و مرورگر می‌فهمد که این صفحه نسبت به بازدید قبلی که مربوط به سه روز پیش بوده تغییراتی را به خودش گرفته است. بنابراین مجدداً فایل‌هایی که تغییر کردن با نسخه جدید از سرور دانلود و جایگزین می‌شوند و دوباره در کش مرورگر قرار می‌گیرند. اگر در پاسخ ارسالی صفحه تغییری نکرده باشد، به جای کد ۲۰۰ کد ۳۰۴ یا ۳۰۴ Not Modified ارسال خواهد شد.

• نکاتی برای بهینه‌سازی تصاویر مورد استفاده در سایت – بخش اول

درخواست شرطی Etag

همان‌طور که گفتیم، این درخواست شرطی هم دقیقاً مشابه Last-Modified هست، با این تفاوت که در اینجا با تاریخ سر و کار نداریم. در این حالت وضعیت کش توسط قطعه کد هش شده توسط MD5 مشخص خواهد شد. به عنوان مثال در اولین بازدید با استفاده از کد MD5 مشابه نمونه زیر که برای مرورگر قابل خوندن است، مشخص می‌شود که آخرین تغییرات با این کد هش شده است!

ETag: "15f0fff99ed5aae4edffdd6496d7131f"

حالا اگه محتوای صفحه را تغییر دهید و ویرایش کنید در این صورت کد هش شده بالا هم تغییر خواهد کرد و در این صورت مشابه نمونه قبلی توسط کد ۲۰۰ یا ۳۰۴ مشخص می‌شود که صفحه تغییری داشته یا خیر. تفاوتی که در اینجا وجود داره این است که اگر تغییری صورت نگیرد، به صورت زیر مشخص خواهد شد.

If-None-Match: "15f0fff99ed5aae4edffdd6496d7131f

 

رفع خطای Specify a cache validator و Configure entity tags

حالا که با انواع هدر cache validator و entity tags آشنا شدید، برای اینکه ارور Specify a cache validator و Configure entity tags رو در جی تی متریکس برطرف کنید، باید هر دو یا حداقل یکی از درخواست‌های Last-Modified یا Etag رو از سمت وب سرور برای مرورگر ارسال کنید. معمولا درخواست Last-Modified به صورت عمومی در همه وب سرورها فعال است و مشکلی از این بابت وجود نخواهد داشت. درخواست Etag هم در سرورهای نوع آپاچی با ورژن بالاتر از ۲٫۴ و برای وب سرور NGINX که از نسخه ۲۰۱۶ به بعد ارائه شده فعال هست که برای این نوع سرورها نیازی به فعال کردن دستی ندارید. حالا شاید این سوال براتون پیش بیاد که با این شرایط سرور که توضیح داده شد، پس چرا با خطا Specify a cache validator و Configure entity tags مواجه شدید؟

این مورد کاملا به کانفیگ سرور توسط شرکت هاستینگ شما بستگی دارد و اگه با دو خطای Specify a cache validator و Configure entity tags در جی تی متریکس مواجه شدید، باید از شرکت هاستینگ خود بخواهید که این وضعیت رو اصلاح کنند. چرا که شما دسترسی لازم رو برای تغییرات سرور ندارید و تنها در صورتی خودتان می‌توانید این خطاها را برطرف کنید که به سرور دسترسی داشته باشید. اگر پاسخی از سمت هاستینگ برای اصلاح این موارد نگرفتید، هم باید از هاست شرکت معتبری استفاده کنید که این موارد رو رعایت کرده باشد.

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

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

در مقاله بعدی به ادامه این بحث می‌پردازیم.