How to Cache AJAX GET Requests with Swift Performance

One area which can be a pain for performance enthusiasts is showing up-to-date recent posts in a sidebar widget or show off your popular posts in the footer. The traditional way to work around this is by using AJAX so Javascript makes a call for PHP to pull fresh data out of the MySQL database. This is very convenient but also potentially resource heavy and slow because of the entire process flow. Let’s cache those instead with Swift Performance.

Speed Benefits of Caching AJAX Get Requests Swift Performance

For this example we use WordPress Infinite Scroll – Ajax Load More plugin for lazy loading posts, single posts, pages, comments and more with Ajax powered queries. It is a great plugin, however we already know that it takes between 300-400ms for the site to display the data. That is not the plugins’ fault, it is just the nature of AJAX

Luckily we can cache this AJAX request and get it down to 50ms with Swift Performance. We will assume you already have Swift installed and configured on your site.

Here are some GTMetrix results before and after caching the AJAX requests.

Uncached AJAX Response Time

With Swift Cacheable AJAX Actions feature DISABLED took 431 ms.

Cached AJAX Response Time

With Swift Cacheable AJAX Actions feature ENABLED took 55 ms.

That is a pretty amazing increase in performance by caching the AJAX request with Swift Performance.

How to Cache AJAX GET Requests with Swift Performance Pro.

Feature description:

Cacheable AJAX Actions – With this option you can cache resource-intensive AJAX requests (eg AJAX search). You should specify the action names here. You can also set cache expiry time for AJAX requests in seconds. For example you can use it to cache custom ajax search or cache WP datatables ajax responses. It´s advanced stuff. If you don´t know how to use this feature, it`s better not to use it.

AJAX Cache Expiry Time – Cache expiry time for AJAX requests in seconds.

You find this feature in Settings->Caching->General of Swift Performance. If AJAX calls are resource-intensive you can cache those with Cacheable AJAX Actions.

So, to achieve this, you first need to find the Ajax Action as Ajax always has an action. Load the page in GTMetrix and open the Waterfall tab, look for the admin-ajax.php and open that tab.

Just click on the Params tab and note the action, in this example: alm_get_posts

Then return to your WordPress site backend, Swift Settings and look for Cacheable AJAX Actions in Settings->Caching->General: set alm_get_posts there. That`s all.

 

Verify if Swift is Caching the AJAX GET Requests

Use Curl or Load the page in GTMetrix and open the Waterfall tab, look for the admin-ajax.php, open that tab Headers. Cache response header should reporting a HIT (swift-performance – HIT).

Now you have successfully cached WordPress admin-ajax GET requests with Swift Performance and your AJAXified content will load faster while PHP and MySQL get a much deserved rest.

Brotli Compression

Most servers use gzip to compress text files before they are sent across the internet. This makes the files smaller, and then the web browser will automatically unzip them. The lose in the zipping and unzipping time is more than made up for in performance gains – at least for text files. This is because text files are pretty inefficient in terms of space used.

Brotli is a generic-purpose lossless compression algorithm that compresses data using a combination of a modern variant of the LZ77 algorithm, Huffman coding and 2nd order context modeling, with a compression ratio comparable to the best currently available general-purpose compression methods. It is similar in speed with deflate but offers more dense compression. Now, while that sounds impressive, do remember that most of the bandwidth hogs on web pages are media, which should not be gzipped as they are already compressed, so if you have gzip enabled fro text files, then there are small gains to be got from shifting to Brotli, but don’t expect massive gains unless you are a text only site. Still every little counts and, if it’s easy enough to install, then why not.

The only downside I see with Brotli compression is, most popular web servers have not incorporated it as part of their features.
That means, to enable Brotli compression, you need to check first if your hosting provider allows it or not.

Prerequisites
I’m not sure if there is a technical reason behind this, but all the browsers I tested with require HTTPS in order to enable Brotli support.
• Apache/NGINX installed.
• HTTPS enabled.
• Access to your Apache/NGINX installation (no shared hosting)
• Brotli binary installed

