رفع خطای Remove query strings from static resources در gtmetrix

در این مقاله قصد داریم درباره مشکل رایج Remove query strings from static resources و حل آن در جی تی متریکس صحبت کنیم و بررسی کنیم که چطور این خطا یا همان حذف علامت سؤال از انتهای آدرس منابع در جهت افزایش سرعت سایت به ما کمک می‌کند و آیا بودن query strings ها برای ساخت سایت ما مفید است یا خیر.

خلاصه‌ای از خطا Serve resources from a consistent URL

نام: Remove query strings from static resources
نوع: محتوا
اولویت: کم
میزان سختی: راحت
میانگین امتیاز: 89%

علت خطای Remove query strings from static resources در جی تی متریکس چیست؟

جنبه منفی query strings: وجود query strings در منابع سایت ما باعث می‌شود که آن منابع در سمت کاربر کش نشود و اگر منابع همانند CSS یا JS در سمت کاربر کش نشود خطاهایی نظیر Leverage browser caching هم رخ خواهد داد و مشکلات بسیار دیگری را فراهم می‌کند، استفاده از query strings باعث می‌شود فایل‌های استایل (CSS) و جاوا اسکریپت در بسیاری از مرورگرها و همین‌طور CDN ها کش نشود.

remove-query-string

جنبه مثبت query strings: وجود query strings این اجازه را به برنامه‌نویس‌های پلاگین و قالب‌ها می‌دهد تا در مدت‌زمان و دوره‌های کوتاه‌مدت منابع را آپدیت کنند و این تغییرات سریع‌تر در سمت کاربر اعمال شود، و از طرفی اگر از query strings استفاده نشود ممکن است فایل برای مدت زیادی در سمت کاربر کش شود و کاربر نتواند نسخه‌های جدید و به‌روزرسانی‌ها را مشاهده کند و شاید به مشکلات دیگر نیز برخورد کند. پس چه باید کرد آیا استفاده از query strings خوب است یا نه.

remove-query-strings-static-resources

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

نحوه رفع خطای Remove query strings from static resources

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

در وردپرس

• برای رفع این خطا اگر تمایل به استفاده از کدها را ندارید و سایت وردپرسی دارید، می‌توانید پلاگین Remove Query Strings را نصب کنید این پلاگین بدون هیچ‌گونه تنظیمات اضافه باعث رفع مشکل Remove query strings from static resources در مدیریت محتوای وردپرس می‌شود.
• پلاگین WP Rocket در نسخه ۲.۹ به بعد خود قابلیت رفع خطای Remove query strings from static resources را قرار داده هست و اگر از این پلاگین استفاده می‌کنید می‌توانید همانند عکس زیر تیک آن را بزنید.

remove-query

• پلاگین W3 total cashe هم گزینه‌ای دارد که با برداشتن آن باعث رفع این خطا می‌شود، اگر این افزونه را در سایت وردپرس خود نصب‌کرده‌اید با فعال بودن گزینه Prevent caching of objects after settings change در قسمت Brower Cahse باعث ایجاد خطای query strings می‌شوید، پس تیک آن را بردارید.

W3-Total-Cache-Browser-Cache

• با استفاده از فایل Function.php می‌توانید به شکل دستی خطای query strings را رفع کنید کافی است کد زیر را در انتهای فایل Function.php قرار دهید.

در دروپال

برای حذف query strings ها درفایل های CSS دروپال می‌توانید کد زیر را در template.php قرار دهید، فقط توجه داشته باشید که به جای MYTHEME نام قالب مورد نظر خود را وارد کنید.

در جوملا

به کمک افزونه joomsef شما می‌توانید این مشکل را رفع کنید، البته در تنظیمات کلی جوملا یعنی Global Configuration و قسمت SEO Settings گزینه‌ای وجود دارد با عنوان search engine friendly (SEF) URLs که اگر فعال باشد آدرس‌های شما را هم برای کاربران و هم برای موتورهای جستجو بهینه تر می‌کند، مثلا آدرس http://example.com/index.php?page=name تبدیل به http://example.com/name می‌شود. اگر شما گزینه SEF URLs را در جوملا فعال کرده باشید ممکن است آدرس‌های non-SEF URLs به شکلی در سایت ایندکس شوند و باعث ایجاد محتوای تکراری شود که تاثیر بد برای سئو سایت دارد و همچنین یکی از عوامل پنالتی شدن سایت در گوگل نیز می‌باشد، بنابراین برای جلوگیری از این امر می‌توانید از دستور زیر در فایل robots.txt استفاده نمایید تا آدرس‌هایی که دارای علامت ? هستند را ربات ایندکس نکند.

