Why Your HMI Screen Is Slow: Measure Tag Load Before You Redraw Graphics

The five-second faceplate

An alarm comes in. The operator clicks the pump. The faceplate takes five seconds to appear. For those five seconds the operator cannot make a decision.

The first thing said about a screen like that is usually "the graphics are too heavy." Measure it, though, and the mimic and symbol loading are done in a few hundred milliseconds — most of the rest belongs to the historian query behind a trend widget tucked into the corner. Redraw the graphics and five seconds becomes 4.8.

So the order matters. Measure, split, then fix.

First-load and update delay are different faults

Two operators can both say "the screen is slow" and mean different things.

First-load delay — navigation click to usable display. Graphic file size, symbol library, startup scripts, initial tag subscription, alarm and historian queries, and browser cache are all mixed into it.
Update delay — field value changes to visible change on an already open screen. PLC scan, driver scan class, subscription settings, network latency, server CPU, and client rendering are mixed into that one.

Fail to separate them and you optimize the wrong thing. Measure in this order:

Restart the client, open the screen, record first-load time.
Close and reopen the same screen, record cached-load time. A large gap between 1 and 2 points at cacheable initialization.
Toggle a safe test bit or simulator value and record the time to visible change.
Repeat during a quiet period and during production peak.
Measure the local panel, the thin client, and the remote desktop session separately.

If first load is slow but updates are instant, the problem is display initialization. If updates are slow on every screen, the screens are innocent — look at scan classes, subscriptions, server load, and controller communication.

Record the display name and revision, client type, the number of live tags the screen actually requests, the slowest widget, and the path from client to PLC. Without that, you hold the same meeting again in six months.

Count tags per screen, not per project

A project with 80,000 tags runs fine if screens subscribe only to what they show. A project with 3,000 tags feels slow if one overview reads every device detail at a one-second rate. Project tag count is not a performance metric.

Display item	Where load comes from	Field check
Overview mimic	Device count, status colors, aggregates	Count visible and hidden bindings together
Motor/valve faceplate	Moderate tag count, fast response expected	Confirm only the selected device subscribes
Alarm summary	Query, sorting, filters	Test in normal state and in flood
Trend embedded in screen	Historian query plus live cursor	Measure query and update time separately
Recipe/MES panel	Database or web service latency	Log request duration and timeout handling
Diagnostic page	Many values, none of them urgent	Slow scan class or on-demand load

Plenty of HMI platforms keep hidden tabs, off-screen popups, and minimized windows subscribed. Invisible in the editor does not mean free at runtime — check the runtime subscription diagnostics.

Count derived tags too. Two hundred bindings where one color expression reads ten source tags is a two-thousand-tag screen.

Putting everything in the fast scan class is the common mistake

It shows up in the last week of commissioning. Every tag on a display goes into the fastest scan class because it works, and everyone moves on. That saves a day and leaves five years of load.

Split by use:

Fast status: running/stopped/faulted, critical interlocks, operator command feedback.
Medium process values: temperatures, pressures, flows, levels used for decisions.
Slow diagnostics: firmware version, cabinet temperature, accumulated run hours, maintenance counters.
On demand: tuning parameters, vendor diagnostic arrays, setup values read a few times a year.

There is no reason to read a pump serial number ten times a second. Reading an emergency stop indication once a minute is not a tradeoff, it is an incident. The test is not what the screen shows — it is what decision a person makes from that value.

The display hierarchy in ANSI/ISA-101.01-2015 doubles as a performance spec here. A Level 1 overview is the first thing opened when the process moves, so it has to be fast; a Level 4 diagnostic display can be slow. The moment both get the same scan rate, the budget starts leaking.

Trends and alarm widgets outweigh the mimic

A trend or alarm table embedded in a screen is not a graphic, it is a query. It pulls history, sorts thousands of records, applies filters, and keeps refreshing while the operator is trying to act.

For trends:

Default time range. Thirty days is the one I see most. Operators look at the last hour, and every navigation fires a large historian query. Eight hours covers most screens.
Pens loaded by default. Six configured, one or two actually watched.
Sampling or compression on long ranges. The historian side of this is covered in setting historian deadbands.
Whether a failed query shows as a failure instead of freezing the whole display.
Whether it was tested against months of accumulated data. Numbers from a fresh historian mean nothing.

For alarm tables:

Whether opening from a faceplate applies an area or equipment filter. A local panel that drags the whole site's alarm history over every time dies along with the flood.
Whether sorting and acknowledgment survive a flood. The commonly cited EEMUA 191 threshold — more than ten alarms per ten minutes per operator — is the state you should create before you test. Sort order itself can be the hazard, which is covered in newest-first alarm summaries hide the critical alarm.
Whether a burst of bad quality makes the widget reload in a loop.

The fastest diagnostic available: remove the trend from the screen and open it again. Still slow, and graphics are back on the table. Fast, and the graphics were never the problem.

Screen scripts are applications with no instrumentation

Scripting is convenient, so displays quietly grow into small programs — programs with no logging and no profiler. Start with anything that runs on every scan, every value change, or every mouse move.

A script looping through all devices every second to count them. One derived tag does the job.
A color expression that reads several tags.
A navigation script that queries a database before the screen is even visible.
A faceplate that creates every child popup and trend object on open.
Failed calls retried with no backoff, so load goes up while comms are down.
A client-side calculation that duplicates one already done in the PLC or the server.

Push shared calculations down to derived tags or server-side logic. Screen scripts should be short, deterministic, and documented somewhere the next person will look.

A fast screen that hurts the PLC is still a failure

Drivers differ. Some pack contiguous addresses into one request; others generate a swarm of small requests when tag addresses are scattered. Screen design gets translated straight into communication load by that difference.

Compare before and after opening the heavy screen:

PLC communication load and CPU.
Driver diagnostics: request rate, failed reads, queue depth, timeout count.
Whether contiguous Modbus registers or PLC array elements really are being grouped.
Whether large structures are browsed whole when only a few members are displayed.
Gateways bridging Ethernet to serial or a vendor network. That is almost always the first thing to saturate.
Whether screen navigation delays command or safety-related tags. Treat that as a safety finding, not a performance one.

A screen that behaves on a simulator can be unusable behind an older PLC, a radio link, or a serial gateway. Acceptance testing belongs on the real path.

Put numbers in writing before handover

Sign off on "slow" and "fine" and you will have the same argument a year later. A few lines per screen type in the HMI standard is enough.

Approximate live tag ceiling.
Default scan rate.
Maximum trend pens loaded by default, and the default query range.
Rules for script execution.
Expected first-load and update times.

The targets we use are two seconds for a Level 1 overview, one second for an operating faceplate, and no limit on diagnostic pages. The exact numbers matter less than having them written down — that is what gives you grounds to refuse when an overview starts growing into a hidden diagnostic workbook.

None of this argues for minimal screens everywhere. Only the displays an operator reads while the plant is moving have to be fast. If you check one thing after this, count how many minimized windows and hidden tabs are holding subscriptions open on the system you run today.