I mostly build websites using ReactJS, VueJS, and other static site generators after that. It was fun. I’ve full control over everything. When I deploy it, I use Netlify or similar static hosting services, and after updating content, I simply push it to GitHub. Within a few seconds, my site is live on different edge servers all around the world. CDN will cache all pages and static files. I don’t have to worry about minification, caching, image optimization etc. All are just a toggle way. I loved the experience!

I came back to WordPress for creating a blog about development. Yes, static site generators can do it. But I don’t want to reinvent the wheel, and I’m already a big fan of WordPress.

Coming back from static sites, optimizing WordPress is cumbersome. When I left WordPress year again, I was using W3 Total Cache!

Glad to see that there are new cache plugins in the market, like WP Rocket, LiteSpeed cache, Swift Performance etc. All are great, but configuring them is still painful, and the performance is still nowhere near static sites.

When I came back to WordPress for my blog, I asked one of the most expensive hosting providers: “Hey, I’ve traffic from the US and India, my server is in the US, so TTFB to India is pretty high”.

They replied, “there will be network latency since your WordPress site is in the US server.”

I felt something wrong. A lot of updates have happened in the Cloud technologies and seems like WordPress still lags behind.

We need a complete solution that can perform like static sites, without leaving the advantages of WordPress. It should be easy to configure too. Not like W3 Total Cache!

Why not a few more Flying * plugins

When I started building a complete solution called FlyingPress, a few of them asked “why not create more small plugins as you did before, that does one functionality well, as modules. So we can choose accordingly…”

A more number of plugins creates more conflicts. If you’re in our Facebook group, you might see posts every day where one of my plugins conflicted with some other cache plugin.

For example, when using Flying Images and Flying Scripts together, we have to parse the HTML twice, which is slightly resource intensive. If it’s a single plugin that does both of them, we’ve to parse HTML only once.

Another example, when you’ve Cache Enabler plugin activated, it starts capturing HTML before Flying Scripts (since ‘C’ starts before ‘F’ in plugins order). So it creates conflicts!

We need a single solution that will take care of everything, without creating conflicts, without eating too many resources, without needing a speed optimization expert.

What is FlyingPress

FlyingPress is an all in one solution to WordPress sites that take care of everything. From page caching, CDN to image optimization.

Any non-techie should be able to create super-fast WordPress sites without going to too many tutorials or multiple plugins for speed optimization.

It should automate all possible optimizations so that users don’t have many headaches.

How FlyingPress Optimize for Core Web Vitals

FlyingPress from the ground up was for a better user experience. We entirely wrote critical css generation and other libraries from scratch to get the best performance.

Both WP Rocket and LiteSpeed cache generate critical css. But I was never happy with their results.

Here is the comparison of core web vital metrics in my blog (wpspeedmatters.com) using different cache plugins:

WP Rocket:

LiteSpeed Cache:

FlyingPress:

If you carefully look at the screenshots generated, you’ll notice a few things:

• No layout shifts – As you can see in the screenshots, FlyingPress from the second frame itself rendered with any layout shifts. Avoiding such layout shifts helps in reducing Cumulative Layout Shifts.
• Fast rendering – While WP Rocket and LiteSpeed cache displayed the blog post imagine 6th frame, FlyingPress showed it from the second frame itself, without even need of placeholder. FlyingPress uses several techniques like preloading above fold images, exclude above fold images from lazy loading, use native lazy load, our own super-fast JS lazy load lib etc. All of such optimizations helps in reducing First Contentful Paint and Largest Contentful paint.

FlyingCDN – Optimizations on the fly!

We already offload 90% of the optimizations externally. By enabling FlyingCDN, you can offload CSS/JS minify and image optimization to CDN.

Here are some of the features:

Cloudflare vs FlyingCDN

Cloudflare is a CDN + proxy. FlyingCDN is just a CDN. So FlyingCDN is not an alternative to Cloudflare. You can use Cloudflare along with FlyingCDN.

FlyingCDN provides many features that are currently not available in Cloudflare or are very costly. 

One example is geo-replication. It will replicate files across different regions so that there will be very low latency even for uncached files.

Here is a comparison of FlyingCDN and Cloudflare features:

	Cloudflare	FlyingCDN
Bandwidth pricing	Free	$3/100GB
Geo-replication
Nearest PoP routing	Business plan ($200/m)
Image compression	Pro plan ($20/m)
WebP conversion	Pro plan ($20/m)
Resized images for mobile	Business plan ($200/m)

