GoogleChrome/lighthouse

Possible Viewer 2.0 Improvements

Open

#2591 opened on Jun 23, 2017

View on GitHub
 (0 comments) (0 reactions) (0 assignees)JavaScript (27,768 stars) (9,278 forks)batch import
P3featuregood first issuehelp wantedviewer

Description

  • Reduce asset sizes:

    • Minify or dedupe report renderer js, css, and templates (included twice, for report rendering but also in a browserified bundle of ReportGenerator for html saving). Minifying just the JS before inlining would save about 75KB in viewer and lighthouse-background.

      This could either use the assets already in the page (but we'd need a non-awkward/maintainable way to do so) so they only appear once, or we could replace brfs with a transform that minifies the JS/CSS/HTML before inlining it as a string (this approach would also fix #2014)

    • Resize lh_logo_bg.png closer to the size it appears on screen (formerly #1569)

    • Minify in-page CSS (formerly #1552)

  • Experiment with versioned viewer/report scripts so old JSON results can still be loaded in viewer. May be less of a priority since we want to maintain some level of backwards compatibility so that DevTools can load old JSON reports.

    Could do this with a script that checks the version and redirects to a specific URL per LH version (easy), or could split viewer and report into separate bundles and load the right report bundle based on json version (harder).

  • PWAify Viewer

  • Switch Viewer to use event-based ga and logging, like report does.

  • Explore CSP options (for extension and HTML report, as well)

  • Verify that report is actually isolated to its container so that when the container is cleared the report is actually cleared. It's likely that event listeners, references, etc remain every time a new report is loaded.

  • Viewer could easily be added to the report compile step since they're designed to be loaded in the page at the same time. Would need to write idbKeyval and firebase externs.

Contributor guide

Tech stack
javascriptcsshtmlfirebase
Domain
frontendperformance
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
over 1 week
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
needs investigation
Prerequisites
JavaScriptHTML/CSSfamiliarity with build tools
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
15
Research direction
Examine the linked files (e.g., report generator.js) to understand current asset inlining. Investigate replacing brfs with a minifying transform. Explore versioning strategies for viewer scripts to maintain backward compatibility. Since the issue is a meta list, seek maintainer guidance on which sub task is most valued.