راههای مختلفی برای بهینه سازی وب سایت وردپرسی شما موجود است که ممکن است برخی از آنها مهمتر از دیگر راهها باشند. یکی از فاکتورهای مهمی که اغلب نادیده گرفته میشود، کاهش زمان لود DNS Lookups (جستجوهای DNS) میباشد. همانند TTFB و لیتنسی (latency) که قبلا درباره آنها صحبت بسیار کرده بودیم، زمان لود DNS Lookups نیز در دستیابی به اولین اطلاعات وب سایت بسیار موثر است. بنابراین امروز تصمیم گرفتیم که به نحوه کاهش زمان لود DNSLookups و افزایش سرعت آنها بپردازیم و با هم به دلیل اهمیت بالای این فاکتور در سرعت وب سایت پیببریم. توضیحات بیشتر درباره TTFB در مقاله بهبود زمان TTFB بخوانید.
سرفصلهای پست
برای فهمیدن اینکه منظور ما از DNS Lookups یا جستجوهای DNS چیست، ابتدا باید با روش کار اصلی DNS آشنا شوید. به طور کلی DNS مخفف کلمه Domain Name Systi و به معنای سامانه نام دامنه میباشد که اساسا به ستون فقرات اینترنت معروف است.دفترچه یادداشتی برای تمام جهان. تمامی طراحی سایت (طراحی سایت شرکتی، طراحی سایت فروشگاهی، سئو سایت) ها و دامنههایی که شما در اینترنت مشاهده میکنید به طور مشخصی به یک IP Address مرتبط میشوند.
برای مثال هنگامی که آدرس Google.com را در اینترنت وارد میکنید، کوئریهای DNS توسط ISP شما برای دریافت اطلاعات مشخص مرتبط به نیم سرورها درخواست میشوند. سپس جمعآوری اطلاعات دامنه توسط IP در پشت صحنه سرور انجام میشود که شما با توجه به اختصاصی بودن IP آدرس وب سایت گوگل شما میتوانید با آی پی 216.58.217.206 نیز وارد این وب سایت شوید. ورود با ای پی آنقدری که به نظر میرسد هم سرگرم کننده نیست.
هنگامی که شما درخواست ورود به یک وب سایت را وارد میکنید اولین چیزی که ISP شما از سرور مقصد درخواست میکند درخواست ارائه اطلاعات DNS وب سایت میباشد. اما در نظر داشته باشید که نیازی نیست برای هر منبعی دوباره DNSجستجو شود. برای مثال به درخواستهای HTTP زیر توجه کنید:
با توجه به اینکه ۸ درخواست HTTP در بالا وجود دارد، با این حال، با توجه به اینکه ۳ دامنه در درخواستها وجود دارد، ۳ جستجو برای اطلاعات DNS لازم است.
اگر نیاز به توضیحات بیشتر و سادهتر درباره نحوه کار DNS Lookups دارید مقاله رفع خطای Reduce DNS lookups را مطالعه فرمایید.
در زیر به نحوه نمایش درخواستهای بالا در ابزار تست سرعت در ساخت سایت Pingdom میپردازیم. DNS در تحلیل آبشاری به رنگ صورتی میباشد و تحلیل سرعت آن به صورت میلی ثانیه است. وقتی برای اولین بار وب سایتتان را در Pingdom مورد ارزیابی قرار میدهید، این وب سایت به صورت کامل اطلاعات IP آدرس و دیگر کوئریهای DNS شما را دریافت و بررسی میکند. توجه کنید که لازم نیست برای هر ارزیابی برای مثال دامنه cdn.wpdev.ink شروع به ارزیابی DNSها کنید. این دقیقا کاری است که DNS میکند، برای هر دامنه کافیست که تنها یک بار آن را لود کنید. در بالا ۸ درخواستHTTP موجود است که از بین اینها تنها ۳ درخواست DNS لازم است.
برای هر بار بررسی DNS ها توسط مرورگر و سرور زمان اضافه ای به لود وب سایت اضافه میشود و هیچ اطلاعاتی قبل از بررسی کامل DNS لود نمیشوند.
برای مثال در بررسی ۳ DNS بالا ، یکی از ۳ DNS برای بررسی ۳۰۰ میلی ثانیه زمان گرفته است که این زمان بدون در نظر گیری زمان لازم برای بررسی DNS دیگر دامین هاست. بنابر این تاثیر بررسی DNS را بر روی سرعت میتوانید کاملا واضح مشاهده کنید.
هنگامی دوباره وب سایت خود را با Pingdom مورد ارزیابی قرار میدهید، متوجه میشوید که اطلاعات DNS در Pingdom کش شدهاند و دیگر نیازی به لود دوباره آنها نیست. این یکی از دلایلی است که پیشنهاد میشود وب سایت خود را چندین بار در Pingdom مورد ارزیابی دقیق قرار دهید. همانطور که در زیر مشاهده میکنید زمان لود DNS در تصویر زیر 0 ثانیه شده است. این بخش، بخشی است که بیشتر مردم آن را اشتباه در نظر میگیرند اما نگران نباشید، ما در رابطه با کش شدن DNSبیشتر صحبت خواهیم کرد.
به طور کلی هر وب سایت بررسی سرعت نوع بررسی خاص خود را دارد ولی بیشتر آنها سرعت بررسی DNS ها را به شما میگویند. در زیر نحوه نمایش زمان بارگیری اطلاعات DNS را در GTMetrix مشاهده میکنید. DNS ها به رنگ سبز و بر اساس میلی ثانیه مشخص شده اند.
ابزار بررسی سرعت وب سایت WebPageTest نیز یک ابزار بسیار دقیق و کارآمد در حوزه بررسی DNSها و تجزیه و تحلیل نمودار آبشاری برای سایت میباشد که در صورت علاقه میتوانید از این وب سایت نیز استفاده کنید و به علت تعداد سرورها در سراسر جهان و همچنین آنالیز کلی تمامی اطلاعات وب سایت کاربر بسیار معروف شده است. اطلاعات مربوط به زمان لود DNS در این ابزار در ستون DNS Lookup و با واحد اندازه گیری میلیثانیه قرار میگیرد. برای مثال ما یک وب سایت خبری را به صورت تصادفی انتخاب کردیم و پس از انجام عملیات بررسی توسط این ابزار زمان لود DNS به ۶.۵ ثانیه رسید!
متاسفانه در بیشتر وب سایتهای خبری، بهینه سازی صورت نمیگیرد و درخواستهای خارجی وب سایتها بسیار زیاد است. با این حال، همانطور که مشاهده میکنید وب سایت خبری مورد مطالعه ما خیلی بیشتر از مقدار قابل قبول لود DNS از نظر کاربران برای لود این فاکتور زمان نیاز دارد. برای همین است که میگوییم DNS ها خیلی اهمیت دارند، زیرا ممکن است باعث کندی بیش از حد و حتی قطعی وب سایت شما شوند.
در رابطه با نحوه کار DNS ها اطلاعات کاملی به دست آوردید. حال وقت آن است که به نحوه کاهش زمان لود و افزایش سرعت DNS Lookups بپردازیم، افزایش سرعت لود DNS Lookups اسم های مختلفی دارد همانند:
یکی از نکات مهم در DNS ها این است که DNS ها نیز مانند هاستهای میزبانی ارائه دهندگانی سریع و کند دارند. این اولین چیزی است که باید در وب سایتتان رعایت کنید.
به طور معمول DNS های ثبت شده توسط GoDaddy و NameCheap بسیار ضعیف عمل میکنند. ارائه دهندگان DNS نیز مانند CDN دارای POPs های مختلفی در جای جای جهان هستند. از بهترین و پر سرعتترین ارائه دهندگان DNS میتوانیم به amazon ، Cloudflare ، Dyn و DNS Made Easy اشاره کنیم. همه این ارائه دهندگان دارای زیرساختهایی وسیع برای سریعترین بازده میباشند.
ما با توجه به این موضوع شروع به بررسی تک تک ارائه دهندگان DNS کردیم که پس از بررسیهایمان متوجه شدیم که در ارائه دهندگان تجاری DNS سرعت تفاوت خاصی نمیکند ولی در ارائه دهندگان DNS رایگان به جز CloudFlare بقیه سرعت ضعیفی دارند. بنابراین اگر کسب و کار خیلی پر اهمیتی دارید پیشنهاد میشود که از یک ارائه دهنده DNS تجاری استفاده کنید.
بعضی از ارائه دهندگان بالا در مناطقی سریع تر از دیگری هستند و این خیلی مهم است که شما چگونه به بارگیری DNS نگاه میکنید، جهانی یا محلی؟
وب سایت DNSPerf ابزاری خوب برای مقایسه انواع ارائه دهندگان DNS میباشد و به شما کمک میکند که بهترین ارائه دهنده را انتخاب کنید. آیا میدانستید که شما میتوانید بدون استفاده از امکانات دیگر Cloudflare از بخش DNS آن استفاده کنید؟
خوشبختانه، با توجه به توضیحاتی که در بالا دادیم، پس از کش شدن DNS در مرورگر شما، دیگر نگرانی برای لود دوباره بررسیهای DNS در دیگر صفحات شما نیست و تنها کافیست که وب سایت شما برای اولین بار لود شود. کش شدن DNSدقیقا مانند کش شدن کامل وب سایت میباشد و تا زمانی که به تاریخ انقضای خود برسد در مرورگر باقی میماند. طول کش DNS از طریق چیزی با نام Time to live (زمان برای زندگی) که مخفف TTL هست، مشخص میشود. اگر TTL وب سایتی بالا باشد، مرورگر شروع به بررسی دوباره DNS میکند.
شما میتوانید ورودیهای TTL وب سایت خود را برای بهبود کش DNS تغییر دهید. قابل توجه است که ISP ها به صورت خودکار DNS شما را کش میکنند ولی با تغییر ورودیهای TTL میتوانید به این کش کمک کنید.
۳۰ دقیقه در هر ساعت برای TTL بیشتر از همه استفاده میشود. با این حال، بعضی از کاربران به علت بروزرسانی پی در پی وب سایتشان TTL کمتری استفاده میکنند. برای مثال Cloudflare به صورت پیشفرض TTL را بر روی ۵ دقیقه ذخیره کرده است. این خیلی خوب است که شما به رکوردهای دیگر خود نیز توجه کنید و نسبت به استفاده وب سایت آنها را تنظیم کنید. برای مثال :
به طور کلی وقتی در رابطه با TTL صحبت میکنیم جواب درست یا غلطی وجود ندارد. اما شما با کمی تغییر در ورودیهای TTL و آزمایش آن میتوانید به کش DNS کمک کنید.
یکی از بهترین راهها برای کم کردن زمان بررسی DNS ها کاهش تعداد درخواستها به دامنههای مختلف است یعنی به طور کلی کاهش تعداد دامنههای متصل به وب سایت است. زمان بررسی DNS ها به تعداد درخواستها آنقدری هم مهم نیست، مهم تعداد دامنهها است که هرچقدر کمتر باشد زمان بررسی DNS ها نیز کاهش مییابد. وب سایت خود را با یک ابزار مانند Pingdom بررسی کنید و درخواستهای مهم را مشخص کنید. با توجه به اینکه DNS ها بر اساس IP ها طراحی میشوند، شاید برای شما سوال شود که چرا مردم از دامنهها در DNS خود استفاده میکنند؟! حتما توجه داشته باشید که DNS های شما بر روی یک دامنه ست شده باشند زیرا آی پیها قابل تغییر هستند (مثلا با تغییر هاست) ولی دامنهها تغییر نمیکنند و همیشه خواهند ماند و برای کش کردن فایلها مناسبتر هستند.
درحالی که کم کردن تعداد دامنهها (hostnames) نسبت به این ترفند راحتتر است، با این حال، ما پیشنهاد میکنیم که ابتداDNS هایی که سرعت بررسی آنها بیشتر از بقیه طول میکشد را بیابید. برای مثال در وب سایت زیر یکی از فایلهای جاوااسکریپت لود شده از Crazy Egg برای لود DNS ۲۵۵ میلی ثانیه زمان لازم دارد که از بقیه DNS ها بیشتر است. این به علت این است که این وب سایت از یک ارائه دهنده DNS خوب استفاده نمیکند.
در این وضعیت شما میتوانید از سرویسهای جایگزین این سرویس مانند Hotjar که دقیقا همان کار را انجام میدهند استفاده کنید که هم از نظر سرعت لود DNS و هم از نظر کارایی بهتر از این سرویس عمل میکنند. این خیلی مهم است که وقتی شما افزونهای را به وردپرستان اضافه میکنید توجه داشته باشید که به عملکرد وب سایت شما آسیبی نمیزند.
یکی از راحتترین راههای موجود برای افزایش سرعت وب سایت خود این است که تا جای ممکن منابع خود را به ارائه دهندهCDN خود انتقال دهید. هنگامی که شما در Pingdom وب سایت خود را آزمایش میکنید میزان درخواستهای وب سایت خود را بر اساس هر دامنه را مشاهده میکنید. همانطور که مشاهده میکنید در زیر ۹۳.۸ درصد درخواستهای ما از CDN لود میشوند. یک درخواست از هاست خودمان و یک درخواست نیز از گوگل آنالیز میباشد. با انتقال منابع به CDN زمان بررسیDNS ها را به تنها یک DNS ارائه دهنده CDN محدود میکنید و سرعت آن را افزایش میدهید. در مقاله دلایل استفاده از CDN ما به شکل کامل توضیحات لازم را ارائه دادهایم.
به هر حال، وب سایت بالا یک وب سایت خاص بوده است ولی به طور کلی همیشه امکان انتقال اطلاعات به طور کامل به CDN وجود ندارد.
شما در بیشتر مواقع منابعی که نیاز است در سرورهای خارجی لود شوند را در CDN لود خواهید کرد. با این حال، ما پیشنهاد میکنیم که تاجایی که به وب سایتتان آسیب نرساند منابع را از CDN لود کنید. در بیشتر اوقات ما مشاهده میکنیم که کاربران وردپرسی بیشتر منابع خود را در هاست خود لود میکنند و CDN را نادیده گرفتهاند. با انجام این کار شما میتوانید از امکاناتHTTP/2 و parallelization نیز استفاده کنید.
در زیر به نکتههایی اشاره کردهایم که میتواند به شما در این مورد کمک کند.
ما در بیشتر وب سایتهای امروزی مشاهده میکنیم که از فونت Awesome به عنوان فونت آیکون در وب سایت خود استفاده میکنند. ولی مشکلی در استفاده از این فونتها وجود دارد این است که در بیشتر وب سایتهای وردپرسی به صورت کاملا مستقیم از هاست کاربر لود میشوند و کاربران بلد نیستند که آنها را از طریق CDN لود کنند ، در این مواقع پیشنهاد میکنیم که از افزونهای مانند CDN Enabler استفاده کنید.
یک راه دیگر استفاده از cdnjs ویا bootstrapcdn می باشد تا فایلهای فونت را از طریق CDN عمومی لود کنید
با توجه به اینکه با اضافه کردن لینک از طریق CDN های بالا یک رکورد به DNS های شما اضافه میشود پیشنهاد میشود کهCDN مخصوص خود را استفاده کنید. (cdnjs از سرورهای Cloudflare و Bootstrap CDN از سرورهای MAXCDN استفاده میکند)
اگر از وردپرس استفاده میکنید حتما با تصاویر کاربری پیشفرض آن یعنی Gravatars آشنا هستید. یکی از بهترین راهها برای خلاص شدن از زمان لود DNS های Gravatars استفاده از لود تنبل نظرات میباشد که در سئوراز آموزش فعالسازی آن را نیز منتشر کردهایم و میتوانید با مراجعه به پست لود تنبل تصاویر از آموزشهای عالی ما بهره ببرید. با این حال اینکار زمان لودDNS شما را کاهش نمیدهد و تنها لود آن را تا وقتی که کاربر تا بخش نظرات اسکرول کند به تاخیر میاندازد. بنابراین شما با اینکار در لود بخش اولیه وب سایت خود زمان لود DNS را کاهش دادهاید. پیشنهاد میکنم که حتما مقاله ما در رابطه با افزایش سرعت دیدگاههای وردپرس را مشاهده کنید.
با فونتهای گوگل شما یک درخواست اضافه برای لود استایلهای مخصوص فونتهای گوگل به وب سایت خود اضافه میکنید. سپس شما باید از طریق gstatic اقدام به دانلود فونتها کنید. سعی کنید که این نوع فونتها را در وب هاست یاCDN خود به صورت محلی لود کنید و از لود از طریق وب سایتهای واسطهای دیگر جلوگیری کنید. این کار مزایا و معایبی به همراه دارد ولی در کل به سرعت وب سایت شما بسیار کمک میکند.
فونت Awesome ، فونتهای گوگل و gravatars تنها نمونههایی از روشهای کاهش زمان لود DNS ها بودند. آیا شما سعی کردید که بیشتر منابع خود را از طریق CDN ها لود کنید؟
یکی دیگر از راههای کاهش زمان لود DNS، استفاده از DNS Prefetching میباشد. این امکان به شما کمک میکند تا DNS ها را در پسزمینه وب سایت خود لود کنید. این کار با اضافه کردن چند خط کد به وب سایتتان امکان پذیر است.به کدهای زیر توجه کنید :
فقط توجه کنید که DNS prefetch در بعضی از مرورگرها مانند Opera Mini پشتیبانی نمیشود ولی نگران نباشید، این پشتیبانی نشدن در عملکرد وب سایت شما تاثیری نمیگذارد ولی برای کاربرانی که از آن مرورگر استفاده میکنند DNS ها دیرتر لود میشوند.
یا اگر از نسخه وردپرس بالای ۴.۶ استفاده میکنید، میتوانید از ترفندهای منابع منتشر شده کمک بگیرید. توسعه دهندگان با استفاده از متد wp_resource_hints میتوانند با اضافه کردن دامنهها و لینکهای جدید، dns-prefetch، preconnect، prefetch و یا prerender را در پسزمینه وردپرس لود کنند.
اگر شما خواندن فایلهای جاوااسکریپت را به تاخیر بیاندازید آنها تا پایان لود کامل دیگر منابع سایت لود نخواهند شد. اینکار سرعت لود DNS Lookup را افزایش نمیدهد ولی باعث میشود که از بروزرسانی پی در پی آن جلوگیری شود. افزونه Varvy یکی از بهترین پیشنهادها برای بررسی تاثیر تاخیر انداختن لود جاوااسکریپت میباشد. نمونه فایل جاوااسکریپتی که بیشتر وب سایتها از آن استفاده میکنند فایل جاوااسکریپت گوگل آنالیز میباشد که نیازی نیست در هنگام لود شدن وب سایت، لود شود و کافیست که پس از لود وب سایت در پس زمینه لود شود.
در وردپرس افزونههایی مانند Async JavaScript وجود دارند که باعث به تاخیر انداختن لود جاوااسکریپت میشوند. با اینحال بعضی از اسکریپتها در لود وب سایت اهمیت دارند و باید شما قبل از فعالسازی تاخیر در لود آنها را پیدا کرده و در لیست پرش یا استثنا قرار دهید.
افزونه Async Javascript با افزونه Autoptimize نیز به صورت کامل همخوانی دارد و قابل ادغام است و یکی از بهترین پیشنهادها برای به تاخیر انداختن لود جاوااسکریپت میباشد.
البته این بحث به تاخیر انداختن لود جاوا اسکریپت به خطای asynchronous resources در GTmetrix هم برمیگردد که میتواند در آنجا به شکل کامل مطالعه نمایید.
در بعضی از ارائه دهندگان DNS رکوردهای اضافهای وجود دارد که میتواند سرعت لود DNS را افزایش دهد.
رکوردهای ANAME به شما عملکرد کلی رکوردهای CNAME را در سطح ROOT نمایش میدهند. برای مثال در نظر بگیرید که شما CNAME دامنه خود را به صورت www.domain.com پیکربندی کردهاید. ابتدا www. باید نام هاست نیم را پیدا کند و سپس به IP متصل شود. پس اینکار ۲ مرحله ایست. در ANAME مرحله اولیه CNAME حذف شده است و مستقیم به IPمتصل میشود که این باعث افزایش سرعت میشود. دقیقا مانند نمونه زیر :
به طور مشابه Cloudflare هم نوعی سرویس به نام CNAME مسطح دارد که دقیقا همان کار ANAME را انجام میدهد و دادهها را در سطح zone apex نمایش میدهد.
به طور کلی، DNS Lookups یکی از فاکتورهایی است که در بیشتر وب سایتها نادیده گرفته میشود ولی با اندکی توجه مدیر وب سایت میتواند به لود وب سایت خود کمک کند. فقط کافیست که بدانید DNS چطور کار میکند، ارائه دهندگان کند و سریعی برای DNS وجود دارد و یاد بگیرید که چگونه مشکلات بررسی DNS را حل کنید.
تحلیل عملکرد وب سایت، یکی از کارهای اساسی است که ما در پروژه های افزایش سرعت سایت انجام میدهیم. یکی از راههای ارزیابی و کشف کندی وب سایت، بررسی تک تک درخواست ها است که به اصطلاح به آن تجزیه و تحلیل آبشاری یا به انگلیسی Waterfall Analysis گفته میشود. ابزارهای فراوانی برای این امر وجود دارند که از جمله آنها میتوان به Chrome DevTools ، WebPage Tools ، Pingdom و GTmetrix اشاره کرد که استفاده از این ابزارهای سئو در درک و نحوه کارکرد طراحی سایت (طراحی سایت شرکتی، طراحی سایت فروشگاهی، ساخت سایت) در دقیق مشخص کردن مشکلات میتواند بسیار کارگشا باشد چرا که این نمودار آگاهی ارزشمندی درباره چگونگی تاثیر گذاری فایلهای پیوست شده (asset) روی سرعت صفحات و تجربه کاربری به شما میدهند. درواقع تجزیه و تحلیل آبشاری همان تجزیه و تحلیل سرعت سایت میباشد.
البته ما در سایت سئوراز بارها از تجزیه و تحلیل آبشاری در ابزارهای آنلاین مختلف استفاده کردهایم، در پست بررسی سرعت با ابزار Pingdom درباره تجربه و تحلیل آبشاری (چارت آبشاری) این ابزار به خوبی اشاره شد، در دوره جامع بهینه سازی سرعت سایت به شکل بسیار جامع درباره تجربه و تحلیل آبشاری سایت Gtmetrix کار شد و همچنین در این پست قصد داریم به تجزیه و تحلیل آبشاری موجود در Chrome DevTools بپردازیم.
سرفصلهای پست
نمودار آبشاری که به عنوان گراف آبشاری و هم چارت آبشاری نیز شناخته میشود، ارائه بصری از نحوه بارگذاری عناصر در وب سایتتان ارائه میدهد. این عناصر شامل CSS، JavaScript، HTML، تصاویر، پلاگین ها، فونتها و … میشوند. نکته مهم دیگر این است که نمودارهای آبشاری به شما اجازه مشاهده ترتیب رندر شدن عناصر در مرورگر را میدهند. از آن جا که این عناصر میتوانند شامل موارد مختلفی باشند از جمله بلاک های CSS تا مشکلات FOIT ، ترتیب بارگذاری از اهمیت زیادی برخوردار است که در ادامه به آن اشاره خواهیم کرد.
ابزارهای تست آنلاین سرعت سایت بسیاری وجود دارند که میتوانید برای ایجاد نمودار آبشاری از آن ها استفاده کنید. در زیر یک نمودار آبشاری معمولی را مشاهده میکنید که با ابزار خوده گوگل کروم یعنی Chrome DevTools ایجاد شده است.
گاهی تمامی رنگ ها، خطوط و ستونها به صورت یک جا میتوانند گیج کننده باشند. در ادامه به بعضی از مهمترین قسمت های نمودار آبشاری میپردازیم. علاوه بر زمان کلی بار گذاری موارد بیشتری در نمودار آبشاری وجود دارند. همچنین به یاد داشته باشید بسته به نوع مرورگر یا ابزاری که استفاده می کنید، نام ویژگی های زیر ممکن است متفاوت باشند که ما در پستهای قبلی برخی از آنها را اشاره کردهایم.
هنگام دسترسی به یک صفحه وب، مرورگر تمام منابعی که نیازمند DNS Lookup هستند و باید تا زمان تکمیل lookup منتظر بمانند را شناسایی میکند. DNS lookup مبتنی بر hostname ها می باشد. به عنوان مثال، اگر Google Analytics را در وب سایتتان اضافه کنید، نه تنها برای دامنه شما DNS lookup انجام می دهد بلکه برای google-analytics.com نیز این کار را انجام میدهد.
پست ما درباره چگونگی کاهش 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 در زمان کلیک کاربر روی یک لینک انجام میشود. مثال زیر را مشاهده کنید:
ارتباط اولیه که با عنوان ارتباط TCP و ارتباط در بعضی ابزارها شناخته میشود، مجموع زمان مورد نیاز برای ایجاد یک ارتباط TCP است. این مورد برای ایجاد یک ارتباط بین یک کاربر یا هاست محلی و سرور استفاده میشود و روشی سه مرحله ای میباشد که نیازمند کاربر و سرور به منظور تبادل بسته ها قبل از شروع تبادل اطلاعات است.
کاهش زمان TCP کمی دشوارتر است. بهترین نقطه برای شروع این است که مطمئن شوید روی یک هاست وب سریع با تاخیر پایین سایت شما پیاده شده است. این handshake با ارسال داده از طرف کاربر در حین SYN اتفاق میافتد، بنابراین به ارتباط ها امکان جایگزینی در حین handshake را میدهد.
همچنین preconnect را فراموش نکنید که به مرورگر اجازه میدهد ارتباطهای ابتدایی را قبل از ارسال واقعی درخواستHTTP به سرور ایجاد کنید.
SSL، که در بعضی ابزار ها به عنوان SSL negotiation نیز معرفی میشود، زمان کلی مرورگر برای اجرای SSL/TLS handshake میباشد. مشخصاً این را زمانی مشاهده میکنید که CDN و یا هاست شما روی HTTPS فعال باشد.
در زیر تعدادی روش برای افزایش سرعت سایت هایی که روی HTTPS اجرا می شوند آورده شده است.
TTFB که خلاصه time to first byte است، مقدار زمانی است که طول میکشد تا یک کاربر یک درخواست HTTP ایجاد کرده و اولین بایت داده را از وب سرور دریافت کند. در Pingdom این مورد به عنوان زمان انتظار یا wait time شناخته می شود. TTFB یک جنبه مهم از بهینه سازی سئو سایت است زیرا هرچه TTFB سریعتر باشد، منبع درخواستی سریعتر به مرورگر ارسال میشود. به طور میانگین هر چیزی با TTFB کمتر از 100 میلی ثانیه فوق العاده است. هرچیزی با میانگین TTFB 200 تا 500 میلی ثانیه استاندارد است و بین 500 میلی ثانیه تا 1 ثانیه کمتر از ایده آل و هرچیزی با TTFB بزرگتر از 1 ثانیه احتمالاً باید مورد بررسی قرار گیرد. نکات تکمیلی و جالب درباره TTFB را حتما در مقاله TTFB چیست بخوانید.
یکی از راه های ساده بهبود TTFB پیاده سازی caching روی سرور است. به عنوان مثال، اگر از وردپرس استفاده می کنید، پلاگین WordPress Cache Enabler می تواند یک فایل Cache استاتیک در قالب HTML روی سرور شما ایجاد کند. این مورد به کاربران اجازه میدهد تا از فرایند فشرده سازی منابع جلوگیری کنند، بنابراین صفحه با TTFB سریعتری تحویل داده میشود.
و البته استفاده از CDN نیز به شدت می تواند TTFB شما را بهبود دهد.
در اینجا مثالی از آزمایش TTFB بدون استفاده از CDN را مشاهده میکنید.
در ادامه مثال قبل را با استفاده از CDN تکرار کردیم.
همانطور که مشاهده می کنید، با استفاده از CDN مقدار TTFB به نصف کاهش پیدا کرد. البته بسته به موقعیت سرور و POPها این موارد متفاوت خواهند بود. از جمله راه های دیگر برای افزایش سرعت TTFB می توان به روز بودن Nginx و Apache و همچنین مدیریت منابع سرور از جمله CPU و IO و همینطور اسکریپت و پلاگینهای نصب شده اشاره کرد.
دانلود محتوا دقیقاً به همان صورتی است که از اسمش به نظر میآید، این مورد مدت زمانی است که طول میکشد تا محتوای مورد نظرتان را دانلود کنید. هرچه asset ها و اندازه فایل ها بزرگتر باشند، زمان بیشتری طول خواهد کشید.
هنگامی که درباره زمان دانلود محتوا صحبت میکنیم فشرده سازی تصویر نقش بزرگی در این مورد ایفا می کند. طبق HTTP Archive، از ژوئن 2017 تصاویر به طور متوسط 61% از حجم وب سایت ها را به خود اختصاص می دهند. مقالات جامع ما درباره بهینه سازی عکس میتواند بسیار به شما کمک کند
و البته استفاده از CDN می تواند یکی از آسان ترین راه ها به منظور کاهش زمان دانلود محتوا باشد، زیرا از این طریق محتوا را از POP های نزدیک به کاربران به آن ها عرضه می کنید. استفاده از CDN باعث کاهش TTFB نیز می شود.
از راه های دیگر به منظور کاهش زمان دانلود می توان به استفاده از javascript و css تنها در موارد مورد نیاز و فشرده سازی با Gzip اشاره کرد.
DOM مخفف Document Object Model می باشد. هنگامی که از inspector کروم یا فایرفاکس استفاده میکنید تبی دارد به نام elients در واقع این تب در حال مشاهده نمایه بصری از DOM هست، Chrome DevTools پس از دستکاری در صفحهDOM را با HTML یا javascript نمایش میدهد. همچنین می توانید به آن به عنوان HTML تجزیه شده نیز نگاه کنید.
هنگامی که به بررسی سرعت صفحات وب سایت می پردازیم، همواره باید مواردی که ممکن است DOM را مسدود کنند و باعث ایجاد تاخیر در زمان بارگذاری میشوند را در نظر داشته باشید. این موارد به عنوان render blocking resources در نظر گرفته میشوند، مانند HTML، CSS و جاوا اسکریپت. بیشتر ابزارهای تست سرعت سایت مجموع محتوای DOM را نمایش می دهند در حالیکه این زمان با زمان کلی بارگذاری متفاوت است.
Load Time که با عنوان Fully Loaded نیز در بعضی ابزار ها شناخته میشود، زمان کلی پایان دانلود، رندر و نمایش به کاربر است. این مورد از معیارهای بسیار مهم است که باید مورد توجه قرار گیرد چرا که این زمان در Devtools واقعی تر از ابزارهای تست آنلاین است، به این علت که ابزارهای تست سرعت سایت لوکیشن ایران را ندارند و شما میتوانید با مرورگر خود یک ابزار تست سرعت سایت در ایران باشید.موارد متعددی وجود دارند که می توانید با انجام آن ها سرعت بارگذاری را افزایش دهید.
Data Transferred در Devtools کروم (دیتا انتقال داده شده)، که در WebPageTest به عنوان Bytes In شناخته میشود، و در Pingdom به عنوان Page Size، اندازه کلی تمامی asset ها (تمام فایلهای پیوست شده در سند html) در صفحه وب می باشد. هرچه این مقدار کوچکتر باشد، بهتر است. توصیه های ما درباره کاهش زمان بارگذاری محتوا که در بالا آورده شد را دنبال کنید و در عوض Data Transfered وب سایت شما کاهش پیدا میکند.
تا سال 2016 متوسط اندازه صفحه، کمی بیشتر از 2 مگابایت بود که بسیار بزرگ است. اندازه صفحه وب از سال 2010 تا 2016 317% افزایش یافته و به مقدار 1530 کیلو بایت رسیده است. پیشنهاد می کنیم حداقل 1 مگابایت یا کمتر برای اندازه صفحه وب سایت خود در نظر بگیرید. اگرچه این امر در تمام محیط ها امکان پذیر نیست.
درخواستها مجموع کلی درخواست های HTTP تولید شده در وب سایت شما را نشان می دهند. هر فایل پیوست شده (CSS، JavaScript، Image) درخواست مربوط به خود را تولید میکند. در مجموع هرچه درخواست های HTTP صفحه شما بیشتر باشد، زمان بارگذاری هم طبیعتا بیشتر میشود.
روش های زیادی برای کاهش تعداد درخواست ها وجود دارند که می توان به موارد زیر اشاره کرد:
ولی اگر قصد دارید اطلاعات بیشتر و کامل تری درباره درخواست های http و نحوه کاهش این درخواست ها کسب کنید مقاله رفع خطای Make fewer HTTP requests ما را حتما مطالعه نمایید.
کدهای وضعیت یا همان Status Codes ، که با عنوان کدهای خطا (Error) و کدهای پاسخ سرور (Server Response Codes) نیز شناخته میشوند، پیام هایی هستند که شامل اطلاعات کامل وضعیت ها درخواست بین کاربر و سرور می باشند. کاربر درخواست خود را به یک سرور HTTP ارسال می کند که میزبان یک وب سایت است، سپس سرور پیام پاسخ را در قالب یک کد بازمی گرداند.
اگر مشکلی در یک درخواست HTTP باشد، لیستی از کدهای وضعیت وجود دارد که مرورگر شما را با استفاده از آن مطلع می سازد تا بتوانید منبع مشکل را پیدا کنید. روشی که مرورگر پاسخ را مدیریت میکند بسته به کد و فیلد header پاسخ دارد. به عنوان مثال، خطای Not Found 404 بدان معناست که محتوا دیگر وجود ندارد یا حذف شده است.
همانطور که مشاهده می کنید، ابزارهایی مانند Chrome DevTools، WebPageTest ، Pingdom و GTmetrix انواع مختلفی از اطلاعات ارزشمند درباره چگونگی بارگذاری صفحات و دلایل تاخیرها فراهم میکنند. درک معنای هر قسمت از داده ها می تواند در عیب یابی و تشخیص مشکلات اجرایی سایت کمک کند. توجه داشته باشید که بهینه سازی سرعت سایت تاثیری مستقیم بر روی افزایش رتبه سایت در گوگل و سایر موتورهای جستجو دارد و جدا از این مورد اثری حیاطی بر روی تجربه کاربری و رضایت بازدیدکنندگان نیز دارد.
امیدواریم این مقاله برای شما مفید بوده باشه و دفعات دیگری که تجزیه و تحلیل آبشاری (Waterfall Analysis) انجام میدهید، خوشبختانه بعضی از نکته های ذکر شده در بالا می توانند به شما کمک کنند.
سرفصلهای پست
امروز قصد داریم تا با نگاهی عمیق به یکی از پرطرفدارترین ابزار آنلاین تست سرعت سایت یعنی ابزار Pingdom و چگونگی استفاده بهتر از این ابزار بپردازیم. البته بارها در پستهای مختلف آموزش سئو به سایت Pingdom اشاره کردیم و حتی در مقاله برترین ابزارهای آنلاین جهت تست سرعت سایت نیز به شکل خلاصه این ابزار قدرتمند را تشریح کردیم. شما با ابزار Pingdom میتوانید تحلیلی آبشاری از وب سایت خود داشته باشید. این تحلیلها به شما کمک میکند تا مشکلات عملکرد وب سایتتان را تشخیص دهید و با حل آنها طراحی سایت (طراحی سایت شرکتی، طراحی سایت فروشگاهی،قیمت طراحی سایت) های بدون مشکل سرعت سایت داشته باشید. مشاهده میشود که بعضی از کاربران وردپرسی ما که به اطلاعات نمایش داده شده در Pingdom آشناییت ندارند، با دستکاری وب سایت سرعت لود وب سایت را از قبل هم بدتر میکنند.
Pingdom یک شرکت ارائه خدمات مانیتورینگ آپتایم و خدمات مدیریت عملکرد وب سایت مستقر در سوئد میباشد. همواره یکی از چیزهایی که هر وب مستری با آن آشناست، ابزار بررسی سرعت لود وب سایت Pingdom میباشد و در بین کاربران وردپرسی نیز میتوان یکی از پرطرفدارترین ابزارها آن را معرفی کرد. چرا؟ اولین دلیل آن استفاده بسیار ساده آن است ، برای استفاده از آن نیازی نیست که کاربر خیلی حرفه ای باشد و برای کاربران عادی وردپرس کاربردی ساده دارد که در ابزارهای جایگزین کمتر دیده میشود. گاهی اوقات امکانات بعضی از ابزارها انقدر پایین است که اصلا جای صحبتی باقی نمیگذارد.
ابزار Pingdom امکان تست وب سایتتان را از ۵ مکان مختلف میدهد، که لیست آنها در زیر آورده شده است:
مکان فیزیکی که انتخاب میکنید خیلی مهم است، زیرا درواقع مربوط به جایی میشود که وب سایت شما میزبانی میشود. با این حال، به ادامه مقاله توجه فرمایید، در ادامه به جزئیات بیشتری اشاره خواهیم کرد.
یک صفحه وب به طور کلی از چندین ساختار مانند HTML،CSS،JS، تصاویر و ویدیوها تشکیل میشود. هرکدام از اینها یک درخواست را هنگامی که شما میخواهید یک صفحه وب را مشاهده کنید ارسال میکنند. به طور کلی، هرچه تعداد درخواستهای وب سایت شما بالاتر باشد، وب سایت شما کندتر میشود ولی همیشه هم درست نیست، در بعضی اوقات برای مثال در Lazy Load با بالا رفتن درخواستها شاهد افزایش سرعت نیز میشوید. در زیر ما قصد داریم که تمامی بخشهای ابزار Pingdom را بررسی کنیم، هر قسمت مربوط به عملکرد کلی وب سایت را به طور کامل برایتان توضیح دهیم و به نحوه تحلیل آبشاری نتایج بپردازیم.
هنگامی که شما وب سایت وردپرس خود را در Pingdom وارد میکنید، Pingdom به شما یک درجه عملکرد، زمان لود، حجم کلی وب سایت و تعداد درخواستها را نشان میدهد میتوان گفت ساختاری شبیه به سایت GTmetrix دارد و اگر مقاله آنالیز Gtmetrix را مطالعه کرده باشید به چنین ویژگیهایی نیز اشاره کردیم. به عنوان مثال، در زیر ما وب سایت perfmatters.io را مورد بررسی قرار دادیم . همانطور که میبینید در اولین تست وب سایت درجه ۱۰۰ را از ۱۰۰ نمره به دست آورد و در زیر ۹۰۰ میلیثانیه لود میشود. همانطور که مشاهده میکنید این وب سایت از ۹۶ درصد وب سایتهای تست شده در این ابزار سریعتر است.
ما یک آزمایش دیگر بر روی این وب سایت انجام دادیم که نتیجه آن لود ۴۹۱ ثانیهای شد. چه اتفاقی برای وب سایت افتاد؟ این اتفاق هنگامی که چندین بار یک وب سایت را در Pingdom آزمایش میکنید اتفاق میافتد که دلیل آن وجود کش در مرورگر کاربر، سرور و DNS میباشد. برای درک بهتر این امر به بخش تحلیل آبشاری مراجعه فرمایید.
آیا میخواهید که نتیجه بهتری در آزمایشات Pingdom داشته باشید؟ با توجه به نوع وب سایت شما و نوع پیکربندی آن هیچ تضمینی در اینکه شما درجه عملکرد ۱۰۰ را از ۱۰۰ نمره بگیرید نیست ولی با صرف چندین ساعت وقت برای بهینه سازی وب سایتتان میتوانید بهبود رتبه را از امروز شروع کنید. در بعضی از مواقع تجربه کاربری ممکن است جای چیزهایی که خواندید را پرکند و شما در بخش هایی نیازی به بهینه سازی محتوا نداشته باشید. هیچ وقت تجربه کاربری (UX) را فراموش نکنید. اما مطمئن باشید که با آموزشی که ما در زیر به شما میدهیم میتوانید کلیه مراحل رساندن وب سایت به نتیجهای مانند نتیجه بالا را یاد بگیرید.
بخش بینش عملکرد (همان Insights) ابزار Pingdom، یکی از بخشهای بسیار مهم و کمک کننده در این ابزار میباشد. تمامی اطلاعات گنجانده شده در این بخش با توجه به قوانین بینش عملکرد گوگل (Insights) میباشد. به طور کلی، اگر شما بتوانید این بخش را در وب سایت خود بهبود دهید، باید شاهد کاهش زمان لود وب سایت خود باشید.
یکی از رایجترین مشکلات افراد در هنگام آزمایش وب سایت در ابزارهای تست سرعت رویارویی با خطای Leverage Browser caching میباشد. این خطا به علت وجود مشکل HTTP Cache header در سرور شما میباشد. برای حل این مشکل به آموزش حل مشکل Leverage Browser Caching وب سایت سئوراز مراجعه کنید.
یکی دیگر از مسائل رایج موجود در آزمایشات مورد Riove Query Strings میباشد. فایلهای CSS و JS در هنگام لود شدن در فایل HTML وب سایت ورژن های خود را نیز لینکها قرار میدهند. مانند :domain.com/file.min.css?ver=4.5.3 .بعضی از سرورها و پروکسیها امکان کش کردن این فایلها وقتی اینگونه لینک میشوند ندارند. پس با حذف ورژن از لینکها شما میتوانید سیستم کش وب سایت خود را بهبود بخشید. برای حل این مشکل میتوانید از افزونه رایگان Query Strings Riover در وردپرس استفاده کنید تا به صورت خودکار عملیات حذف ورژنها انجام شود. در غیر اینصورت برای حل این مشکل میتوانید به آموزشحل مشکل Riove Query Strings وب سایت سئوراز مراجعه فرمایید.
در بیشتر مواقع وب مسترها به علت وجود پروتکلهای جدیدی مثل HTTP/2 این خطا را نادیده میگیرند. اضافه کردن یک اتصال جدید همیشه نسبت به زمانی که همه ساختار را در یک اتصال بارگیری میکنید، هزینه کمتری برایتان خواهد داشت. با این حال، ما دو راه برای حل این مشکل داریم که یک استفاده از یک ارائه دهنده CDNو دیگری اضافه کردن یک دامنه یا زیردامنه (SubDomain) به وب سایت است.
این مشکل به علت وجود محدودیت در HTTP/1.1 و اتصال همزمان مرورگر به وب سایت میباشد ، که در بیشتر سرورها ۶ اتصال است. این هشدار بیشتر در وب سایت هر پربازدید و پردرخواست نمایان میشود. در گذشته تنها کاری که میتوانستیم انجام دهیم عمل Call Domain Sharding بود. با این حال، اگر از سرویس CDN استفاده میکنید و سرویس CDN شما ازHTTP/2 پشتیبانی میکند، میتوانید این هشدار را نادیده بگیرید زیرا در حال حاضر دانلودهای شما در چندین سرور تقسیم بندی میشود.
این خطا به HTTP header وب سایت شما مربوط میشود و باید در سروراصلی وب سایت شما رعایت شود، که سرور درخواستی را برای مرورگر کاربر بفرستد تا متوجه شود که آن مرورگر امکان مشاهده محتوا بهینه سازی شده را دارد یا خیر!!!
این هشدار به کش HTTP header وب سایت مربوط میشود که باید در سرور اصلی وب سایت بر روی اعتبار و زمان کش اعمال شود. اگر header ها لود نشوند، مرورگر درخواست دیگری را ارسال میکند و تا دریافت نهایی header وب سایت لود نمیشود و این باعث افزایش زمان لود وب سایت میشود. این header ها شاملlast-modified ،ETag، Cache-Control وانقضای کش میشود. برای حل این مشکل مقاله Specify a cache validator وب سایت سئوراز را بررسی کنید.
قسمت بعدی ابزار تست سرعت Pingdom مربوط به کدهای پاسخ میباشد. کدهای پاسخ یا کدهای وضعیت HTTP مانند یک نکته کوتاه وضعیت صفحه وب را به شما نمایش میدهند. هر کد نشانگر وضعیتی است که هنگام ارسال درخواست توسط مرورگر، سرور پاسخ میدهد.در زیر به بعضی از کدهای رایج میپردازیم :
بخشهای بعدی که قصد داریم به آن بپردازیم حجم محتوا بر اساس نوع آنها و همچنین درخواستها بر اساس نوع محتوا میباشد. با استفاده از هر قسمت این بخش میتوانید متوجه شوید که هریک از ساختار وب سایت شما چه مقدار حجم دارند و چه مقدار از درخواستها مربوط به یک ساختار میشود.
با مراجعه به آخرین HTTP Archive متوجه میشویم که ۶۴ درصد صفحات وب را تصاویر تشکیل دادهاند. این موضوع را معمولا در بیشتر جاها مشاهده میکنیم. ولی در مورد زیر متوجه میشوید که همیشه هم اینطور نیست. در نمونه زیر نزدیک به ۴۶ درصد از ساختار به دسته Other یا دیگر اختصاصی داده شده است که بیشتر این ساختار مربوط به فونتهای گوگل و font awesome میباشد. فونتهای وب در بخش دیگر تست Pingdom قرار میگیرند.
راه دیگری که میتوانید به جای استفاده از تصاویر استفاده کنید، استفاده از فونت آیکونها مانند فونت Awesome به جای تصاویر می باشد. این استفاده میتواند به مقدار قابل ملاحظهای در حجم وب سایت شما موثر باشد.
بخش حجم محتوا (Content size by domain) و درخواست نسبت به دامنه (Requests by domain) یکی از بهترین راهها برای یافتن ساختارهاییست که خارج از وب سایت شما لود میشوند.
در مثال زیر شما مشاهده میکنید که ما همه ساختار وب سایتمان را از CDN لود میکنیم. سپس یک فایل HTML وب سایت میماند که از خود وب سایت لود میشود و یک لینک خارجی نیز به وب سایت Google Analytics متصل شده است. بسته به نوع وب سایت، شما ممکن سرویسهای خارجی مختلفی اعمم از فیسبوک، اینستاگرام، توییتر، تلگرام، تبلیغات و غیره را به وب سایت خود متصل کنید.
به طور کلی، هرچه درخواستهای خارجی وب سایت شما کمتر باشد، بهتر است. زیرا، هر درخواست خارجی در لیتنسی (latency) شما تاثیر میگذارد، مرورگر باید DNS اش را بررسی کند، TLS را به تاخیر میاندازد وغیره. پس بهتر است که درخواستها را تاجای ممکن کوتاه کنیم و ساختارها را از یک سرور فیزیکی یا CDN لود کنیم. یکی از بهترین مثالها فونت Awesome میباشد. بهجای اینکه بیاییم و از لینک خارجی آن را لود کنیم بهتر است که مستقیم آن را دانلود کنیم و از سرور خودمان لود کنیم، ما در مقاله رفع ارور Reduce DNS lookups به شکل بسیار کاملی درباره این موضوع پرداختیم.
و بالاخره، چارتهای آبشاری ساخته شده از هر درخواست میباشد که در زیر مشاهده میکنید. شما توسط این چارت میتوانید تمامی درخواستهایی که باعث کاهش سرعت و ایجاد مشکل در عملکرد وب سایت شما شده اند را مشاهده کنید. این دقیقا همان تحلیل آبشاری است که قبلا در رابطه با آن صحبت میکردیم. در زیر به توضیح جامعی در رابطه با هر یک از رنگهای موجود در چارت آبشاری میپردازیم.
DNS چیست؟ خب، فکر کنم شبیه یک دفتر تلفن بتوانیم آن را بیان کنیم. در شبکه به آن نام سرور دامنه (Domain Name Server) میگویند که در خود تمامی اطلاعات مربوط به سرور وب سایت و آی پی سرور را در خود نگهداری میکند. هنگامی که شما در Pingdom وب سایت خود را بررسی میکنید، این وب سایت در ابتدا به سرعت شروع به بررسی DNS وب سایت شما میکند و کوئریهای مربوط به دریافت اطلاعات IP شما را ایجاد میکند. این بررسی در بعضی اوقات طولانی مدت طول میکشد و این به فرآیند DNS lookups گویند.
هنگامی که وب سایت خود را چند بار توسط Pingdom بررسی میکنید، این ابزار DNS شما را در خود کش کرده و به علت اینکه IP شما ثابت است دیگر نیازی ندارد که دوباره DNS شما را بررسی کند. به همین دلیل است که هنگامی که شما چندین بار وب سایت خود را بررسی میکنید افزایش سرعت را مشاهده میکنید. همانطور که در تصویر زیر مشاهده میکنید ما بعد از انجام آزمایش دوم از وب سایت دیگر لود شدن DNS را مشاهده نمیکنیم و زمان لود DNS به 0 میلیثانیه تغییر کرده است که قبلا ۳۳ میلیثانیه بود. این یکی از موردهاییست که بعضی از افراد اشتباه تفسیر میکنند و احساس میکنند که اصلا DNSلود نشده است درحالی که اینطور نیست و DNS به صورت کش شده لود شده است.
دلایل دیگری نیز وجود دارد که ممکن است وب سایت شما پس از چند بار آزمایش سریعتر لود شود و یکی از آنها استفاده ازCDN میباشد. برای آن دسته از کاربرانی که با CDN آشنا نیستند پیشنهاد میشود که مقاله ما در رابطه با CDN را مطالعه کنند. هنگامی که برای بار اول توسط Pingdom وب سایت را بررسی میکنید اطلاعات توسط CDN بررسی میشوند و سپسCDN دقیقا همانند DNS اطلاعات را کش میکند و در بار دوم دیگر سرعت به خاطر لود اطلاعات درون CDN پایین نمیآید.
همچنین راه دیگری نیز برای لود سریع وب سایت از طریق DNS میباشد که از متد DNS prefetching استفاده کنید. با اینکارDNS های وب سایت شما در پسزمینه لود میشوند. شما میتوانید با اضافه کردن چند خط به بخش Header پوسته وردپرس خود این متد را فعال کنید. به کدهای زیر توجه فرمایید :
یا اگر از نسخه وردپرس بالای ۴.۶ استفاده میکنید، میتوانید از ترفندهای منابع منتشر شده کمک بگیرید. توسعه دهندگان با استفاده از متد wp_resource_hints میتوانند با اضافه کردن دامنهها و لینکهای جدید، dns-prefetch، preconnect، prefetch و یا prerender را در پسزمینه وردپرس لود کنند.
رنگ وضعیت بنفش زمانی ظاهر میشود که شما در وب سایت خود از SSL/TLS handshake استفاده کرده باشید. وقتی شما وب سایتی را با پروتکل HTTPS لود میکنید متوجه میشوید که آن وب سایت گواهینامه SSL دارد و برای کدگذاری اطلاعات شما و حفظ امنیت شخصی شما زمانی را صرف میکند. در تست زیر ما هم در سرور خود و هم در CDN از گواهینامه SSLاستفاده میکنیم. بنابراین زمانی را در ابتدا برای کدگذاری اطلاعات شما بر روی سرور برای جلوگیری از دزدی اطلاعات، به زمان لود صفحه اضافه میشود.
در گذشته اگر وب سایتی از گواهینامه SSL استفاده میکرد و باید برای ورود از پروتکل HTTPS استفاده میکردیم، لود آن وب سایت عذاب آور میشد ولی حالا خوشبختانه با وارد شدن نسل جدیدی از پروتکل به نام پروتکل HTTP/2 زمان لود صفحاتHTTPS ناچیز شده است. در حال حاضر بیشتر مرورگرها از پروتکل HTTP/2 پشتیبانی میکنند و از نظر من با توجه به پیشرفت روز به روز اطلاعات تعداد کاربرانی که از آخرین نسخه مرورگرها استفاده نمیکنند ناچیز است پس این پروتکل HTTP/2 کمک موثری به لود وب سایت شما میکند. همچنین باید توجه داشته باشید که همه ارائه دهندگان میزبانی و CDNاز پروتکل HTTP/2 پشتیبانی نمیکنند و شما باید توجه فرمایید، در صورتی که به HTTPS نیازمندید باید به دنبال ارائه دهندگانی باشید که از پروتکل HTTP/2 پشتیبانی میکنند. خوشبختانه سئوراز در طراحی سایت برای شما از سرورهای معتبری استفاده میکند که همه از پروتکل HTTP/2 پشتیبانی کامل میکنند.
توجه داشته باشید که پروتکل HTTP/2 از نسخه ۴۹ به بعد کروم فعالسازی شده است و نسخه کرومی که Pingdom برای تست استفاده میکند ۳۹ میباشد، بنابر این درصورتی که از این ابزار برای بررسی سرعت لود وب سایت خود استفاده میکنید ممکن است نتایج نمایشی تمامی تاثیرات پروتکل HTTP/2 را به شما نمایش ندهد ولی مطمئن باشی، در صورتی که کاربران از نسخه بروز کروم استفاده کنند، سرعت قابل ملاحظهای را احساس خواهند کرد.
زمان اتصال در Pingdom به اتصال TCP یا کل زمان لازم برای ایجاد اتصال TCP مربوط میشود.شما نیازی نیست که خیلی در این رابطه اطلاعات داشته باشید ولی به صورت خیلی ساده این بخش مربوط به سرعت اتصال کاربر به سرور شما میباشد.
زمان انتظار به مدت زمان لازم برای دسترسی مرورگر کاربر به اولین بایت از صفحه شما گفته میشود و در اصطلاح به آن TTFB نیز میگویند. TTFB نوعی اندازهگیری از واکنشپذیری سرور ویا دیگر شبکهها میباشد.به طور کلی، هر زمانی زیر 200 میلیثانیه برای TTFB عالی است. اگر به بالای 800 میلیثانیه رسیدید، باید در کانفیگ سرور خود مراجعه کنید و آن را بروزرسانی کنید و ومشکلات را حل کنید زیرا صد در صد مشکل در پیکربندی سرور میباشد و این چنین نتیجهای غیرعادی میباشد.
بهترین راه برای کاهش زمان TTFB چیست؟ یکی از بهترین راههای کاهش زمان TTFB استفاده از CDN میباشد. در زیر سرعت ساخت سایت را با فعالسازی و غیرفعالسازی CDN بررسی کردیم تا نتیجه مطلوبی بدست آید.
در ابتدا بدون اتصال CDN به وبسایت، وب سایت را تست کردیم و همانطور که مشاهده میکنید TTFB وب سایت 136 میلیثانیه طول میکشد و وب سایت نیز در 1.45 ثانیه لود میشود.
سپس ما CDN را متصل کردیم و دوباره آزمایش را انجام دادیم. مشاهده میکنید که زمان لود وب سایت به 788 ثانیه و زمان TTFB نیز 37 میلیثانیه شده است.
البته علاوه بر CDN، داشتن یک هاست میزبانی خوب نیز در کاهش این زمان موثر است و پیشنهاد میشود علاوهبر تهیهCDN، یک هاست میزبانی خوب نیز تهیه کنید که این مشکل را نداشته باشید.
با توجه به اطلاعات بالای شما عزیزان فکر نکنم توضیحات زیادی برای توجیح دو وضعیت دریافت و ارسال نیاز باشد. به طور کلی وضعیت ارسال(Send) به معنای زمان لازم برای ارسال درخواست از مرورگر به سرور میباشد. همچنین دریافت(receive) نیز زمان لازم برای دریافت اطلاعات توسط مرورگر از سرور میباشد. هردوی اینها زمان خیلی کمی لازم دارند و تاثیر زیادی بر روی آزمایش شما نمیگذارد.
هنگامی که در حال بررسی چارت آبشاری هستید، میتوانید هر یک از دادههای جدول را نسبت به پاسخهای سربرگ HTTP(یا همان درخواست HTTP Headers) بررسی کنید.
در این بخش اطلاعات ارزشمندی قرار دارد. در نمونه زیر شما متوجه میشوید که محتوا توسط متد فشردهسازی gzip بهینه سازی شدهاند، کش در وب سایت فعال است (HIT به معنای فعال و Miss به معنای غیر فعال) ، نوع محتوا از نوع html و یونیکد از نوع UTF-8 میباشد و غیره…
حالا اگر مقاله تحلیل آبشاری توسط Pingdom من را به صورت کامل بررسی کردید، حالا وقت آن است که دست به کار شوید و مشکلات وب سایت خود را حل کنید. در بیشتر وقتها دیدن آموزشها بدون در نظرگیری اطلاعات کامل در رابطه با محصول مورد مطالعه آزار دهنده است و در بیشتر سایت ها رعایت نمیشود. بنابراین در زیر اطلاعات پیکربندی وب سایت مورد مطالعه این مقاله را قرار میدهیم و شما با در نظرگیری آنها میتوانید یک وب سایت پرسرعت را داشته باشید.
در زیر تمامی افزونههای استفاده شده در این وب سایت را مشاهده میکنید که بیشتر آنها به صورت رایگان از مخزن وردپرس قابل دریافت میباشند.
نکته : بعضی از افزونههایی که در وب سایت استفاده شده است خیلی کوچک بوده و با چند کد جاوااسکریپت هم میشود که آنها را فعال کرد ولی با توجه به سادگی و حجم کم از این افزونه استفاده شده است.
در حال حاضر، شما با Pingdom بیشتر آشنا شدید و میدانید که در تحلیل آبشاری Pingdom هر قسمت چه معنایی دارد و برای حل مشکلات چهکار باید کرد. در تحلیلهای آبشاری خیلی مهم است که شما دلیل اتفاق افتادن هر قسمت را بدانید و با نحوه حل مشکل آشنا باشید.
اگر با نکته جدیدی در Pingdom مواجه شدید و یا پیشنهادی در رابطه با ارائه مقالهای جامع در رابطه با بخشهای مختلف سئو و بهینه سازی داشتید با ما از طریق بخش دیدگاه درمیان بگذارید. همینطور میتوانید به جای استفاده از این سایت از ابزار GTmetrix استفاده نمایید.
به عنوان مدیر یک وب سایت شما همیشه به دنبال افزایش سرعت وب سایت خودتان برای بالا بردن رضایت کاربرانتان یا همان تجربه کاربری هستید. یکی از جدیدترین و مدرنترین مدلهای افزایش سرعت سایت در حال حاضر استفاده یک سرویس CDN میباشد. (CDN به معنای شبکه تحویل محتوا یا شبکه توزیع محتوا یاد میشود).
این سرویسها بار اضافه را از سرور اصلی سایت شما کاهش داده و باعث میشود سرعت تحویل محتوا به کاربران بالاتر رود، تجربه کاربری بهتری در مدیریت وب سایت به شما و کاربرانتان هدیه میدهند.
امروز ما میخواهیم شما را با نحوه کار CDN ها و همچنین دلیل استفاده از آنها و معرفی برخی مزایای اضافی CDN ها آشنا کنیم. همچنین با نمایش چندین آزمایش سرعت قبل و بعد از فعال سازی سرویس CDN شما را به چالش میکشیم که خود تفاوت استفاده کردن و استفاده نکردن CDN را قضاوت کنید.
۴۰ درصد کاربران اگر وب سایتی بیشتر از ۳ ثانیه لود شود آن رها میکنند. (این یک شاخص جهانی است ولی در ایران با توجه به سرعت بسیار پایین اینترنت و حجم بالای وب سایت ها این شاخص تا ۷ ثانیه پیشبینی میشود).
کلمه CDN مخفف کلمه content delivery network به معنای شبکه تحویل محتوا (شبکه توزیع محتوا) میباشد. این سرویس یک شبکه از سرورها در سراسر جهان میباشد که برای میزبانی اطلاعات استاتیک (و گاهی داینامیک) وب سایت شما نظیر تصاویر، ویدیوها، فایلهای CSS و فایلهای جاوااسکریپت طراحی شده است. توجه داشته باشید که وقتی از میزبانی صحبت میکنیم منظور میزبانی وب سایت شبیه هاستهای اشتراکی یا اختصاصی سایت شما نیست. CDN به طور کامل یک سرویس جداگانه میزبانی میباشد. سرویسهای CDN جایگزین هاستهای میزبانی شما نیست ولی راهی اضافه برای بهبود سرعت سئو سایت میباشد.
سرویس CDN دقیقا چگونه کار میکند؟ خب، به عنوان مثال ، وقتی شما قصد خرید یک هاست میزبانی وب را دارید ، میبایست مکان یک دیتاسنتر فیزیکی مثل آلمان، فرانسه، امریکا، ایران و غیره را انتخاب کنید. به عنوان نمونه فرانسه را برای میزبانی انتخاب کردیم. این به معنی آن است که مثلا وب سایت شما توسط سرورهایی واقع در پاریس میزبانی میشود. حال در نظر بگیرید فردی در ایران بخواهد وارد وب سایت ما شود و فردی نیز از فرانسه وارد وب سایت ما شوید، به علت مکان قرارگیری سرور و همچنین انتقال دادهها از مبدا به کشور مقصد، زمان لود وب سایت در ایران بیشتر از فرانسه خواهد بود. این چیزی است که به آن لِیتنسی یا تاخیر گفته میشود (latency). لیتنسی به زمان یا تاخیری گفته میشود که برای انتقال اطلاعات در شبکهها لازم است. بنابراین هرچه فاصله کاربر از مکان قرارگیری سرور وب سایت دورتر باشد لیتنسی نیز بیشتر میشود.
همچنین لیتنسی را در تبادل دادهها فراموش نکنید، هنگامی که شما به عنوان کاربر دادهها را دریافت میکنید و با پر کردن فرم یا کلیک روی کلیدی درخواستی را برای سرور ارسال میکنید، باز هم فاصله شما با سرور باعث تاخیر در دریافت پاسخ میشود. حال جایی است که CDN وارد بازی میشود و ما در این زمان برای کاهش لیتنسی سرویسی به نام CDN را وب سایت خود اضافه میکنیم. سرویس CDN اطلاعات را از نزدیکترین سرور برای کاربر نمایش میدهد و این کار باعث کاهش لیتنسی لود وب سایت میشود. سرورهای CDN را گاهی نقطه حضور (POPs) مینامند.
کاربران وردپرسی در ابتدا برای استفاده از CDN بیمیلی نشان میدهند. در اینجا ما در ۳ مرحله خیلی ساده نحوه عملکرد CDNو همچنین نحوه فعالسازی آن در وب سایتتان را آموزش میدهیم.
یک ارائه دهنده سرویس CDN را انتخاب کنید و در وب سایتش ثبت نام کنید. سرویس دهی آنها بیشتر به صورت ماهیانه یا حجم پهنایباند میباشد و اکثر ارائه دهندگان برای محاسبه قیمت، به صورت هوشمند عمل میکنند و نیازی به ارسال تیکت یا تماس با ارائه دهنده نیست.
برای ادغام CDN خود با وردپرس از یک افزونه رایگان مانند CDN Enabler استفاده کنید. این افزونهها به صورت خودکار دادههای شما را با CDN ادغام میکنند. با این افزونهها نیازی نیست که شما به هیچ چیزی دست بزنید و همه کارها به صورت خودکار انجام میشود، صرفا برخی اطلاعات اولیه برای وصل شدن به CDN لازم دارند. در حال حاضر استفاده ازCDN نسبت به چند سال پیش خیلی راحتتر شده است.
حال هنگامی که کاربران شما وارد وبسایتتان میشوند، اکنون محتوای وب سایت وردپرسی شما در CDN هایی در سراسر دنیا لود میشود و نسبت به مکان کاربر نزدیک ترین سرور CDN انتخاب میشود و اطلاعات برایش لود میشود. پس اگر حال کاربر از ایران وارد وب سایت ما شود دیگر لیتنسی قبلی را برای انتقال از فرانسه به ایران را احساس نمیکند زیرا اطلاعات از سروری در آسیا برایش ارسال میشود. حال به این بخش میرسیم که CDN چگونه مکان کاربر را تشخیص میدهد. این سرور برای تشخیص مکان فعلی کاربر از تشخیص IP و همچنین مسیریابی جغرافیایی استفاده میکند تا دقیقترین مکان را تشخیص و نزدیکترین سرور را به درستی انتخاب کند.
با این حال، هنوز هم انتخاب یک سرور قدرتمند در یک مکان مرکزی بسیار اهمیت دارد، چون اگر از یک CDN قدرتمند برای لود اطلاعات وب سایت خود استفاده کنید نیز مرورگر باید چند درخواست برای دریافت فایلهای استاتیکی مثل HTML وPHP ارسال کند، مگر اینکه از تکنیک ذخیره سازی در سرور پروکسی استفاده کنیم که آن بخشی جداست که بعدا به آن میپردازیم. در حال حاضر وب سایتهای میزبانی بسیاری هستند که از نظر ارائه سرور قدرتمند در ایران فعالیت میکنند و از مکانهای مختلفی از جهان از جمله خود کشورمان ایران سرویس دهی میکنند.
در زیر تعداد اندکی از مزایای بسیار زیاد CDN ها را بیان میکنیم.
بهبود عملکرد یکی از مهمترین دلایل استفاده از این سرویس میباشد. با این سرویس هربار که وب سایت را لود میکنید سرویس از نزدیک ترین سرور با حداکثر سرعت دادهها را دریافت کند و نرخ فرار کاربران یا bounce rate را کاهش دهد (اطلاعات بیشتر درباره bouce rate را میتوانید در مقاله bounce rate چیست بخوانید) و برای شما بازدیدکنندگانی وفادار پیدا کند. و این به معنای تغییر سادهای در تجربه کاربری نیست. آخرین باری که وارد وب سایتتان شدید و وب سایت دیر لود شد چه زمانی بود؟ این چیزی است که دوست دارید براتون خاطره شود و همیشه سرعتی عالی برای لود شدن صفحه داشته باشید. این سرعت به همین راحتیها هم به دست نمیآید. در زیر آماری معتبر از بزرگان این صنعت براتون آماده کردیم که بهتر است به آن توجه کنید :
تمامی این مشکلات و نکات توسط CDN امکان پذیر است.
ما قبلا در بالا ذکر کردیم که اتصال یک CDN به وب سایت وردپرسی شما باعث میشود که لیتنسی وب سایت شما با کم شدن مسافت فیزیکی کاربران نسبت به سرور کاهش یابد. همچنین میتواند باعث کاهش زمان دستیابی شما به اولین بایت وب سایت شود.(TTFB یا time to first byte)
در تعریف ساده TTFB باید بگویم که برای دریافت اولین بایت دادههای وب سایت، مرورگر موظف است زمانی منتظر بماند. هرچقدر که این زمان بیشتر باشد، لود وب سایت نیز دیرتر انجام میشود. ولی پیشنهاد مهمی برای شما داریم و آن این است که حتما مقاله TTFB چیست را مطالعه نمایید تا باعث بهینه سازی زمان بارگذاری سایت خود شوید.
یک تصور غلط در رابطه با محاسبه TTFB این است که بیشتریها تصویر میکنند که زمان دستیابی مرورگر به اولین بایت وب سایت بعد از بررسی DNS میباشد که این تصوری کاملا اشتباه است. زمان تاخیر TTFB به لیتنسی وب سایت شما بستگی دارد و هرچه پایینتر باشد TTFB شما نیز پایینتر است.
به طور کلی لود شدن اولین بایت در وب سایت باید ۳ مرحله پردازش، تاخیر و لیتنسی را بگذراند. TTFB بالا در وبسایت شما ممکن است به علت کدنویسی اشتباه ویا استفاده اشتباه از سیستم کش باشد.ولی مکان کاربران نیز یکی از دلایل موجود میباشد. ما با انجام آزمایشی تفاوت فعال بودن و نبودن CDN را در TTFB وب سایتمان بررسی کردیم که نتیجه آن به صورت زیر میباشد.
ما در ابتدا یک تست را بدون فعالسازی CDN انجام دادیم که در نتیجه تست زمان لود وب سایت ۱.۴۵ ثانیه نمایش داده شد که از این زمان ۱۳۶ میلی ثانیه اش به TTFB وب سایت مربوط بود.
پس از فعالسازی CDN و تست دوباره وب سایت، همانطور که مشاهده میکنید زمان لود وب سایت ۷۸۸ ثانیه و TTFB وب سایت نیز 37 میلیثانیه شده است. حال وقت آن است که بگویید، واو CDN چه تغییری ایجاد کرد. CloudFlare CDN افزایش سرعت سایت طراحی سایت ساخت سایت طراحی سایت شرکتی طراحی سایت فروشگاهی سئو سایت قیمت طراحی سایت
سرفصلهای پست
امروز قصد داریم تا نگاهی به جدول wp_options در پایگاه داده وردپرس خود کنیم. به طور کلی این منطقه شامل کلیه عملکردهای وردپرس و پایگاه داده است که در بیشتر اوقات به آن توجه نمیشود.
با توجه به بارگیری های خودکار داده ها در پوسته ها و افزونه های وردپرس توجه نکردن به این جدول (مخصوصا در وب سایتهای پربازدید و قدیمی) میتواند باعث کندی صفحهها و همچنین کاهش سرعت سایت و در نتیجه سئو وب سایت شما شود.
نکاتی که در پایین به شما آموزش میدهیم را بررسی کنید تا یاد بگیرید که چطور جدول wp_options را بررسی، عیبیابی و پاکسازی کنید.
جدول wp_options حاوی تمامی نوع داده مربوط به عملکرد وب سایت وردپرسی شما میباشد ، دادههایی مانند :
موارد زیر در جدول wp_options وجود دارد که یکی از آنها را که در عملکرد وب سایت نقش بسیاری دارد را پررنگ کردیم:
یکی از مهمترین مواردی که باید در رابطه با wp_options بدانید ، اطلاع داشتن از بخشی به نام بارگیری خودکار (autoload) میباشد. این بخش شامل دو متغیر بله و خیر (yes or no) میباشد . که اساساً برای کنترل تابع wp_load_alloptions() استفاده میشود. دادههای Autoload ، دادههایی هستند که در هر صفحه وردپرسی شما اجرا میشوند.
دقیقا مانند غیرفعال کردن بارگیری بعضی از کدهای جاوااسکریپت در بعضی از صفحات وب سایت ، این بخش نیز به راحتی غیرفعال و فعال میشود.
به طور کلی ، دادههای Autoload به صورت پیشفرض در تمامی جداول بر روی “yes” تنظیم شدهاند که با توجه به اینکه بعضی از افزونهها نیازی نیست که در تمامی صفحات بارگیری شوند، توسط توسعه دهندگان بارگیری خودکارشان (autoload) غیرفعال میشود.
تجربه نشان داده است که وجود مقدار زیادی autoload در جدول wp_options میتواند باعث مشکل در وب سایت وردپرس شما شود.
در زیر به تعدادی از مشکلات معمول این دسته اشاره میکنیم:
حداکثر مجاز استفاده از autoload در یک وب سایت وردپرسی چقدر است؟ این مقدار میتواند در هر نوع وب سایتی متفاوت باشد ولی به طور کلی حجم دادهها معمولا بهتر است بین 300 کیلوبایت تا 1 مگابایت باشد.
هنگامی که شما شروع به بررسی جدول wp_options میکنید با حجمی حدود 3 تا 5 مگابایت مواجه میشوید که حتما چیزهایی را باید غیرفعال یا به طور کلی حذف کنید تا جدول و دادههای autoload بهینه سازی شوند. اگر هنگام بررسی با حجمی بیشتر از 10 مگابایت مواجه شدید ، باید بگویم که وضعیت بحرانی است و باید سریعا به بررسی جدول wp_options بپردازید. با این حال ، صحبت ما به این معنا نیست که اگر بررسی نکنید با مشکل مواجه میشوید ولی در کل اگر از حالا بهینه سازی را شروع کنید ، مشکلات آینده را پیشگیری کرده و همچنین سرعت سئو سایت تان را بهبود میبخشید.
اگر شما با مشکل کندی سرعت سایت روبهرو شدهاید، یکی از دلایلی که میتواند باعث این مشکل شده باشد ، وجود کوئریها و یا دادههای خودکار بارگیری شدهی یک افزونه قدیمی در جدول wp_options میباشد.
در زیر ما به شما نشان میدهیم که چگونه حجم دادههای ستون autoload در جدول wp_options را بررسی کنید و خیلی راحت اطلاعات اضافه را پاکسازی کنید.
اولین کاری که باید انجام دهید ، بررسی حجم داده های ستون autoload در حال مصرف در وب سایت وردپرسی شماست. برای اینکار ، وارد phpMyAdmin شوید.
از سمت چپ صفحه دیتابیس خود را انتخاب کنید و سپس وارد سربرگ SQL شوید .
بعد از انجام این کار دستور زیر را در بخش ادیتور وارد کنید و روی کلید GO کلیک کنید.
توجه داشته باشید ما نسبت به نصب پیشفرض وردپرس آموزش میدهیم و ممکن است شما به علت امنیت از پیشوندی غیر از wp_ استفاده کرده باشید که برای استفاده از دستور بالا میبایست پیشوندی که تعریف کردهاید را به جای wp_ وارد کنید.
حجم نمایش دادهشده از تابع autoload_size بر مبنای بایت می باشد. هر 1000 بایت برابر 1 کیلوبایت است و هر 1000 کیلوبایت برابر 1 مگابایت است . بنابراین در تصویر زیر حجم autoload_size وردپرس ما 249025 بایت به معنای 0.25 مگابایت میباشد. به طور کلی این مقدار حجم برای یک وب سایت ، حجمی ایدهآل است. اگر نتیجه بررسی شما نیز کمتر از 1 مگابایت بود نیازی نیست که نگران چیزی باشید.
برای تبدیل راحت بایت به مگابایت کافی است در گوگل عبارت “byte to mb” سرچ کنید تا در یک rich answers گوگلبتوانید تبدیل را انجام دهید.
بنابراین ، اگر حجم autoload_size وب سایت شما بیشتر از 1 مگابایت بود ، پیشنهاد میشود که حتما در ادامه این مقاله سئوراز را دنبال کنید تا سئو و سرعت وب سایت خود را از این طریق بهبود بخشید.
در نمونه زیر حجم autoload_size برابر 137724715 بایت معادل 137 مگابایت میباشد. که این مورد نشان دهنده وجود مشکل در یک وب سایت وردپرسی است.
شما همچنین میتوانید برای بررسی تخصصی تر از چندین دستور مختلف دیگر استفاده کنید.
در دستور زیر حجم autoload_size بر حسب کیلوبایت ، تعداد کوئری های autoload و 10 دستور autoload اول دیتابیس به شما نمایش داده میشود.
اگر شما از خدمات سایت New Relic استفاده میکنید ، میتوانید از آن برای پیدا کردن مشکلات کوئری های جدول wp_options استفاده کنید، در سربرگدیتابیس این وب سایت ، شما میتوانید فهرستی از جداول و کوئریهایی که پرمصرف هستند را به دست آورید، اگر روی یکی از گزینههای در فهرست کلیک کنید، در رابطه با کوئریها اطلاعات بیشتری کسب میکنید. در مثال زیر ، شما میتوانید تعداد انگشت شماری از دادههای autoload در جدول wp_options را مشاهده کنید.
با اطمینان میتوان گفت که با جستوجویی کوتاه متوجه خواهیم شد که حدودا داده های autoload شده این وب سایت حداقل 250 مگابایت است.
مرحله بعدی بهینه سازی ، مرتب کردن پر مصرف ترین ها در داده های autoload شده میباشد. شما میتوانید با دستور SQLزیر به سرعت لیست 10 داده پرمصرف را به دست آورید.
دوباره خاطر نشان کنیم که ممکن است شما پیشوند جداول وردپرس خود را هنگام نصب برای افزایش امنیت تغییر داده باشید و نامی جز wp_ گذاشته باشید، برای اینکه دستور بالا کار کند ، شما باید پیشوند جداول خود را جایگزین wp_ کنید.
مرحله بعدی ایجاد تغییرات در یک داده autoload شده پرمصرف میباشد.
همانطور که مشاهده میکنید در تصویر بالا در صدر لیست ریدایرکت 301 قرار دارد. این کوئری به احتمال بسیار زیاد مربوط به یک افزونه سئو وردپرس میباشد و وظیفه انتقال دادن صفحات را دارد. در این نوع موارد ، بهتر است که از افزونه برای انتقال صفحات استفاده نکنید و از ابزار پیشفرض وب سرور خود استفاده کنید.
دلیل این پیشنهاد چیست ؟ به این دلیل که استفاده از افزونههای رایگان وردپرس برای انجام عملیات انتقال صفحات ممکن است باعث ایجاد اختلال در عملکرد وب سایت شوند ، نیازمند اجرای کد های اضافی و منابع دارد و همچنین ایجاد کوئری autoload در وب سایت میباشد ، پیشنهاد میشود که از انتقال صفحات از طریق پلاگین استفاده نکنید.
در لیست مرتب شده بالا هشت جایگاه را کوئری wpurp_custom_tiplate_ اشغال کرده است. به طور کلی شما باید بتوانید نام این کوئری ها بیابید و همچنین به سرور برای دسترسی به نقاطی از پوستهها و افزونهها دسترسی داشته باشید. اگر دسترسی دارید ، از طریق دستور grep زیر بررسی کنید که آیا میتوانید این کوئریها را پیدا کنید یا خیر! شما همچنین میتوانید از طریق درگاههای SFTP نیز این رکوردها را بررسی کنید.
اگرچه در بعضی از سرورها این روش کارایی ندارد ، ما توانستیم با جستوجویی ساده در گوگل دریابیم که این کوئری به افزونهای تحت عنوان WP Ultimate Recipe مربوط است. این کوئری یک نمونه از غیرضروریترین کوئریهای autoload شده در وردپرس می باشد. بنابراین اگر چنین افزونهای در لیست افزونههای خود دارید سعی کنید که آن را به طور کامل حذف کنید. درواقع ، منظور ما پاکسازی کامل افزونه و هرچیزی که تا به حال در پایگاه داده تولید کرده است میباشد.
نوع بعدی دادههای پرمصرف به دادههای um_cache_userdata_# مربوط میشود، این دادهها را در چند سطر از لیست 10 داده پر مصرف autoload بالا در میبینید.
با توجه به اینکه چند داده um_cache_userdata_ در پایان لیست قرار دارند . ما به سرعت وارد MySQL خود شده و با دستور زیر 40 کوئری Autoload پر مصرف مربوط به این داده را فراخوانی میکنیم.
و یا مجموع تمامی مقادیر بالا مربوط به آن پیشوند :
اگر متوجه شدید که تعداد بیشتری کوئری وجود دارد ، دوباره مجبورید در بین افزونهها و پوستهها جستوجو کنید و دستور grep مخصوص آن را اجرا کنید.
با توجه به جستوجویی که ما انجام دادید دریافتیم که این داده مربوط میشود به افزونه معروف Ultimate Miber و پس از جستوجویی کوتاه در گوگل راهی ساده برای حل مشکلات این افزونه نیز پیدا کردیم. سعی کنید قدرت جستوجو و تحقیق با گوگل را تمرین کنید تا به راحتی بتوانید نیازهای خود را در یک سرچ هدفمند پیدا کنید.
در جستوجو متوجه شدیم که برای حل مشکلات این افزونه چندین راه وجود دارد
گزینه دیگر برای پیداکردن گزینه های autoload کلیک روی کلید ویرایشگر است که میتواند لیست پوستهها/افزونهها و یا لیست وب سایت توسعه دهندگان آنها را به شما نمایش دهد.
یکی دیگر از گزینههای پرمصرف در بخش autoload استفاده مکرر Cronjobs ها میباشد. در این مورد، هر Cron ممکن است در این مسئله دخیل باشد، بنابراین هنگامی که ممکن است با کلیک روی کلید ویرایش وب سایت خراب شود ، باید چهکار کنیم ؟
برای مثال یک کوئری بسیار پرمصرف در وب سایت های وردپرسی کوئری Cron تحت عنوان do_pings میباشد که شما با یک جستوجوی ساده میتوانید نحوه پاکسازی این نوع کوئریها را پیدا کنید، اگر با نحوه کار و پاکسازی آن اشراف کامل را ندارید این مورد را نادیده بگیرید، یا قبل اجرا بک آپ در دیتابیس خود تهیه نمایید.
اگر تعداد زیادی از نمونههایی که در بالا به شما نشان دادیم را مشاهده کردید ، حالا وقت آن است که شروع به پاکسازی تمامی دادههای autoloaded کنیم. این نکته بسیار پیشنهاد میشود که تا جای ممکن سعی کنید که تعداد سطر های جدول wp_options شما در کمترین حالت ممکن باشد. لطفا سعی کنید قبل از هرگونه پاکسازی یا ایجاد تغییرات در پایگاه داده خود از آن نسخه پشتیبان تهیه کنید. اگر امکان این کار را ندارید ، پیشنهاد میکنیم یک متخصص حرفهای استخدام کنید.
مانند اولین نکتهای که به شما گفتیم ، برای پاکسازی جدول wp_options باید ابتدا وارد phpMyAdmin شوید. از منو سمت چپ پایگاه داده وردپرس خود را انتخاب کنید و وارد سربرگ SQL شوید. سپس دستور زیر را وارد کنید و روی کلید GO کلیک کنید.
این دستور به شما تمامی دادههای جدول wp_options را که در آنها autoload بر روی yes ذخیره شده است را نمایش میدهد.
با اسکرول کردن سطرها به ترتیب تمامی افزونههایی که در حال حاضر نصب یا درحال استفاده نیستند را مشاهده میکنید. به عنوان نمونه در این آموزش ما سطرهایی از افزونه Jetpack توسعه داده شده توسط وردپرس را بررسی میکنیم.
به عنوان مثال در حال حاضر وب سایت از افزونه Jetpack استفاده نمیکند.
همیشه بهتر است قبل از انجام هرکاری مستندات ارائه شده توسط توسعه دهندگان افزونهها را بررسی کنید ، گاهی اوقات در بعضی از مستندات توسعه دهنده میگوید که چطور جداول گذشته را پاکسازی کنید یا شاید گزینهای برای پاکسازی پایگاه داده در تنظیمات افزونه قرار داده بود. در بعضی اوقات بهتر است که ابتدا یک بار افزونه را حذف کنید و دوباره نصب کنید و سپس بررسی کنید که آیا کوئریهای پایگاه داده آن پاکسازی شده است یا خیر و سپس در صورتی که پاک شده بود آن را به طور کامل حذف کنید. با این حال ، در این مقاله ما به شما آموزش میدهیم که چطور به صورت دستی جداول را پاکسازی کنید.
برای مثال در دستور زیر ، ما تمامی دادههای autoload درون wp_options را که مخصوص افزونه jetpack هستند را فراخوانی میکنیم:
سپس روی کلید Select All کلیک میکنیم و روی Delete کلیک میکنیم تا به طور کامل جداول حذف شوند.
یا شما میتوانید به صورت مستقیم با دستور زیر اقدام به حذف کوئریها کنید:
حالا شما میتوانید با تغییر options_name به عنوان افزونه و یا پوسته قدیمی خود داده های autoload شده جدول را پاکسازی کنید.
اگر از یک حافظه کش استفاده میکنید، وردپرس رکوردهای گذرا یا transient را در خود جدول wp_options ذخیره میکند. به طور کلی این نوع رکوردها باید زمان انقضایی داشته باشند و در طول زمان پاکسازی شوند ، با اینکه ، همیشه اینطور نیست. در حال حاضر پایگاههای دادهای وجود دارد که بیشتر از هزاران رکورد transient قدیمی را در خود نگاه داشتهاند. باید توجه داشته باشید که رکوردهای transient به صورت پیشفرض به صورت خودکار بارگیری نمیشوند.
شما میتوانید از دستور زیر برای مشاهده رکوردهای transient خودکار بارگیری شده استفاده کنید :
به هر حال ، شما میتوانید از افزونه Transient Cleaner نیز برای پاکسازی دادههای گذرا از پایگاهداده خود استفاده کنید.
اگر پاکسازی دادههای جدول wp_options کافی نبود ، شما بهتر است که از یک شاخص برای autoload استفاده کنید.
این کار اساسا کمک میکند که جستوجوی شما کارآمدتر شود.
تیم تست به نام 10آپ ، چند آزمون مختلف بر روی جدول wp_options با رکوردهای autoload شده انجام داده است تا نمایش دهد که چطور با افزودن یک شاخص به کوئریهای wp_options میتوانیم در عملکرد وب سایت بهبود بخشیم.
افزونه Little Bizzy یک افزونه کاملا رایگان وردپرسی است که با اضافه کردن شاخصی برای autoload جدول wp_options با استفاده از wp_cron برای گزارش روزانه میتواند به شما بسیار کمک کند.