جدول wp options چیست و چه وظایفی دارد ؟

امروز قصد داریم تا نگاهی به جدول wp_options در پایگاه داده وردپرس خود کنیم. به طور کلی این منطقه شامل کلیه عملکردهای وردپرس و پایگاه داده است که در بیشتر اوقات به آن توجه نمی‌شود.

با توجه به بارگیری های خودکار داده ها در پوسته ها و افزونه های وردپرس توجه نکردن به این جدول (مخصوصا در وب سایت‌های پربازدید و قدیمی) می‌‌تواند باعث کندی صفحه‌ها و همچنین کاهش سرعت سایت و در نتیجه سئو وب سایت شما شود.

نکاتی که در پایین به شما آموزش می‌دهیم را بررسی کنید تا یاد بگیرید که چطور جدول wp_options را بررسی، عیب‌یابی و پاکسازی کنید.

جدول wp options چیست و چه وظایفی دارد ؟

جدول wp_options حاوی تمامی نوع داده مربوط به عملکرد وب سایت وردپرسی شما می‌باشد ، دا‌ده‌هایی مانند :

آدرس وب سایت ، آدرس وردپرس ، ایمیل مدیر ، دسته‌بندی پیش‌فرض، تعداد مقالات در هر صفحه ، فرمت زمان و …

تنظیماتی مخصوص ابزارک‌ها ، افزونه‌ها و پوسته‌ها

داده‌های موقت ذخیره شده

wp options

موارد زیر در جدول wp_options وجود دارد که یکی از آنها را که در عملکرد وب سایت نقش بسیاری دارد را پر‌رنگ کردیم:

option_id

option_name

option_value

autoload ( بارگیری خودکار)

wp option mizfa

یکی از مهم‌ترین مواردی که باید در رابطه با wp_options بدانید ، اطلاع داشتن از بخشی به نام بارگیری خودکار (autoload) می‌باشد. این بخش شامل دو متغیر بله و خیر (yes or no) می‌باشد . که اساساً برای کنترل تابع wp_load_alloptions() استفاده می‌شود. داده‌های Autoload ، داده‌هایی هستند که در هر صفحه وردپرسی شما اجرا می‌شوند.

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

به طور کلی ، داده‌های Autoload به صورت پیش‌فرض در تمامی جداول بر روی “yes” تنظیم شده‌اند که با توجه به اینکه بعضی از افزونه‌ها نیازی نیست که در تمامی صفحات بارگیری شوند، توسط توسعه دهندگان بارگیری خودکارشان (autoload) غیرفعال می‌شود.

تجربه نشان داده است که وجود مقدار زیادی autoload در جدول wp_options می‌تواند باعث مشکل در وب سایت وردپرس شما شود.

در زیر به تعدادی از مشکلات معمول این دسته اشاره می‌کنیم:

داده‌ها به طور کلی توسط خود افزونه‌ها بارگیری خودکار می‌شوند و نیازی نیست که در تمامی صفحات بارگیری شوند و برای مثال داده‌های فرم تماس نیازی نیست که در تمام صفحات وب سایت لود شوند ، بنابراین بهتر است که متغیر داده Autoload را بر روی “no” قرار دهید.

افزونه‌ها و پوسته‌ها را حذف می‌کنید ولی هنوز تنظیمات مخصوصشان در جدول wp_options وجود دارند . این بدان معناست که ممکن است وب سایت در هنگام بارگیری، اطلاعات غیر ضروری قدیمی را نیز بارگیری خودکار کند.

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

حداکثر مجاز استفاده از autoload در یک وب سایت وردپرسی چقدر است؟ این مقدار می‌تواند در هر نوع وب سایتی متفاوت باشد ولی به طور کلی حجم داده‌ها معمولا بهتر است بین 300 کیلوبایت تا 1 مگابایت باشد.

هنگامی که شما شروع به بررسی جدول wp_options می‌کنید با حجمی حدود 3 تا 5 مگابایت مواجه می‌شوید که حتما چیزهایی را باید غیرفعال یا به طور کلی حذف کنید تا جدول و داده‌های autoload بهینه سازی شوند. اگر هنگام بررسی با حجمی بیشتر از 10 مگابایت مواجه شدید ، باید بگویم که وضعیت بحرانی است و باید سریعا به بررسی جدول wp_options بپردازید. با این حال ، صحبت ما به این معنا نیست که اگر بررسی نکنید با مشکل مواجه می‌شوید ولی در کل اگر از حالا بهینه سازی را شروع کنید ، مشکلات آینده را پیشگیری کرده و همچنین سرعت سایت و سئو وب سایتتان را بهبود می‌بخشید.

عیب‌یابی Autoload (بارگیری خودکار) در جدول wp_options

اگر شما با مشکل کندی سرعت سایت روبه‌رو شده‌اید، یکی از دلایلی که می‌تواند باعث این مشکل شده باشد ، وجود کوئری‌ها و یا داده‌های خودکار بارگیری شده‌ی یک افزونه قدیمی در جدول wp_options می‌باشد.

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

قبل از اعمال هر عملی در سایت خود بک آپ تهیه فرمایید تا اگر مشکلی پیش آمد بتوانید دوباره 

بررسی حجم داده‌های ستون Autoload

اولین کاری که باید انجام دهید ، بررسی حجم داده های ستون autoload در حال مصرف در وب سایت وردپرسی شماست. برای این‌کار ، وارد phpMyAdmin شوید.

از سمت چپ صفحه دیتابیس خود را انتخاب کنید و سپس وارد سربرگ SQL شوید .

بعد از انجام این کار دستور زیر را در بخش ادیتور وارد کنید و روی کلید GO کلیک کنید.

توجه داشته باشید ما نسبت به نصب پیش‌فرض وردپرس آموزش می‌دهیم و ممکن است شما به علت امنیت از پیشوندی غیر از wp_ استفاده کرده باشید که برای استفاده از دستور بالا می‌بایست پیشوندی که تعریف کرده‌اید را به جای wp_ وارد کنید.

بررسی حجم autoload مصرفی در وردپرس

حجم نمایش داده‌شده از تابع autoload_size بر مبنای بایت می باشد. هر 1000 بایت برابر 1 کیلوبایت است و هر 1000 کیلوبایت برابر 1 مگابایت است . بنابراین در تصویر زیر حجم autoload_size وردپرس ما 249025 بایت به معنای 0.25 مگابایت می‌باشد. به طور کلی این مقدار حجم برای یک وب سایت ، حجمی ایده‌آل است. اگر نتیجه بررسی شما نیز کمتر از 1 مگابایت بود نیازی نیست که نگران چیزی باشید.

برای تبدیل راحت بایت به مگابایت کافی است در گوگل عبارت “byte to mb” سرچ کنید تا در یک rich answers گوگل بتوانید تبدیل را انجام دهید.

بنابر‌این ، اگر حجم autoload_size وب سایت شما بیشتر از 1 مگابایت بود ، پیشنهاد می‌شود که حتما در ادامه این مقاله میزفا را دنبال کنید تا سئو و سرعت وب سایت خود را از این طریق بهبود بخشید.

wp option query

در نمونه زیر حجم autoload_size برابر 137724715 بایت معادل 137 مگابایت می‌باشد. که این مورد نشان دهنده وجود مشکل در یک وب سایت وردپرسی است.

مثالی از autoload_size حجیم

