The modern web is obsessed with speed. Just this week, Vercel launched Next.js 11 with a special focus on Core Web Vitals, a new set of Google metrics that are measured in tens of milliseconds to determine page speed. Google has noticed that faster websites mean better user experiences, and has incorporated these metrics into their search ranking algorithms.

At Clerk, we're focused on a speed challenge that's equally important but often neglected: how quickly can users sign in?

In working to optimize our prebuilt Sign In UI, we've had a few surprising insights we thought are worth sharing.

After much qualitative debate - Clerk originally launched with Google and Facebook sign in buttons below the option to sign in by email.

After collecting a few months of data, we realized we should make an adjustment. There was a near-perfect 50/50 split between users who preferred Social Sign In vs email and password. But, Social Sign In was faster: ~5 seconds on average compared to ~8 seconds for email and password. So we made the switch:

In the months since making this change, Social Sign In usage has started to outpace email and password, with the last month seeing a 52/48 split.

As expected, since more users are now using a faster authentication strategy, the change has also resulted in a faster overall sign in speed.

Passwordless should remain a fallback

The passwordless concept has existed in authentication systems for decades. If a user forgets their password, a code or link is emailed to them for authentication without a password.

Recently, there has been a lot of buzz about promoting passwordless flows to the primary authentication mechanism. While Clerk allows developers to configure their Sign In this way, we recommend against it, and suggest leaving it as a fallback.

On average, we see passwordless flows take ~35 seconds to complete. Despite using Sendgrid to deliver our emails quickly and with high inbox rates, the process of checking email is simply slow in comparison to Social Sign In or email and password.

While building Clerk, we cataloged our frustrating sign in experiences across the web and made sure we had a resolution. The source of much frustration was Social Sign In - even amongst the web's biggest properties, we came across sign in flows that were blocking users from using Social Sign In if they hadn't originally signed up that way:

While it's obvious that roadblocks like these slow the sign in process, handling them elegantly takes a lot of development time. Many developers are comfortable pushing off a proper solution because these scenarios feel like edge cases.

In practice, we've learned that these "edge cases" are surprisingly common. In fact, 15.9% of users who have used Social Sign In have also used another method. Of those:

• 2 in 3 originally signed up with a password then later chose Social Sign In
• 1 in 3 originally signed up with Social Sign In, then later tried signed in without (they were sent a code to their email)

At Clerk, we've invested heavily in handling these scenarios as elegantly and quickly as possible. Regardless of a user's choice of sign in strategy, they will always be linked to the same underlying account.

Clerk's prebuilt Sign In UI

Clerk enables developers to add beautiful, high-conversion Sign In form to their application in minutes. Our prebuilt UI can easily be themed to match any company's brand and style guidelines.

We're constantly analyzing the data in search of better user experiences, as well as evaluating new technologies for addition to our product. If you have questions or ideas for improvement, reach out to us on X @clerk, or through support.