Why no Unlimited plan or LTD

Many of the paid plugins in the WordPress ecosystem provide an unlimited plan and sometimes LTD (lifetime deals) too.

I’m not against unlimited plans or LTD. It works great for some products, and I’ve even run LTD my previous startup.

However, it’s not possible in FlyingPress.

As I’ve mentioned before, FlyingPress is not just a plugin. We do many resource-intensive tasks, like removing unused css at our Google Cloud server cluster. So our server costs are pretty high. Unlimited plans or LTD is too risky.

We also wanted to prevent abuse by using the same account by multiple persons.

Similar case for LTD, it helps us to make quick money. But will put the business at risk in the long term. I want FlyingPress to be a sustainable business.

More than 100 websites? Contact us for custom pricing.

We’re not stopping here.

We’re still not close by the goal of delivering HTML pages from edge servers with <30ms latency worldwide, no matter which hosting you’re in or where is your server location. Our TTFB Optimizer is a work in progress and will be a game-changer in WordPress.

We’ve only set up the basement.

But why? Because every code I copied from StackOverflow worked only after importing jQuery!

What’s wrong with jQuery

jQuery is 90 KB, but when minified it’s only 32 KB.

That’s so small. A good CDN can deliver it in less than 50ms!

But it’s not about the size. jQuery has around 10k lines of code. You might not be using even 10% of it.

Every line has to be parsed and evaluated by the browser which is resource-intensive. This process affects render time, especially in mobile.

To see the actual difference, here is the same functionality written in pure jQuery and vanilla JavaScript:

jQuery:

<body>
  <div id="hello-div"></div>
  <script src="https://code.jquery.com/jquery-3.4.1.js"></script>
  <script>
    // jQuery
    const div = $("#hello-div");

    for (let i = 0; i < 10000; i += 1) {
      div.append("<p>Hello world</p>");
    }
  </script>
</body>

Vanilla JavaScript:

<body>
  <div id="hello-div"></div>
  <script>
    // Pure JavaScript
    const div = document.getElementById("hello-div");

    for (let i = 0; i < 10000; i += 1) {
      const p = document.createElement("p");
      p.textContent = "Hello world";
      div.appendChild(p);
    }
  </script>
</body>

Here is the performance difference:

While jQuery took 2.4s, pure JavaScript only took 0.8s. That shows vanilla JavaScript is 4x faster than jQuery.

Why you don’t need jQuery

A few years back writing standard functions in vanilla JavaScript was pain and jQuery made our lives easier.

But web browsers have evolved a lot. Most of the functions that you wrote in jQuery can be written in pure JavaScript.

Here are a few examples:

1. Ajax Requests

Fetching data from a URL:

jQuery:

$.ajax({
  url: '/api.json',
  type: 'GET'
  success: (data) => {
    console.log(data)
  }
})

Vanilla JavaScript:

fetch('/api.json')
  .then(response => response.text())
  .then(body => console.log(body))

2. Find Elements & Manipulate

Find some elements from DOM (HTML) and change color:

jQuery:

<p><span>Hello</span>, how are you?</p>
<p>Me? I'm <span>good</span>.</p>

<script>
  $("p").find("span").css("color", "red");
</script>

Vanilla JavaScript:

<p><span>Hello</span>, how are you?</p>
<p>Me? I'm <span>good</span>.</p>

<script>
  document
    .querySelectorAll("p > span")
    .forEach((elem) => (elem.style.color = "red"));
</script>

3. Show/Hide Elements

Common use case of jQuery, show/hide something on click:

jQuery:

<button id="button">
  Hide me
</button>

<script>
  $("#button").click(function () {
    $("#button").hide();
  });
</script>

Vanilla JavaScript:

<button id="button">
  Hide me
</button>

<script>
  document.getElementById("button").addEventListener("click", function () {
    document.getElementById("button").style.display = "none";
  });
</script>

4. Animate

jQuery:

<button id="button" class="animate">
  Hide me
</button>

<script>
  $("#button").click(function () {
    $("#button").hide("slow");
  });
</script>

Vanilla JavaScript:

<style>
  .animate {
    opacity: 0;
    transition: opacity 0.5s ease;
  }
</style>

<button id="button">
  Hide me
</button>