شما همچنین می‌توانید برای بررسی تخصصی تر از چندین دستور مختلف دیگر استفاده کنید.

در دستور زیر حجم autoload_size بر حسب کیلوبایت ، تعداد کوئری های autoload و 10 دستور autoload اول دیتابیس به شما نمایش داده می‌شود.

SELECT 'autoloaded data in KiB' as name, ROUND(SUM(LENGTH(option_value))/ 1024) as value FROM wp_options WHERE autoload='yes'

UNION

SELECT 'autoloaded data count', count(*) FROM wp_options WHERE autoload='yes'

UNION

(SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 10)

نمونه ای از چند دستور در رابطه با autoload_size

اگر شما از خدمات سایت New Relic استفاده می‌کنید ، می‌توانید از آن برای پیدا کردن مشکلات کوئری های جدول wp_options استفاده کنید، در سربرگ دیتابیس این وب سایت ، شما می‌توانید فهرستی از جداول و کوئری‌هایی که پرمصرف هستند را به دست آورید، اگر روی یکی از گزینه‌های در فهرست کلیک کنید، در رابطه با کوئری‌ها اطلاعات بیشتری کسب می‌کنید. در مثال زیر ، شما می‌توانید تعداد انگشت شماری از داده‌های autoload در جدول wp_options را مشاهده کنید.

با اطمینان می‌توان گفت که با جست‌وجویی کوتاه متوجه خواهیم شد که حدودا داده های autoload شده این وب سایت حداقل 250 مگابایت است.

نمونه ای از لیست new relic

مرتب سازی داده های Autoload شده در بالا

مرحله بعدی بهینه سازی ، مرتب‌ کردن پر مصرف ترین ها در داده های autoload شده می‌باشد. شما می‌توانید با دستور SQL زیر به سرعت لیست 10 داده پرمصرف را  به دست آورید.

SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 10;

دوباره خاطر نشان کنیم که ممکن است شما پیشوند جداول وردپرس خود را هنگام نصب برای افزایش امنیت تغییر داده باشید و نامی جز wp_ گذاشته باشید، برای اینکه دستور بالا کار کند ، شما باید پیشوند جداول خود را جایگزین wp_ کنید.

مرتب سازی لیست 10 داده پر مصرف autoload

ایجاد تغییرات در یک داده autoload شده مشخص در جدول wp_options

مرحله بعدی ایجاد تغییرات در یک داده autoload شده پرمصرف می‌باشد.

ریدایرکت 301

همانطور که مشاهده می‌کنید در تصویر بالا در صدر لیست  ریدایرکت 301 قرار دارد. این کوئری به احتمال بسیار زیاد مربوط به یک افزونه سئو وردپرس می‌باشد و وظیفه انتقال دادن صفحات را دارد. در این نوع موارد ، بهتر است که از افزونه برای انتقال صفحات استفاده نکنید و از ابزار پیش‌فرض وب سرور خود استفاده کنید.

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

wpurp_custom_template_

در لیست مرتب شده بالا هشت جایگاه را کوئری wpurp_custom_template_ اشغال کرده است. به طور کلی شما باید بتوانید نام این کوئری ها بیابید و همچنین به سرور برای دسترسی به نقاطی از پوسته‌ها و افزونه‌ها دسترسی داشته باشید. اگر دسترسی دارید ، از طریق دستور grep زیر بررسی کنید که آیا می‌توانید این کوئری‌ها را پیدا کنید یا خیر! شما همچنین می‌توانید از طریق درگاه‌های SFTP نیز این رکورد‌ها را بررسی کنید.

grep -Ri "wpurp_custom_template_"

اگرچه در بعضی از سرور‌ها این روش کارایی ندارد ، ما توانستیم با جست‌وجویی ساده در گوگل دریابیم که این کوئری به افزونه‌ای تحت عنوان WP Ultimate Recipe مربوط است. این کوئری یک نمونه از غیرضروری‌ترین کوئری‌های autoload شده در وردپرس می باشد. بنابراین اگر چنین افزونه‌ای در لیست افزونه‌های خود دارید سعی کنید که آن را به طور کامل حذف کنید. درواقع ، منظور ما پاک‌سازی کامل افزونه و هرچیزی که تا به حال در پایگاه داده تولید کرده است می‌باشد.

جست‌وجو در رابطه با wpurp_custom_template_

um_cache_userdata_

نوع بعدی داده‌های پرمصرف به داده‌های um_cache_userdata_# مربوط می‌شود، این داده‌ها را در چند سطر از لیست 10 داده پر مصرف autoload بالا در می‌بینید.

با توجه به اینکه چند داده um_cache_userdata_ در پایان لیست قرار دارند . ما به سرعت وارد MySQL خود شده و با دستور زیر 40 کوئری Autoload پر مصرف مربوط به این داده را فراخوانی میکنیم.

SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 40;

و یا مجموع تمامی مقادیر بالا مربوط به آن پیشوند :

SELECT 'sum size in KiB', ROUND(SUM(length(option_value))/1024,0) FROM wp_options WHERE autoload='yes' AND option_name like "um_cache_userdata_%"

اگر متوجه شدید که تعداد بیشتری کوئری وجود دارد ، دوباره مجبورید در بین افزونه‌ها و پوسته‌ها جست‌وجو کنید و دستور grep مخصوص آن را اجرا کنید.

grep -Ri "um_cache_userdata_"

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

در جست‌وجو متوجه شدیم که برای حل مشکلات این افزونه چندین راه وجود دارد

Ultimate Member > Dashboard > User Cache > Clear Cache

Ultimate Member > Settings > Advanced > گزینه Stop caching user’s profile data را فعال کنید > سپس تغییرات را ذخیره سازی کنید.

گزینه دیگر برای پیداکردن گزینه های autoload کلیک روی کلید ویرایشگر است که می‌تواند لیست پوسته‌ها/افزونه‌ها و یا لیست وب سایت توسعه دهندگان آن‌ها را به شما نمایش دهد.

Cron Jobs

یکی دیگر از گزینه‌های پرمصرف در بخش autoload استفاده مکرر Cronjobs ها می‌باشد. در این مورد، هر Cron ممکن است در این مسئله دخیل باشد، بنابراین هنگامی که ممکن است با کلیک روی کلید ویرایش وب سایت خراب شود ، باید چه‌کار کنیم ؟

برای مثال یک کوئری بسیار پرمصرف در وب سایت های وردپرسی کوئری Cron تحت عنوان do_pings می‌باشد که شما با یک جست‌وجوی ساده می‌توانید نحوه پاکسازی این نوع کوئری‌ها را پیدا کنید، اگر با نحوه کار و پاک‌سازی آن اشراف کامل را ندارید این مورد را نادیده بگیرید، یا قبل اجرا بک آپ در دیتابیس خود تهیه نمایید.

کرون جاب

پاکسازی جدول wp_options

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

مانند اولین نکته‌ای که به شما گفتیم ، برای پاکسازی جدول wp_options باید ابتدا وارد phpMyAdmin شوید. از منو سمت چپ پایگاه داده وردپرس خود را انتخاب کنید و وارد سربرگ SQL شوید. سپس دستور زیر را وارد کنید و روی کلید GO کلیک کنید.

SELECT * FROM `wp_options` WHERE `autoload` = 'yes'

این دستور به شما تمامی داده‌های جدول wp_options را که در آنها autoload بر روی yes ذخیره شده است را نمایش می‌دهد.

