firebaseui-web: Redirection after authentication is very slow

I’m migrating from Google Identity Toolkit to Firebase Auth and noticed that the redirection to the signInSuccessUrl after successful authentication takes on average 6 secs to complete. The loading bar goes across 3-4 times before the redirection is completed. Is this considered normal? It is significantly slower than the Identity Toolkit.

I also noticed that it is spitting several messages started with Received message: in the browser console while the redirection is taking place. It shouldn’t be logging anything to the console unless it’s running in some kind of debug mode.

Note that I’m currently testing it on localhost. Could that be the reason for seeing those log messages?

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 12
  • Comments: 21 (4 by maintainers)

Most upvoted comments

Can confirm waiting times for google login and facebook login of up till 6 seconds.

I’ve previously reported major slowness when logging in with Twitter, and the problem still persists.

Here’s logging in with Twitter to the Firebase Auth demo:

Firebase redirection slow Twitter

And here’s logging in with Twitter to Spectrum.chat. Way, way faster:

Spectrum chat redirection FAST Twitter

@bojeil-google I have uploaded a screen recording to show the slow redirection in real-time. After selecting a Google account when the empty white box with a progress bar at the top is shown, the bar moves across about 1 and a 3 quarter (1.75) times. This is about 3 secs. This is in fact on the faster side as the average is 2-3 times.

I’m not sure how you claim it to be about a second.

Link to the video recording:

https://drive.google.com/open?id=1kAHMIgjzYw0S6wS4yMXEdTxAJiuI8BCp

Just want to add another datapoint that this issue is still prominent in east Asia (Tokyo, Taipei). Specifically the redirects flow from login -> home page. I found a couple questions on SO that exactly mirror my experience.

https://stackoverflow.com/questions/41158695/firebase-authentication-using-google-redirect-redirects-to-my-login-page

I also have the same problem. Twitter login takes more than 4 seconds.

Signing in with Github is really slow if the user is signing in for the first time and needs to authorize the app. It takes around 10 seconds. Way too slow to be of any practical use for end users. I can’t recommend Firebase authentication. Handling the sign in manually with Github is the only way to go.

I can’t replicate this on my end. I have tested dozens of times with our demo app https://fir-ui-demo-84a6c.firebaseapp.com/widget on Chrome/Linux and Safari/Mac browsers and it takes a second to complete the sign in. As I explained, there may be local factors affecting this on your end. It is not possible for me to speculate on the cause with the information I have.

This is not a subjective issued. We reduced 2 network requests from the sign in flow. The issue is clearly related to your environment. Google identity toolkit’s dependency on accountchooser.com also logged console messages. You don’t see the messages in the demo app because it uses one-tap sign-up as its credential manager.

Thanks for the help.

I switched to the latest version and I do see an improvement of 33% in the sense that the bar now moves across 2 times compared to 3 times earlier. It’s more like 4 secs now (compared to 6 secs with the previous version).

I compared it with the demo app and it’s exactly the same i.e. the bar moves across 2 times before the redirection is done. It’s nowhere close to 1 sec.

With Identity Toolkit, it’s definitely less than 1 sec and that’s what I was hoping to get with Firebase Auth, but the latter is still about 4x slower.

UPDATE 1:

The Google and Facebook logins are slow (~4 secs) but the email/password login is much faster (~1 sec).

I also continue to see log messages in the console. I’m not using accountchooser.com as far as I can tell but you are right that the messages are coming from accountchooser. I don’t see the log messages in the demo app though.

Here’s my configuration:

<body>
    <div id="firebaseui-auth-container"></div>

    <script type="text/javascript">
        var uiConfig = {
            'signInSuccessUrl': '/',
            'signInOptions': [
                firebase.auth.GoogleAuthProvider.PROVIDER_ID,
                firebase.auth.FacebookAuthProvider.PROVIDER_ID,
                firebase.auth.EmailAuthProvider.PROVIDER_ID
            ],
            'tosUrl': '/terms',
            'credentialHelper': firebaseui.auth.CredentialHelper.NONE
        };
    
        var ui = new firebaseui.auth.AuthUI(firebase.auth());
        ui.start('#firebaseui-auth-container', uiConfig);

    </script>
</body>

CredentialHelper is set to NONE, but for some reason accountchooser is still interfering. Is there anything that I may be missing? Could that be slowing down the redirection?

How is this closed? The service is still unusable due to this performance issue

I’m willing to provide all the details that I can, but since this issue is reproducible on your demo app, I don’t know what other verifiable examples can I provide. Are you saying that you don’t see the 3-4 sec delay? Should I do a screen recording to share with you as proof? Let’s first establish whether you acknowledge the 3-4 secs delay or not. If you do, then I’ll file an issue with Firebase JS SDK.

As I’ve mentioned before, I’m currently on Google Identity Toolkit and it doesn’t suffer from this delay. It is also using signInWithRedirect. What is different with Firebase Auth then?

Identity toolkit is partially broken (password reset is not working) and there’s no proper channel to get support for it. That forced me to kick-off the migration to Firebase Auth that Firebase Auth is not working even half as good as Identity Toolkit. As a developer, I put a lot of trust in Google and always thought that if I go with a Google product, I can’t go wrong. But Firebase Auth seems like a half-baked product with lots of problem and no proper channel to get support. The responses from the Firebase support channel have been mostly non-technical and unhelpful.