Loading: Tokyo status updates (Nov 25, 2015)

[Kinuko Yasuda]

go/tok-loading-notes (internal link)

Tokyo loading team is a part of bigger loading team and working on various loading-related efforts: metrics, WebFonts, s-w-r, memory tracking in Resource, and loading system health / investigations.

Highlights:

• Did lightweight OKR mid-q review
  
• Evaluation for new time-to-first-* metrics is ongoing: ksakamoto@'s preliminary evaluation results, discussion thread
  
• Did preliminary survey WebFonts loading on slow networks (toyoshim@, ksakamoto@)
• 24+% of fonts loading end up with 3 sec timeout regardless of font size!
• Started discussion for Fonts intervention (toyoshim@) design doc
• yhirano@ started evaluating Mojo's Data Pipe, looking at possibility to use it in loading: doc
  
• Will start a discussion on loading-dev@
• tzik@'s tracing tips! slide

Nov 25, 2015: Raw notes

• Attendees: kinuko, yhirano, ricea, ksakamoto, tzik, toyoshim, kouhei, tyoshino, kenjibaheux, hiroshige

• OKR review (lightweight, Tokyo local)

• Time-to-first-text: added the basic ones, evaluating the ones added so far, need to discuss next step

• Fonts intervention: will start discussion on loading-dev@ → started

• Cache experiments/improvements:

• Planning to start experiment for stale-while-revalidate in M49

• Some progress in Cache 304 issue?

• We’re unlikely doing additional experiments

• HTMLParser related optimizations: making some progress (e.g. kouhei@ made token queueing optimization, Pat is trying to make some more optimizations)

• One caveat: adding various optimization could make the code more and more hacky (e.g. parser yield timing, resource fetch prioritization).  How to make these saner / more coordinated?

• Code health: focus on onload event and memory tracking by Resource in Q4.

• Memory tracking: a few possibly low-hanging fruits for reduction (link element, m_documentResources, script and maybe image)

• horo@ in SW team is considering working on CORS but worrying about conflict between loading team, would be nice to coordinate between horo@, tyoshino@ and hiroshige@.

• Updates

• First paint metrics:

• Did some evaluation to see how plausible the new time-to-first-*-paint metrics are (ksakamoto@)

• In general the new metrics seem to be working good, but seeing huge discrepancy between filmstrip first paint vs new metrics on some sites (e.g. youtube, first paint seems to be white bg paint)

• Next step: look into the cases where gap is big. csharrison@ will look into alternative approach using Invalidation Rect to see if we can detect the timing when ATF layout is stabilized

• Would be nice to talk with wangxianzhu@, invalidationRect  expert (in MTV B43)?

• AI: move the discussion onto loading-dev@ → done

• First paint control proposal (kouhei@)

• Kouhei@ will polish the idea/proposal, listing up existing approaches with pros/cons

• Instant Tab restoration

• kouhei@: writing a parsed CSS serializer experimentally

• CSS back forward cache -> was prolonging lifetime of StyleSheetContents, which doesn’t work well with current Chrome.

• tzik@: wrote http header normalization for resource fetch speed up. under review piece wise.

• tzik@: investigating WindowProxy::initialize()

• tzik@: tweak base::Tuple to replace it with std::tuple

• Mojo Data Pipe: measured performance (yhirano@): doc, cl

• Chromium IPC vs Mojo Data Pipe

• Sometimes Chrome IPC perform better, for network load 150+ MB/s could be a border

• Data Pipe is not using the shared memory yet

• AI: discuss the next step, want to start using Data Pipe soon?

• AI: ask error code question on chromium-mojo@

• Fonts

• Initial implementation of font-display landed behind the experimental web platform feature flag (ksakamoto@)

• Preliminary Survey on Web Font Loading on slow networks (toyoshim@, ksakamoto@): doc

• Interesting finding: fallback happens for 24+% of fonts loading even if the font size is small

• Intervention: prototype for 2G and designing for NQE plumbing (toyoshim@): doc

• Making onload async:

• Nate’s last attempt: https://codereview.chromium.org/465563002/

• ~50 layout tests failed

• testRunner’s async test configuration is related???

• can someone take a look? → hiroshige@ will take a look

• tzik@’s deep dive: tracing tips

• slide

• Use faster machine, limit the # of measurement environment so that we can do many iterations

• Measure on Android: do the screening first

• 2-phased:

• Explore: turn on ipc-flow, toplevel-flow, identify the critical path

• Investigate: turn off as many categories as possible to focus on the problem

• Find the solution for a bottleneck resolution

• Cache the result of repeated-heavy calculation?

• Remove unneeded mass string copy / comparison?

• Remove unneeded shm usage?

• “Really” want to fix the problem?

• Identify the tradeoff

• Need heavy surgery?