IMPROVING PERFORMANCE IN DRUPAL WITH QUICKLINK 2.0

I could have sworn I had done a post talking about the Quicklink module when it came out in 2019, but I couldn't find it.

Today's article is about the post recently made by the Lullabot team (the maintainers of the module): https://www.lullabot.com/articles/improve-your-sites-experience-quickli…

Does it improve performance?

This module, in a simplified form, what it does is to preheat the caches.

In the first version of the module, the way it worked had serious problems and negatively affected the performance of the server.

It was a module that I did not recommend, especially since a client hired me for Drupal performance analysis and where I detected that the main problem was the Quicklink + Webform module.

To understand why I do NOT recommend it for any website, and why it is not a "just install and do not configure" module, I have to explain a couple of things first.

What does it do and how does it work?

For example, when a user enters the Home page of your website this module is responsible for asynchronously preloading the pages that have the links of the Home page.

As the user scrolls through the home page, requests will be made to the links of your domain. This means that only the links that the user currently sees on the screen are preloaded.

Let's suppose you have a typical website in your home page where you have a menu in the header with four links (the typical "About Us", "Services", "Contact", "Prices", ...) and below the menu, you have a text with some other links, a couple of banners, a list of categories and at the bottom of the page you have a list with the latest blog articles.

The Quicklink module will load the links from top to bottom. So let's assume that without scrolling what the user sees on his screen is the menu, the text and a couple of banners. All these links will be pre-loaded without the user noticing it, and then the rest of the links will be pre-loaded when the user scrolls and the list of categories or the list of blog articles appear on the screen.

So far this implementation seems like a good idea, and theoretically, you should notice an increase in loading speed, or at least that's what the user should notice by having the caches pre-heated (or pre-loaded pages or whatever you want to call it).

Real-life case

On many websites, there is at least one page that is a black hole when it comes to performance. Typical ones are forms with some anti-captcha system that disable caches (for example the registration form or contact pages implemented with the webform module) or listings made with views that for some reason should not be cached (search_api + facets, listings with random order, or listings that are unique for each user).

In short, Quicklink loads pages that are black holes in terms of performance. And the biggest problem is that they are usually pages that are rarely accessed by users, but that Quicklink makes them load all the time.

Let's imagine that we have 1000 visits to our home page, and out of all those users, only 10 go to the contact page. Initially, only those 10 people will have to load the contact form (webform + captcha) and therefore we have only invalidated the caches of those 10 pages. For the rest of the 990 visits, only 500 are still browsing the web, the remainder is only people who see the Home page and bounce when they stop browsing because they are not interested in what they see.

At this point, we have 1000 visits to the home page + 500 visits to other pages + 10 visits without cache.

Now let's suppose we install Quicklink. By default, we would have 1000 visits multiplied by the number of links visible on the user's screen. To make round numbers let's assume that there are only 10 visible links (among which we have the contact page).

Then we have 1000 X 10 = 10,000 requests to the server, of which 1000 are to the contact page which invalidates the caches because it has a captcha to avoid Spambots.

And add to that if we have 500 users who end up going to another page then we have 500 X 10 = 5000.

Comparison:

• Without Quicklink: 1510 requests to the server. Only 10 slow requests.
• With Quicklink: 10,000 + 5000 + 00 = 15,010 requests of which 1000+500 are useless requests to the contact page.

I think it is clear that we are saturating the server. And if it is not clear to you then I assure you that it is noticeable in the CPU and that it can knock down the web when you have many visits, since it is a multiplying effect.

For that reason, I do not recommend installing the Quicklink module unless you know what you are doing.

And by the way, if you have a website with several languages then these numbers are worse since on all pages you will have links to several URLs (their translations) and normal users do not change the language if they have come from Google.

Who can Quicklink be useful for?

Either for small websites with very few visits or for websites that have a team that knows very well what they do and which pages to exclude.

Quicklink is not a magic solution to make your website go faster. On the contrary, it can negatively affect the server and slow down the whole system.

Configurations to keep in mind

All of the above is if you don't configure the module correctly, or if you don't use v2.

As far as I can see, in the recently released v2 you can configure which links you want to ignore so they are not preloaded.

• You can ignore paths, for example "/contact".
• Or ignore CSS selectors, for example, to ignore all links in the header or footer menu or the language selector.

Also in V2, you can now set a limit and a timeout. And this is very useful to avoid overloading the server with many useless requests.

In any case, Quicklink is a powerful module that in certain projects can be very useful. But it is not a module that can be recommended to inexperienced people to "improve performance magically and effortlessly".