پایگاه داده و phpMyAdmin

با اسکرول کردن سطر‌ها به ترتیب تمامی افزونه‌هایی که در حال حاضر نصب یا درحال استفاده نیستند را مشاهده می‌کنید. به عنوان نمونه در این آموزش ما سطر‌هایی از افزونه Jetpack توسعه داده شده توسط وردپرس را بررسی می‌کنیم.

به عنوان مثال در حال حاضر وب سایت از افزونه Jetpack استفاده نمی‌کند.

 

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

برای مثال در دستور زیر ، ما تمامی داده‌های autoload درون wp_options را که مخصوص افزونه jetpack هستند را فراخوانی می‌کنیم:

SELECT *

FROM `wp_options`

WHERE `autoload` = 'yes'

AND `option_name` LIKE '%jetpack%'

سپس روی کلید Select All کلیک می‌کنیم و روی Delete کلیک میکنیم تا به طور کامل جداول حذف شوند.

حذف کوئری ها به صورت دستی

یا شما می‌توانید به صورت مستقیم با دستور زیر اقدام به حذف کوئری‌ها کنید:

DELETE

FROM `wp_options`

WHERE `autoload` = 'yes'

AND `option_name` LIKE '%jetpack%'

پاکسازی داده های autoload شده در جدول wp_options

حالا شما میتوانید با تغییر options_name به عنوان افزونه و یا پوسته قدیمی خود داده های autoload شده جدول را پاکسازی کنید.

پاکسازی گذرا

اگر از یک حافظه کش استفاده می‌کنید، وردپرس رکورد‌های گذرا یا transient را در خود جدول wp_options ذخیره می‌کند. به طور کلی این نوع رکورد‌ها باید زمان انقضایی داشته باشند و در طول زمان پاک‌سازی شوند ، با اینکه ، همیشه اینطور نیست. در حال حاضر پایگاه‌های داده‌ای وجود دارد که بیشتر از هزاران رکورد transient قدیمی را در خود نگاه داشته‌اند. باید توجه داشته باشید که رکورد‌های transient به صورت پیش‌فرض به صورت خودکار بارگیری نمی‌شوند.

شما می‌توانید از دستور زیر برای مشاهده رکورد‌های transient خودکار بارگیری شده استفاده کنید :

SELECT *

FROM `wp_options`

WHERE `autoload` = 'yes'

AND `option_name` LIKE '%transient%'

به هر حال ، شما می‌توانید از افزونه Transient Cleaner نیز برای پاکسازی داده‌های گذرا از پایگاه‌داده خود استفاده کنید.

یک شاخص برای Autoload اضافه کنید

اگر پاکسازی داده‌های جدول wp_options کافی نبود و به مشکل برخوردید ، شما بهتر است که از یک شاخص برای autoload استفاده کنید.

این کار اساسا کمک می‌کند که جست‌وجوی شما کارآمدتر شود.

تیم تست به نام 10آپ ، چند آزمون مختلف بر روی جدول wp_options با رکورد‌های autoload شده انجام داده است تا نمایش دهد که چطور با افزودن یک شاخص به کوئری‌های wp_options می‌توانیم در عملکرد وب سایت بهبود بخشیم.

یک شاخص برای Autoload اضافه کنید

افزونه Little Bizzy یک افزونه کاملا رایگان وردپرسی است که با اضافه کردن شاخصی برای autoload جدول wp_options با استفاده از wp_cron  برای گزارش روزانه می‌تواند به شما بسیار کمک کند.

رفع خطای 504 Gateway Timeout

ارور 504 Gateway Timeout یعنی چه

خطای 504 Gateway Timeout معنای لغوی آن وقفه دروازه 504 است یک کد HTTP status که از سری ارور 5XX است. معنی دقیق آن این است که یک سرویس‌دهنده (سرور) پاسخی به موقع از سرویس‌دهنده‌ی دیگر که در تلاش برای بارگذاری صفحه‌ی وب یا تکمیل درخواست مرورگر است، را دریافت نکرده است.

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

ظاهر خطای 504

Gateway Timeout

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

504 Gateway Timeout

HTTP 504

504 ERROR

Gateway Timeout (504)

HTTP Error 504 - Gateway Timeout

Gateway Timeout Error

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

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

دلایل بروز خطاهای 504 Gateway Timeout

یک خطای 504 Gateway Timeout در بیشتر مواقع به این معنی است که هر قدر اتلاف زمان در سرور دیگر بیشتر طول بکشد، “زمان انقضا” احتمالاَ کم‌تر خواهد بود و یا این که پس از این زمان سرور به درستی کار نمی‌کند.

نحوه رفع خطای 504 سمت کاربر

از آن جایی که این خطا یک خطای شبکه‌ای بین سرورها در اینترنت است و یا مسئله‌ای مرتبط با یک سرور خاص است؛ این مشکل احتمالاَ ربطی به رایانه، دستگاه یا ارتباط اینترنتی شما ندارد.

بنابراین کارهای اندکی از سوی شما کاربران (برای رفع این مشکل) برمی‌اید که به قرار زیر است:

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

تمام دستگاه‌های شبکه خود را راه‌اندازی مجدد کنید. مشکلات موقتی مرتبط با مودم، روتر، سوئیچ‌ها و یا دیگر سخت‌افزارهای شبکه ممکن است سبب ایجاد مشکل 504 شود. بنابراین فقط راه‌اندازی مجدد دستگاه‌ها ممکن است اثربخش باشد.
نکته: در حالی که سفارش خاموش کردن این دستگاه‌ها خیلی مهم نیست اما شما بایستی این کار را انجام دهید. به طور کلی وقتی به دستگاه‌های نیاز ندارید آن‌ها را خاموش کنید.

تنظیمات سرویس‌دهنده‌ی پراکسی را در مرورگر یا نرم‌افزار خود بررسی کنید و مطمئن شوید آن‌ها درست عمل می‌کنند. تنظیمات پراکسی نادرست ممکن است سبب بروز خطاهای 504 شوند.
نکته: لینک http://proxy.org  را برای دریافت فهرستی روزآمد از سرویس‌دهنده‌های پراکسی ببینید؛ می‌توانید از بین فهرست انتخاب کنید.
توجه: بسیاری از رایانه‌ها فاقد تنظیمات پراکسی هستند بنابراین چنان‌چه (این قسمت) در رایانه‌ی شما خالی است جای نگرانی نیست، در این صورت بایستی از این مورد چشم‌پوشی کرد.

سرویس‌دهنده‌های DNS خود را تغییر دهید. این امکان وجود دارد که ارور 504 که شما با آن روبه‌رو شده‌اید به دلیل بروز مسئله در سرویس‌دهنده‌های (سرور) DNS باشد که شما از آن‌ها استفاده می‌کنید.
نکته: سرور‌های DNS که در حال حاضر اقدام به پیکره‌بندی آن‌ها نموده‌اید احتمالا همان‌هایی هستند که به طور خودکار به وسیله‌ی ISP های (ارائه دهنده‌های اینترنت) شما تعیین شده‌اند.

