Flag Evaluation Latency
The delay between page load and the client knowing which variant to show, which produces a visible flicker unless the flag is resolved before render.
On the server, a flag is evaluated before anything renders. On the client, the flag service must be reached first, so there is a window in which the code does not know which variant applies. The naive implementation renders the control variant and then switches, which the user sees as the page changing under them — worse when the variants differ in layout, because it is also a layout shift.
The arrangements that avoid it, in rough order of preference: evaluate on the server and deliver the resolved values with the initial response, which removes the window entirely; bootstrap from a cached value so the previous evaluation is used immediately and updated in the background, which is correct almost always and occasionally shows the previous variant; or reserve the space and defer rendering that region, which is honest and delays the content.
The related properties to design for are staleness and offline behaviour. A client that has not reached the flag service must still render something, and the default value is therefore a real decision rather than a fallback — it is what every offline or blocked user will see, and content blockers do block flag services.