Installing Brotli

apt-get install brotli

Setting up on Apache

Apache has supported brotli since version 2.4.26 by way of the mod_brotli module.
However, I can’t find any information on this so we are installing this module by kjdev

Install the Module

git clone --depth=1 --recursive https://github.com/kjdev/apache-mod-brotli.git
cd apache-mod-brotli
./autogen.sh
./configure
make
install -D .libs/mod_brotli.so /usr/lib/apache2/modules/mod_brotli.so -m 644
cd /etc/apache2/mods-available
echo "LoadModule brotli_module /usr/lib/apache2/modules/mod_brotli.so" > brotli.load

 

This has added the .load file to the mods available. We need to create an accompanying config file called brotli.conf, adding:

<IfModule brotli_module>
  BrotliCompressionLevel 10
  BrotliWindowSize 22
  AddOutputFilterByType BROTLI text/html text/plain text/css application/x-javascript
<IfModule brotli_module>

 

Enable the module

a2enmod brotli
service apache2 restart

 

You should now see in the response header that the page is compressed with brotli (br):

Setting up on Nginx

Google has released a Nginx Brotli module
Download the module

cd /usr/local/src
git clone https://github.com/google/ngx_brotli.git
cd ngx_brotli
git submodule update --init --recursive

 

Rebuild Nginx with our new module
You should run nginx -V to get your config string and add:

cd /opt/nginx-1.13.1/  (or your own path)
./configure YOUR CONFIG STRING --add-module=/usr/local/src/ngx_brotli
make
make install

 

Finally, add to your nginx.conf file

http {
    brotli on;
    brotli_static on;
}

 

In conclusion, the setup for both Apache and Nginx is pretty painless. If the browser does not support brotli it can always fallback to the ever faithful gzip.

Does your browser support Brotli?
Browsers which support Brotli send ‘br’ along with ‘gzip’ in accept-encoding request header. If Brotli is enabled succesful on your web server, you will get response in Brotli compressed format.

HTTP/2 200
server: nginx
date: Thu, 11 Apr 2019 21:01:27 GMT
content-type: text/html
content-length: 32395
last-modified: Thu, 04 Apr 2019 13:49:47 GMT
etag: "3c420-585b4a4af8fe6-br"
accept-ranges: bytes
cache-control: max-age=0
expires: Thu, 11 Apr 2019 21:01:27 GMT
vary: Accept-Encoding,User-Agent
content-encoding: br
strict-transport-security: max-age=31536000

You may also check here, if your server support Brotli.

In combiniation with Swift, you may disable GZIP in Settings->Caching->General and add these rules in Settings->General->Tweaks: Custom Htaccess 

AddOutputFilterByType BROTLI_COMPRESS text/plain text/css text/html application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript
SetOutputFilter BROTLI_COMPRESS
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-brotli

 

If you are unsure of how to enable Brotli on your server, then hopefully this helps!

CDN for more speed, performance and security

CDN is short for Content Delivery Network which is a network of servers that deliver cached static content from websites to users based on the geographic location of the user.

You can/must use CDN on top of having a web hosting account. CDN helps speed up things, but doesn’t replace a web hosting account.

Akamai and Gomez.com explored the correlation between website load times and visitor activity. Here are just some of the facts they found:

  • 47% of people expect websites to load within 2 seconds.
  • 40% of people consider 3 seconds too long to wait for a website to load.
  • If a page were to delay in loading by just one second, it could mean a difference in 7% in conversions.

For websites with a lot of traffic and/or with a large global audience, this is a huge deal. Those few seconds you lose in load time (and in potentially converted business) are extremely valuable.

Akamai predicts that within two years 55% of global web traffic will pass through CDNs.

Cloudflare with AkamaiFastlyHighwindsLevel3 and EdgeCast is part of the Google Cloud Platform CDN Interconnect program. Cloudflare is a content delivery network (CDN) and acts between your website and your visitors.