اگر تا اینجا نتوانسته باشید بر مشکل غلبه کنید، احتمالاَ برقراری تماس با وب‌سایت گزینه‌ی بعدی شما است. این احتمال وجود دارد که مدیران وب‌سایت در تلاش برای رفع علت اصلی خطای 504 باشند با این حال برقراری تماس با آن‌ها جای نگرانی ندارد.
نکته جالب: در توییتر  معمولا  زمانی یک سایت به طور کامل Down یا به اصطلاح خوابیده می‌شود، به ویژه اگر سایت Down شده از وب‌سایت‌های محبوب و پرمخاطب باشد، مملو از بحث هایی در قالب تویت می‌شود و اگر در سایت های بزرگ با چنین مشکلی مواجه شدید، می‌توانید به این شبکه ها سر بزنید و با یک جستجو به اطلاعات لازم درباره خطاهای اخیر در آن سایت می‌رسید. مثلا می‌توان از هشتک هایی مثل  #websitedown در توییتر استفاده کرد برای پیدا کردن یک سایت خاص. به عنوان مثال زمانی که سایت فیسبوک برای مدت کوتاهی Down شد هشتک facebookdown در این شبکه اجتماعی مورد استفاده زیادی قرار گرفت. یا سایت آمازون هم در این شبکه اجتماعی مورد هدف کاربران قرار گرفته و با هشتک amazondown تویت های بسیاری را می‌بینیم. در واقع این روش، ترفندی عالی برای اطلاع از وضعیت دیگر سایت‌ها به جز توییتر است.

برقراری تماس با ارائه‌دهنده‌ی خدمات اینترنتی (ISP) شما. پس از دنبال‌ کردن تمام مراحل عیب‌یابی (مراحل بالا) احتمال بالایی وجود دارد که خطای 504 مشکلی است که ناشی از بروز مسئله شبکه‌ای باشد؛ مسئله‌ای که ارائه‌دهنده‌ی خدمات اینترنت شما باید پاسخگوی آن باشد.

در زمانی دیگر مراجعه داشته باشید. چنان چه تمام موارد بالا را برای رفع خطا انجام داده‌اید ولی همچنان با خطای 504 error مواجه هستید، قطعا احساس خستگی خواهید کرد، راهکار این است که سایت (مورد نظر) را به صورت دوره‌ای بررسی کنید. بدون شک آن سایت دوباره شروع به کار خواهد کرد.

چگونگی رفع خطای 504 سمت سرور

بسیاری از مواقع بروز خطا اصلاَ تقصیر شما که مالک و مدیر سایت هستید، نیست و از طرفی این مشکل ربطی به کاربران ندارد. در این وضعیت سرور خود را بررسی کنید؛ و با نرم افزارهای مختلفی سرور را مورد تست و ارزیابی قرار دهید. منظور از نرم افزار همان CMS های موجود و رایگان در فضای نت است.

ترافیک خیلی سنگین ممکن است به بروز خطای 504 منجر شود (منظور از ترافیک همان بازدید کاربران است) ، حتی در این شرایط خطای 503 هم می‌تواند به وجود آید. باید دقیق بررسی کرد.

در وردپرس، به طور ویژه پیغام‌های خطای 504 گاهی اوقات به دلیل پایگاه‌های داده‌ای ایجاد می‌شوند. پلاگین بهینه سازی پایگاه داده WP-DB را نصب کنید، سپس تلاش کنید “DB را تعمیر کنید”، کار را با “بهینه‌سازی DB” ادامه دهید و ببینید این کار موثر است یا خیر. (منظور از DB همان پایگاه داده است)

همچنین از درستی فایل HTACCESS خود به ویژه اگر وردپرس را نصب مجدد کرده‌اید، مطمئن شوید.

ممکن است بعد از آپدیت کردن اسکریپت یا افزونه ای با چنین مشکلی مواجه شده باشید و افزونه نتواند با سرور شما ارتباط برقرار کند و در صفحاتی که آن افزونه لود می‌شود با ارور 504 روبه‌رو شوید.

حتما شما سایت cloudflare را می‌شناسید ما در مقاله آموزش cloudflare به این موضوع اشاره کردیم و خطا 504 همگام استفاده از این شبکه تحویل محتوا یا همان CDN بسیار است و علت ممکن است این باشد که در این مسیر ارتباط بین سرور اصلی و سرور CDN مشکلاتی رخ داده باشد و اصولا این مشکلات موقت هستند.

سرانجام این که برقراری تماس با شرکت میزبان (وب‌سایت) خود را مورد توجه قرار دهید. ممکن است خطای 504 که در مورد وب‌سایت شما ایجاد شده است به مسائلی ناشی از (شرکت میزبان) برگردد که نیازمند رفع است.

خطای 504 هم همانند خطاهای 5XX اهمیت بالایی در بهبود تجربه کاربری و همچنین سئو سایت دارد. همیشه سعی کنید از یک هاست مطمئن و معتبر برای میزبانی سایت خود استفاده کنید.
خطای 504 شباهت بسیار زیادی با خطای 502 دارد و اگر راه‌کارهای بالا را انجام دادید ولی موفق نشدید میتوانید خطای 502 را مطالعه کنید.
خطاهای رده 4XX مثل خطای 400 ، خطای 401 ، خطای 403 ، خطای 404 و خطای 408 هم همانند خطای 504 می‌تواند بر روی عواملی که ذکر کردیم تاثیرگذار باشد.
امیدواریم این مقالات سئو برای شما مفید واقع شده باشد و بتوانید از آن استفاده کنید.

تجزیه و تحلیل آبشاری (Waterfall Analysis)

نمودار آبشاری که به عنوان گراف آبشاری و هم چارت آبشاری نیز شناخته می‌شود، ارائه بصری از نحوه بارگذاری عناصر در وب سایتتان ارائه می‌دهد. این عناصر شامل CSS، JavaScript، HTML، تصاویر، پلاگین ها، فونت‌ها و … می‌شوند. نکته مهم دیگر این است که نمودارهای آبشاری به شما اجازه مشاهده ترتیب رندر شدن عناصر در مرورگر را می‌دهند. از آن جا که این عناصر می‌توانند شامل موارد مختلفی باشند از جمله بلاک های CSS تا مشکلات FOIT ، ترتیب بارگذاری از اهمیت زیادی برخوردار است که در ادامه به آن اشاره خواهیم کرد.

ابزارهای تست آنلاین سرعت سایت بسیاری وجود دارند که می‌توانید برای ایجاد نمودار آبشاری از آن ها استفاده کنید. در زیر یک نمودار آبشاری معمولی را مشاهده می‌کنید که با ابزار خوده گوگل کروم یعنی Chrome DevTools ایجاد شده است. می‌توانید ببینید که زمان کلی بارگیری سایت میزفا 2.97 ثانیه می‌باشد، 31 درخواست HTTP وجود دارد و در مجموع 966 کیلو بایت داده منتقل شده است.

نمودار آبشاری سایت میزفا در devtools کروم

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

1 – DNS Lookup / DNS

هنگام دسترسی به یک صفحه وب، مرورگر تمام منابعی که نیازمند DNS Lookup هستند و باید تا زمان تکمیل lookup منتظر بمانند را شناسایی می‌کند. DNS lookup مبتنی بر hostname ها می باشد. به عنوان مثال، اگر Google Analytics را در وب سایتتان اضافه کنید، نه تنها برای دامنه شما DNS lookup انجام می دهد بلکه برای google-analytics.com نیز این کار را انجام می‌دهد. (اگر اطلاعی درباره DNS Lookup ندارد این قسمت را بخوانید)

dns lookup در devtools