<script>
  document.getElementById("button").addEventListener("click", function () {
    document.getElementById("button").classList.add("animate");
  });
</script>

You can find a lot more similar examples in:

• You might not need jQuery
• Should you use or learn jQuery in 2020?
• From jQuery to JavaScript – How to make the move

What about Browser Support?

Most of the functions I used above are widely supported in all major browser.

It’s usually Internet Explorer and Opera Mini which doesn’t support some of them.

If you still want to support such old browsers, you can detect the browser and add polyfills. Here are a few polyfills for such common functions:

• github/eventlistener-polyfill
• github/fetch
• iamdustan/smoothscroll
• yola/classlist-polyfill

Browser support for querySelector:

Browser support for fetch:

Everyone is moving away, except WordPress

Thanks to advancement made in front-end development tools and browser support, we’re now able to drop jQuery as a dependency, but you’d never notice otherwise

Bootsrap 5 – blog post

GitHub.com also removed jQuery in 2018 – Removing jQuery from GitHub.com frontend.

While everyone has started moving away from jQuery, it’s pretty tricky in WordPress due to the vast number of plugins and themes.

From the recent blog post of Updating jQuery version shipped with WordPress:

WordPress should deprecate jQuery and gradually migrate to vanilla JavaScript.

You might not need JavaScript too

As I said before, the web and JavaScript is evolving fast. Similarly CSS.

Many functions which were done via JavaScript be done via CSS now. This gives another performance boost.

Some of them which can be done in pure CSS:

• Image Slider – CSS Slider Builder, CSS Gallery, Pure CSS Slider
• Modal – Pure CSS Modal
• Form validation – HTML form validation
• Scroll Indicator – CSS only scroll indicator
• Accordion – 4 Ways to Create Awesome CSS-Only Accordions
• Lightbox – Pure CSS Lightbox, CSS only Lightbox
• Tabs – CSS-Only Tabs, Material Design CSS Only Tabs
• Scroll to top – Pure CSS Smooth-Scroll “Back to Top”
• Smooth Scroll to links – CSS Smooth Scroll Demo
• Sticky navbar – Pure CSS Sticky Header

The results were quite interesting. A good percentage of the search keywords has typos which resulted in Zero search results!

Here are a few examples:

So I researched a lot and ended up using Algolia.

What is Algolia?

Algolia is a “Search as a service”. You provide them with the content and they provide you with an API for search.

Why Algolia in WordPress?

• Offload WordPress search – Every time you search for a keyword in default WordPress, the keyword is searched in the MySQL table which is a resource-intensive task, especially if there are a lot of posts.
• Faster search results (extremely fast) – As I mentioned above, the default search is resource-intensive and can quickly become slow on large sites. Algolia can get results in <5ms!
• Better user experience – Auto suggestions, typo tolerant, instant results, highlight keyword and much more.

Before and After using Algolia search

Here is how my search results look like before and after when user types “buny” (meant “bunny” or “BunnyCDN“)

Pricing of Algolia

You can find the detailed pricing here.

The free plan says “for personal, non-commercial projects”. My blog is commercial, so I contacted their support to see if I can use the free plan.

Here is what they said: “The free plan is for non-commercial use but it’s more a legal term than anything. You can use the free plan as long as you display the Algolia logo in the search results page“.

How to Implement Algolia Search in WordPress

Get Algolia API keys

Sign up for Algolia and get the API keys (an app will be automatically created).

Install and Configure WordPress plugin

Install WP Search with Algolia and add the above API keys in the plugin settings

Configure Search Page

By default, it will be set to “Do not use Algolia”. Choose “Use Algolia in the backend” or “Use Algolia with Instantsearch.js”.

Algolia in the backend vs Instantsearch.js

I use “backend” options in this blog, mainly because it plays nicely with my theme and doesn’t inject any JavaScript.

Here is the difference:

	Backend	Instantsearch.js
Search interface	From Theme	Algolia UI
Algolia logo	Add via custom code	Enable/disable from the plugin
Typo tolerant
Instant results
Autocomplete
Extra JS file

Conclusion

Implementing Algolia is not just about getting faster results, it’s about providing better user experience. I regret I didn’t do this earlier!

Are you planning to use Algolia? Let me know.

Comment below if you’ve any queries or feedback. I read and reply to each of them within 8 hours!

Each has its pros and cons. But one of the biggest “cons” of Disqus Comments is the speed. Yes, it’s heavy and can slow down the site a lot with the default settings.

