Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Runtime error encountered: wastedBytes provided value was not a number #9684

Closed
mikedijkstra opened this issue Sep 17, 2019 · 7 comments · Fixed by #9693 or #9731
Closed

Runtime error encountered: wastedBytes provided value was not a number #9684

mikedijkstra opened this issue Sep 17, 2019 · 7 comments · Fixed by #9693 or #9731
Labels

Comments

@mikedijkstra
Copy link
Contributor

mikedijkstra commented Sep 17, 2019

Provide the steps to reproduce

  1. Run lighthouse https://www.lendo.se

What is the current behavior?

Lighthouse throws the following error:

Runtime error encountered: ICU Message "Potential savings of {wastedBytes, number, bytes} KB" contains a numeric reference ("wastedBytes") but provided value was not a number
Error: ICU Message "Potential savings of {wastedBytes, number, bytes} KB" contains a numeric reference ("wastedBytes") but provided value was not a number

What is the expected behavior?

A successful test

Environment Information

  • Affected Channels: All
  • Lighthouse version: 5.3.0 (works in 5.2.0)
  • Node.js version: 11.6.0
  • Operating System: Mac OSX, Linux
@connorjclark
Copy link
Collaborator

connorjclark commented Sep 17, 2019

Thanks for the quick bug report!

@exterkamp

but provided value was not a number

We should make this error message provide the value that was unexpected.

@connorjclark
Copy link
Collaborator

connorjclark commented Sep 17, 2019

wastedBytes is null.

Trace: Infinity [
  {
    url: '.ValidationMessage--wrapper--_cTsh{margin-top:8px} ...',
    wastedBytes: Infinity,
    wastedPercent: 97.84842105263158,
    totalBytes: Infinity
  },
  {
    url: '.Success-module--wrapper--fKXGO{text-align:center;padding-left:14px;padding-right:14px; ... } ...',
    wastedBytes: Infinity,
    wastedPercent: 100,
    totalBytes: Infinity
  }
]
    at Function.createAuditProduct (/usr/local/google/home/cjamcl/code/lighthouse/lighthouse-core/audits/byte-efficiency/byte-efficiency-audit.js:202:15)
    at /usr/local/google/home/cjamcl/code/lighthouse/lighthouse-core/audits/byte-efficiency/byte-efficiency-audit.js:124:50
    at processTicksAndRejections (internal/process/task_queues.js:85:5)
    at async Function.computeWastedCSSBytes (/usr/local/google/home/cjamcl/code/lighthouse/lighthouse-core/audits/byte-efficiency/render-blocking-resources.js:190:23)
    at async Function.computeResults (/usr/local/google/home/cjamcl/code/lighthouse/lighthouse-core/audits/byte-efficiency/render-blocking-resources.js:90:28)
    at async Function.audit (/usr/local/google/home/cjamcl/code/lighthouse/lighthouse-core/audits/byte-efficiency/render-blocking-resources.js:207:33)
    at async Function._runAudit (/usr/local/google/home/cjamcl/code/lighthouse/lighthouse-core/runner.js:341:23)
    at async Function._runAudits (/usr/local/google/home/cjamcl/code/lighthouse/lighthouse-core/runner.js:258:27)
    at async Function.run (/usr/local/google/home/cjamcl/code/lighthouse/lighthouse-core/runner.js:96:28)
    at async runLighthouse (/usr/local/google/home/cjamcl/code/lighthouse/lighthouse-cli/run.js:193:26)
  status Auditing: Minify CSS +8ms
  status Auditing: Minify JavaScript +15ms
  status Auditing: Remove unused CSS +53ms
Trace: Infinity [
  {
    url: '.ValidationMessage--wrapper--_cTsh{margin-top:8px} ...',
    wastedBytes: Infinity,
    wastedPercent: 97.84842105263158,
    totalBytes: Infinity
  },
  {
    url: '.Success-module--wrapper--fKXGO{text-align:center;padding-left:14px;padding-right:14px; ... } ...',
    wastedBytes: Infinity,
    wastedPercent: 100,
    totalBytes: Infinity
  }
]
    at Function.createAuditProduct (/usr/local/google/home/cjamcl/code/lighthouse/lighthouse-core/audits/byte-efficiency/byte-efficiency-audit.js:202:15)
    at /usr/local/google/home/cjamcl/code/lighthouse/lighthouse-core/audits/byte-efficiency/byte-efficiency-audit.js:124:50
    at processTicksAndRejections (internal/process/task_queues.js:85:5)
    at async Function._runAudit (/usr/local/google/home/cjamcl/code/lighthouse/lighthouse-core/runner.js:341:23)
    at async Function._runAudits (/usr/local/google/home/cjamcl/code/lighthouse/lighthouse-core/runner.js:258:27)
    at async Function.run (/usr/local/google/home/cjamcl/code/lighthouse/lighthouse-core/runner.js:96:28)
    at async runLighthouse (/usr/local/google/home/cjamcl/code/lighthouse/lighthouse-cli/run.js:193:26)
  status Auditing: Serve images in next-gen formats +3ms

^me printing out wastedBytes @byte-efficiency-audit.js:202. maybe those Infinity values are ill-handled somewhere?

EDIT: not sure how Infinity turns into null, but the value shouldn't be Infinity in the first place.

@connorjclark
Copy link
Collaborator

bisected to #9570 dc0295d

@connorjclark
Copy link
Collaborator

In the meantime, I've set v5.2.0 to the latest tag in npm.

@brendankenny
Copy link
Member

bisected to #9570 dc0295d

ah, yes, we can't JSON.stringify() Infinity or it'll go to null.

Probably needs a test for that and NaN as well.

@brendankenny
Copy link
Member

brendankenny commented Sep 17, 2019

#9687 makes it not a fatal error to have Infinity as a numeric ICU replacement value.

For the underlying issue in unused-css-rules ("Potential savings of ∞ KB"), there are two things going on:

  • a networkRecord.resourceSize of undefined is guarded against but 0 isn't, so you get a compressionRatio of whatever / 0 === Infinity.

    const transferSize = networkRecord.transferSize || 0;
    const resourceSize = networkRecord.resourceSize;
    const compressionRatio = resourceSize !== undefined ? (transferSize / resourceSize) : 1;
    return Math.round(totalBytes * compressionRatio);

    we could (and maybe should) have it fall back to a ratio of 1 in that case, but why is there a resourceSize of 0 for this example in the first place?

  • It turns out there are two requests for the main page in the example https://www.lendo.se for whatever reason, and if you load the page in DevTools you can see the second load has a resourceSize of 0 there too (so we aren't doing anything different). That's a little weird because it's supposedly not loaded from disk/memory cache or a sw, so where was the resource loaded from?

    Regardless, our problem is that we have an intermediate map of url to stylesheet-or-thing-containing-a-stylesheet, and when constructing that map the last instance of a url wins, so we pick the networkRecord with resourceSize 0.

    We'll need a more deliberate step picking a canonical networkRecord when multiple ones exist for a single url. First one wins? First one with a non-zero resourceSize?

const indexedNetworkRecords = networkRecords
.reduce((indexed, record) => {
indexed[record.url] = record;
return indexed;
}, /** @type {Object<string, LH.Artifacts.NetworkRequest>} */ ({}));

This was referenced Sep 18, 2019
@brendankenny
Copy link
Member

We should fix the css infinite savings bug (but we can move to a new issue if someone else wants to)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
3 participants