How reCAPTCHA Is Killing Your Website’s Performance

reCAPTCHA is a great means of stopping spam on your website. It’s well designed and minimally invasive. However, reCAPTCHA also bogs down your website’s performance in ways that you might not have thought about. Let’s discuss the impacts reCAPTCHA has on your performance as well as alternatives you can look for.

Video explaining how reCAPTCHA slows down your website.

What Uses reCAPTCHA?

reCAPTCHA is commonly used in many contact form plugins. This includes Ninja Forms, Contact Form 7, WP Forms, and the like. The reason for this is because it’s arguably the most effective captcha service on the market. It also comes with a sleek design and best of all it’s free.

Many users, unknowingly load the JavaScript from reCAPTCHA on pages where it’s not necessary. Therefore, this adds unnecessary bloat to all of your pages.

Let’s look at how much bloat reCAPTCHA adds and the potential impact it has on your website’s performance.

What Does It Add?

Some notes, this test was performed on SiteGround Shared Hosting (Serverside Caching was disabled). The theme is Genesis Sample with all necessary plugins imported and activated (with the exception of WP Forms being deactivated along with some other non-active plugins).

Additionally, both tests included the Contact Form 7 CSS and JavaScript. The only thing we added was enabling reCAPTCHA.

Establishing the Baseline

To establish a baseline performance, we made use of Page Speed Insights, GTMetrix, and Pingdom. We then got to measure the impacts and map out the performance issues that arose with the addition of the script.

GTmetrix

Our before’s were scored as follows I will also be including the timing intervals.

PageSpeed Score: 71%
YSlow Score: 83%
Fully Loaded Time: 1.2 Seconds
Total Page Size: 775KB
Requests Count: 29

Our timing intervals were as follows.
TTFB: 402MS
First Paint: 1.0 Seconds
Contentful Paint: 1.0 Seconds
DOM Interactive: 1.0 Seconds
DOM Loaded: 1.0 Seconds
Onload: 1.1 Seconds

This is not what I would call an optimized site, but it’s how it was delivered when the Genesis demo was imported. This is good enough for our baseline.

Pingdom

Pingdom is a good test for just quick data pertaining to onload event times. It’s also a quick and convenient test. Here is where we sat at before.

Performance Grade: 88
Page Size: 807.6KB
Load Time: 610MS
Requests: 29

Our test location was Washington D.C.

Page Speed Insights

Finally comes Page Speed Insights where we saw the greatest variation in before and after numbers.

Mobile
Score: 69
First Contentful Paint: 3.2 Seconds
First Meaningful Paint: 3.2 Seconds
Speed Index: 5.4 Seconds
First CPU Idle: 3.2 Seconds
Time To Interactive: 5.8 Seconds
Max Potential First Input Delay: 90MS

Desktop
Score: 93
First Contentful Paint: 0.9 Seconds
First Meaningful Paint: 0.9 Seconds
Speed Index: 1.5 Seconds
First CPU Idle: 0.9 Seconds
Time To Interactive: 0.9 Seconds
Max Potential First Input Delay: 30MS

For an unoptimized demo site, this actually wasn’t that bad.

Measuring The Impact

So, now let’s look at what our tests were showing after we enabled reCAPTCHA through Contact Form 7. Keep in mind that our Contact Form wasn’t enabled on the homepage, but the scripts for the service were still loaded and included (as they are done so globally).

GTMetrix

GTmetrix saw some variation but the largest noticeable change was the 200+ KB increase in page size and the impact on our fully-loaded time.

PageSpeed Score: 69%
YSlow Score: 78%
Fully Loaded Time: 3.3 Seconds
Total Page Size: 990KB
Requests Count: 40

Our timing intervals were as follows.
TTFB: 354MS
First Paint: 1.4 Seconds
Contentful Paint: 1.4 Seconds
DOM Interactive: 1.5 Seconds
DOM Loaded: 1.5 Seconds
Onload: 3.2 Seconds

So, our timing intervals took quite a hit and the only number seeing improvement was due to variabilities in network speed and ultimately the server. Despite that though, the other numbers continued to increase.

Pingdom

Pingdom is a good test for just quick data pertaining to onload event times it’s also a quick and convenient test. Which saw some negatives from adding the service.

Performance Grade: 84
Page Size: 1.2MB (1200KB)
Load Time: 829MS
Requests: 41

Our test location was Washington D.C. There was no surprise here outside of the major increase in page size which was to be expected.

Page Speed Insights

Finally comes Page Speed Insights where we saw the greatest variation in before and after numbers. These were not pretty.

Mobile
Score: 45
First Contentful Paint: 3.2 Seconds
First Meaningful Paint: 3.2 Seconds
Speed Index: 6.0 Seconds
First CPU Idle: 7.8 Seconds
Time To Interactive: 9.6 Seconds
Max Potential First Input Delay: 1340MS

Desktop
Score: 91
First Contentful Paint: 0.9 Seconds
First Meaningful Paint: 0.9 Seconds
Speed Index: 1.6 Seconds
First CPU Idle: 1.9 Seconds
Time To Interactive: 1.9 Seconds
Max Potential First Input Delay: 310MS

What we can gather from here is that mobile devices suffered the most from the addition of reCAPTCHA. This is due to them having a slower network connection, while also having a slower CPU.

Interpreting The Results

The addition of reCAPTCHA across the board had an impact on our website’s performance which we expected. However, mobile devices saw a significantly larger decrease than their desktop counterparts. This is due to mobile devices having both slower network connections and hardware.

We saw an increase of page weight of about 240KB for most tests excluding Pingdom which saw a significantly larger increase of around 400KB. Our request count was only around 10 or so additional requests, which was impressive.

One major hindrance is the addition of 89KB of CSS by reCAPTCHA (Compressed). The site’s total CSS was 149.4KB compressed meaning only 60KB of the CSS was actually coming from the site and the rest was from reCAPTCHA.

We saw another sharp increase in JavaScript weight reCAPTCHA delivered around 98KB of compressed JavaScript in most tests the total site had 154KB of JavaScript with only 56KB coming from the website itself.

What Can You Do?

As the end-user or developer, you have to decide if reCAPTCHA is both the best solution for your problem, as well as the most efficient. I personally am a huge fan of Akismet which is a much lighter solution and is nearly the same level of effectiveness (at least for my use case).

I also gain the advantage of having virtually no payload to the device which allows mobile devices to load the site quickly and it frees up CPU time.

If you’re determined to keep reCAPTCHA, make sure to load it with a defer attribute and in the footer if at all possible.

Final Thoughts

If you’re building a WordPress website, in particular, it’s important to keep an eye on your usage of third party services. They can be a quick and easy solution for a real problem you’re experiencing. But more times than not, the addition of these services greatly impacts the performance of your website and you have to decide whether they are worth that cost.

If you have any questions about the testing, video or just want to say hi you can reach out to me below or contact me via my contact form!

scott hartley

About the author

Scott is a web performance geek, lover of all things coffee, and avid video game player. His WordPress work delves into web performance, web security, and SEO.

3 thoughts on “How reCAPTCHA Is Killing Your Website’s Performance”

  1. Thank you for the article it was very informative. In fact, in my humble opinion it has the best baseline testing and explanations.

    I’m suffering from acute lag because of recapta on my website below.
    http://Siliconhell.com

    I’m going to take your advice and look for an alternative solution.

    Reply
  2. Thanks for the article. Very informative. My blog’s performance was taking a hit to due to recaptcha. Your numbers made my decision easier.

    Reply

Leave a Comment