Opening an asset in the annotation workspace fetches the asset's own bytes twice. The two requests
carry the same URL and arrive back to back, so the second is redundant work on the request that
matters most for how quickly a frame appears.
Observed in a browser network log while investigating suggest latency, on an ordinary navigation
to a job's annotation page:
489. [GET] /api/projects/{project_id}/assets/{asset_id}/content => [200] OK
490. [GET] /api/projects/{project_id}/assets/{asset_id}/content => [200] OK
Nothing else in the log is duplicated, and the pair reproduces on a fresh navigation rather than
only on a re-render after some other interaction. Whether it comes from two components each asking
for the image, from an effect that runs twice, or from the image element and a fetch both
resolving the same URL was not investigated — the observation is the duplicate pair, not its
cause.
The cost is one extra transfer of the full asset per frame opened, which on a large frame is the
single biggest payload on that page. Since the bytes are content-addressed and the response
already carries caching headers, the second request may well be served from the browser cache in
some conditions and not in others; that is worth establishing as part of the fix rather than
assumed either way.
This was found during a backend investigation and is deliberately left for a frontend change.
Opening an asset in the annotation workspace fetches the asset's own bytes twice. The two requests
carry the same URL and arrive back to back, so the second is redundant work on the request that
matters most for how quickly a frame appears.
Observed in a browser network log while investigating suggest latency, on an ordinary navigation
to a job's annotation page:
Nothing else in the log is duplicated, and the pair reproduces on a fresh navigation rather than
only on a re-render after some other interaction. Whether it comes from two components each asking
for the image, from an effect that runs twice, or from the image element and a fetch both
resolving the same URL was not investigated — the observation is the duplicate pair, not its
cause.
The cost is one extra transfer of the full asset per frame opened, which on a large frame is the
single biggest payload on that page. Since the bytes are content-addressed and the response
already carries caching headers, the second request may well be served from the browser cache in
some conditions and not in others; that is worth establishing as part of the fix rather than
assumed either way.
This was found during a backend investigation and is deliberately left for a frontend change.