پست ما درباره چگونگی کاهش DNS lookup را حتما مشاهده کنید چرا که در این قسمت به شکل کامل به DNS Lookup پ نحوه کاهش آن بحث کردیم.

کاهش DNS Lookup کمک بزرگی به بهبود سرعت سایت می‌کند، به همین دلیل است که همواره توصیه می‌شود عناصر واسطه بیشتری را روی CDN قرار دهید زیرا این کار درخواست های DNS lookup را کاهش می‌دهد. همچنین باید توجه داشته باشید که در ابزارهای زیاد، اگر تست های سرعت را چندین بار اجرا کنید، آن‌ها DNS را cache می کنند، به این معنی که این اطلاعات را در تست های بعدی مشاهده نخواهید کرد. اما lookup همچنان برای بازدیدکنندگان جدید که وارد سایت شما می شوند انجام می‌شود. سایت WebPageTest که از نگاه بنده بهترین ابزار برای آنالیز درخواست های http و همینطور تجزیه و تحلیل آبشاری سایت هست، برای رفع این مشکل راه حل مناسبی به نام First View و Repeat View دارد. از این طریق می توانید تصویر کلی بهتری را مشاهده کنید.
همچنین می توانید از resource hint هایی مانند DNS prefetching استفاده کنید که به مرورگر امکان انجام DNS lookup در یک صفحه در پس زمینه در حالی که کاربر در حال استفاده از مرورگر است را می‌دهد. این امر باعث کاهش latency یا همان تاخیر در DNS lookup در زمان کلیک کاربر روی یک لینک انجام می‌شود. مثال زیر را مشاهده کنید

https://uupload.ir/files/ow41_blog-seo.png

<!-- Prefetch DNS for external assets -->

 <link rel="dns-prefetch" href="//fonts.googleapis.com">

 <link rel="dns-prefetch" href="//www.google-analytics.com">

 <link rel="dns-prefetch" href="//cdn.domain.com">

2 – Initial Connection / Connect (ارتباط اولیه یا اتصال)

ارتباط اولیه که با عنوان ارتباط TCP و ارتباط در بعضی ابزارها شناخته می‌شود، مجموع زمان مورد نیاز برای ایجاد یک ارتباط TCP است. این مورد برای ایجاد یک ارتباط بین یک کاربر یا هاست محلی و سرور استفاده می‌شود و روشی سه مرحله ای می‌باشد که نیازمند کاربر و سرور به منظور تبادل بسته ها قبل از شروع تبادل اطلاعات است.

بررسی زمان اتصال اولیه ؟

کاهش زمان TCP کمی دشوارتر است. بهترین نقطه برای شروع این است که مطمئن شوید روی یک هاست وب سریع با تاخیر پایین سایت شما پیاده شده است. این handshake با ارسال داده از طرف کاربر در حین SYN اتفاق می‌افتد، بنابراین به ارتباط ها امکان جایگزینی در حین handshake را می‌دهد.
همچنین preconnect را فراموش نکنید که به مرورگر اجازه می‌دهد ارتباط‌های ابتدایی را قبل از ارسال واقعی درخواست HTTP به سرور ایجاد کنید. مثال زیر طرز فعال کردن preconnect را نشان میدهد.

3 – SSL / TLS

SSL، که در بعضی ابزار ها به عنوان SSL negotiation نیز معرفی می‌شود، زمان کلی مرورگر برای اجرای SSL/TLS handshake می‌باشد. مشخصاً این را زمانی مشاهده می‌کنید که CDN و یا هاست شما روی HTTPS فعال باشد.

زمان لود SSL

در زیر تعدادی روش برای افزایش سرعت سایت هایی که روی HTTPS اجرا می شوند آورده شده است.

 HSTS مخفف عبارت HTTP Strict Transport Security می‌باشد، یک تقویت کننده امنیت است که صرفاً دسترسی مرورگرها فقط از طریق HTTPS محیا می‌کند. این ابزار با حذف redirect های HTTP و HTTPS غیر ضروری باعث کمک به عملکرد سرعت وب سایت شما می‌شود.

خاتمه دادن زودهنگام در کاهش تاخیر SSL/TLS handshake بسیار مهم است. با توزیع محتوا به کمک CDN تاخیر هر رفت و برگشت بین کاربر و سرور را کاهش می‌دهید. یک CDN به شما اجازه می دهد ارتباط نزدیکتر به کاربر را برقرار کنید.

OCSP stapling رویکردی جایگزین برای تعیین معتبر بودن یا نبودن یک سند SSL است. این رویکرد به وب سرور اجازه می‌دهد تا معتبر بودن گواهینامه ها را بررسی کند و نیاز به درخواست صدورگواهی از جانب کاربر را حذف کند و درخواست دیگر را کاهش دهد. هنگامی که با HTTPS سروکار دارید، OCSP به طور خودکار فعال می‌شود.

و البته HTTP/2 را داریم که دومین به روز رسانی عمده پروتکل HTTP از زمان HTTP1.1 می‌باشد. ویژگی های عملکردی HTTP/2 شامل بهبود سرعت مرور وب و همچنین افزایش امنیت می‌باشد.

4 – TTFB / Waiting

TTFB که خلاصه time to first byte است، مقدار زمانی است که طول می‌کشد تا یک کاربر یک درخواست HTTP ایجاد کرده و اولین بایت داده را از وب سرور دریافت کند. در Pingdom این مورد به عنوان زمان انتظار یا wait time شناخته می شود. TTFB یک جنبه مهم از بهینه سازی وب سایت است زیرا هرچه TTFB سریع‌تر باشد، منبع درخواستی سریع‌تر به مرورگر ارسال می‌شود. به طور میانگین هر چیزی با TTFB کمتر از 100 میلی ثانیه فوق العاده است. هرچیزی با میانگین TTFB 200 تا 500 میلی ثانیه استاندارد است و بین 500 میلی ثانیه تا 1 ثانیه کمتر از ایده آل و هرچیزی با TTFB بزرگتر از 1 ثانیه احتمالاً باید مورد بررسی قرار گیرد. نکات تکمیلی و جالب درباره TTFB را حتما در مقاله TTFB چیست بخوانید.

زمان انتظار یا TTFB

یکی از راه های ساده بهبود TTFB پیاده سازی caching روی سرور است. به عنوان مثال، اگر از وردپرس استفاده می کنید، پلاگین WordPress Cache Enabler می تواند یک فایل Cache استاتیک در قالب HTML روی سرور شما ایجاد کند. این مورد به کاربران اجازه می‌دهد تا از فرایند فشرده سازی منابع جلوگیری کنند، بنابراین صفحه با TTFB سریع‌تری تحویل داده می‌شود.
و البته استفاده از CDN نیز به شدت می تواند TTFB شما را بهبود دهد. از مقاله دلایل استفاده از CDN به شکل کاملی فواید CDN تشریح کردیم.

TTFB قبل از CDN

در اینجا مثالی از آزمایش TTFB بدون استفاده از CDN را مشاهده می‌کنید.

زمان TTFB بدون CDN

TTFB با CDN

در ادامه مثال قبل را با استفاده از CDN تکرار کردیم.

زمان TTFB با فعال بودن CDN

همانطور که مشاهده می کنید، با استفاده از CDN مقدار TTFB به نصف کاهش پیدا کرد. البته بسته به موقعیت سرور و POP ها این موارد متفاوت خواهند بود. از جمله راه های دیگر برای افزایش سرعت TTFB می توان به روز بودن Nginx و Apache و همچنین مدیریت منابع سرور از جمله CPU و IO و همینطور اسکریپت و پلاگین‌های نصب شده اشاره کرد.

