27 lines
1,011 B
Markdown
27 lines
1,011 B
Markdown
|
# Optimizing Tutu
|
||
|
|
|
||
|
|
Topic Index:
|
||
|
|
|
||
|
|
- Time to first byte
|
||
|
|
- Time to first draw: [Load size](#load-size)
|
||
|
|
- CLS
|
||
|
|
- Framerate: [Algorithm](#algorithm)
|
||
|
|
|
||
|
|
## Load size
|
||
|
|
|
||
|
|
The baseline for the load size is lowest 3G download bandwidth in 2s, typically 1.1Mbps (or ~137 kilobytes/s) * 2s = 274 kilobytes.
|
||
|
|
|
||
|
|
In another words there is 274 kilobytes budget for an interaction without further notice. Notice and progress are needed if the interaction needs than that.
|
||
|
|
|
||
|
|
The service worker can use 1 chunk of size.
|
||
|
|
|
||
|
|
## Algorithm
|
||
|
|
|
||
|
|
Don't choose algorithm solely on the time complexity. GUI app needs smooth, not fast. The priority:
|
||
|
|
|
||
|
|
- On the main thread: batching. Batching is usually required to spread the work to multiple frames.
|
||
|
|
- Think in Map-Reduce framework if you don't have any idea.
|
||
|
|
- On the worker thread: balance the speed and the memory usage.
|
||
|
|
- Arrays are usually faster and use less memory.
|
||
|
|
- Worker is always available on our target platforms, but workers introduce latency in the starting and the communication.
|