Startup time of an SPA is meaningless when it's for the sort of app you open once in the morning and then use during the rest of the day. It's a single startup-

Startup time of an SPA is meaningless when it's for the sort of app you open once in the morning and then use during the rest of the day. It's a single startup-hit, and the user suffers it in between closing the tabs from the previous day and fiddling with some emails. Doesn't matter it is 10-20 seconds. The problem with the long startup is that it tends to cloud any discussion on performance. Code loading and parsing is basically the biggest bar in the app-perf breakdown of your profiles, and thus spins this narrative that this is the thing to optimize for, because it's the biggest bang. Rather than say, responding to user selections, reducing jitter and sluggishness while scrolling, etc... I'm starting to believe that for a large class of apps, developers should look at it as if they are writing video games: the user will tolerate the spinner before the level, but then it needs to be silky smooth after. And the _smooth after_ requires a whole class of other optimizations; it's striving for a flat memory profile, it's small ad-hoc data transfer, it's formatting data into usable layout at lower levels in the stack, it's lazy loading of content in the background, etc... Those are the areas where web-devs should be looking a (again, this only applies for that sort of SPA; e.g read-only content, blogs and such, should display _fast_).