Questo contenuto è disponibile in Italiano
It goes without saying-but not for everyone, it seems! – that a site’s speed is a key requirement foracquiring and retaining visitors(read also “buyers”).
WP Rocket is a widely used commercial solution for managing part of the optimization parameters of a WordPress site.
In this article – the first in a series – we will focus on the basic functionality of the plugin, initiated when it is first activated.
We can distinguish them into automatic (not visible in configuration) and default (easily manageable).
It is highly recommended that you inquire about the integration between WP Rocket and your server!
Take the case of Kinsta, which we use extensively: since version 3.0 of WP Rocket, GZIP compression and page caching are automatically disabled on plugins and managed by the server.
Features such as cache duration may be irrelevant. Others, such as cache preloading, may even be discouraged!
Specifically, please refer to this update (dated January 2022).
We do not rule out addressing this topic in one of the next articles.
1 – Automatic features
When WP Rocket is activated, some features are started automatically, without being visible in configuration.
The most important ones are:
- Pagecaches,
- Configuring browser-sidecache deadlines,
- GZIP compression.
The complete list is given in this article.
Let us look in detail at the 3 mentioned.
1.1 – Page Cache
Trivially, it consists of storing the code of a page.
When first viewed by any user (or when being preloading, as we shall see), WordPress generates the HTML code. This will be available for all subsequent views, by any user, until it expires.
It goes without saying that the use of static HTML results in reduced stress on the server (both PHP and MySQL sides) and increased speed.
The cache is totally or partially cleared:
- At its own deadline;
- To publishing/updating a piece of content (along with home and archive pages of the taxonomies to which the page belongs);
- By changing the settings of WP Rocket.
1.2 – Configuring browser-side cache deadlines
The browser cache is the classic storage of files in the browser of the user. It is normally always active (unless inhibited) for any static content on the network.
Site content may need to be updated at different cadences.
For example, the company logo will not be changed frequently. It may be stored on the user’s browser, with expiration set at one week. If the file changes, it would take a maximum of one week to be downloaded again.
This is where WP Rocket comes in, which adjusts expiration times by optimizing them based on content. It should be mentioned that configuration on Apache, being able to take advantage of .htaccess editing, will be more complete. It is also possible to take manual action to achieve the same results on NGINX.
Therefore, in case the user visits several pages, or visits the same page several times, it will reduce bandwidth, HTTP requests and increase speed.
Browser caching only affects content served by the domain; NOT third-party content(Google, Facebook, etc.).
1.3 – GZIP Compression
GZIP is a compression format that can be applied to network-served content (pages, style sheets, JavaScript), thus reducing transfer times.
GZIP compression can only be applied to content served by the domain; not to third-party content (Google, Facebook, etc.).
WP Rocket enables GZIP compression only on Apache, by modification of .htaccess. For NGINX and IIS, you will need to contact the vendor directly.
2 – Default features
Some features, which are basically active, can be managed in configuration.
These include:
- Mobile cache;
- Cache expiration of 10 hours;
- Cache preloading;
- Preloading of links;
- API Activity Reduction Heartbeat.
Let’s look at them in a roundup.
2.1 – Mobile Cache
Simply, it is the application of the cache on “mobile” devices, where by that term WP Rocket exclusively identifies phones.
As a rule, it is always recommended to enable it, as long as the site is responsive.
2.2 – Cache expiration
The 10-hour duration of the cache of page is a starting point.
In the face of frequent updates, it may be reasonable to lower the time, acting gradually.
2.3 – Cache preloading
The preloading of the page cache results in it being generated independently by WP Rocket, regardless of user interactions.
If preloading is turned off, each page will require at least one visit to be cached.
Therefore, the first user will view it slower and slower.
2.4 – Link Preloading
The preloading of links improves the perceived interaction time by the user browsing the site.
If the user clicks or scrolls on a link for more than 100ms, the HTML content of the related page will be preloaded in the background.
Feature active only on Chrome and Chromium browsers.
The option does not result in improvements in PageSpeed, Pingdom, GT Metrix scores, but it does provide smoother navigation.
2.5 – Reducing the activity of the Heartbeat API.
THEAPI Heartbeat is a WordPress default.
It provides a connection for real-time information transfer between server e browser. For example, it is involved in automatic saves, administrator notifications, blocking of posts during editing by a user, and more.
In an interval on the order of seconds, the API launches a series of commands by exploiting the admin-ajax.php file for external communication.
Although critical, it can lead to high CPU utilization.
WP Rocket basic reduces its activity by limiting its startup every 2 minutes(Reduce activity).
3 – Two words about user cache
This is a basic disabled feature, but it deserves mention.
It consists of creating a separate cache for each user accessing the site.
The option has no effect on external visitors.
It is therefore useful with sites that integrate restricted areas.
4 – It is only the beginning
We have addressed only the basic functionality of WP Rocket, without going into too much detail.
We will soon address aspects such as media, preloading, external content, and more.
Stay tuned in the coming weeks; new articles are coming soon!
Questo contenuto è disponibile in Italiano