Without Disqus (Native Comments)

So before we start to optimize Disqus comments, let’s see how native comments look like, just to get a baseline:

Disqus with Default Settings

Ok, now let’s see how Disqus performs with default settings (I’m in the free plan).

Pretty bad right? Now let’s optimize it!

How to Optimize Disqus Comments in WordPress

Disable Tracking

Go to your site’s settings in Disqus dashboard and turn off “Tracking”.

We’re able to remove 50+ requests and 40KB. Nice!

Disable Affiliate Links

Similarly, disable “Affiliate Links”.

Not a big improvement, but still…

Load on User Interaction

Disqus is just “comments”, do we need to load them right on the initial page load? 99% of the sites have comments at the bottom, right?

Let’s load them only when the user interacts with the site (a kind of lazy loading).

Install Flying Scripts and add “disqus-comment-system” to the keywords.

Now Disqus will be loaded only when the user makes an interaction with the site, like a scroll, mouse movement, keyboard inputs, touch etc.

How’s that?!

There is also a plugin called Disqus Conditional Load which lets you load on click, scroll. However, loading ‘right after scroll start’ is their paid version.

Conclusion

Comment below if you’ve any queries or feedback. I read and reply to each of them within 8 hours!

So I did some tests to figure out which one is well coded and took optimization seriously.

How tests are done

To get a fair comparison, here is how I tested:

• Fresh WordPress install with Twenty Twenty theme
• No plugins or external scripts (not even Google Analytics)
• Same country for server and testing location (India), to minimize network latency
• All tests are done thrice to get an average
• Embed codes are added at the footer

Tools used for collecting metrics

• GTmetrix.com – To measure fully loaded time, no. of requests, page size. Test location India, Chrome Desktop.
• Lighthouse – To measure FCP, FMP, TTI, FID etc. Test device – Mobile. Applied 4G with 4x CPU slowdown.
• Pingdom Tools – To measure content size by file type, domain lookups etc.

Why Lighthouse instead of PageSpeed Insights?

Some of the chat widgets checks for the user agent and if it contains a keyword like “Google”, they’ll not load the widget.

This is probably to exclude Google bots crawling pages. However, PageSpeed Insights uses a similar user-agent.

Also Read

• OOptimization

14 Tools I Use to Audit Performance of a WordPress site

• byGijo Varghese
• July 19, 2019

What metrics should I care?

Measuring fully loaded time is a great way to know the speed.

But keep in mind that chat widgets should be loaded in the background so that it will not affect FCP (first contentful paint) or TTI (time to interactive) or FID (first input delay).

These are also the metrics Google looks for in rankings. It’s now visible in Google Search Console.

Here is what Google suggests:

Test Results

No Widgets

To get a baseline, here are the results without using any chat widgets:

Crisp

Crisp is fairly new to this market. But within this short period, they’ve added tons of features and gained a lot of traction. Pricing starts with a free plan (2 seats) to $95/month.

Drift

Drift is another chat widget which is more focussed into sales and marketing. Their bots/automation is pretty cool. They do have a free plan.

Facebook

Facebook launched its chat widget named “Customer Chat Plugin” a few years back. It’s tied to your Facebook page. Not feature-rich as other platforms, but 100% free.

HubSpot

HubSpot is well known for its CRM. They also have a live chat widget which comes free and has tight integration with their CRM and other services.

Intercom

Intercom is probably the company who revolutionized chat widgets in websites. Almost every SaaS websites use it. I love their UI. It has all the features like live chat, emails, CRM, marketing, help centre etc.

Intercom doesn’t offer a free plan. Pricing is based on the features you want. The ‘Essential’ plan starts at $38/month.

LiveChat

LiveChat, yet another live chat solution! No free plan. Starts at $16/month.

PS: Upon testing, they translated the text to Hindi, since I’m from India. But I don’t know how to read and write Hindi!

Tawk.to

Tawk.to is probably one of the oldest live chat solutions. Within the last few years, they changed the UI and added a lot of cool features. 100% free.

While testing, I noticed that Tawk.to widgets are not rendered in GTmetrix. On further investigation, I found that Tawk.to blocks GTmetrix from loading their scripts.

So if you’re using Tawk.to and uses GTmetrix to measure speed, you might be getting the wrong results.

ZenDesk

