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.
Access MyKinsta Analytics
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 24 hours, 7 days, or 30 days.
MyKinsta Analytics has been split up into seven different sections of which we will dive into each further below:
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.
Resources – Visitors
Kinsta’s hosting plans are based on the total number of visitors to your site. Read more about how Kinsta counts visitors. Note: Your total visits count in the resources section might differ from the total you see on your main MyKinsta dashboard. This is because the MyKinsta dashboard shows visits within your current billing cycle.
The bandwidth usage report shows the total data your site has used. Kinsta charges for plans based on the number of visitors to your site, but bandwidth usage can help you troubleshoot performance issues. 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.
Resources – bandwidth usage
We strongly recommend every customer to implement a CDN. Not only because you’ll see an increase in speed, but this can be a great way to decrease bandwidth and resources on your site. CDN bandwidth is very cheap or even free. Check out our in-depth post on the benefits of a WordPress CDN and why you should use one. Or if you’re ready, check out how to enable the Kinsta CDN on your site.
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.
Resources – top requests by bytes
Top Requests by Count
The top requests by count report shows you the most requested resources from your site on the server. Using this report and the ones above can help you troubleshoot and figure out where your bandwidth is going. A lot of times you can easily spot a pattern.
Resources – top requests by count
2. CDN Usage
Under the CDN usage section, you can view your CDN bandwidth, top files by requests, top files by bytes, top file extensions by bytes, and HTTP response codes. If a certain media file from your site is hogging all of your bandwidth, you’ll be able to easily spot it within a few seconds.
CDN usage in analytics
In the bottom of the CDN usage section, you can see the top file extensions by bytes. This makes it easy to see what type of media on your site is responsible for the majority of your bandwidth usage.
You also have a response code breakdown. A 200 status code is typically what you want to see, this means that everything was delivered “OK.” Check out our post on HTTP status codes to learn more about 300, 400, and 500 status codes.
CDN top file extensions and response codes
Under the dispersion section, you can view different insights about traffic on your site.
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 86%.
Dispersion – mobile vs desktop
4. Performance Monitoring
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. This chart shows you the average response time of the PHP engine and the MySQL engine for every non-cached dynamic request. Knowing these response times can help you troubleshoot slowness. If you are seeing huge spikes here, feel free to open up a support ticket with our team.
Performance – Average PHP + MySQL Response Time
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. In other words, it shows you how many times a PHP asset was requested.
Performance – PHP throughput
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. This chart shows the count of the admin-ajax requests. You can then utilize some of the tips in the post we mentioned above to narrow down where they might be coming from.
Performance – AJAX usage
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. This list shows the top average PHP and MySQL response times (combined) for your requests.
Performance – Top average upstream time
Top Maximum Upstream Time
This list shows the top response times from PHP and MySQL. Please note, that these numbers can be one time peaks, it’s suggested to compare this list with “Top Average Upstream Time.”
Performance – top maximum upstream time
Under the response analysis section, you can view your response code breakdown, response stats, 500 error breakdown, 400 error breakdown, redirect breakdown, and top 404 errors.
Response Code Breakdown
The response code breakdown report lets you see an overview of the distribution of HTTP status codes served for the requested resources. 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.
Response – response code breakdown
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.
Response – response stats
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. Read more about why a 502 bad gateway error occurs.
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.
Response – 500 error breakdown
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.
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.
405: “Method not allowed.” This is generated when the hosting server (origin server) supports the method received, but the target resource doesn’t.
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.
Response – 400 error breakdown
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.
Response – redirect breakdown
Top 404 Errors
The top 404 errors report helps you more easily troubleshoot the most requested resources that visitors or bots are hitting that no longer exist on your site.
Top 404 errors
If you’re seeing a large amount of 404 errors, it is recommended that you go through your site and fix them for SEO and usability purposes. You can also look them up in Google Search Console under crawl errors.
Fix 404 errors
6. Cache Analysis
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.
HTTP response header
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 thecached 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.
Cache – cache component stack
Cache Component Chart
The cache component chart is again another way to view your total cache requests.
Cache – cache component chart
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 – top cache bypasses
7. Geo Analysis & IP
Under the Geo analysis section, you can view your top countries, top regions, top cities, and the top IP address visiting your site.
The top countries report can be one good way to determine where you should be placing your WordPress site. This is a geo analysis by country of the requests from visitors IP addresses. 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 15 Google Cloud Platform locations around the globe where you can host your WordPress site.
Geo & IP – top countries
Geo analysis by region of the requests from visitors IP addresses.
Geo & IP – top regions
Geo analysis by city of the requests from visitors IP addresses.
Geo & IP – top cities
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. This shows the top IP addresses, listed by request count.
Geo & IP – top client IPs
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.
Full log data in regards to analytics is retained for 30 days. We suggest checking the dashboard and analytics section more frequently after first migrating to Kinsta. If you see an unexplained traffic spike or inconsistency which has you concerned, let our team know and we can further investigate the logs for you to help determine the cause.
With all of the data above, hopefully, now you have a better understanding of how Kinsta is actually delivering content to your visitors.
A cookie is a piece of information that a website stores on a visitor’s computer. We use this for some functionality on our website to work properly, collecting analytics to understand and improve a visitor’s experience, and for personalized advertising. You can accept all cookies at once or fine-tune your preferences in the cookie settings.
Thanks, we've saved your settings, you can modify them any time on the cookie settings page
These cookies are needed for our website to function providing payment gateway security and ther essentials. Therefore they are always on but they do not contain personally identifiable information (PII).
If you've set preferences (which cookies you accept and which you don't) we store your preferences here to make sure we don't load anything that you didn't agree to.
WordPress sets a couple of cookies that track logged in users and store user preferences set in their WordPress user profile. These are set for members of the Kinsta website only - members of our staff.
Stripe is our payment provider and they may set some cookies to help them with fraud prevention and other issues. This is required for our payments to work.
This cookie contains information about the affiliate who refered a visitor. The cookie contains no information about the visitor whatsoever.
Analytics help us deliver better content to our audience. We have made sure no personally identifiable information (PII) is sent by anonymizing IPs.
If you sign up for our newsletter we'll remove the newsletter subscription box for you. This cookie has not personal data it just indicates if you have signed up.
Analytics cookies allow us to gather data to help us better understand our visitors and offer them a better experience.
Set and used by Hotjar. We use Hotjar to analyze user behavior without identifying the user.
Marketing cookies help us target our ads better. We mainly use them to target ads to users who have visited Kinsta.
Set and used by Twitter, used for targeting advertisements and promoting content to users who have visited kinsta.com.
Set and used by LinkedIn, used for targeting advertisements and promoting content to users who have visited kinsta.com.
Set and used by Facebook, used for targeting advertisements and promoting content to users who have visited kinsta.com.
Set and used by Google Ads for remarketing, personalization, and targeting advertisements to users who have visited kinsta.com. (Google Ads Settings)
Set and used by Bing Ads for remarketing, personalization, and targeting advertisements to users who have visited kinsta.com. (Bing Ads Settings)
Set and used by Quora, used for targeting advertisements to users who have visited kinsta.com.