It can sometimes be frustrating when you realize you don’t have enough access to data to troubleshoot issues on your WordPress site. Thankfully, with the new revamped MyKinsta Analytics you can now investigate and diagnose a lot of these problems from right within the dashboard. Today we’ll dive into each section of MyKinsta Analytics and share some examples (and real-world scenarios) of how you can take advantage of these new reports to improve and fix your WordPress sites. Find out what’s going on under the hood!
Diving Into MyKinsta Analytics
The main dashboard of MyKinsta has a few quick insights into your resource usage, as well as data transfer and unique visits. To dive into the more in-depth reports you will want to click on “Analytics” on the sidebar.
At the top you can filter the stats individually or view data for all of them combined. You can then choose to see data for the past 7 days or past 24 hours. Note: We are adding a 30-day filter as well.
MyKinsta Analytics has been split up into seven different sections of which we will dive into each further below:
- Resource Usage
- Performance Monitoring
- Visitor Analysis
- Response Analysis
- Cache Analysis
- Geo Analysis
- Security Metrics
Under the resource usage section, you can view your total number of visitors, bandwidth usage, total requests by bytes, and total requests by visits.
The visitor’s report lets you see the total number of people that have visited your WordPress site. If you highlight a specific point in time on the graph it will show you some comparison statistics, such as the total number of visitors being higher than the previous day, etc. This is the exact number of visitors to the web server. Remember, that your Google Analytics filters and rules won’t work here. In case you’d like to know the number of human visitors of your site, all services will show a different number based on their own set of rules — who they consider to be irrelevant/bot traffic and those that they don’t.
The bandwidth usage report shows the total data your site has used. This is important because Kinsta charges you based on the bandwidth your site uses on a monthly basis. And there is a limit in each plan. If you highlight a specific point in time on the graph it will show you some comparison statistics, such as the total being lower than the period average, etc. Read more about bandwidth overage charges.
We strongly recommend every customer to implement a CDN. Not only because you’ll see an increase in speed, but this can be a very cost effective way to decrease the bandwidth needed on your host. CDN bandwidth is very cheap or even free. So combining a CDN with Kinsta will actually save you money. Check out our in-depth post on the benefits of a WordPress CDN and why you should use one.
Top Requests by Bytes
A byte is a sequence of binary bits in a serialized data stream in data transmission systems. When it comes to your WordPress site, this is typically measured in MBs, GBs, and TBs. The total number of bytes transferred on your site make up your bandwidth. In the top requests by bytes report, you can see exactly which requests on your site are using up the most bandwidth.
Top Requests by Visits
Similiar to the report above, the top requests by visits reports shows you the top bandwidth being used by visitors to your site. Using this report and the ones above can help you troubleshoot and figure out where your bandwidth is going. If you are having trouble with overages, this would be the first place to look. A lot of times you can easily spot a pattern.
Under the performance monitoring section, you can view your average PHP + MySQL response time, PHP throughput, AJAX usage, top average upstream time, and top maximum upstream time.
Average PHP + MySQL Response Time
Whenever you visit your WordPress site, PHP and MySQL are used to compile and query the data you see on the page. The average PHP + MySQL response time report can help you troubleshoot slowness. If you are seeing huge spikes here, feel free to open up a support ticket with our team.
Throughput indicates the number of transactions per second an application can handle, and in this report, it is referring to PHP throughput from your WordPress site.
AJAX is a client-side script that communicates to and from a server/database without the need for a postback or a complete page refresh. When it comes to WordPress, a lot of you have probably seen this in your speed tests. The top two issues with AJAX include plugins causing it to spike and CPU issues on the back-end. Make sure to check out our in-depth post on diagnosing high Admin-AJAX usage on your WordPress site.
The AJAX usage report in MyKinsta analytics can be a great way to help you troubleshoot these types of issues as you can see if you are seeing certain AJAX spikes during certain periods. You can then utilize some of the tips in the post we mentioned above to narrow down where they might be coming from.
Top Average Upstream Time
Upstream time is the total time taken for NGINX (and upstream servers) to process a request and send a response. Time is measured in seconds, with millisecond resolution. Read more about NGINX metrics. The top average upstream time report shows the responses with the highest averages.
Top Maximum Upstream Time
Similiar to the report above, the top maximum upstream time report shows the responses with the highest response times.
Under the visitor analysis section, you can view your unique requests, requests & bots, and mobile vs desktop.
Whenever a browser fetches a file from a web server it performs what is known as an HTTP request. The unique requests report show you the total number of requests, both unique and repeat requests.
Requests & Bots
The requests & bots report shows you the total number of bot requests vs that of human requests. Bots can include all sorts of different things from Google’s bot crawling your site to index it, or scrapers simply hitting your site for no apparent reason. Bots can be both good and bad. If you are seeing a high-ratio of bot traffic you might think about implementing a CDN like KeyCDN which has a feature to block bad bots. Why? Because bots can drain your bandwidth which costs you money and could even result in overage charges. Cloudflare and Sucuri also have web application firewalls which can also dramatically help reduce bot traffic.
Mobile vs Desktop
The mobile vs desktop report allows you to see which devices are hitting your site. In this example below, you can see that it is primarily desktop traffic at over 80%.
Under the response analysis section, you can view your response code breakdown, response stats, 500 error breakdown, 400 error breakdown, and redirect breakdown.
Response Code Breakdown
The response code breakdown report lets you see an overview of the errors on your site. Response codes, also known as HTTP status codes, are not always bad. For example, a 200 HTTP status code means that “Everything is OK.” This is the code that is delivered when a web page or resource acts exactly the way it’s expected to. We’ll go into the others further below.
The response stats report lets you see the total number of redirects happening, errors, success rate, and error ratio. Every WordPress site will typically have a small error rate ratio, this is completely normal.
500 Error Breakdown
The 500 error breakdown report shows you the total number of 500 errors that occurred on the server. Here is a more in-depth explanation of what each of these means:
- 500: “There was an error on the server and the request could not be completed.” A generic code that simply means “internal server error”. Something went wrong on the server and the requested resource was not delivered. This is the code generated by WordPress when the connection to the database breaks. Make sure to check out our in-depth article on how to fix the error establishing a database connection.
- 502: “Bad Gateway”. This error code typically means that one server has received an invalid response from another. Sometimes a query or request will take too long and so it is canceled or killed by the server.
- 503: “The server is unavailable to handle this request right now.” The request cannot be completed right now. This code may be returned by an overloaded server that is unable to handle additional requests.
400 Error Breakdown
The 400 error breakdown report shows you the total number of 400 errors that occurred on the server. Here is a more in-depth explanation of what each of these means:
- 401: “Unauthorized.” This is returned by the server when the target resource lacks valid authentication credentials.
- 403: “Access to that resource is forbidden.” This code is returned when a user attempts to access something that they don’t have permission to access. For example, trying to view password-protected content without logging in might produce a 403 error.
- 405: “Method not allowed.” This is generated when the hosting server (origin server) supports the method received, but the target resource doesn’t.
- 404: “The requested resource was not found.” The most common error message of them all. This code means that the requested resource does not exist and that the server does not know if it ever existed.
- 429: “Too Many Requests.” This is typically generated by the server when the user has sent too many requests in a given amount of time (rate limiting). A lot of times this could happen from bots or scripts trying to brute-force their way into your default WordPress login page. You can help lock down your site by changing your WordPress login URL.
- 499: “Client closed request.” This is returned by NGINX when the client closes the request while NGINX is still processing it.
If you are seeing a large amount of 404 errors, like in the example above, it is recommended that you go through your site and fix them for SEO and usability purposes. You can install a 404 error plugin or look them up in Google Search Console under crawl errors.
The 300 error breakdown report shows you the total number of 300 errors that occurred on the server. Remember, that like 200 response codes, not all errors are bad. 300 errors typically mean you have simply moved the content elsewhere. 301 redirects, for example, are very important as they will help retain your SEO rankings for URL and site changes. Here is a more in-depth explanation of what each of these means.
- 301: “The requested resource has been moved permanently.” This code is delivered when a web page or resource has been permanently replaced with a different resource. It is used for permanent URL redirection.
- 302: “The requested resource has moved, but was found.” This code is used to indicate that the requested resource was found, just not at the location where it was expected. It is used for temporary URL redirection.
- 304: “The requested resource has not been modified since the last time you accessed it.” This code tells the browser that resources stored in the browser cache haven’t changed. It’s used to speed up web page delivery by reusing previously downloaded resources.
Under the cache analysis section, you can view your cache component stack, total cache bypasses, and cache component chart.
Cache Component Stack
Whenever a file or resource is requested from Kinsta’s servers it sends a value in the HTTP response header (X-Kinsta-Cache) to let you know the status of the cache.
There are four types of cache response headers returned:
- HIT: A HIT means that the resource is being served from the cache on Kinsta’s servers. Typically this is what you want to see.
- BYPASS: This means that there is probably a rule or conflict that is preventing the resource from caching. We have rules in place so that certain things on your WordPress site don’t cache. For example, your /wp-login.php page is one. This is to ensure proper functionality when you log in to your dashboard.
- MISS: This means that the content was not yet in the cache but will be after the first request. The second request to that file will be a cache HIT. Remember that each time you purge the cache on your WordPress site that it has to rebuild by people visiting it. This is why we recommend not clearing entire cache constantly. The Kinsta cache plugin automatically purges only certain sections of your site so that the rest can remain cached. Read more about how Kinsta handles caching.
- EXPIRED: This means the cached content has expired and the new content from the hosting server has been fetched.
The cache component stack report lets you see the total number of response header values that have been generated from your site.
Top Cache Bypasses
The top cache bypasses report lets you see some of the top requests that are bypassing the cache on Kinsta’s servers. It is good to take a look at this and ensure they should be. In this example below, we can see that the OneSignal push notification plugin has a few files that are bypassing the cache. Because of how the plugin works, this is actually OK. We can also see that /wp-cron.php isn’t cached, which again, shouldn’t be.
Cache Component Chart
The cache component chart is again another way to view your total cache requests.
Under the Geo analysis section, you can view your top countries, and top cities.
The top countries report can be one good way to determine where you should be placing your WordPress site. In this example below, the site should probably be placed on a server in the United States, since a majority of the traffic is from there. Make sure to read our in-depth post about network latency and why it’s important to strategically place your site. Kinsta now has 12 Google Cloud Platform locations around the globe where you can host your WordPress site.
You can also view top regions.
You can also view top cities.
And last but not least, we have the security metrics section. This will most likely continue to grow as we improve our analytics tool.
Top Client IPs
The top client IPs report can be very helpful if your site is suddenly generating a lot of bandwidth or getting hit by bots.
How can you use this data? Well, we recently did a case study on a small e-commerce WordPress site. Analyzing the top 10 client IPS for the last 7 days to the site instantly showed some suspicious activity. A majority of them had over 10,000 requests, and there were quite a few. It was most likely a DDoS or brute force attack. You can always rely on Google to provide you with data. Entering in a couple of the top IPs into search, we could easily see that most of them were all proxy addresses, meaning someone was most likely wanting to hide their traffic.
The next step in this scenario that we would recommend is either reaching out to the Kinsta team to block the IPs for you, or considering a web application firewall like Cloudflare or Sucuri. You can check out our case study in which Sucuri instantly blocked all this bad traffic.
With all of the data above, hopefully, now you have a better understanding of how Kinsta is actually delivering content to your visitors.