I'm a full stack web developer, I've been looking for a job lately as a junior since I don't have experience with working for companies, but I've done some projects in the past from design to deployment(for about 6 years).

In a job interview, I had lately I've been asked what I think is a weird question in the context of front-end CSS questions:

Interviewer: "What would you do to optimize the performance of rendering many elements to the page?"

Me: "I don't think I follow, optimizing what exactly? what do you mean by 'rendering'?"

Interviewer: "Let's say that you got 10,000 search results from the back end, how can you optimize the performance of rendering them to the page"

Me: "Sorry again, but don't understand the question, In the front end, if you must render all of them I don't know a way of 'optimizing' the rendering. Are we talking about CSS here? or JS? Ajax?"

Interviewer: "...Whatever you see fit to solve that problem..."

Me: "Well, being honest, I wouldn't send 10,000 search results in the first place. And if I had to I would display only a handful of them to the user at a time may be using placeholders(later clarified that I meant virtual lists) for the loading elements. but I don't see a solution if you want to display all of them at once..."

The interviewers seemed like I got it wrong...

Did I miss anything? I even searched the web for an answer but found nothing, and to be honest, I feel confident with my front-end(specifically) knowledge... But that question made me think that maybe I missed something in the field.

Edit: Just to clarify, I don't specifically care if that was the answer the interviewer wanted, I want to know if there is a way I don't know to optimize the rendering of that amount of elements other than the examples I gave.

  • 3
    A virtual list. You compute which elements are on the screen (which is easy if they're fixed height, as search results often are), and only create DOM elements for visible elements. Commented Jun 7, 2017 at 11:56
  • An example: github.com/sergi/virtual-list Commented Jun 7, 2017 at 11:56
  • I'd take a look api.jquery.com/load about loading page fragments. Render the top 100 or top 10 results, then the rest. I'm not 100 % sure about it though. Commented Jun 7, 2017 at 11:57
  • 5
    The problem with interview questions is that we have no way to tell what's the "right" answer. The "right" answer is not necessarily the "correct" answer. It is the answer the interviewer wants to hear. We don't know the person who interviewed you, so we can not know what answer they expected.
    – Philipp
    Commented Jun 7, 2017 at 12:01
  • 2
    this question seems to suffer from the XY problem: Do you want to know how people would solve it using front-end, or what the interviewer wanted you to do? You feel very confident with HTML and CSS (omitting the rest), but consider yourself a full stack web developer. Commented Jun 7, 2017 at 12:05

3 Answers 3


I believe what you are looking for is Lazy Loading. It may or may not be what you meant by "virtual" list, but in my years of experience, this is the optimized way to render 10,000 elements into the DOM.

Here is some more insight. First off, you never want to load 10,000 elements into the DOM, it will cause too much stress on the browser and will make the web page extremely unresponsive. You only want to display what is needed to the user, afterall front-end is user-centric. Having said that, there is nothing wrong with quering for 10,000 elements because you can cache it in the front-end to reduce API calls later.

In front-end there is a difference between Visibility and Display. Visibility will still render the element in the DOM, but hide it from the user, while Display will not. From an optimization perspective, display: none; is more efficient than visibility: hidden; But by no means should you use element selectors to toggle display states of elements. Does looping through 10,000 elements and switching their states sound efficient?

In conclusion, I believe best practices is still to only load whatever the user sees, whether it is 1 item, 5 items or 10 items. Dynamically load the list as a subset of the 10,000 to reduce the number of elements in the DOM.

  • 1
    I'd caveat the statement 'there's nothing wrong with querying for 10,000 elements' with "usually". First, depending on where you are in the world, there could be valid reasons (old browsers, for example, or charge models) that you don't want to query for 10,000 in one shot either; that's a number that will rarely be used by an actual user and is far more likely to be a bot trying to harvest your data. Honestly, if I'd been in the interview, I'd probably have started a discussion about the core requirement before ever getting into the optimization discussion.
    – Paul
    Commented Jun 7, 2017 at 13:54
  • I agree with your point, I didn't question the 10,000 items query because the interviewer narrated the plot. If we were to discuss the query then yes, cost, runtime (potential hanging, 500, etc), bots and a whole lot of reasons why we shouldn't query large datasets :)
    – Kaneki
    Commented Jun 7, 2017 at 14:40

It is impossible for us to know what answer the interviewers were expecting.

But if it was a real-world situation, then the only correct answer is "Where is the bottleneck?". If you have a performance problem, you need to use profiling to determine where the issue is, since it could be anywhere in the stack.

  • 1
    It takes relatively little experience to know that 10k DOM subtrees, even small, are going to cost you significant RAM and rendering speed. Hence the bottlenecks.
    – 9000
    Commented Jun 7, 2017 at 15:48
  • @9000 I agree, the question is not about finding the issue, we know what it is, but how to minimize the impact of the rendering of those elements.
    – Samuel E.
    Commented Jun 7, 2017 at 16:21

LoL, I was looking for your answer and now end up writing one.

  1. 10,000 items could be the total of multiple UI elements combined. Ten select controls with 1000 options element each (or however you want to divide up, multiplied, added up, etc).
  2. Yes, you never render all 10,000 items at once. Just like how the 10,000 elements is result of multiplication and addition. The strategy for handling such UI is to divide and conquer.
  3. Your solution is just one of the many ways of dividing up the 10,000 elements. So in short all these possible solutions are designing the problem away:
  • Pagination (simplest solution, even with 10,000 elements, it's not a problem if you only render 100 at a time)
  • Infinite scroll (virtual list, only render the part visible, leave the rest in the virtual list)
  • Hidden children (Accordion panes, Master details) - Useful when there's category associate with each list item since it's better UX and manages the size of the rendering issue at the same time.
  • If the interviewer is thinking of Single Thread Javascript blocking issue, like I'm facing, then you should also mention things like requestAnimationFrame and good old setTimeout

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.