Director says ICA RTT is fine. StoreFront returned 200. The session is connected. The nurse is still waiting for the chart. That is the Citrix response-time problem in one sentence: protocol health is not the wait the user feels.
Direct answer: Measure Citrix response time from what the user sees on the screen — on the glass — not only from ICA/HDX protocol counters or StoreFront HTTP. Time the interval from a click or key until the expected screen state is visible. That interval is click-to-ready. It is the number a CAB and a help desk can share.
The full method for walking StoreFront or Gateway, driving HDX, and stopping at a written experience budget is in How to load test Citrix. This post is narrower: how to time the wait itself.
Why HDX can look fine while users wait
HDX — the current name for the ICA protocol family — is a remoting protocol. It moves pixels out and keyboard and mouse in. Director, Monitor, and HDX Insights are good at telling you the session is up and the channel is healthy. They are not a stopwatch for “the published app painted.”
A session can stream a logon animation, a spinning cursor, or a half-drawn shell and still look connected. Profile attach (FSLogix or equivalent), GPO, and the line-of-business app itself sit after HDX is already up. StoreFront is a website. Hammering it with an HTTP generator times the store, not the farm.
ICA RTT is useful. It is not the same as “the chart appeared.”
The same split, in product language, is Citrix HDX vs real user experience. Host CPU can sit at 40 percent while login-to-shell stretches and Hyperspace paints late. Green protocol tiles do not close that ticket.
Left column is what protocol timers see. Right column is what the user waits on. Only the right column is Citrix response time as a person experiences it.
Which steps to time
Write the steps before you pick a tool. Three intervals cover most Citrix UX arguments:
- Logon-to-shell — from credentials submitted (or the Workspace / Gateway launch) until a usable desktop or published-app window is ready: shell, icons, no logon animation. Not “the broker returned a session.”
- Published app launch — from the icon or Start-menu click until first paint of the business app: Epic, SAP, Outlook, the line-of-business client. Not “the process started on the VDA.”
- In-session transactions — from the click or key that starts the work until the ready state: search, open the record, save, print, switch published apps. This is the wait that generates “Epic is slow” tickets after everyone is already in session.
Pin the image, VDA, Workspace app, StoreFront or Gateway build, and the published resource. A timer on a moving image is a story, not a measurement.
For capacity work, run a logon storm separately from density. Storm stresses login-to-shell. Density stresses in-session transactions on hosts that already have users. Blending them hides which interval broke.
Time it like a script, not a feeling
On HDX there is no DOM event that means “done.” The practical signal is the bitmap. The measurement pattern is the same one CitraTest has used for years on published apps:
- StartTimer when the user action happens — submit, click, or key.
- WaitForImage until a baseline of the ready state is visible: the shell, the app window, the chart.
- StopTimer when that image matches.
The recorded interval is click-to-ready for that step. Image recognition — and OCR when the ready state is text — is how you know the glass painted. You do not install an agent on the VDA to learn that. That is the core of on-the-glass APM.
That pipeline is the same for login, app launch, and in-session work. Change the start action and the ready image. Keep the timer.
Stopwatch versus synthetic
A person with a stopwatch can time one logon on a quiet morning. That is a demo, not a measurement program.
A one-off cannot give you a tail. It cannot run at 8:00 every weekday. It cannot hold two hundred sessions and still time open-chart. It cannot attach a screenshot of the failed state. Means hide the damage until the service desk is already taking calls.
A synthetic does the same StartTimer → WaitForImage → StopTimer path as a real Workspace app client, on a schedule or under load, with the same baseline images. That is on-the-glass monitoring when it runs continuously, and a Citrix load test when it ramps concurrent users.
If you only have a stopwatch, use it to write the acceptance line — then automate the line. Example language teams already put on capacity plans (schematic only, not a customer dataset): logon-to-shell 45 seconds at p95 and 60 seconds at p99; published-app open 8 seconds at p95; fewer than 1 percent of runs fail, disconnect, or hang.
Continuous watch versus load test
On-the-glass is an idea, not a product SKU. Two jobs share the path:
- CitraTest VU load-tests capacity. Freeze the image, walk the real StoreFront or Gateway path, run storm and sustain as separate shapes, stop at the written budget. That is the concurrent-user number a CAB can defend. See CitraTest VU load testing.
- CitraTest APM watches production. The same login → app → in-session steps, every N minutes, with alerts and screenshots when glass time slips. That is the morning watch after go-live. See CitraTest APM.
The lab answers “how many good sessions fit on this SKU.” The watch answers “is today’s logon-to-shell and open-chart still inside the SLA.” Do not use a load-test generator as your only production monitor, and do not treat a single synthetic as a density number.
No agents on the VDAs or brokers are required for that path. Each virtual user or monitor is another Workspace app session. If the generator desktop is pegged, you are measuring the lab, not the farm.
What this is not
- It is not a replacement for Director, Monitor, or HDX Insights. Keep those for the remoting path.
- It is not an HTTP soak of StoreFront or Gateway. Keep that for the front door.
- It is not “we have full-stack APM, so Citrix is covered.” Published HDX GUIs are pixels, not traces.
- It is not a promise that last quarter’s number survives a new VDA, FSLogix policy, or a move to Citrix DaaS. Re-time the glass when the image changes.
Take the interval users already wait
Citrix response time, as a user experiences it, is click-to-ready on the glass. Time logon-to-shell, published-app launch, and the in-session steps that generate tickets. Use a stopwatch only to write the line. Use a synthetic to keep the line: CitraTest VU under load, CitraTest APM every shift.
When you need that path without agents on the farm — real Workspace client, image and OCR, StartTimer to StopTimer — schedule a demo. Product pages: CitraTest VU and CitraTest APM.