Dropdooms! How Binding an Unbounded Reference Table Can Kill Your UI’s Performance

Dropdooms! How Binding an Unbounded Reference Table Can Kill Your UI’s Performance

It’s a situation you never want to find yourself: Client support pulls you into a call with a large client, and they’re not happy. The website is slow! You need to fix it!

You know that websites can almost always be more responsive, but it’s not bad enough to justify this level of frustration. You start to ask questions. Where do things get slow?  The “Add a New Deal” screen?  That’s a simple page, there’s nothing going on there.

You go through the process of testing and pull it up on:

• Your dev environment. You see a sub-second load time.
• The test environment in production. There’s a sub-second load time there, too. 
• The client’s account. The load time is only 45 seconds.

How could that be? You wonder if the client’s database is overloaded. You check but the rest of their account is responsive.

That’s when you spot it — the stage dropdown has 25,000 elements.

You’ve been dropdoomed!

What is a dropdoom?

A dropdown that operates fine with no loading issues.

A dropdoom is a regular DROPDOWN UI element that is populated from a user-generated list.  When the dropdown gets more than (roughly) 300 elements it will start impacting page rendering. And that’s when it switches from a dropdown to a dropdoom.

The same screen now takes 3 seconds to load.

Even on fast computers, dropdowns with more than a few hundred elements are going to slow down page rendering.  

With the example covered above, the developers gave clients the ability to add custom deal stages. The assumption that the list would be short — how many stages can a deal have?  Apparently 25,000! The clients generated so much data that rendering the dropdown became a performance bottleneck. Since only the client could see their own data, the developer didn’t know that the issue existed until the client called to complain.

Other examples of real dropdooms I’ve encountered include:

• Assigning a task to an employee using a dropdown with all employees. This worked fine at first — until the company expanded to 2,000 employees. A combined total of 6 dropdooms added 20 seconds to the page rendering time. Using the task system became a chore, and eventually people stopped using it entirely.
• A multi-select dropdown with all the tags a user has created. The page loaded in less than a second for clients with only a dozen tags. It became an issue when a client had 80,000 tags, increasing load time to over 30 seconds.
• A survey with a dropdown to select your favorite European city. The dropdown showed a list of the largest 2,080 cities in Europe. That one element added 3 additional seconds to the survey’s load time.

The underlying problem

Most of the time fields will only have a handful of options. But some fields will always be growing, slowly at first, and then an exponential explosion. When things go bad, it isn’t the user’s fault for hiring too many employees, creating too many tags, or running a survey with too many cities.

You’ve handed the user experience to the users, but kept control of the interface. And sometimes, clients will abuse a feature on accident - those 80,000 tags were a result of a developer developing against the API.

The Solution

Instead of a simple dropdown, the safest default option is a type-ahead search. This requires users to have some idea what to type in order to make results appear.

Other options include:

• The top 10 options plus a type-ahead option
• An interstitial/pop-up with all the options in paginated results 
• A mix of top options and an interstitial option

There’s no magic solution, and it can be easy to blame the user.  Users will always do things you don’t expect and might not make sense to you — but they’re not developers, you are.  Making safe tools to protect the user from inadvertently impacting performance is your job. When you can think ahead and plan for possible outcomes, you can solve the problem before it even starts — and avoid a dreaded dropdoom.