در PHP

اگر ساختار سایت شما بر اساس زبان برنامه نویسی PHP است و از CMS های رایگان استفاده نمی‌کنید می‌توانید از دستور زیر برای رفع خطای query strings استفاده کنید، کد نوشته شده توسط سایت Addedbytes است و تشکر به خاطر این دستور نوشته شده، شما برای حذف مقادیر موجود در url می‌توانید از متغییر $key استفاده نمایید.

رفع خطای Serve resources from a consistent URL در gtmetrix

در این مقاله قصد داریم درباره مشکل رایج Serve resources from a consistent URL و حل آن در جی تی متریکس صحبت کنیم. توجه داشته باشید که حل خطای اشاره شده باعث رفع خطای Remove duplicate JavaScript and CSS در YSlow هم می‌شود.

خلاصه‌ای از خطا Serve resources from a consistent URL

نام: Serve resources from a consistent URL
نوع: محتوا
اولویت: زیاد
میزان سختی: راحت
میانگین امتیاز: 88%

علت خطای Serve resources from a consistent URL در جی تی متریکس چیست؟

این خطا وقتی رخ می‌دهد اگر شما دو عکس یکسان را با دو آدرس متفاوت در صفحه‌ای از طراحی سایت (طراحی سایت شرکتی، طراحی سایت فروشگاهی) خود بارگذاری نمایید، این عمل باعث می‌شود که تعداد درخواست‌های سمت سرور بالا رود و وقتی درخواستهای HTTP افزایش یابد، سرور بیشتر درگیر پاسخ می‌شود و اگر تعداد چنین فایل‌هایی زیاد باشد به مراتب تعداد درخواست‌ها بیشتر می‌شود و طبیعتا درگیری سرور هم بالا می‌رود، این موضوع شاید در سایت‌های کم بازدید خیلی محسوس نباشد ولی وقتی بازدیدکننده سایت بالا باشد قطعا رفع مشکل Serve resources from a consistent URL قدم بزرگی در بهینه سازی سایت چه در سمت سرور و چه در سمت کاربر خواهد کرد.

serve-resources-from-a-consistent-URL

در جلسات گذشته آموزش جی تی متریکس درباره نحوه کاهش تعداد درخواست‌ها بسیار صحبت کردیم، خطاهای مختلف زیادی مربوط به کاهش درخواست های HTTP اشاره می‌کردند که خطای Serve resources from a consistent URL هم جر این دسته‌ها است، تمام مقالات زیر به شکل مستقیم یا غیرمستقیم باعث کاهش درخواستهای HTTP می‌شود و خواندن آن به شما دوستان در جهت ارتقا بهینه سازی داخلی سایت توصیه می‌شود.

• رفع خطای Combine images using CSS sprites
• رفع خطای Inline small CSS and JavaScript
• رفع خطای Defer parsing of JavaScript
• رفع خطای Leverage browser caching
• رفع خطای Minimize request size
• رفع خطای Enable Keep Alive

نحوه رفع خطای Serve resources from a consistent URL

نحوه رفع چنین خطاهایی گاهی راحت و گاهی دشوار و نیاز به برنامه‌نویسی دارد، در یکی از پروژه‌های افزایش سرعت سایت که تیم میزفا داشت با چنین خطایی روبه‌رو شدیم و سایت مشتری دارای فایل‌های تکراری همانند زیر بود:

برخی از این خطاها که در سیستم‌های مدیریت محتوا مثلا وردپرس و جوملا بیشتر به چشم میخورد به علت فعال بودن پلاگین‌های غیراستاندارد است و گاهی اشتباهات دستی که باعث می‌شود یک فایل که دارای محتوای یکسان هست با آدرس های مختلف بالا بیاید، و یا ممکن است ۲ افزونه به یک محتوا عمومی نیاز داشته باشند (محتوای عمومی منظور مثلا Font Awesome می‌تواند باشد یا یک سری فایل‌های جاوااسکریپت معروف) و هر کدام از این افزونه ها برای لود کردن محتوای عمومی می‌آیند از آدرس‌های خود فراخوانی می‌کنند که در این صورت خطای فایل تکراری در دو url را شما می‌توانید مشاهده کنید، که در این صورت باید تک تک افزونه ها را غیرفعال کنید و ببینید کدام افزونه چنین عملی را پیاده می‌کند و اگر پیدا کردید به جای آن افزونه از یک افزونه دیگر استفاده کنید. همین موضوع می‌توانید بین قالب و یک افزونه یا چند افزونه هم پیش بیایید که باید همین سیاست را در پیش بگیرید.

