I was also surprised to read this, because Linear has always felt a little sluggish to me.

I just profiled it to double-check. On an M4 MacBook Pro, clicking between the "Inbox" and "My issues" tabs takes about 100ms to 150ms. Opening an issue, or navigating from an issue back to the list of issues, takes about 80ms. Each navigation includes one function call which blocks the main thread for 50ms - perhaps a React rendering function?

Linear has done very good work to optimise away network activity, but their performance bottleneck has now moved elsewhere. They've already made impressive improvements over the status quo (about 500ms to 1500ms for most dynamic content), so it would be great to see them close that last gap and achieve single-frame responsiveness.

▲

m-s-y 6 days ago | parent [-]

150ms is sluggish? 4000ms is normal?

The comments are absolutely wild in here with respect to expectations.

▲

layer8 6 days ago | parent [-]

150 ms is definitely on the “not instantaneous” side: https://ux.stackexchange.com/a/42688

The stated 500 ms to 1500 ms are unfortunately quite frequent in practice.

	▲	fleabitdev 6 days ago \| parent \| next [-]
		Interesting fact: the 50ms to 100ms grace period only works at the very beginning of a user interaction. You get that grace period when the user clicks a button, but when they're typing in text, continually scrolling, clicking to interrupt an animation, or moving the mouse to trigger a hover event, it's better to provide a next-frame response. This means that it's safe for background work to block a web browser's main thread for up to 50ms, as long as you use CSS for all of your animations and hover effects, and stop launching new background tasks while the user is interacting with the document. https://web.dev/articles/optimize-long-tasks
	▲	8n4vidtmkvmk 6 days ago \| parent \| prev [-]
		I think under 400ms is fast enough for loading a new page or dialog. For loading search suggestions or opening a date picker or similar, probably not.