Identify which schedule code is shipped before the first interaction
The screen downloads export and map code before the user opens either feature. The team needs sizes and dependency paths before splitting bundles.
- Focused work estimate
- 1h 30m + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Bundle analysis · Network loading
Estimated field mix
- Performance engineering60%
- Frontend40%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional repair coordinator opens a week containing 2,000 jobs. The initial page loads, but filtering and selecting a job can freeze the interface. Build a synthetic scheduling screen with keyboard operation before measuring changes.
Setup prerequisites
- Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses.
- Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison.
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
Acceptance criteria
- Report transferred and parsed script sizes for the production build with cache state recorded.
- Identify the dependency paths for export and map features and their actual use in the baseline workflow.
- Separate first-load transfers from subsequent navigation and avoid adding compressed sizes to uncompressed sizes.
Implementation constraints
- Use local build artifacts and browser network records; do not compare development bundles with production output.
Verification to include
- Capture cold-cache and warm-cache navigation separately.
- Open the export and map features after baseline load and verify which additional resources are requested.
Deliverables
- Bundle inventory and a justified split proposal
Rollout and recovery
This ticket changes no loading behavior; preserve the measured build identifier for the implementation comparison.
Value of the work
For the engineer: Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility.
For the team: Produce a bounded performance investigation and regression workflow for dense operational interfaces.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.