توجه داشته باشید که آدرس‌های زیر شاید همه به یک محتوا اشاره کنند ولی هر کدام یک درخواست محسوب می‌شوند:

در ۴ آدرس بالا به یک محتوا اشاره می‌کند ولی ۴ درخواست مختلف سمت سرور ارسال می‌شود، و شما برای رفع چنین خطایی باید اول منشا آن را شناسایی کنید و سپس آن آدرس را در صورت امکان حذف یا تصحیح کنید.

این خطا باعث کاهش تعداد درخواست های HTTP هم نیز می‌شود و شما اگر قصد دارید تعداد درخواست هایطراحی سایت خود را در جهت بهینه سازی، کاهش دهید حتما مقاله رفع خطای Make fewer HTTP requests را هم بخوانید.

رفع خطای Specify a character set early در GTmetrix

در این پست قصد داریم به شکل خلاصه درباره خطای Specify a character set early صحبت کنیم.

بهینه سازی سایت

قیمت طراحی سایت

خلاصه‌ای از خطای Specify a character set early

نام: Specify a character set early
نوع: محتوا
اولویت: متوسط
میزان سختی: راحت
میانگین امتیاز: ۹۹%

خطا Specify a character set early

طراحی سایت (طراحی سایت فروشگاهی، طراحی سایت شرکتی)

برای رفع ارور Specify a character set early کافی است متاتگ character set را به شکل یک درخواست HTTP ارسال نماییم.

رفع خطای Specify a Vary: Accept-Encoding header در gtmetrix

در این مقاله قصد داریم درباره مشکل رایج رفع خطای Specify a character set early و حل آن در جی تی متریکس صحبت کنیم.

سئو سایت

خلاصه‌ای از خطا Specify a Vary: Accept-Encoding header

نام: Specify a Vary: Accept-Encoding header
نوع: محتوا
اولویت: زیاد
میزان سختی: راحت
میانگین امتیاز: 88%

علت خطای Specify a Vary: Accept-Encoding header در جی تی متریکس چیست؟

یکی دیگر از درخواست‌های HTTP مهم که تاثیر مناسبی در بهینه سازی سرعت سایت نیز دارد Vary: Accept-Encoding است. متاسفانه سایت‌های ایرانی دوباره همانند بسیاری از خطاهای دیگر به اشتباه این ارور را تفسیر کرده‌اند و بسیار تعجب آور است که برای رفع خطا Vary: Accept-Encoding متاتگ <meta charset=”utf-8″> را پیشنهاد می‌دهند :/

طراحی سایت (طراحی سایت شرکتی، طراحی سایت فروشگاهی)

برای رفع این خطا باید شما یک درخواست هدر HTTP از نوع Vary: Accept-Encoding را ارسال کنید و ربطی به متاتگ اشاره شده ندارد.

vary-accept-encoding-header-kinsta

طبق توضیحات سایت معتبر kinsta وقتی شما هدر Vary: Accept-Encoding را در هاست خود فعال ندارید وب سرور یا CDN شما به جای ارسال فایل‌های فشرده شده (همان GZIP بودن فایل‌ها) فایل‌های فشرده نشده را به اشتباه به مرورگرها ارسال می‌کند و این آسیب به بهینه سازی سایت شما خواهد زد ولی اگر هدر Vary: Accept-Encoding فعال باشد وب سرور یا CDN نسخه صحیح فایل‌ها را به کاربران ارسال می‌کند. پس توجه داشته باشید که فعال بودن آن بسیار اهمیت دارد، هر چند در اکثر سرورها به شکل پیش‌فرض فعال است.

specify-vary-accept-encoding-header-pagespeed

نحوه فعال سازی Vary: Accept-Encoding

رفع خطای Specify a Vary: Accept-Encoding header در وب سرویس آپاچی

اگر وب سرویس سایت شما Apache است کافی است فایل .htaccess موجود در ریشه هاست خود را edit کرده و دستور زیر را وارد نمایید.

