recaptcha
recaptcha copied to clipboard
google
Reduce widget payload
Address opportunities to improve the overall loading time and bandwidth cost of the widget, specifically:
- Seemingly 3 transfers of
recaptcha__en.jsat ~90KB per time - Coverage reports at ~73% unused
- Logo is 2.3KB PNG, would this be better as inline SVG?
Any other thoughts? @addyosmani @khempenius re: https://twitter.com/JamesWee_/status/1169760386834284545
Would love to see if we can get some eyes on the largest offenders here (script costs). I'm curious if it's possible to break down the user-flows here into distinct on-demand loading steps (e.g lean core, minimal script for the "I am not a robot" flow, only load script for the more complex verification steps as needed..)
I would also love to see some resolution to this issue. Right now, 3 of the same scripts at 90kb each, is accounting for around 7-12% of each of the pages on the site I'm building (289kb total recaptcha/1.4MB total page assets). Justifying that to kind of load increase is tough when I've spent days setting up image optimization and caching, and minifying files.
Hi @thestereoscopics - This is on our radar (I was actually just talking about this yesterday). However, it’s is a busy time of the year, so it’s going to be a little bit longer until we can get this prioritized (unfortunately).
How can this not be a priority? We're trying to speed up our pages to please google audit tools etc., and get this slap to the face from google itself. Almost everything is loaded double, and the file sizes are not small...
Frickin 600 KB gzipped...
I'm not a part of the Chrome team but I did a little audit, out of curiosity, to see how other things than code splitting, as suggested by @addyosmani, could lower the widget payload.
| Opportunity | KB saved |
|---|---|
| Enable Brotli compression where possible | (In comparison to GZIP) Brotli compression results in:
• 21% smaller HTML • 17% smaller CSS • 14% smaller JS |
Enable Conditional Requests (Last-Modified and/or ETag) for
https://www.google.com/recaptcha/api.js
|
0.57 [1] |
Minify <iframe> HTML resources:
https://www.google.com/recaptcha/api2/anchor?{...}
https://www.google.com/recaptcha/api2/bframe?{...}
|
1.12 (before GZIP) 1.07 (before GZIP) |
| Compress PNG (from 91.3 KB to 41.2 KB) :file_folder: bg-png.zip | 50.1 |
| Convert [2] base64 encoded images to PNG and compress (from 135.43 KB data URI to 31.37 KB PNG) :file_folder: bg-base64-to-PNG.zip | 104.06 |
| Compress JPG (from 17.4 KB to 8.62 KB) :file_folder: bg-jpg.zip | 8.78 |
| Convert photography images from PNG to JPG and compress (from 63.6 KB to 21.7 KB) :file_folder: bg-png-photos-to-jpg.zip | 41.9 |
[1]: Payload may accumulate depending on the amount of navigations (where max-age=300 has expired). Enable Conditional Requests to return 304 instead of re-downloading the resource if unmodified.
[2]: Although base64 encoded images are generally much larger than PNGs, some of these images aren't used until a user clicks the "I'm not a Robot" checkbox, converting those to PNGs saves bytes but will likely have a negative effect on image rendering (hence the data URI usage?), perhaps preloading can help here, in browsers that support it. CSS animations is also an option, but that's a bigger task to take on.
If this conversion from base64 to PNG is done, the following CSS selectors (in styles__ltr.css / styles__rtl.css) can reuse the same background-image URLs to reference the then identical images, instead of having one reference the PNG version, and the other the base64 encoded version (saving 30.58 KB):
-
.recaptcha-checkbox-borderAnimationand.recaptcha-checkbox-nodatauri.recaptcha-checkbox-borderAnimationto both use the compressed PNG version of checkbox_sprite.png -
.recaptcha-checkbox-checkmarkand.recaptcha-checkbox-nodatauri.recaptcha-checkbox-checkmarkto both use the compressed PNG version of checkmark_sprite.png -
.recaptcha-checkbox-spinnerand.recaptcha-checkbox-nodatauri.recaptcha-checkbox-spinnerto both use the compressed PNG version of loading_sprite.png -
.recaptcha-checkbox-spinnerAnimationand.recaptcha-checkbox-loading .recaptcha-checkbox-nodatauri.recaptcha-checkbox-spinnerAnimationto both use the compressed PNG version of loading_bg_sprite.png
That concludes a saving of roughly 240 KB in total, excluding potential savings from Brotli compression.
@rowan-m
Logo is 2.3KB PNG, would this be better as inline SVG?
The HTML resource containing that PNG isn't cacheable, inline SVG in this case would increase bandwidth usage on subsequent requests, however, compressing it reduces the size to 1.39 KB (byte savings included in the analysis above).
another +1 on fixing this as it is the biggest waste of resources I have atm
#yakillingmesmalls
Another +1 here: a simple inclusion of a recaptcha on an empty HTML page results in 675 KB of resources loaded...
+1 for this. It'd be great, if this gets fixed. It loads ~600 KB of resources for a very tiny signup form. :(
+1, got recaptcha__en.js requested 3 times: once by https://www.google.com/recaptcha/api.js once by https://www.google.com/recaptcha/api2/anchor once by webworker.js
they are the exact same files
recaptcha__en.js requested 3 times
"requested" is the key word here.
Note that the resources are only downloaded multiple times when the HTTP cache is disabled. In actuality, the resources are requested multiple times, but only downloaded once, for subsequent requests the files are served from the cache.
This means that
~600 KB of resources
isn't true for real world users.
Oh you are right I forgot about that I use Disable cache all the time for development.
Nevertheless I've still got 2 downloads of recaptcha_en.js when I start with an empty cache (after this all reloads fully works from cache ofc).
once by https://www.google.com/recaptcha/api.js once by https://www.google.com/recaptcha/api2/anchor webworker.js uses the cached one
So we might still get a double size we don't have the cached version already.
It's absurd that this still hasn't been resolved. I mean, this isn't some random lib with 3 stars on GitHub, it's a popular lib by Google.
Would be good to get this fixed as we are still seeing recaptcha_en.js being loaded twice. When we generate a lighthouse report for our site it advises us to reduce the impact of third-party code and the top three offenders are Google CDN, Google Analytics and Google Recaptcha 😂
I don't think they care. In general GG, FB, Bing, etc. are all on the top of the offender lists including a bad cache timeout but you have no handle on that. The reports are just to show that they are doing something to HELP you. It is utter nonsense. After a recent warning I tried adding async to defer according to the most recent guidelines. No increase in the rating at all. Worse in fact.
Google imposes how to do things, but even they don't comply. In my village, this is called politics.
Guess we should switch to hCaptcha ;)
Much more reasonable with it's 24kb and tree shaking (only loads scripts it needs when it needs), api compatible with reCaptcha, no brainer for me. Still waiting for the noCaptcha implementation to be rolled out to be perfect
"requested" is the key word here.
Note that the resources are only downloaded multiple times when the HTTP cache is disabled. In actuality, the resources are requested multiple times, but only downloaded once, for subsequent requests the files are served from the cache.
Because Chrome and ~most~ [2022 edit: all] modern browsers are now partitioning the cache, this is no longer true. Safari, Firefox, and now Chrome all have changed their caches in such a way that reCAPTCHA will have to download its entire bundle multiple times (as reCAPTCHA uses iframes). That compounds the issue here.
Guys, you can use Intersection Observer API. Add script and initialize it when recaptcha block appears on screen. This will make it possible not to load it immediately