The Correlation Between Performance and User Experience

I used to work as product manager for a company that developed a set of tools for recording website visitors’ actions (aka journeys) while collecting metrics on the web page usability. Companies often implemented the software on business-critical pages, like the shopping cart on an e-commerce site, or any page that had a high likelihood of driving a conversion - from user to customer. Soon after implementing, companies were able to watch recordings, analyze reports (e.g. heatmaps), and even discover faults in the web pages. This allowed them to then make modifications, improve the user experience, and in many cases, get higher conversion rates.

Image 1: Web page usability heatmap, red color signifies more end-user attention and focus.

Understanding and improving the way users interact with your application is just one aspect of the user experience. The other aspect is critical pages’ performance, specifically load and response time. Most customers were familiar with Akamai’s research, which showed that on conversion pages “a one SECOND delay in page response can result in a 7% REDUCTION in conversion”. In other words, if the performance is bad, users will drift away right to the hands of the competition. Let's play with some numbers here:

An e-commerce site is making $100,000 per day. A one-second page delay could potentially cost $2.5 million in lost sales every year.

Interesting, right? Well, perhaps not all online shops make that much money yearly, but still, everyone wants their users to have a good experience. In that context, ask yourself:

• Do we measure our apps’ pages response time?
• How does it change in peak hours?
• Do we have an SLA for performance?
• Do we meet our SLA?
• What actions do we take to improve our application performance?

These are tough questions to answer. Maybe you have some of the answers, but isn't there always room for improvement?

Of course, there’s always the possibility of scaling up/out, but it can be costly and sometimes even doesn’t really pay off. What else can you do, other than re-write your code? That’s right - use caching wisely.

Zend Server provides three layers of caching to help improve your application performance: OPCache for byte-code caching, data/element caching using Zend Data Cache, and full-page caching using Zend Page Cache.

Byte-Code Caching With OPcache

Zend OPcache performs byte-code optimization and caching. It speeds up PHP applications by eliminating the process of reading scripts from disk and compiling them, often resulting in performance gains of 2x – 3x. Zend OPcache runs automatically after installing your application on top of Zend Server. OPcache is a Zend contribution to the open source PHP.

Zend Data Cache

Zend Data Cache is a set of API functions enabling a developer to store and manage data items (PHP strings, arrays, and other data), in addition to, outputting elements to either disk-based cache or shared memory cache. Data Cache speeds up the application response time by avoiding unnecessary and time-consuming data processing. The API is easy-to-use on existing code, and in many cases, a developer can skip existing code sections by simply wrapping them with caching APIs.

Read more about Data Cache.

There are other good data caching alternative tools such as the popular Memcached or Redis. Nevertheless, there are advantages to using Zend Data Cache:

1. Works out of the box, no need for setup or usage of dedicated servers
2. It's fast – saves the network time (connecting to another server), as it uses local memory or filesystem
3. Supplies immediate feedback and statistics on the cache utilization

One of the main challenges is to understand how useful and fine-tuned the caching really is. In most cases it's done only by testing the end-result, i.e. did we improve the app response time?

Zend Server Data Cache Pulse takes this even further. The minute you start using the cache you’re getting feedback on how much faster your application really is, what is the rate of the cache hits, and how much time was saved in server processing. Moreover, you can see how this is measured over time. 

Image 2: Zend Server Data Cache Pulse to highlight the caching utilization efficiency.

Pulse helps you fine-tune and improve the caching, based on live and historical data. Some examples:

• Low percentage of requests that use the cache may indicate that you aren’t using caching in the right places
• Low hit ratio can indicate that you need to re-evaluate the ‘time to live (TTL)’ attribute, as cached pages are invalidated too quickly, which results in cache misses. You may want to consider increasing TTL and revisit Pulse later to analyze results
• Add/remove some caching in different code segments and revisit Pulse to get feedback on the change effect
• Examine the average time per request before and after using the cache. If no major improvement is evident (i.e. low % faster), it may hint that you invested time in caching where in fact it had a minimal impact

And much more. Makes sense so far? OK, now let's take caching even one step further.

Full Page Caching With Zend Page Cache

Zend Page Cache allows caching of entire PHP web pages, or more correctly put, entire HTTP responses sent out from PHP. Page Cache dramatically improves the performance of pages on web applications (sometimes running as high as 10x, 20x, and even 100x times faster), simply by fetching the page from cache rather than sending the request to PHP for processing. Page Cache has the added benefit of not requiring any code changes, and it can be set up from the Zend Server UI, with an elaborate system of caching rules that can be based on request parameters and user session data.

See an example in Image 3 below, rules are defined per app. Note that I have my Wordpress app deployed, with 2 rules attached to it: wordpress1 and www12.

Image 3: Zend Server Page Cache – rules management, two active rules for Wordpress application

The rules are active which means that if a client request comes in and matches the rule, it will be served by the cache. Let’s take a dive into how wordpress1 rule is defined, see Image 4:

Image 4: Zend Server Page Cache – rule configuration.

The rule definition is a combination on a set of conditions on the URL, RegEx in this case, and its request parameters, in this example on the _GET. Very easy to configure and very flexible.

See more information about Zend Page Cache. Once you have Zend Page Cache rules defined and active, Pulse supplies immediate and over-time feedback on the caching utilization. See Image 5 below: 

Image 5: Zend Server Page Cache Pulse to highlight the Page Cache utilization efficiency.

How to use Pulse to improve your page caching?

The metrics and statistics are similar to the ones presented in Data Cache Pulse, as I described earlier. Fine tune the rules conditions, the cache duration time, and see how this affects your system over time via Pulse.

Summary

As the title insinuates, I do believe that application performance and response time are an integral part of the overall user experience. In this short blog post, I took you on a short journey to encourage you to learn more about Zend Server caching for improving app performance.

How to start? Try Zend Server, deploy your PHP application code on to it and start experimenting with the caching capabilities. Use our online documentation to help you kick-start… and make your users happier!

START FREE TRIAL

Additional Resources

• 101 Guide: Developing Web Applications with PHP
• Blog: Why You Should Use Asynchronous PHP
• Blog: What's New in PHP 7.4