رفع ارور Specify a Vary: Accept-Encoding header در وب سرویس NGINX

اگر وب سرویس سایت شما NGINX است کافی است فایل موجود در ریشه /etc/nginx/nginx.conf. خود را edit کرده و دستور زیر را وارد نمایید.

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

در این مقاله داریم درباره مشکل رایج Specify a cache validator و حل آن در جی تی متریکس صحبت کنیم.

خلاصه‌ای از خطا Specify a cache validator

نام: Specify a cache validator
نوع: سرور
اولویت: زیاد
میزان سختی: راحت
میانگین امتیاز: 92%

specify-a-cache-validator

درباره خطای Specify a cache validator در جی تی متریکس

زمانی که با ارور Specify a cache validator روبه رو می‌شوید نمایان‌گر این موضوع است که تنظیمات کش سرور شما به خوبی تنظیم نشده، حال منظور از اینکه کش وب سرور به خوبی تنظیم نشده است را در ادامه خواهیم گفت.

هر سروری که به خوبی تنظیم شده باشد یک سری محتوای هدر HTTP برای کش کردن فایل‌ها سمت کاربران در جهت بهینه سازی سایت ارسال می‌کند این هدرهای کش اصولا دو عمل اصلی را انجام می‌دهند، یکی Cache Validate یعنی معتبرسازی فایل‌های کش و دیگری Cache Length به معنای طول کش یا مقدار زمان کش است. و هر کدام از این موارد نباشند مشکلاتی برای طراحی سایت (طراحی سایت شرکتی، طراحی سایت فروشگاهی) ایجاد می‌کنند. در ادامه این عبارات را تشریح می‌کنیم.

specify-a-cache-validator-warning

این دو هدر تعیین می‌کنند که چه مدت یک فایل باید نگه داشته شود و اگر این دو هدر تنظیم نشده باشند خطای Leverage browser caching رخ می‌دهد و اگر چنین خطایی را دارید می‌توانید به کمک این پست رفع کنید. ولی اگر چنین مشکلی ندارید به شکل خلاصه بدانید که در هدر Cache-Control مدت زمان انقضا مشخص می‌شود به این منظور که یک عدد بر حسب ثانیه برای کش کردن فایل در نظر می‌گیرد ولی در هدر Expires تاریخ زمان انقضا درج می‌شود و یک تاریخ مشخص می‌شود که مثلا تا فعلان تاریخ فایل کش شود. استفاده از هر دو هدر Expires و Cache-Control لازم نیست، ولی حداقل استفاده از یکی در جهت افزایش سرعت سایت لازم و ضروری است ولی اگر هر دو را اضافه کنید جز محکم‌کاری در جهت کش شدن فایل‌ها کار خاص دیگری نکرده‌اید ولی به شکل کلی هدر Cache-Control نسبت به هدر Expires اولویت بالاتری دارد. Cache-Control جدیدتر و معمولا این متد توصیه می‌شود ولی با این حال هنوز برخی سایت‌های آنالیز سرعت مثل Gtmetrix هدر Expires را چک می‌کنند.

Cache Validate

دو هدر HTTP داریم که Cache Validate را تعیین می‌کند Last-Modified و Etag

این دو هدر تعیین می‌کنند که فایل کش شده برای چه تاریخی و ورژنی است و اگر به خوبی تنظیم نشده باشد خطای Specify a cache validator رخ می‌دهد. به این نکته توجه داشته باشید که شما فقط فایل‌هایی را می‌توانید رفع خطا کنید که در سرور شما باشد پس اگر فایلی در طراحی سایت شما از طریق یک سرور دیگری لود می‌شود به علت دسترسی نداشتن به آن سرور و فایل، نمی‌توان کاری انجام داد.

ما قرار هست در این پست درباره هدرهایی که Cache Validate را تعیین می‌کنند صحبت کنیم و همان‌طور که گفتیم این هدرها نشان می‌دهد که فایل کش شده چه ورژنی دارد و اخرین ورژن کش شده برای چه تاریخی است، هر دو هدر Last-Modified و Etag چنین عملی را انجام می‌دهند، به این دو هدر درخواستی اسم دیگری هم دارند و به آن‌ها Conditional requests یا درخواست‌های شرطی هم گفته می‌شود، در ادامه بیشتر در این باره صحبت خواهیم کرد.

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

last-modified-header

