Rebuilding a 400-seat Service Cloud console

Four hundred agents used this console for six hours a day. It took four seconds to open a case, and the internal satisfaction survey had a free-text field that mentioned it eleven times.

What was wrong

Not one thing. The console was six years old and every year had added a component that queried on load.

• Eleven Aura components, each with its own init handler firing a server call
• Six of those calls synchronous, so they queued behind each other
• A related-list component that loaded every field on the object and rendered four
• No caching anywhere, so opening the same case twice cost exactly the same as opening it once

What we did

1. Measured firstChrome’s performance panel and the Lightning Usage app, for a week, before touching anything.
2. Killed the waterfallSix synchronous calls became two parallel ones. This alone took a second off.
3. Migrated to LWCEleven components, leaf-first, over five weeks. See the write-up in the blog.
4. Cached the reference dataPicklists and routing rules moved into Platform Cache. They change monthly and were being fetched per case.

The result

The number I care about most is the last one. A performance project that ships three bugs has not made anyone’s day better.

What I would do differently

We measured for a week before starting and did not measure again until the end. Two of the four changes turned out to contribute almost nothing, and we only found that out afterwards. Measuring after each change would have let us stop two weeks earlier.