feat: more async work + prefer Stream over Enum

[thecristen]

Scope

Asana Ticket: 📅🔎 Investigate + identify SF 2.0 performance improvements

Implementation

• Streams are generally known as being more performant for working over large collections, and it turns out we're dealing with so many schedules and predictions here.. that replacing some of the intermediary Enum functions with Stream actually does a lot.
• I am now making upcoming departures load asynchronously, so it doesn't block the page from initially loading. Sorry about the additional spinner! This is probably the change that impacts the "feel" the most. Luckily, with the aforementioned changes, neither spinner seems to say on screen for long!
• Just for fun, I made a similar improvement to the throwaway route/stop picker component (and had to change it into a LiveComponent to implement it), along with some minor attempted UI improvements so we can more easily see when the page changes behind the popovers 😅

Screenshots

I did record a few flamegraphs to help point me in the right direction for functions to target. I'm not sure if sharing them in isolation would be useful here, but..

A before and (intermediate) after for the curious

Before	After

How to test

I'm going to deploy this, so you can play with it in that environment or locally, honestly navigating routes/stops and loading information should feel tangibly faster.

Since the load testing script automatically records average load times and such, I'm going to run another test and compare the numbers.

[thecristen]

Okay I was having trouble getting multiple load tests to give me the report format I wanted, but can also compare in other ways:

1. curl and measure the response time

Using a script like this..

curl -o /dev/null -s -w 'Establish Connection: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n'  "https://dev-blue.mbtace.com/departures/?route_id=1&direction_id=0&stop_id=188"

I can compare time to establish the connection, time to first byte (measures the time between starting navigating to a page and when the first byte of a response begins to arrive), and total time (lower times are better)

	blue (main)	green (this)
Establish connection	0.035985s	0.035705s
TTFB	1.552685s	1.440056s
Total	2.267935s	1.520626s

2. in Chrome devtools, generate a Lighthouse report

• First Contentful Paint (FCP) marks the time at which the first text or image is painted - lower is better
• Cumulative Layout Shift (CLS) measures the movement of visible elements within the viewport - lower is better
• Performance score is out of 100 and accounts for these and more metrics - and higher is better

	blue (main)	green (this)
Performance score	93	98
FCP	1.2s	0.9s
CLS	.045	.002

[lvachon1]

It certainly feels a lot faster, what a difference!