CDN providers are usually using a cookiless unique subdomain for every site. These providers usually use pull technology, so they can proxy the content for the first request, and serve the following requests from the cached version from their server.

Cloudflare will handle the traffic at DNS level, which means it won’t change the host for the static content. Because of this, it can also improve security. Whenever a user visits your site, Cloudflare will first check for any indicators of malicious intent. Once Cloudflare verifies the visit isn’t motivated by nefarious purposes, it serves up data from the data center that’s geographically closest to your visitor

That provides your web security and much faster website load speeds.

 

Why HTTP2

The Hyper Text Transfer Protocol (HTTP) enables the retrieval of network connected resources available across the cyber world and has evolved through the decades to deliver fast, secure and rich medium for digital communication.

HTTP was proposed by Tim Berners-Lee. Tim Berners-Lee is pioneer of the World Wide Web who designed the application protocol to perform high-level data communication functions between Web-servers and clients.

The first documented version of HTTP was released in 1991 as HTTP 0.9, which later led to the official introduction and recognition of HTTP1.0 in 1996. HTTP1.1 followed in 1997 and has since received little iterative improvements.

HTTP/2 will make our applications faster, simpler, and more robust. HTTP/2 opens up a number of entirely new opportunities to optimize our applications and improve performance.

The primary goals for HTTP/2 are to reduce latency by enabling full request and response multiplexing, minimize protocol and add support for request prioritization and server push.

HTTP2 provides multiplexing – ability to get multiple interactions into a single TCP connection, similar to what SPDY gave us; header compression – reduces the redundancy of sending the same headers repeatedly; server push – handles some of the issues of resource dependencies so the server can push them to you knowing you’ll need them and resource prioritization – prioritizing delivery based on type/content using weights and dependencies.

HTTP/2 on top provides that the web is more situational than ever.

From idea to project

Although it is common knowledge that the programers are reluctant to go public and are the happiest when we let them to work, we have succeeded in luring Peter Molnar for one quick interview, the chief and responsible for the idea and development of the Swift Plugin.

How the story with Swift started? How did the idea come?
We started to develop Fevr theme and I started to optimize it (it also has a performance module, that was the very first version of Swift Performance). I wanted to create critical CSS on the fly to optimize CSS delivery, but I realized the process will be too slow, so I will need to add caching to be able to publish it as a standalone plugin.

What was the main purpose of this plugin development?
I always liked new challenges, I wanted to make the best cache plugin.

What is your previous experience in this area
I made some WordPress sites where the speed was very important, so I started to learn everything about this topic. I also had some experience in optimization when we were working on Fevr.

What are the main differences between Swift and other similar plugins?
I love to find new aspects, adding unique features like Auto-generated critical CSS, Async Javascript execution, Ajaxify, etc.

How long have you been working on the development of Swift?
We started to work on it in 2016 December, 1.0 was released on 8. April. 2017.

How much progress has been made from day one?
A lot. Current version is more stable, and much more compatible with other WordPress products than 1.0 was, and of course, we also added tons of new features since the beginning (like Smart Youtube embed, Async JS execute, Plugin organizer, WooCommerce specific features, etc).

What are your plans with Swift in the future?
I have to point out today that Swift works thx to a whole team of people without which this plugin would certainly not be so fast and well-developed. With a good team, the users are also needed, who will trust your product, especially at the beginning. Today we have formal and informal members, and they all greatly help to be even bigger. Today we can praise Swift has taken an important place on the WP accelerator market.

Swift is not just an ordinary Caching plugin but an all in one optimization plugin that replaces many other speed up plugins.
However, we also plan many other new and exciting projects: to find new opportunities to speed up WordPress and also make it easier to use even for nontechnical users – that is our first step forward.  So stay tuned and follow us! 🙂

How many users currently have Swift?
Currently, we have more than 10 000 Lite users and more than 2500 active subscriptions. Fortunately, we are still growing.

Image Optimization

„A picture is worth a thousand words”

Are you dreaming of easily optimize images in WordPress for better speed and performance? Swift Performance can make your wish come true.