5 – دانلود محتوا (Content Download)

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

هنگامی که درباره زمان دانلود محتوا صحبت می‌کنیم فشرده سازی تصویر نقش بزرگی در این مورد ایفا می کند. طبق HTTP Archive، از ژوئن 2017 تصاویر به طور متوسط 61% از حجم وب سایت ها را به خود اختصاص می دهند. مقالات جامع ما درباره بهینه سازی عکس می‌تواند بسیار به شما کمک کند

نحوه دانلود محتوا در نمودار آبشاری

و البته استفاده از CDN می تواند یکی از آسان ترین راه ها به منظور کاهش زمان دانلود محتوا باشد، زیرا از این طریق محتوا را از POP های نزدیک به کاربران به آن ها عرضه می کنید. استفاده از CDN باعث کاهش TTFB نیز می شود.
از راه های دیگر به منظور کاهش زمان دانلود می توان به استفاده از javascript و css تنها در موارد مورد نیاز و فشرده سازی با Gzip اشاره کرد. برای فشرده سازی فایل‌ها توسط سرور به مقاله جامع ما درباره نحوه فعال سازی gzip مراجعه نمایید

.

6 – محتوای بارگذاری شده DOM

DOM مخفف Document Object Model می باشد. هنگامی که از inspector کروم یا فایرفاکس استفاده می‌کنید تبی دارد به نام elements در واقع این تب در حال مشاهده نمایه بصری از DOM هست، Chrome DevTools پس از دستکاری در صفحه DOM را با HTML یا javascript نمایش می‌دهد. همچنین می توانید به آن به عنوان HTML تجزیه شده نیز نگاه کنید.
هنگامی که به بررسی سرعت صفحات وب سایت می پردازیم، همواره باید مواردی که ممکن است DOM را مسدود کنند و باعث ایجاد تاخیر در زمان بارگذاری می‌شوند را در نظر داشته باشید. این موارد به عنوان render blocking resources در نظر گرفته می‌شوند، مانند HTML، CSS و جاوا اسکریپت. بیشتر ابزارهای تست سرعت سایت مجموع محتوای DOM را نمایش می دهند در حالیکه این زمان با زمان کلی بارگذاری متفاوت است.

محتوای بارگذاری شده DOM

7 – زمان بارگذاری (Load Time) / بارگذاری کامل (Fully Loaded)

Load Time که با عنوان Fully Loaded نیز در بعضی ابزار ها شناخته می‌شود، زمان کلی پایان دانلود، رندر و نمایش به کاربر است. این مورد از معیارهای بسیار مهم است که باید مورد توجه قرار گیرد چرا که این زمان در Devtools واقعی تر از ابزارهای تست آنلاین است، به این علت که ابزارهای تست سرعت سایت لوکیشن ایران را ندارند و شما می‌توانید با مرورگر خود یک ابزار تست سرعت سایت در ایران باشید.

زمان لود سایت در کروم کاربر

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

8 – Data Transferred / Bytes In / Page Size

Data Transferred در Devtools کروم (دیتا انتقال داده شده)، که در WebPageTest به عنوان Bytes In شناخته می‌شود، و در Pingdom به عنوان Page Size، اندازه کلی تمامی asset ها (تمام فایل‌های پیوست شده در سند html) در صفحه وب می باشد. هرچه این مقدار کوچکتر باشد، بهتر است. توصیه های ما درباره کاهش زمان بارگذاری محتوا که در بالا آورده شد را دنبال کنید و در عوض Data Transfered وب سایت شما کاهش پیدا می‌کند.

دیتا انتقال داده شده از سرور به مرورگر کاربر

تا سال 2016 متوسط اندازه صفحه، کمی بیشتر از 2 مگابایت بود که بسیار بزرگ است. اندازه صفحه وب از سال 2010 تا 2016 317% افزایش یافته و به مقدار 1530 کیلو بایت رسیده است. پیشنهاد می کنیم حداقل 1 مگابایت یا کمتر برای اندازه صفحه وب سایت خود در نظر بگیرید. اگرچه این امر در تمام محیط ها امکان پذیر نیست.

9 – درخواست های HTTP

درخواست‌ها مجموع کلی درخواست های HTTP تولید شده در وب سایت شما را نشان می دهند. هر فایل اضافه شده  (CSS، JavaScript، Image) درخواست مربوط به خود را تولید می‌کند. در مجموع هرچه درخواست های HTTP صفحه شما بیشتر باشد، زمان بارگذاری هم طبیعتا بیشترخواهد شد.

تعداد درخواست های http برای لود سایت

روش های زیادی برای کاهش تعداد درخواست ها وجود دارند که می توان به موارد زیر اشاره کرد:

قرار دادن کدهای کوچک جاوا اسکریپت به صورت درون خطی

کاهش asset هایی مانند اسکریپت های واسطه و پلاگین هایی که درخواست های خارجی زیادی تولید می کنند.

استفاده نکردن از framework های واسطه که به آن ها نیاز ندارید.

کم کردن کد.

ترکیب فایل های css و javascript.

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

10 – کدهای وضعیت (Status Codes)

کدهای وضعیت یا همان Status Codes ، که با عنوان کدهای خطا (Error) و کدهای پاسخ سرور (Server Response Codes) نیز شناخته می‌شوند، پیام هایی هستند که شامل اطلاعات کامل وضعیت ها درخواست بین کاربر و سرور می باشند. کاربر درخواست خود را به یک سرور HTTP ارسال می کند که میزبان یک وب سایت است، سپس سرور پیام پاسخ را در قالب یک کد بازمی گرداند.

نمایش Status Codes با کدهای مختلف همانند 404 و 200

اگر مشکلی در یک درخواست HTTP باشد، لیستی از کدهای وضعیت وجود دارد که مرورگر شما را با استفاده از آن مطلع می سازد تا بتوانید منبع مشکل را پیدا کنید. روشی که مرورگر پاسخ را مدیریت می‌کند بسته به کد و فیلد header پاسخ دارد. به عنوان مثال، خطای Not Found 404 بدان معناست که محتوا دیگر وجود ندارد یا حذف شده است.

نحوه محاسبه Bounce rate در گوگل آنالیتیکس

نحوه محاسبه Bounce rate در گوگل آنالیتیکس

Bounce Rate چیست را به شکل کلی در مقاله اول تعریف کردیم ولی تعریف Bounce rate یا همان نرخ پرش از نگاه گوگل در ابزار Google Analytics کمی متفاوت و البته دقیق‌تر است، از نگاه گوگل:

اگر کاربری Interaction انجام ندهد یک بانس ریت (Bounce Rate) رخ داده است.

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

Interaction درGoogle Analytics چیست

معنی Interaction “تعامل” می‌باشد به زبان ساده آیا کاربر درگیر سایت شده است؟ آیا واکنشی نشان داده؟ نام پارامتر این تعامل را interaction گویند. و حال اینکه چه چیزی شامل Interaction می‌شود را در ادامه به شکل کامل توضیح خواهیم داد.

بانس ریت در گزارش Audience گوگل آنالیتیکس

انواع Interaction در گوگل آنالیتیکس

سه نوع interaction داریم که در ادامه معرفی خواهیم کرد:

