Analytics
With WordPress Analytics in MyKinsta, you can find out what’s going on under the hood of your site by viewing a wide array of analytics data. You can even investigate and diagnose some site issues from right within the MyKinsta dashboard. Today we’ll dive into each section of MyKinsta Analytics and even share some examples of how you can use this data to improve and fix your WordPress site.
Diving into MyKinsta analytics
The Dashboard page of MyKinsta has a few quick insights into your resource usage, data transfer (bandwidth), unique visits to your live site, and CDN usage (when applicable).
To dive into the more in-depth reports, you can look at analytics for all sites in your plan by going to your username > Company settings > Analytics page. Note: If you also have Application Hosting or Database Hosting, you’ll need to select the WordPress Sites subpage. When you’re viewing company-level analytics, you’re viewing data for all WordPress sites and environments.
To view analytics for only one specific site (site-level analytics), go to WordPress Sites > sitename > Analytics.
You can then choose to see data for the past 24 hours, 7 days, 30 days, or the current billing cycle (Current month in the dropdown menu).
Analytics are split into seven different sections, which we will dive into further below:
Resources
Under the Resources section, you can view your total number of visits, disk space, bandwidth usage, top requests by bytes, and top requests by views.
Plan usage
Plan usage shows the totals for all sites in your company’s plan. Disk usage information is calculated once every day for each website at various times. This means the amount of disk space used can vary during the day, and the total for all websites might not be entirely accurate until the next day.
Plan usage distribution
The plan usage distribution report shows you a breakdown of the number of visits, bandwidth usage, and disk space usage for each WordPress site in your company plan. Disk Space refers to the storage capacity currently in use and always displays the most recent data within the specified time frame. You can sort this chart by Visits, Bandwidth, or Disk Space in ascending or descending order by clicking on the corresponding header.
As Kinsta’s hosting plans are based on the total number of visitors to your live site, you can identify how much of your plan each site uses. The bandwidth usage and disk space usage help you to identify which sites you may need to perform more analysis on for troubleshooting issues.
Visits
The visits graph shows you the number of visits to your WordPress environment (Live, Standard Staging, or Premium Staging). This chart uses Coordinated Universal time (UTC).
If you highlight a specific point in time on the graph, it will show you the number of visits for that day and a comparison percentage to the previous data point (day or hour, depending on the time frame selected). This is the exact number of visits to the environment. Remember that your Google Analytics filters and rules do not apply here. 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.
Kinsta’s hosting plans are based on the total number of visitors to your live site. Only visits to the live environment are counted in your plan usage (shown at the top of your Company-level Analytics page and in the WordPress analytics section of your Dashboard page). Read more about how Kinsta counts visits.
Note: The total visits in the Resources section of analytics may differ from the total you see on the Dashboard page in MyKinsta. This is because the MyKinsta Dashboard page always shows visits within your current billing cycle.
Disk space
The disk space chart shows your storage limit and usage. Note: Disk space usage cannot be viewed for the past 24 hours, so you’ll need to select 7 days, 30 days, or the Current month for the time frame in the dropdown menu near the top of the page.
Bandwidth
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. This chart uses Coordinated Universal time (UTC).
If you highlight a specific point in time on the graph, it will show you some comparison data, such as the percentage difference between each day.
We strongly recommend every customer 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 Kinsta’s 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 makes up your bandwidth. In the top requests by bytes report, you can see which requests on your sites use up the most bandwidth.
Top requests by views
The top requests by views report shows you the most requested resources from your site on the server, regardless of size. If your site uses more bandwidth than expected, this report and the ones above can help you troubleshoot and determine where your bandwidth is going. A lot of times, you can easily spot a pattern.
CDN & edge
Under the CDN Usage section, if Kinsta’s CDN is enabled, you can view your CDN bandwidth, top files by requests, top files by bytes, and top file extensions by bytes. If a particular media file from your site is hogging all of your bandwidth, you can spot it here.
CDN bandwidth
The CDN bandwidth usage report shows the total CDN data your site has used. This chart uses Coordinated Universal time (UTC).
If you highlight a specific point in time on the graph, it will show you some comparison data, such as the percentage difference between each day.
Edge cache bandwidth
This chart shows the total data served by the edge cache. This chart uses Coordinated Universal time (UTC).
If you highlight a specific point in time on the graph, it will show you some comparison data, such as the percentage difference between each day.
Top files by requests
The top files by requests report shows you the most requested files on your site served by the CDN. This can help you identify which files are responsible for most of your CDN bandwidth usage.
Top files by bytes
The top files by bytes report shows you the largest files on your site served by the CDN. This can help you identify large files that you may be able to optimize, reducing the file size and your CDN bandwidth usage.
Top file extensions by bytes
The top file extensions by bytes report shows you the top X file extensions served by the CDN. This can help you identify the type of media on your site responsible for most of your CDN bandwidth usage.
Dispersion
Under the Dispersion section, you can view different insights about the traffic on your site.
Desktop vs. tablet vs. mobile
The desktop vs. tablet vs. mobile chart lets you see which devices are hitting your site. In the example below, you can see that it’s primarily desktop traffic at 95%.
Performance
Under the Performance section, you can view your average PHP + MySQL response time, PHP throughput, PHP memory limit reached, PHP thread limit, AJAX usage, top average PHP + MySQL response time, and top maximum upstream time.
Average PHP + MySQL response time
Whenever you visit a 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 uncached request.
If this value is high or shows a recent spike, feel free to open up a new chat with our Support team so they can check for any server-related issues. If no server-related issues are found, we recommend using our APM tool to help diagnose performance issues.
PHP throughput
Throughput is the number of transactions per unit of time. In this report, it refers to PHP throughput from your WordPress site. In other words, it shows how many total requests were executed for the selected time frame. The line graph shows a more detailed breakdown by hours or days (depending on the time frame).
PHP memory limit reached
This chart shows the number of times the PHP memory limit was reached. Kinsta’s default PHP memory limit is 256MB, which is more than enough for most WordPress plugins and sites. This limit exists to prevent PHP scripts from consuming excessive memory. If you set the limit too high, a misconfigured or broken script can cause serious issues by using up too much memory. If your site is set up correctly at Kinsta, you shouldn’t reach the PHP memory limit.
You can change a site’s PHP memory limit per thread within WordPress sites > sitename > Info > PHP performance > Change. If you increase the memory per thread, this reduces the number of PHP threads available and, therefore, reduces the number of incoming requests your site can handle simultaneously. However, you can also change your Total memory pool to increase both the number of threads and memory available for your site.
PHP thread limit
The PHP thread limit chart shows how often the PHP engine reached the maximum allocated PHP threads. For example, if your plan includes 4 PHP threads, and your site utilizes all 4 PHP threads simultaneously and cannot immediately respond to incoming PHP requests, that would count as one instance of reaching the PHP thread limit.
This may only give you a partial picture of your PHP thread activity as this only records the number of times the PHP thread limit is reached and not how long all PHP threads were in use.
Each hosting plan at Kinsta includes a default number of PHP threads. You can change the number of PHP threads for each site within WordPress sites > sitename > Info > PHP performance > Change. If you increase the number of threads, this reduces the memory limit per thread; however, you can also change your Total memory pool to increase both the number of threads and memory available for your site. The information in this chart can help you gauge whether or not your site is continuously hitting limits.
AJAX usage
AJAX (Asynchronous JavaScript and XML) is a term that describes using a client-side script that lets you update parts of a web page without having to do a postback or page refresh.
When it comes to WordPress, you may have seen admin-ajax.php in your speed tests. WordPress uses Ajax for core admin features like auto-saving posts, user session management, and notifications. The Ajax calls for those features are done through the admin-ajax.php file in /wp-admin.
The most common issues with Ajax in WordPress are plugins causing it to spike and CPU issues on the back end. For more details, check out our in-depth post on diagnosing high Admin-AJAX usage on your WordPress site.
The AJAX usage chart shows the count of the admin-ajax requests, and you can see if there are Ajax usage spikes during specific periods. Select one of the bars in the chart, and you can see the number of Ajax requests for that particular time period. You can then utilize some of the tips in the post we mentioned above to narrow down the source of those spikes.
Top average PHP + MySQL response time
This list shows the paths with the top response times from PHP and MySQL. The time is the average per request, not the total time for all requests. These numbers can be one-time peaks, so it’s best to compare this list with the Top maximum upstream time list.
Top maximum upstream time
Upstream time is the total time taken for NGINX (and upstream servers) to process a request and send a response. This list shows the paths with the top PHP and MySQL upstream times (combined) for requests. The time is per request, not the total time for all requests.
Response
Under the Response 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 chart 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 “Everything is OK.” This code 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 stats
The Response stats report shows you the total number of redirects, errors, success rate, and error ratio. Every WordPress site will typically have a slight error rate ratio, which is completely normal.
500 error breakdown
The 500 error breakdown chart 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 means there was an “internal server error.” Something went wrong on the server, and the requested resource was not delivered.
- 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, so it is canceled or killed by the server. Read more about how to fix a 502 bad gateway error.
- 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 cannot handle additional requests. We have a step-by-step guide on how to fix the 503 service unavailable error in WordPress.
400 error breakdown
The 400 error breakdown chart 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.” The server returns this error 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 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 server can’t find the requested resource, and the server does not know if it ever existed.
- 405: “Method not allowed.” This error is generated when the hosting server (origin server) supports the method received, but the target resource doesn’t.
- 429: “Too Many Requests.” The server typically generates this error when the user has sent too many requests in a given amount of time (rate limiting). Often, this is caused by 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 error is returned by NGINX when the client closes the request while NGINX is still processing it.
Redirect breakdown
The Redirect breakdown chart shows you the total number of redirects that occurred on the server. Remember that like 200 response codes, not all response codes are bad. 300 response codes typically mean you have 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 indicates that the requested resource has been temporarily moved to a different location.
- 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 speeds up web page delivery by reusing previously downloaded resources.
Top 404 errors
The Top 404 errors list helps you troubleshoot the most requested resources that visitors or automated bots are hitting that do not exist on your site.
If you see a large amount of 404 errors, it’s generally 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.
Cache
Under the Cache section, you can view your cache component stack, cache component chart, and total cache bypasses.
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 a rule or conflict is probably preventing the resource from caching. We have rules in place so that certain things on your WordPress site aren’t cached. For example, your /wp-login.php page isn’t cached, which ensures 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 be rebuilt by people visiting it. This is why we recommend not clearing the entire cache constantly. The Kinsta MU plugin automatically purges only certain sections of your site so 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 cache response header values generated from your site.
Cache component chart
The cache component chart is another way to view your total cache response header values.
Top cache bypasses
The top cache bypasses report lets you see the top requests that bypass the cache on your site. It’s good to take a look at this and make sure those paths should be bypassing the cache. The example below shows that /wp-cron.php isn’t cached, which is necessary for WP-Cron to work as expected.
Geo & IP
Under the Geo & IP section, you can view the top countries, top cities, and the top IP address visiting your site. This gives you insights into the countries, cities, and individual IP addresses of visitors to your site.
Top countries
The Top countries list can help you determine if the data center your site is in is the best location. This list is a geo analysis by country of visitors’ IP addresses. In the example below, the site should probably be placed on a server in the United States since most of the traffic is from there.
Kinsta now has 37 Google Cloud Platform locations around the globe where you can host your WordPress site. For more details, check out our in-depth post about network latency and why it’s important to place your site strategically.
Top cities
The Top cities list shows you the geo analysis by city of visitors’ IP addresses.
Top client IPs
The Top client IPs list can be helpful if your site suddenly uses a lot of bandwidth. This shows the top IP addresses listed by request count.
How can you use this data? Here’s an example of a case study on an e-commerce WordPress site. Analyzing the top 10 client IPs to the site for the last 7 days showed some suspicious activity. Most of them had over 10,000 requests, and there were quite a few IPs with this many requests. It was most likely a DDoS or brute force attack. Entering a couple of the top IPs into Google search, we could see that most of them were proxy addresses, meaning someone most likely wanted to hide their traffic.
The good news is, in addition to firewall protection, our Cloudflare integration also includes free DDoS (Distributed Denial of Service) protection. If you need further intervention, let our Support team know. If necessary, we can block the IPs for you.
Other options include setting up your own Cloudflare account (where you can enable and configure Cloudflare’s Web Application Firewall with more specific rules for your site) or adding a different web application firewall like Sucuri.
Additional notes
Full analytics data is retained for 30 days. We suggest checking the Dashboard and Analytics pages more frequently after first migrating to Kinsta. If you see an unexplained traffic spike or inconsistency that concerns you, let our Support team know, and we can further investigate the logs to help determine the cause.
Hopefully, with all of the data above, you will have a better understanding of how Kinsta delivers content to your visitors.