ZenDesk is a customer support ticket system and support platform. It’s widely used by many websites. Their live chat solution integrates well with the tickets system too.

Summary

Here is the comparison of each based on the load time, no. of requests, size, and domain lookups:

Crisp and Intercom are very well optimized. Crisp also has almost zero impact on PageSpeed/Lighthouse.

Both of them has also written detailed blog posts on how much effort they put into optimization:

• Crisp – Our actions to optimize performances
• Intercom – Reducing the Intercom Messenger bundle size by 65%

Comment below if you’ve any queries or feedback. I read and reply to each of them within 8 hours!

I’ve also seen a few hosting providers telling me that they don’t need to use the cache plugins because they’ve server-side caching.

But is that enough?

What is Server-Side Cache?

When a request reaches your server, WordPress has to execute a lot of PHP scripts and MySQL scripts.

Every time you open a page/post, it has to execute a minimum of 27 MySQL queries. 27 is the default queries count, it may be 50 or 100 depends on your theme and the number of plugins installed. Each of these queries may take a few milliseconds depending on the size of the SQL query and the data in your database.

Summing up all these PHP and MySQL executions, your TTFB (Time to First Byte) can be around a second or even more.

Also Read

• HHosting

9 Tips to Reduce TTFB in WordPress

• byGijo Varghese
• May 10, 2019

Server-side caching eliminates this process by storing copies of the generated HTML in disk/memory. This reduces TTFB and lowers server resource usage. Because the server only needs to serve that generated file.

Different hosting providers have different server-side cache solutions. The most common one is FastCGI caching in Nginx servers. Varnish, Redis, Memcache etc are also similar caching layers.

If you cache HTML pages in Cloudflare, it’s also a sort of server-side cache.

Also Read

• CCloudflare

Caching WordPress Pages using Cloudflare Page Rules

• byGijo Varghese
• April 19, 2019

What Cache Plugins do that Server Side Caching can’t?

Most of the cache plugins generate HTML pages just like in server-side caching. But cache plugins can do more front-end optimizations that server-side cache can’t.

Here are a few:

• Generate critical path css – Improves FCP (First Contentful Paint), which now a ranking factor in Google SERP.
• Defer JavaScript & CSS – Remove render-blocking scripts by loading them asynchronously.
• Minify CSS and Javascript
• Lazy loading – Lazy load images, videos, embeds etc.

There are a lot more features depending on the cache plugin you use.

I recommend FlyingPress for caching.

So in short, do I need a cache plugin with server-side cache? The answer is YES!

How Lazy Loading works?

A normal image is HTML looks like this:

<img src="sample.jpg" width="100%"/>

What lazy loading plugins do is rewrite the code to:

<img data-src="sample.jpg" width="100%"/>

As you noticed, the src attribute has been changed to data-src.

Since there is no src, the browser won’t download that image initially. Later a small JavaScript code checks whether the image is in the viewport (user viewing area) and if it’s inside data-src is changed back to src which trigger browser to download and display the image.

What is Native Lazy Loading?

Chrome has come with “native lazy loading”. You can read more about it here.

The advantage of native lazy loading is that there is no need for JavaScript and is generally much faster since it’s done “natively” by the browser.

The code looks like this:

<img src="sample.jpg" loading="lazy" width="100%"/>

What is Flying Images?

Flying Images is a high-performance lazy loading plugin. It uses the browser’s “native” lazy loading if available, otherwise, use normal JavaScript for lazy loading.

Flying Images can also load images even before images are in the viewport.

Are you afraid of lazy loading because it degrades user experience?

See the review from Gulshan Kumar:

How Flying Images is different from other lazy loading plugins?

• Uses native lazy loading – Use native lazy loading if available (currently supported only in Chrome), otherwise use JavaScript to lazy load images.
• Load images even before entering viewport – While other plugins load images when they’re ‘inside’ the viewport, Flying Images load them when they’re about to enter the viewport.
• Tiny JavaScript – Only 0.5KB, gzipped, minified.
• Optionally use native only – Only want to support Chrome? You can switch to “native only” which injects zero JavaScript.
• Rewrites entire HTML – Never miss an image from lazy loading (even the ones injected by gallery plugins).
• Transparent placeholder – A tiny base64 transparent is added to all images. No more flickering while loading images.
• Exclude keywords – Almost all lazy loading plugins provide exclude feature, however, Flying Images can also exclude images from the images’ parent node. Helpful if your image doesn’t have a class name.
• Supports IE and JavaScript disabled browsers – All images are loaded instantly if is Internet Explorer or even if JavaScript is entirely disabled (using noscript tag).