Images are larger in size and they take longer to load and can slow down your website. Is there anything more annoying that waiting for a website to load for website visitors?

According to HTTP Archive, on an average, around 64% of a website’s weight is comprised of images.

As per Gomez and akamai.com, half of the users love sites which load in less than 2 seconds. If the page takes more than 3 seconds to load almost 40% of visitors tend to leave that site, thus increasing the bounce rate. Image optimization is the only solution for this problem.

Images make your content more attractive and interactive, they are important for your web, but also you must think about optimizing of all of your images on your web.

Sounds boring, isnt’t it? That’s why Swift Performance gives you optimization without any of your effort, except that you need to have Swift Performance.

Don’t worry about the quality

Optimizing web images is a process of delivering the high-quality images in the right format, size, resolution and dimension while keeping the smallest possible size. That is what we do – automatically compressing images and using the smaller sized version on your website.

original

optimized

You can set the desired image quality, even using lossless optimization to keep good quality images with reduced size.

Don’t worry about CPU usage

Swift Performance is using our API server to optimize images, the optimization process won’t use extra resources on your server.

The image optimizer is unlimited, there is no any additional costs for image optimization.

Result is – faster load, better SEO ranking, boost conversions and at the end and most important image optimization provides you happy customers.

Your Swift Team

Why is cache so important?

Cache is the place where computer stores recently used information and when you think about optimizing your website, never underestimate the role of caching in WordPress.

Website caching makes websites extremely fast. That also means better SEO scores and increased user satisfaction, better conversions and at the end increased income with lower costs.

In general caching keeps accessed objects, images and data closer to where you need them, speeding up access to websites you hit often.

The more cache, the less time the computer spends accessing slower main memory. Results are in programs that may run faster and it leads to greater performance of your website.

There are 2 basic type of cache: server side and client side cache.

In WordPress you are not updating it everyday, after every post or page. Server side caching creates static copies of your post or page, and serves that to visitors. This way, the back and forth queries to and from the database can be avoided, reducing the server load.

On the client side we can tell to the browser which content should it keep for longer time and which not. Static contents like images, fonts, CSS and Javascript files should be cached even for a year. It is not just speeding up the site, but also decrease the network traffic, which can be an additional benefit for mobile users.

The benefits of caching

There are various benefits of caching in WordPress, such as reducing the load on your hosting server, enhancing the speed and performance of your website and decreasing the network traffic. It provides you faster websites, but not only faster while loading but also getting a favorable rank with search engines. Least but not last – catch provides better user experience overall.

Swift Performance plugin can help you to have all that in one.

So, what do you waiting for?

Proxy caching with Cloudflare

What is proxy caching

Speed is important. Even if you have optimized your site already, the load times can vary based on the physical location. You may also have a good server, but you can still improve TTFB and page load time with proxy caching.

Many sites are using Cloudflare as a CDN, however you can also use it to cache your pages, and let Cloudflare serve them to your visitors. It means, that on the first visit Cloudflare will cache the page content as well, so following requests won’t even hit your server. Of course if you are using Cloudflare for page caching you will need to enable Auto Purge for Cloudflare.

NOTE: only Cloudflare Business and Enterprise packages let you to bypass the cache based on cookies, however in most cases you can also use this feature with their free plan, but your logged in users will get the same cached pages. Of course My Account, Cart, Checkout (and any excluded) pages won’t be cached.

Let’s see how can Cloudflare caching can improve the speed of an already optimized site.

Environment:
Siteground StartUp Hosting (Bulgaria)
WordPress 5.0.3
OceanWP + Elementor (Business demo content installed)

Configuration

Swift Performance

Enable Auto Purge and set API credentials to let Swift Performance clear cache if it is necessary

Also enable Proxy Cache and set the Proxy Cache Maxage to 1 year (30879000)

Cloudflare

Add a Page rule in Cloudflare to cache everything

Testing

We will test the site loading speed with GT Metrix from 2 locations: Vancouver, Canada and Hong Kong, China. We will choose Chrome desktop browser for the tests.