Pageviews

Pageviews همان تعریف قدیمی بانس ریت را همراه دارد، اگر یک Pageviews توسط بازدیدکننده صورت بگیرد به این معنا است که آن بازدیدکننده یک صفحه از سایت را مشاهده کرده است.
حال زمانی Pageviews باعث می‌شود Bounce rate رخ ندهد که دو Pageviews و یا بیشتر توسط کاربر صورت گیرد، یعنی اگر بازدید کننده دو صفحه و یا بیش از دو صفحه را در سایت مشاهده کند دیگر Bounce rate یا نرخ پرش رخ نمیدهد و طبیعتا بالا نمی‌رود. حتما میدانید که هر چقدر نرخ پرش بالاتر باشد بدتر است. (البته همیشه به این شکل نیست و این موضوع شرط دارد که بعدا اشاره خواهیم کرد)

مثال: فرض کنیم یک کاربر Page-A (منظور از Page-A یعنی یک صفحه فرضی که نام آن را A گذاشتیم) را مشاهده می‌کند و بعد از آن Page-B را مشاهده می‌کند در این حالت دو Pageviews توسط کاربر یک صورت گرفته است و Bounce rate این کاربر ۰ درصد است.
کاربر دوم فقط Page-A را مشاهده کرده و فقط یک Pageviews داشته است در این صورت Bounce rate این کاربر ۱۰۰ درصد است.

با یک محاسبه ساده متوجه می‌شویم که حاصل بازدید این ۲ کاربر یک نرخ پرش با مقدار ۵۰ درصد است.

Event

Event به رفتارهایی گویند که توسط کاربر در سایت ثبت می‌شود و با Event های رویدادی که به شکل دورهمی، کلاس و یا همایش برگزار می‌شوند، متفاوت می‌باشد.
Event ها اصولا باید توسط شما در سایت تعریف شوند و ابزار گوگل آنالیتیکس خود نیز به شکل پیش فرض Event ندارد و شما باید به کمک ابزار قدرتمند Google Tag Manager که به اختصار GTM گفته می‌شود، بتوانید Event های لازم را در سایت خود تعریف کنید.

اگر تا به حال شما از GTM استفاده نکردید پس Eventها در Bounce rate شما تاثیری نخواهند داشت. ولی به شکل کلی بدانید که اگر Eventها به همراه Hit ارسال شوند می‌توانند روی بانس ریت تاثیرگذار باشند و آن را کمتر کنند. و اگر بدون Hit تنظیم شود تاثیری روی Bounce rate نخواهند داشت.

شاید بپرسید Hit چیست؟ hit یک سری داده های کوچک متنی هستند که از سمت کد موجود گوگل آنالیتیکس در سایت ما به سرورهای اصلی گوگل آنالیتیکس ارسال می‌شوند .

نکته مهم: بنابراین ما متوجه شدیم که خودمان می‌توانیم با Eventها باعث تغییر Bounce rate  شویم ولی تغییر Bounce rate در گوگل آنالیتیکس تاثیری در سئو و بهبود سایت در نتایج گوگل نخواهد داشت. آماری که در گوگل آنالیتیکس به شما نشان داده می‌شود صرفا برای آگاهی شما است، بنابراین سعی بر آن نداشته باشید که با تعریف Event دارای Hit آمار Bounce rate را کاهش دهید، چرا که این عمل صرفا شما را به مسیری نادرست هدایت می‌کند و باعث فریب شما در آنالیز کردن داده‌های سایتتان می‌شود.

بعدا در مقاله های جداگانه درباره Eventها صحبت خواهیم کرد.

Transaction چیست؟

Transaction هم یک نوع Pageviews است ولی در صفحات خرید یک محصول، به عبارتی وقتی کاربری قصد خرید یک محصول را داشته باشد به سبد خرید (cart) مراجعه می‌کند و سپس به صفحه پرداخت (checkout) می‌رود و بعد از آن پرداخت را صورت می‌دهد. به همین منظور برای طی کردن این مسیر (مسیر کاربر در گوگل آنالیتیکس را Flow گویند) نیاز هست به صفحات مختلف برود و این یعنی Pageviews یا همان transaction رخ دادن.
طبیعتا عمل transaction باعث میشود که نرخ پرش رخ ندهد به عبارت دیگر باعث کاهش بانس ریت می‌شود.

جمع بندی حرف ها در نحوه محاسبه بانس ریت در گوگل آنالیتیکس

اگر هیچ کدام از انواع Interaction های بالا توسط یک کاربر رخ ندهد در گوگل آنالیتیکس نیز یک بانس ریت ایجاد می‌شود. و فرمول بانس ریت به صورت زیر است:

Bounce Rate = Bounces / Total Visitors (x100)

مثال: اگر تعداد bounce = 540 باشد و 1000 بازدید کننده داشته باشیم باید این دو عدد را بر هم تقسیم کنیم و نتیجه به دست آمده را سپس برای محاسبه نرخ پرش ضرب در ۱۰۰ کنیم. در این مثال bounce rate مساوی ۵۴٪ می‌شود.

رفع خطای soft 404

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

خطای soft 404 به این معنی است که شما در حال نشان دادن صفحه‌ای به کاربر هستید که وجود ندارد و عملا یک صفحه 404 است؛ درحالیکه HTTP status code مربوط به این صفحه کد 200 را برمی‌گرداند.

برای دیدن کدهای HTTP status code مربوط به یک صفحه کافی است بر روی صفحه راست کلیک کرده و گزینه Inspect Element را انتخاب کنید. در پنجره باز شده داخل بخش Network  شوید ومطابق شکل کد مربوط را پیدا کنید.

البته اگر به دنبال همه کدهای HTTP هستید حتما مقاله کدهای HTTP status code را مطالعه بکنید، و با کلی خطا که مهم هستند آشنا شوید.

وضعیت کدها یک سایت در مرورگر

به زبان ساده تر، شما در سایت خودتان صفحاتی دارید که به کاربر می‌گویند این صفحه وجود ندارد اما همزمان به مرورگر می‌گویند که این صفحه موجود است.

اما چرا این اتفاق می‌افتد

در اکثر موارد، صفحاتی در سایت شما وجود دارند که یا محتوای کمی دارند یا اصلا محتوایی داخل آن‌ها وجود ندارد.
به عنوان مثال، سایت شما با سیستم مدیریت محتوای وردپرس کار می‌کند و شما یک تگ جدید به مجموعه تگ‌هایتان اضافه کرده‌اید که هنوز هیچ محصول یا مقاله‌ای از آن تگ استفاده نمی‌کند. وردپرس به صورت اتوماتیک صفحه‌ای با عنوان آن تگ تولید می‌کند که محتوایی داخل آن وجود ندارد. در نتیجه، با این کار سایت خود را در معرض مواجه شدن با خطای soft 404 قرار داده اید.

صفحاتی که محتوای کمی دارند به شدت برای ربات‌های گوگل گیج کننده هستند. بیایید نحوه کار ربات گوگل در هنگام خواندن این نوع صفحات را برررسی کنیم.

