IE11: Poor performance when scrolling rankings

[Lane]

There is a noticeable delay when scrolling rankings on IE11.

[Lane]

The ranking page is unusable when running locally, there are seconds of delay any time you go to scroll. When I view on the staging / beta links, there is still a noticeable delay, but it's usable.

Spent a bunch of time trying to fix this today but having a hard time pinpointing where the problem is. Some thing I've tried:

• Changing to style encapsulation to ViewEncapsulation.None on the rankings components. Some articles / issues I was looking at suggests that using attribute selectors for styling (which angular does a lot) is bad for performance on IE: https://medium.com/@antipov.alexei/ie11-performance-bottleneck-de304569361d
• Cutting out the ranking service and using a static data array for the locations. This improved performance quite a bit on the initial UI render, but didn't help out too much with scrolling.
• Dropping the list from 100 to 10 items. No change.
• Stripping out components one by one. Scrolling performance is good when one of the three components (ranking-ui, ranking-list, or ranking-panel) is present on the page, but gets noticeably worse with each component on the page.
• Removed HTML from ranking-ui, ranking-list, and ranking-panel so they only render a static paragraph. Still scrolls slowly!
• Dropping all of the inputs from the ranking-ui, ranking-list, and ranking-panel components that are specified in evictions.component.html. Scrolls at an acceptable speed

So, it seems like the scrolling performance is somehow tied to passing data into child components. I can't see anything that'd be problematic by looking... so we'll probably need to dive into this a bit more.

Given scrolling works okay on non-dev environments and the potentially infinite amount of time to debug this, setting as a low priority post-launch task.

[pjsier]

This is still not something worth resolving until after launch, but I've also noticed this in both Safari and Firefox. It's only in local development though, so still not a priority

[Lane]

Yeah, it's bad in development. I think building a service worker to handle data retrieval, filtering, sorting would help a lot.. and maybe breaking up CSVs based on area type?

[pjsier]

That makes sense to me! Honestly breaking up the area types would probably go a long way on its own. I don't think it's too bad in production, so I'm hesitant to rock the boat, but splitting up the CSVs seems like low hanging fruit after launch