Optimization


Feature ID	FEA024
Subsystem the feature is part of	UX
Responsible person	Developers
Status	Implemented

Description

The developers try to optimize the application, so that it runs smoothly, and the user experience is as pleasant as possible.


Use Case 1	The user wants to not be annoyed by the app's performance
FUNC-REQ-C0024	Developers have to make sure the application performs smoothly

Preliminary user stories

#64 As a user I want the performance to be optimized

User interface mock-up

Implementation

Tukko relies on fetched data to be displayed, and there can be hundreds of points to display. The optimizations come from generating these points, to how we display them, and optimizations can also implemted to data tranfers. The actual generation of markers is not something we can do anything about without rewriting Leaflet, apart from not adding too much extra to be processed to the markers.

Bigger frontend optimizations came from how we display markers. We used cluster markers ( Leaflet.markercluster and React leaflet markercluster ) to "hide" markers that are very close together, reducing marker counts from 436 to 77 at minimum zoom from Helsinki to Oulu (numbers taken on 24.7, stations could have been removed or added since). This dramatically increased the frontend performance on weaker machines.

Initially we loaded all data uncompressed on page load, and that data would trickle down to components that needed them. This made for a relatively big 1.8MB fetch on initial startup. Since then, with ideas from Teemu, we Gzipped the fetches, and split the fetches to be done as needed. This reduced the network transfer on initial page load to ~81KB, with ~1.1MB actual data size.

Additionally we did our best to keep the worst case scenarios in algorithms and iterations to O(n) as well, and avoid iteration in bigger data if at all possible.

Testing / possible acceptance criteria

Testcase	Test source	Responsible
Testcase 1	FUNC-REQ-C0024	Testers