The three recorded timings
The checks recorded requests to the SoloWord API. These are request timings from one development sequence, not application startup times or a benchmark covering all devices.
| Operation | Recorded duration | Observation |
|---|---|---|
| First guess request | 10,725 ms | A long wait before the result |
| Next guess request | 175 ms | A much shorter response in the same sequence |
| Hint preparation | 4,985 ms | A hint was available, but preparation took additional time |
The measurements do not include a recorded device model, network profile or repeated sample set. They should not be read as today's expected response time for every player.
The working explanation was first-use initialization
The large first-to-next difference pointed toward work that happens on first use. Loading or initializing the language model was the working explanation discussed during diagnosis. The timings are consistent with that explanation, but do not isolate model loading from network, server load or other initialization.
This distinction affects how a fix is evaluated. A second request being fast does not prove that a new player's first request has become fast. A useful follow-up must reproduce the first-use condition.
What warming up the service was intended to change
The server configuration included a warmup option, and the investigation focused on enabling it so that initialization could happen before a player's guess. The intended result was to move first-use preparation out of that request path.
The follow-up feedback was that the game felt faster. There was no separate numerical repeat test after warmup in the recorded discussion. Therefore, 175 ms is the observed next-request duration, not a measured after-fix first-request result. Claiming a quantified improvement from the change would go beyond the evidence.
Why hint preparation needed its own investigation
The hint request still took almost five seconds in the original check. Its recorded result said that a hint was available; it did not establish that delivery was fast. Preparing candidate words was considered a possible separate source of work.
This is a useful distinction when reporting a problem: a guess that loads slowly, a hint that takes time to prepare, and an unavailable rewarded ad are different symptoms. A faster guess does not establish that the entire hint flow has also become faster.
A repeatable check for this kind of delay
- Record the date, app version, connection and server state before testing.
- Measure the first guess after a controlled service start, then several later guesses under comparable conditions.
- Measure hint preparation separately from ad playback and the rest of the interface.
- Repeat the sequence after the change and report the sample count and variation, not just the fastest response.
This is the proposed verification method, not a claim that those additional tests have already been completed. It would allow a later report to distinguish a consistent improvement from one unusually fast response.
What a player can send when a delay returns
Include the app version, language, mode, approximate time and whether this was the first guess after opening the app. Say whether later guesses were also slow and whether the delay affected guesses, hints or both. A screenshot of an error is useful; passwords and payment details are not needed.
Use the support checklist to report the problem. For an unexpected score rather than a delay, use the closeness guide. These checks address different kinds of feedback.