rowan-m commented 4 years ago

Address opportunities to improve the overall loading time and bandwidth cost of the widget, specifically:

Seemingly 3 transfers of recaptcha__en.js at ~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

addyosmani commented 4 years ago

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..)

thestereoscopics commented 4 years ago

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.

khempenius commented 4 years ago

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).

briedis commented 4 years ago

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...

heipei commented 4 years ago

Any update on this item?

Malvoz commented 4 years ago

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-borderAnimation and .recaptcha-checkbox-nodatauri.recaptcha-checkbox-borderAnimation to both use the compressed PNG version of checkbox_sprite.png
.recaptcha-checkbox-checkmark and .recaptcha-checkbox-nodatauri.recaptcha-checkbox-checkmark to both use the compressed PNG version of checkmark_sprite.png
.recaptcha-checkbox-spinner and .recaptcha-checkbox-nodatauri.recaptcha-checkbox-spinner to both use the compressed PNG version of loading_sprite.png
.recaptcha-checkbox-spinnerAnimation and .recaptcha-checkbox-loading .recaptcha-checkbox-nodatauri.recaptcha-checkbox-spinnerAnimation to both use the compressed PNG version of loading_bg_sprite.png

[!NOTE] 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).

heipei commented 4 years ago

Sounds like you should be part of the Chrome team 😃

ByronAP commented 4 years ago

another +1 on fixing this as it is the biggest waste of resources I have atm

recaptch-redic-wtf-usage

yakillingmesmalls

guillaumevp commented 4 years ago

Another +1 here: a simple inclusion of a recaptcha on an empty HTML page results in 675 KB of resources loaded...

ManadayM commented 4 years ago

+1 for this. It'd be great, if this gets fixed. It loads ~600 KB of resources for a very tiny signup form. :(

nghitrum commented 4 years ago

+1 for this since I also have the same recaptcha__fi.js loaded 3 times.

zfeher commented 4 years ago

+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

Malvoz commented 4 years ago

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.

zfeher commented 4 years ago

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.

fabis94 commented 4 years ago

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.

dansykes80 commented 3 years ago

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 😂

tucoinfo commented 3 years ago

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.

milabron commented 3 years ago

Google imposes how to do things, but even they don't comply. In my village, this is called politics.

alishahlakhani commented 3 years ago

+1

rahulnuo commented 3 years ago

+1

Tofandel commented 3 years ago

Lighthouse report... Not even served Gzipped

ThodorisElissaios commented 3 years ago

any news?

Tofandel commented 3 years ago

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

luiznasciment0 commented 3 years ago

+1 :(

lexusburn commented 3 years ago

+1

Leland commented 3 years ago

"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.

ericfurspan commented 2 years ago

+1

ansmlc commented 2 years ago

+1

Anu3ev commented 1 year ago

+1

Anu3ev commented 1 year ago

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

Tofandel commented 1 year ago

@Anu3ev You shouldn't that's the point, invisible recaptcha is designed to be loaded from the first page load to track users and detect if they are bots or not, if you just load it when it gets into view, recaptcha won't have enough information and will always show a recaptcha to the user