In today’s technology driven society, there is a constant need for validation that our phones, iPads, computers, and tablets are running at optimal speed. There has never been a world that strives to compete with being “the fastest” like the world we live in today. Everyone wants information and entertainment as quickly as they can get it. Often we say to each other “the website I downloaded is amazing; it loads in 2 seconds”. But is that truly a measure of efficiency? Should we instead look beyond the load times on our technology (webpages, stores, etc.) as a measure of performance? Now is the time to shift our perception of how to truly measure real user experiences.
Let’s get back to the assumption of “the website loaded in 2 seconds”. To many that instills the conception that the website is very fast and efficient. This way of thinking incorrectly showcases reality. Load times are not the same overall and in fact they may vary dramatically from one person to the next. This is due to the device they are using and if the network they are on is connected optimally. Presenting load times as one number is one dimensional at best and completely disregards those who experienced lagging load times.
Another assumption that is used often is that slow performance with a webpage or store loading means that the performance of the site or store will be poor. But, just because a site is slow to load does not mean that it has been adequately measured for performance. There are other instances, besides load time, in which a poor performance of a store or webpage can happen. Have you ever used a website that freezes or is slow to respond to taps? That user experience will be low because the website is not running as smoothly as advertised. Develops should not solely focus on how quickly a webpage or a store loads, but also by how smooth the user experience will be overall.
Does your site respond to taps quickly? If not, how do you measure that?
(Actually you can measure that with HotJar)
How can we overcome the flawed metrics that developers have been using? By pushing away from performance metrics of load time and instead going towards newer methods that focus on answering questions such as how do we measure these metrics on actual users? Is the webpage useful? Is it usable? Another pertinent question to ask would be: is the website lag free? These questions are starting points to where developers need to fully optimize performance metrics.
Example of Poor Performance Metrics: PageSpeed Insights
A source known as PageSpeed Insights has been lauded as a way to measure performance of websites. This is especially important because as mobile access to websites increase, users expect speed on multiple possible sources. PageSpeed is meant to be used by developers and is very advanced to fully comprehend. Not everyone who uses PageSpeed is a webmaster, this can bring up confusion about performance and speed. Google receives a 59 out of 100 as far as speed goes (according to PageSpeed), but does that make Google a poor performer with dissatisfied users? No, it does not; but having misconceptions about measuring speed as the driving metric for how optimal a store or website is, is the real issue at hand.
Fast user experience seems to be what PageSpeed Insights look for. A company called Aristotle offers advice on the best metrics available to gauge performance. From a user-experience perspective, developers should focus on the following metrics: page weight, perceived site performance, and time to first byte (TTFB). These metrics are the select few that consistently gauge performance and positive user experience across websites and platforms. Here is a breakdown of these metrics:
- Page Weight – We mentioned briefly how mobile browsing has gained a large chunk of Internet traffic in the past couple of years. Therefore, your page weight should be somewhere under 2,000 kilobytes, and the average number is around 1,500. Anything more than that will be a poor experience for a mobile user audience. The heavier your page weight, the more data it takes to view a webpage.
- Perceived Site Performance – It should only take 2-3 seconds to load “above-the-fold content” or the content at the top of the page. Anything longer than that will result in a loss of potential audience. Then you can kiss potential users and sales goodbye. Access to a webpage is what customers want, and service begins from the moment people type in your URL.
- Time to First Byte – This is the total time it takes for the first byte of data to be sent to the user by the server, or TTFB. TTFB needs to be short and sweet and has been correlated to Google search rankings. Developers can use special tools to optimize your servers for better performance, but again, the focus is about being available and helpful to the customer.
Aristotle utilizes a tool that allows website designers and marketers to check site performance for the three metrics above. If web developers focus on the performance and the output of the above metrics, then the website will have a very positive user experience. These three metrics aren’t the end-all solution; as long as the user gets what they need as soon as they want it, then the performance of your site, store, or platform is optimal for your business.
PageSpeed Insights is a tool that not only causes confusion for most website designers and marketers, but it also doesn’t fully measure user experience in the correct way. Developers should focus less on the grade they might receive and more on the overall user experience when accessing their site.
Caching: Another Misconception about Webpage Speed
When we focus too much on the test results from a source such as PageSpeed, then you may not be getting the whole picture of how your website is truly running. Many believe that their website is fast because you they make sure to test their cache. But that doesn’t work as a realistic solution to the problem at hand; the website may be slow even if the cache is tested. This leads to the overall problem of not knowing how your users and visitors experience your website or store.
Full page caching does not work as a testing method for web performance. Caches need to be complete before they can be utilized. That means that caching will not work for the first request and is a poor choice as a performance enhancement. Another important note is that caches always expire. This means that even though a page has a cache run now, the cached page will disappear from the cache – and the cached element will need to be recreated.
Here’s an example of site performance with incorrectly configured cache:
We created a blank WordPress site with default settings. Nothing fancy, and ran a pingdom speed test:
Then we enabled full page cache from nginx and did another speed test:
Pretty awssome, right? Well look what happened 1 hour later when the cache expired:
These results fluctuated even more when the CDN cache expired some of the static assets from this site. Scores got better when the test was run again after a minute or so.
Developers will recommend caching as a viable method to mark performance of the website. Their reasoning is that the full-page caching always will have a positive impact on resource reduction on the server level. However, this does not mean that full page caching will ultimately mean a better preforming website. Full page caching can be an effective tool for scaling, or if you have a web page that you don’t load new content to on a regular basis. Unfortunately, the average normal WordPress or WooCommerce sites are not designed that way.
How caching works live in action, is that full page caches only provide performance improvements for recently accessed pages (good for scalability, but limited effect on performance).
Why Caching Doesn’t Mean Improved Website Speed?
There are multiple reasons why caching is not effectively improving the speed of your website:
- The full-page cache does not work for the first request to the site
- The full-page cache contains only the pages that have recently been accessed and the older pages have expired
- Visitors and users access the site through a series of random pages, and therefore there is little chance that they will hit a cached page. The greater chance will be hitting a non-cached page.
- Site admins clear caches regularly to get their new content put on the site.
However, full-page caching may still be an effective tool for you to use as a way to make the site faster. For full-page caching to be a main performance metric, the site must have several features. These include, a largely static and rarely changing web content, not needing users to log in to the site, large traffic of the site so that the visitors hit the cached pages, and always be sure to rarely clear the cache.
The issue with these requirements to make full-page caching a feasible performance enhancer method is that they do not pertain to e-commerce or even most websites out there. The types of sites that full-page caching would be a fine option for are online magazines or newspapers, perhaps even some blogs out there, where the dynamic content of the site is offloaded to external services.
Even though you may think that despite all the evidence presented in the previous paragraphs that full-page caching is still the answer, consider this: the potential of making your website faster from caching is only applied to certain parts of the webpage. The effects of full page caching are limited to work for anonymous users on your website. It may be possible to extend the caching to other parts of the website, but that operation takes a lot of web developing and maintenance to keep up the caching. Full-page caching may seem like it is achieving something, but most of the time the method will not work.
Solutions to Capture User Performance Experience
Synthetic Monitoring is a more active type of web monitoring. In synthetic monitoring, behavioral scripts are deployed in a browser to simulate the path an end-user takes through a website. In addition, this active monitoring permits webmasters to test the website before launch. That makes it an essential tool for sites with a high volume of traffic.
New Relic has a wide set of services to measure synthetic and real user performance.
Real User Monitoring
There are solutions out there that will answer the question of how to properly measure user experience in an efficient and easy to understand manner. One such solution is known as Real User Monitoring. Real User Monitoring (RUM) is a type of performance measuring that monitors and examines every time users load a website or store. This monitoring is also known as real user measurement, real user metrics, and end-user experience monitoring.
RUM is used to understand user experience while looking at the load time of the store, website, or platform and transaction paths of what is being accessed. RUM uses a type of passive web monitoring system. This means that it relies on services that observe the system in the background constantly, namely tracking availability, functionality, and responsiveness.
RUM in the real world is best put to task when it is used to monitor stores and/or webpages to uncover issues that cannot be seen by other testing methods. An example is the constant monitoring of a blog in the background to see when and where page load times increase. Another example is a bank software system that may use RUM to spot erratic problems, such as login failures that may only occur under specific conditions.
RUM can provide you actionable insights into site performance.
Utilizing Real User Monitoring
RUM observes whether the user experience runs smooth and easily on the cloud, mobile, or web-based sites. After the observations are collected, RUM creates a performance report that make it easy to spot where there are issues in the infrastructure and/or with the user experience and how to troubleshoot them. RUM also captures live sessions and monitors the user experience across several categories. If RUM is used properly is can capture and monitor multiple important facets of data, such as which pages did the most customers visit, when did they visit them, and what parts of the webpage malfunctioned (if any).
RUM goes through the following steps in gathering data of user experience performance:
- Data capture: RUM captures details about what pages are requested, and other resources from the browser to web servers. This can capture requests from other sites.
- Sessionization: The collected data are organized into a record containing pages, components, and timing information for each visit.
- Problem Detection: Any lagging behavior such as slow response times, internal systems problems, and other failures are analyzed per visit.
- Individual Visit Reporting: The collected data are used to mimic or recreate the individual visits. You may be able to see what the user saw, depending on the website being viewed. For the most part you will just see a summary of the data.
- Reporting and Segmentation: Combined data can be used to identify page availability and performance across different browsers and user segments.
- Alerting: The system activates an alert to inform the developer that a serious issue is found.
Why should you use RUM as a performance measurement?
RUM is an excellent tool to display how page visitors are using a site or store. RUM also provides necessary performance metrics such as load time and the information of how the page performed during individual visits. RUM provides a measurement of key targets by tracking actual visits and delivering easy to understand data on actual use cases. Problems within the store, page, or platform may also be easily identified, thus leading to better prioritization of issues. Any hitches at the page level can be determined and properly fixed. Hidden problems are also eased out by RUM, making it ideal for a developer who wants their site running as seamlessly as possible.
Most people have a blog nowadays. If a blogger is interested in their site’s performance, they could use RUM to gain more views or site hits by tracking the conversion of people who access their site. RUM can also assist in making sure that the speed of the website is fast; this often leads to more visits because users like their information as quick as they can get it.
Limitations of Real User Monitoring
RUM does have a few limitations to consider when looking at the user experience performance measuring aspect. RUM cannot calculate your website in comparison to your competitor. Lack of benchmarking. RUM is unable to examine your competitor’s websites. Therefore, benchmarking is a limit with RUM. Effectiveness in pre-production settings is limited because most customers do not have as much traffic in those settings. However, it should be noted that RUM runs acceptably in pre-production settings. One last limit is that RUM may produce too much data. While the information is extensive, it can make some users feel overwhelmed with the volume of data that it presents.
You can utilize Google Analytics with some custom tweaks to get data like this.
Other Solutions Available
There are quite a few alternative methods to ensure that you are correctly and accurately calculating user performance experiences with the site. First, be sure to start tracking real web performance data rather than just testing the performance of your cached pages. Be sure to always focus on the possible reasons why the site, store, or platform may not be performing the best and check what possible performance driver tools exist.
Another solution would be to start testing your sites performance with a crawler. Test the performance of all pages on your website using a Crawler. Crawlers are a way to get a real view of how websites perform. When applying crawlers to all pages of the website you’d like to examine, this method makes it easy to discover what pages are in worse shape than others.
Tools available to utilize for your website include, Sitebulb—which has a free trial available of all features—and SEOFrog, which is an excellent resource for calculating average response times and presents data in graph form for easy breakdowns of the data. You can also get visibility into user actions with solutions like MixPanel and Crazyegg, although mixpanel requires some code changes before you can collect data.
The point of this article is that site performance matters, and there are ways to measure it correctly. Once you have the correct performance data available, you can start improving it. Stay tuned for a detailed guide about improving WooCommerce performance.