First test

Swift Performance is inactive, Cloudflare standard caching enabled. Even if Cloudflare is active, it caches only static content, not the page itself.

Location Fully loaded time Onload Contentful paint Test link
Vancouver 1.5s 1.5s 1.2s
Hong Kong 1.9s 1.8s 1.8s

With Swift Performance

We activated Swift Performance and configured it. We already improved the speed, but is it enough? Not for us…

Location Fully loaded time Onload Contentful paint Test link
Vancouver 1.3s 1.2s 0.9s
Hong Kong 1.6s 1.4s 1.3s

Proxy cache enabled

Lets see what happens if we let Cloudflare cache the page itself.

Location Fully loaded time Onload Contentful paint Test link
Vancouver 0.7s 0.6s 286ms
Hong Kong 0.5s 286ms 224ms

Conclusion #1

The most important factor for user experience is Contentful paint time. We decreased it to 2-300ms, which is almost instant load. That means when the user clicks your link in Google results, the page will be shown instantly on their device.

But there is an other important aspect: load time on 3G

Testing on 3G

We will test the site loading speed with GT Metrix from 2 locations: Vancouver, Canada and Hong Kong, China. We will choose Chrome desktop browser for the tests again, but now we limit the connection speed to 3G

First test

Swift Performance is inactive, Cloudflare standard caching enabled. Even if Cloudflare is active, it caches only static content, not the page itself.

Location Fully loaded time Onload Contentful paint Test link
Vancouver 10.7s 9.8s 4.2s
Hong Kong 12.5s 11.2s 7.0s

With Swift Performance

We activated Swift Performance and configured it. Lets see if it is good enough this time…

Location Fully loaded time Onload Contentful paint Test link
Vancouver 5.8s 5.6s 3.3s
Hong Kong 5.6s 5.4s 3.3s

Proxy cache enabled

Lets see what happens if we let Cloudflare to cache the page itself.

Location Fully loaded time Onload Contentful paint Test link
Vancouver 4.4s 4.2s 2.2
Hong Kong 4.4s 4.2 2.1s

Conclusion #2

We decreased the rendering time (contentful paint) to 2.2s. If you imagine yourself with your phone in your hand, you just clicked to a link somewhere, and you need to wait 5-7s to see the content, or only ~2s you can imagine the difference 🙂

Speed up benefits

47% of people expect your site to load in less than 2 seconds and 40% will abandon it entirely if it takes longer than 3 seconds.

Is that good reason why is important to speed up your site with Swift Performance plugin? Swift plugin provide you so many speed up benefits, but today we will talk about why speed is crucial.

Put yourself in the shoes of the user of your website. Has he time to wait for the information? No and he expects and demands fast loading content on your website.

First impression that he will have is not just the visual side of your site, but the speed. Users want to get what they want immediately, so give it ti them fast with Swift plugin.

85% of internet users expect a mobile site to load as fast or faster than on their desktop.
If not, 40% of people will abandon your site if it they will wait longer than 3 seconds to load.

So, if 200,000 people visit your site every month, you can lose 80,000 people (customers, clients, buyers).

According to a DoubleClick study, “53% of mobile site visits are abandoned if pages take longer than 3 seconds to load”, even though the average loading time is 19 seconds over a standard 3G connection. The study revealed faster websites have higher revenue. Mobile sites loading in up to 5 seconds earn up to 2x more mobile ad revenue than those loading in 19 seconds.

Speed creates trust! Slow sites are mostly suffering from disadvantages of trust. And that’s for a reason. Slow website can hurt your brand in the future, so think in advance.

In 2010 Google announced that they do take website load speed into account when ranking websites, so website speed affects your Google rank.

When you sum up – with Swift Performance you will speed up you web, improve your SEO, achieve better conversion, spend less time, but also less money, achieve fewer intercompatible issues, lowering site maintenance costs, and spending on various plugins. Do you need more reasons?

Stay tuned, be fast and work smart!

Statistics are from Kissmetrics.com