مقدار Last-Modified یک تاریخ خاصی را نشان می‌دهد، Last-Modified تاریخ آخرین ورژن فایل یا تاریخ اخرین ویرایش یک عکس یا صفحه است، همانند کد زیر:

زمانی که فایلی یا صفحه‌ای را تغییر و ویرایش دهید، باید این تغییرات نیز سمت کاربر هم اعمال شود تا به درستی سایت کار کند، بنابراین وقتی کاربر دوباره وارد سایت شما می‌شود یک درخواست شرطی توسط هدری مجزا با عنوان If-Modified-Since ارسال می‌کند، مقدار این هدر مجرا از Last-Modified گرفته شده است، هدر If-Modified-Since زمانی که سمت سرور ارسال می‌شود بررسی می‌کند تا ببیند آیا تاریخ سمت سرور به روز شده است یا خیر، و منتظر پاسخ وب سرور می‌شود، اگر پاسخ با کد 200 ارسال شود به معنای جواب مثبت است و تاریخ تغییر کرده است و ولی اگر وب سرور کد 304 یا همان 304 Not Modified را ارسال کند به این معنا است که فایل مورد نظر به روز نشده است و از فایل موجود در کش مرورگر کاربر استفاده شود.

اگر توضیحات قسمت Cache Length را مطالعه کرده باشید اشاره کردیم که  هدر Cache-Control نسبت به هدر Expires اولویت بالاتری دارد و اگر فرض بگیریم وب سرور در پاسخ به درخواست If-Modified-Since کد 200 را ارسال کند سر انجام تاریخ Last-Modified تغییر خواهد کرد و سر انجام باعث می‌شود مقادیر دو هدر Cache-Control و Expires تغییر کند و فایل جدید با اخرین ویرایش موجود در کش کاربر ذخیره شود.

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

etag-header

هدر ETag با اسم کامل Entity Tag به معنای “برچسب هویتی” همانند هدر Last-Modified تغییرات صفحه یا فایل را به مرورگر کاربر اطلاع می‌دهد، با این تفاوت که به جای تاریخ و زمان آخرین ویرایش صفحه یا فایل از محتوای متنی منحصر به فردی برای هر صفحه یا فایل (مثل یک MD5 Hash) برای شناسایی آن صفحه توسط سرور استفاده می‌شود

و از طرفی مرورگر کاربر به جای درخواست هدر قبلی If-Modified-Since که در حالت Last-Modified ارسال می‌کرد این بار هدر مجزایی با عنوان If-None-Match که مقدار آن از هدر ETag گرفته شده است به سمت وب سرور ارسال می‌کند و دوباره همانند قبل وب سرور با ارسال کد 200 یا 304 تعیین می‌کند که آیا فایل یا صفحه نیاز به آپدیت شدن در سمت کش کاربر را دارد یا خیر.

نکته: در بخش YSlow سایت GTMetrix خطای (Configure entity tags (ETags موجود است که اشاره به نبودن هدر ETags می‌کند که با رفع خطای Specify a cache validator آن هم رفع می‌شود.

نحوه رفع خطای Specify a cache validator

برای رفع این ارور باید هدرهای Last-Modified یا Etag یا هر دو با هم از سمت وب سرور ارسال شود، هدر درخواست Last-Modified به شکل کلی از سمت وب سرورها فعال است و نیازی به تنظیمات دستی آن نیست، هدر Etag در وب سرورهای Apache ورژن 2.4 به بالاتر به شکل اتوماتیک فعال است و سمت کاربران این هدر ارسال می‌شود و در وب سرور NGINX از 2016 به بعد به شکل پیش فرض هدر Etag در آن فعال است.

پس شمایی که این خطا را دارید چه کاری باید انجام دهید؟

اول توجه داشته باشید با هاست مناسب از شرکت‌های معتبر، بعید است با مشکل Specify a cache validator روبه‌رو شوید به هر حال با برخورد این خطا به پشتیبانی هاست خود تیکت زده و درخواست دو هدر یا حداقل یک هدر را ارسال کنید، و راه بعدی برای این مشکل رفع خطای Leverage browser caching است، گاهی تنظیمات وب سرور به شکلی است که با رفع ارور Leverage browser caching مشکل موجود در Specify a cache validator هم رفع می‌شود، و اگر دقت کرده باشید اکثر سایت‌های ایرانی برای رفع خطای Specify a cache validator کد مربوط به Leverage browser caching را قرار می‌دهند.

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