Why a JavaScript dashboard is slow on older office computers

Open the dashboard on the slow computer itself. Press F12 in Chrome or Edge and use the Performance tab to record ten seconds of normal use. The flame chart shows whether time goes to scripting, layout or painting.

On your own machine, throttle the CPU to four or six times slower in the same panel. It will not match an old Celeron exactly, but it reproduces the pain well enough to compare before and after.

Write down three timings: first load, switching a filter and an hour of use. Measure every fix against them.

The commonest cause is a table that renders every row. Five thousand rows with eight cells each means forty thousand elements the browser must lay out. An old computer stalls for seconds on every sort.

Fix it with server-side paging, or with a virtualised list that draws only the rows on screen. Move sorting and filtering to the database, where MySQL does it faster than the browser can.

Ask users how many rows they truly read. Most scan the first page, then filter. A default filter such as this week only can cut the load before any code changes. Charts compound the problem. Twelve charts on one screen each load a library, each fetch data and each repaint a canvas. Load the visible ones first, build the others when scrolled into view, and cap points at what the eye can read.

Open the Network tab and sort by size. Scripts of several megabytes are common when a charting library, a date library and a UI kit are all imported whole. Old CPUs spend seconds just parsing it.

Split the bundle by route so the login page does not carry the reports module. Import only the chart types you use. Replace a large date library with the built-in Intl formatters where possible.

Serve files compressed and cached. Check that the API compresses its JSON, since a ten megabyte response hurts a slow tablet more than a fast laptop.

Offices leave the dashboard open from morning to evening. A small leak, such as an event listener never removed or a timer never cleared, adds up. By afternoon the tab uses over a gigabyte and the whole computer swaps to disk.

Take a heap snapshot at nine and again at three. Objects that only grow point to the leak. Clear intervals and subscriptions when a component unmounts.

Detached DOM nodes are a common culprit. Search the snapshot for them and trace each back to the chart or modal that created it. Then look at polling. Twelve widgets each asking the API every five seconds makes the NestJS server and the tablet both busy. Poll once for a combined payload, stretch the interval, and pause when the tab is hidden.

Do the cheap, large wins first. Paginate the biggest table, then pause hidden polling, then split the bundle. These three usually remove most of the delay without redesigning anything.

Next fix memory leaks, since they decide whether the dashboard survives a full day. Last, tune individual charts and animations.

Turn off decorative animation on low end tablets. It costs frames and adds nothing to a stock count. Re-run your three timings after each change and keep the numbers in a short log. Ask the staff who complained to try it again before you move on.