What is Quicklink?

Faster subsequent page-loads by prefetching in-viewport links during idle time

Quicklink, Google

Quicklink is a tiny JavaScript file that detects links in the viewport (visible area) and preloads them even before the user clicks on it.

Also Read

• PPlugins

Quicklink by Google for WordPress – Faster Subsequent Pages

• byGijo Varghese
• April 27, 2019

What’s is wrong about Quicklink?

Issue #1 – Crash Servers

If you’ve too many links in the viewport, Quicklink will tell the browser to prefetch all the links at the same time. This will create a high server load.

I haven’t felt any issues like this because my hosting can easily handle it. But those who are in shared hosting or hosting that doesn’t have enough resources, it will crash the server during peak times.

Solution: Stop preloading if the server is busy and preload only a few requests per second.

Issue #2 – Don’t Prefetch Dynamically Injected Links

Quicklink finds all links on the web page during the initial load. It’s not aware of any links which are injected later. A good example is ‘infinite scroll’ contents like blog posts or products that load on clicking ‘Load more’ button.

Solution: Preload pages on mouse hover too, similar to Instant.page

What’s Instant.page?

Instant.page uses just-in-time preloading — it preloads a page right before a user clicks on it. Before a user clicks on a link, they hover their mouse over that link

Instant.page

It is somewhat similar to Quicklink, but instead of prefetch all links in the viewport, it prefetches link on mouse hover.

What’s wrong about Instant.page?

Usually, a user takes around 300ms from hover to click. So if the server didn’t respond within 300ms, then most likely you won’t notice any difference. Achieving <300ms TTFB is pretty hard. Most of the hosting providers have this around 400ms and even 1s to halfway around the globe.

Solution: Preload links in viewport instead of hover, similar to Quicklink.

Introducing Flying Pages

Flying Pages is built to fix issues with both Quicklink and Instant.page

• Preload pages in the viewport (similar to Quicklink)
• Preload pages on mouse hover (similar to Instant.page)
• Limits the number of preloads per second
• Stops preloading if the server is busy
• Understands the user’s connection and preferences
• 1KB gzipped

Flying Pages detects all the links in the viewport and add it to a queue. Links in the queue are processed by a limit of 3 requests per second (by default). This will prevent sending a large number of requests in an instant. It will also preload links instantly on mouse hover, if not preloaded yet in the queue.

Flying Pages is also smart enough to detect slow responses and crashed servers. Whenever it detects like that, all preloading will be stopped.

Quicklink vs Instant.page vs Flying Pages – A comparison

	Quicklink	Instant.page	Flying Pages
Preloading method	Viewport	Mouse hover	Viewport + Mouse hover
Server load	High	Low	Medium
Delay	0 ms	65 ms	0 ms
Size (gzipped)	0.8 KB	0.8 KB	1 KB
Respect user connection
Support Safari browser
Limit preloads per second
Preload dynamically injected links
Stops preloading on slow response
Stops preloading if server crashes
Configurable via WordPress plugin

Comment below if you’ve any queries or feedback. I read and reply to each of them within 8 hours!

So which one is the fastest cookie notice plugin?

I couldn’t find a good one. Most of the cookie consent WordPress plugins will slow down your site. They’re bloated with too many features and unwanted CSS and JavaScript.

So I built one, a code snippet for cookie notice in WordPress without a plugin!

This website uses cookies to ensure you get the best experience on our website
Got it!

• Less than 1 KB in size (~500 bytes gzipped)
• No CSS or JavaScript files (everything inlined)
• No jQuery dependency
• No database queries needed
• Responsive
• Fully customizable

Here is how it looks:

On mobile:

Easily customize to match your theme:

Code

<p id="cookie-notice">This website uses cookies to ensure you get the best experience on our website<br><button onclick="acceptCookie();">Got it!</button></p>

<style>#cookie-notice{color:#fff;font-family:inherit;background:#596cd5;padding:20px;position:fixed;bottom:10px;left:10px;width:100%;max-width:300px;box-shadow:0 10px 20px rgba(0,0,0,.2);border-radius:5px;margin:0px;visibility:hidden;z-index:1000000;box-sizing:border-box}#cookie-notice button{color:inherit;background:#3842c7;border:0;padding:10px;margin-top:10px;width:100%;cursor:pointer}@media only screen and (max-width:600px){#cookie-notice{max-width:100%;bottom:0;left:0;border-radius:0}}</style>