وقتی ربات گوگل یا هر موتور جست‌و‌جوی دیگری در حال بررسی سایت شماست، سرور پیغامی تحت عنوان HTTP status code به این ربات‌ها ارسال می‌کند. همانطور که می‌دانید، کد 200 به معنای موجود بودن یک صفحه است. ربات از سرور پیغام موجود بودن صفحه را می‌گیرد اما با صفحه‌ای بدون محتوا، محتوای کم یا تکراری روبرو می‌شود. واکنش ربات موتورهای جست‌و‌جو به این حالت این است: “این صفحه ارزشمند نیست و دلیلی برای index شدن آن وجود ندارد.”

هم‌چنین ممکن است بخواهید آدرسی از صفحات سایت تان که در گوگل ایندکس شده‎ است را  به یک صفحه دیگر مثل صفحه اصلی ریدایرکت کنید. اتفاقی که می‌افتد این است که کاربر در صفحه جست و جوی نتایج موتور جست و جو (SERP) روی لینک مطلبی که ریدایرکت شده است کلیک می‌کند و به صفحه ای کاملا نامرتبط با درخواستی که داشته هدایت می‌شود. در این حالت صفحه اول که به صفحه اصلی ریدایرکت شده است برچسب خطای soft 404  می‌گیرد.

آیا مشکل خطا soft404 احتیاج به حل شدن دارد

صفحه‌ای که توسط گوگل برچسب soft404 می‌خورد از ایندکس گوگل خارج می‌شود و دیگر در نتایج جست و جو نشان داده نمی‌شود. ( توجه داشته‌باشید که این خطا جزو کدهای وضعیت رایج بین سرور نیست و تنها برچسبی است که گوگل به بعضی صفحات می‌زند.)

چگونه متوجه وجود صفحاتی با برچسب soft 404 شویم

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

اگر صفحه‌ای از سایت شما وجود داشته باشد که بعد از فچ شدن پیغام ریدایرکت به شما ندهد، در حالیکه آن صفحه ریدایرکت شده است نشان می‌دهد خطایی در قسمت  HTTP status code  برای آن صفحه وجود دارد.

fetch

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

چگونه ارور soft 404 را برطرف کنیم ؟

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

داشتن تعداد زیادی صفحه که از طرف گوگل ارور soft404 خورده‌اند، باعث می‌شود گوگل سایت شما را به عنوان سایتی که اطلاعات درستی از وضعیت صفحات خود ارائه نمی‌دهد شناسایی کند. این حالت باعث می‌شود crawl budget سایت شما کاهش پیدا کند.
منظور از crawl budget چیست ؟ یک مقدار بودجه تقریبی است که گوگل برای بازدید ربات‌هایش از سایت شما در نظر می‌گیرد. اگر سایت شما یک سایت با تعداد آدرس‌های زیاد است کم شدن crawl budget  می‌تواند بر روی رنکینگ سایت شما تأثیر منفی بگذارد و باعث کاهش رتبه سایت در نتایج گوگل شود. و اگر جدا از این خطاها، مشکلات دیگر در سئو داشته باشید احتمال پنالتی شدن صفحات سایت در کلمات مرتبط و یا خاص وجود دارد.

برای اینکه بتوانید  مشکل صفحات با خطای soft404  را حل کنید ابتدا باید به علت وقوع این خطا پی ببرید. قبل از هر اقدامی مطمئن شوید  صفحاتی که این مشکل را دارند HTTP status code ، 200 را برگردانند.

چند راه حل برای برطرف کردن خطای soft 404

آدرسی که با این خطا روبه‌رو شده، دیگر وجود ندارد

صفحاتی که دیگر وجود ندارند باید کد 404 یا 410 را به سرور برگردانند. این کد به مرورگرها و موتورهای جست‌و‌جو اعلام می‌کند که آدرس مدنظر دیگر وجود خارجی ندارد.
اگر یکی از 3 حالت زیر برای صفحات سایت شما وجود داشته باشد، ممکن است با خطای soft404 رو به رو شوید.

۱) صفحات خالی
۲) صفحات دسته بندی محصولات که محصولی در آن وجود ندارد
۳) صفحات دسته بندی مجله سایت که هنوز مطلبی مختص آن دسته بندی داخل آن قرار نگرفته و خالی مانده است.

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

در این حالت بهترین راه برای برطرف کردن خطای soft 404 ، طراحی یک صفحه 404 است که HTTP status code 404 را به مرورگر برگرداند.  صفحه 404 شما باید به گونه ای طراحی شود که کاربران را به صفحاتی مشابه با درخواستشان انتقال دهد. تنها در این حالت است که ربات‌های گوگل قانع می‌شوند سایت شما پاسخ درستی به نیاز کاربران ارائه داده است.اگر از سیستم مدیریت محتوای وردپرس استفاده می‌کنید و دسته بندی جدیدی به سایت خود اصافه کرده اید که هنوز مطلب یا محصولی داخل آن قرار ندارد مشمول یکی از 3 حالت بالا شده اید.

در این حالت بهترین راه برای برطرف کردن خطای soft404 ، طراحی یک صفحه 404 است که HTTP status code 404 را به مرورگر برگرداند.  صفحه 404 شما باید به گونه ای طراحی شود که کاربران را به صفحاتی مشابه با درخواستشان انتقال دهد. تنها در این حالت است که ربات‌های گوگل قانع می‌شوند سایت شما پاسخ درستی به نیاز کاربران ارائه داده است.

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

فرض کنید آدرس یک صفحه را که قبلا در گوگل ایندکس شده است را به  صفحه ای با محتوای کامل تر و آدرسی جدید تغییر داده اید.در اینصورت باید آدرس قبلی را به صورت دائمی به آدرس جدید منتقل کنید. (redirect 301)

آدرسی که با این خطا روبه‌رو شده، در سایت شما موجود است.

اگر آدرس صفحه مورد نظر هنوز در سایت شما قرار دارد و می‌خواهید در نتایج جست و جوی گوگل نشان داده شود اما اما آن صفحه برچسب soft404 گرفته است ممکن است به علت کم بودن محتوا یا داشتن محتوای تکراری باشد
در اینصورت باید بر روی غتی کردن محتوای آن صفحه تمرکز کنید. توجه داشته باشید همیشه باید بتوانید به نیاز کاربران پاسخ درستی بدهید.

اگر آدرسی که این برچسب خطا را خورده است؛ وجود دارد اما شما نمی‌خواهید که در نتایج جست و جوی گوگل نمایش داده شود.

اگر صفحه‌ای از سایت شما از طرف گوگل برچسب soft 404 گرفته است و قصد ندارید که با غنی کردن محتوای آن صفحه آن را در نتایج جست و جوی گوگل نمایش دهید بهتر است دسترسی ربات های گوگل را از داخل فایل robots.txt به آن صفحه ببندید تا دیگر توسط ربات های گوگل قابل خواندن نباشد.

پایان وجمع بندی

در پایان به خاطر داشته باشید با بررسی مستمر صفحات سایت خود در ابزار وبمستری گوگل ( search console) می‌توانید صفحات با برچسب soft404  را پیدا کنید و با بررسی علت های مختلفی که در این آموزش به آن‌ها اشاره شد مشکل این صفحات را برطرف کنید.

در پایان امیدواریم این مقاله از سایت میزفا مورد توجه شما قرار گرفته باشد و بتوانید به راحتی به حل مشکل soft 404 که از رده خطاهای 4xx هست، پایان دهید. چرا که این خطا همانطور که در مقاله اشاره شد تاثیر مهمی بر روی سئو داخلی سایت شما دارد و باید برای پیدا کردن و حل کردن انواع خطاهای سایت هوشیار باشید.