<script>function acceptCookie(){document.cookie="cookieaccepted=1; expires=Thu, 18 Dec 2030 12:00:00 UTC; path=/",document.getElementById("cookie-notice").style.visibility="hidden"}document.cookie.indexOf("cookieaccepted")<0&&(document.getElementById("cookie-notice").style.visibility="visible");</script>

Adding it to WordPress

I didn’t make it as a WordPress plugin because it’s so easy to integrate. Also creating it as a WordPress plugin will require database calls to query the text, colour etc.

In order to add it to your WordPress site, go to your Appearance -> Theme Editor -> Theme Footer (footer.php) (from the right side) and paste the above code just before </body>.

Customization

The text can be easily changed in the <p> tag. You can insert links or anything as you wish.

To edit the background colour, search for #596cd5 and replace it with yours. For the button’s background colour search for #3842c7 and replace it.

Comment below if you’ve any queries or feedback. I read and reply to each of them within 8 hours!

I’ve built a better version of Quicklink, you can read more about it here:

Also Read

• PPlugins

Quicklink vs Instant.page vs Flying Pages – Why I built Flying Pages

• byGijo Varghese
• August 31, 2019

What is Quicklink?

From the official Quicklink project:

Faster subsequent page-loads by prefetching in-viewport links during idle time

Google

Quicklink is a small JavaScript code (<1KB) that will pre-load links in the viewport. So when the user clicks on that link, it will be displayed immediately. Result? Superfast inner pages navigation!

Before diving into Quicklink, we need to understand what is prefetching and viewport.

What is Prefetching?

By adding a small code snippet in the <head> of HTML, you can tell the browser to download a resource even if it’s now required right now. So whenever browser actually needs the resource it’s available without any network requests. The code looks like this:

<link rel="prefetch" href="(URL)">

What is Viewport?

The viewport is the portion of the website that the user is currently viewing.

How Quicklink works?

Quicklink detects all the links the viewport of browser and injects those links with prefetch API to the <head>. When the browser detects a new URL in prefetch, it will download those URLs and save it in the cache.

Here is a short video on Quicklink prefetching:

Install Quicklink in WordPress

Instaling Quicklink in WordPress is pretty easy. Download and install Quicklink for WordPress plugin and you’re good to go. No configurations are needed!

QuickLinks vs Instant.page

Instant.page is a similar plugin to Quicklink. But instead of prefetches links in the viewport, it prefetches when the user hovers over a link.

An average mouse hovers to click time would be more than 300ms. Most of the pages (without edge caching) will take more than 400ms to load from the server including network latency. So it isn’t an efficient method.

Quicklink, on the other hand, loads all the links in the ‘viewport’ and continuously monitor viewport changes. The result is even before the user hovers a link, it will be cached.

 Also found that Instant.page may cause multiple requests to the same URL:

1) If you hover on a link, Instant.page starts fetching the URL. But if the user clicks on the link before getting a response, the browser will send another request.

2) Every time you hover on a link Instant.page fetches it even if its already in the cache. This is something Quicklink won’t do. If it’s cached, it will never fetch it again.

Also Read

• PPlugins

Quicklink vs Instant.page vs Flying Pages – Why I built Flying Pages

• byGijo Varghese
• August 31, 2019

Will Quicklink slow down my website?

Quicklink only injects and prefetch data when the browser is idle and if the user is on a fast connection. Also the JavaScript code in less than 1KB. So adding Quicklink to your site will not slow it down.

A note on Shared Hosting

Based on the number of links in viewports, Quicklinks send more requests than usual. Some shared hosting providers might not be able to handle it. Try it yourself.

I’m not seeing in any improvements in PageSpeed Insights/ Pingdom/ Gtmetrix

The aim of Quicklink is to improve inner pages navigation. It won’t have any effect on improving the speed of the initial page. You’ll feel the difference when clicking through the links.

Conclusion

Using a tiny JavaScript code, Quicklink we could load the inner posts/pages almost instantly. Without touching any server configs or complex cache plugins, Quicklink is a great way to boost speed in your WordPress site.

Comment below if you’ve any queries or feedback. I read and reply to each of them within 8 hours!