Coder Social home page Coder Social logo

budget.json's Introduction

Budget.json

This repo

This repository tracks the current budget.json format as well as upcoming changes and features. budget.json is the format used by Lighthouse for declaring performance budgets.

NOTE: The Lighthouse npm module is updated periodically, so it doesn't necessarily reflect very recent code changes. Features affected by this are noted in the API docs below. If you don't want to wait for the updated npm package, you can install Lighthouse directly from Github to get the most up-to-date code.

Sample budget.json file

The budget.json file is an array containing one or more Budget objects.

This sample budget.json file below contains two Budget objects:

  • The first budget applies to all pages except those with URL path starting with /blog. The budget sets the following thresholds: a 300KB limit on total page resources, a 150KB limit on total JavaScript resources, and a limit of 10 third-party requests.
  • The second budget that applies to pages with a URL path starting with /blog. The budget sets the following thresholds: a 200KB limit on total page resources.
[
   {
      "path":"/*",
      "resourceSizes":[
         {
            "resourceType":"total",
            "budget":300
         },
         {
            "resourceType":"script",
            "budget":150
         },
      ],
      "resourceCounts":[
         {
            "resourceType":"third-party",
            "budget":10
         }
      ]
   },
   {
      "path":"/blog",
      "resourceSizes":[
         {
            "resourceType":"total",
            "budget":200
         }
      ]
   }
]

The Budget Object

This section provides more information on the properties that are a part of the Budget object.

path

Optional, String, Lighthouse 5.3 & up

The path property indciates the pages that a budget applies to. This string should follow the robots.txt format.

If path is not supplied, a budget will apply to all pages.

If a page's URL path matches the path property of more than one budget in budget.json, then the last matching budget will be applied. As a result, global budgets (e.g. "path": "/*") should be listed first in budget.json, followed by the budgets that override the global budget (e.g. "path": "/blog").

Examples

Match all URL paths.

"path": "/" (This is equivalent to writing "path": "/*")

Match all URL paths starting with /articles.

"path": "/articles"

Match URL paths within the uk/ directory and ending with shopping-cart.

"path": "/uk/*/shopping-cart$"

resourceSizes

Optional, Array

This is an array of resourceSizeBudget objects. A resourceSizeBudget object contains two properties: resourceType and budget. resourceType is one of the resource types supported by budget.json. The budget property is defined in kilobytes and refers to the transfer size of a resource.

Example

This array contains two resource size budgets: a budget of 500KB for total resources & a budget of 300KB for script resources.

[
   {
      "resourceType":"total",
      "budget":500
   },
   {
      "resourceType":"script",
      "budget":300
   }
]

resourceCounts

Optional, Array

This is an array of resourceCountBudget objects. A resourceCountBudget object consists of two required properties: resourceType and budget. resourceType is one of the resource types supported by budget.json. budget is defined in number of requests..

Example

This array contains one resource count budget: a budget of 10 requests for third-party resources.

[
   {
      "resourceType":"third-party",
      "budget":10
   }
]

resourceType

String

The following resource types are supposed by budget.json:

  • document
  • font
  • image
  • media
  • other
  • script
  • stylesheet
  • third-party
  • total

Proposed Features

  • Support setting budgets for specific files.
  • Support whitelisting of first-party domains.
  • Support timing-based budgets.
  • Support setting budgets for the change in resource size(s).

Contributing

If you have feedback or ideas on the budget.json format, please file an issue in this repo to get involved.

If you are interested in contributing to the Lighthouse budget.json implementation, please refer to the Lighthouse repo.

budget.json's People

Contributors

khempenius avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

budget.json's Issues

Support main-resource metrics (i.e. metrics on inlined content)

Motivation
The size of the main resource, including any inlined content, currently counts towards the
document category in LightWallet. The role of the main resource is unique, so although it is correct to consider it a document, not providing more information on its size or contents is unhelpful. This feature would have the largest impact on:

  • sites that load a significant number of documents besides the main resource
  • the 10-25% of sites with large main resources (main resource size: p75 = 25KB, p90 = 50KB).

Implementation: Budget.json
An additional resourceType, main-resource, will be added to LightWallet. Budgets can be set for main-resource just like any other resourceType supported by LightWallet.

This has no impact on the usage of the document resourceType. The main resource is a subset of document and will still be reported as such.

Implementation: Lighthouse Report
Sub-metrics on the script, stylesheet, and image content of the main resource will be reported in the Lighthouse Report.

Sub-metrics will not be included for the following resource types: document, media, font, and other:

  • document: All of the main resource is a document, so it does not make sense to report this twice.
  • media: While it is technically possibly to inline media (example), usage is ~0%.
  • font: Fonts are typically inlined through stylesheets.
  • other: In addition to it being difficult to directly classify something as other, this classification could also be ambiguous. In the context of this feature, other would imply a resource that is not a script, image, or stylesheet. However, in the browser and elsewhere in LightWallet other refers to a smaller subset of content than this.

Implementation: Content Classification

  • Inline scripts are identified by <script> tags without the src attribute.

  • Inline stylesheets are identified by <stylesheet> tags without the src attribute.

  • Inline images are identified by <img> tags using data URLs.

    Inlined images within inlined stylesheets
    Inlined images within inlined stylesheets would only count towards main resource stylesheet
    size rather than both the main resource stylesheet size and main resource image size. This
    removes the need to parse the stylesheet. In addition, I believe this interpretation is probably
    more intuitive to most users. For example, if images counted towards both totals, it could
    appear that the combined contents of the main resource exceed the size of the main resource
    itself (which would be a bug).

    Known limitations
    This implementation would not attempt to categorize content inlined via tag. According
    to HTTP Archive data, only .12% (i.e. <1%) of tags use data URLs.

Implementation: Lighthouse Report (JSON)
The API below shows how additional details could be included in the JSON object for the Lighthouse report. In the future, this pattern could be applied to other resourceTypes beside main-resource. Note: it needs to be confirmed that this is compatible with Lighthouse CI’s plans for surfacing details on individual resources.

details: {
  headings: [...],
  items: [{
      resourceType: "main-resource",
      label: "Main Resource",
      requestCount: 1,
      size: 1757,
      sizeOverBudget: 1654,
      components: [
         {resourceType: "script", size: 1000},
         {resourceType: "image", size: 500},
         {resourceType: "stylehseet", size: 300}
       ]
  }]
}

Add resource type `initial-document`

I'm copy-pasting from this LH issue by @csabapalfi


Feature request summary

I'd like to add a new resource type to Lighthouse performance budgeting called initial-document. This will allow setting a resource size budget that only includes the initial document.

I'm happy to work in this myself.

What is the motivation or use case for changing this?

The initial document is much more important to set a budget for then later document requests (sometimes even by third-parties).

How is this beneficial to Lighthouse?

It'll allow users to set more targeted budgets.

Support for [Options]

Hello,

Before two weeks, I have run a LightWallet test with a budget.json file. There was no error.
After two weeks I have created a new test with the same file and it says

Runtime error encountered: Budget has unrecognized properties: [options]

My file is like below:

[
  {
    "path": "/*",
    "options": {
       "firstPartyHostnames": ["*.vava.cars"]
    },
    "timings": [
      {
        "metric": "interactive",
        "budget": 3500
      },
      {
        "metric": "first-meaningful-paint",
        "budget": 1000
      }
    ],
    "resourceSizes": [
      {
        "resourceType": "total",
        "budget": 1500
      },
      {
        "resourceType": "script",
        "budget": 100
      },
      {
        "resourceType":"stylesheet",
        "budget":200
      },
      {
        "resourceType":"image",
        "budget":10
      },
      {
        "resourceType":"third-party",
        "budget":250
      }
    ],
    "resourceCounts": [
      {
        "resourceType": "third-party",
        "budget": 3
      },
      {
        "resourceType":"stylesheet",
        "budget":2
      }
    ]
  },
  {
    "options": {
       "firstPartyHostnames": ["*.my-site.com", "my-site.cdn.com"]
    },
    "path": "/checkout",
    "resourceSizes": [
      {
        "resourceType": "script",
        "budget": 200
      }
    ]
  }
]

I have tried to change the second options section, but there was no result. I have taken the code from LightWallet's introduction page.

Add budget for totalExecutionTime

I'm copy-pasting from this LH issue by @patrickhulce


Feature request summary
I'd love to see totalExecutionTime available as an assertion/budget target in Lightwallet.

What is the motivation or use case for changing this?
The metric values can exhibit high variance in certain situations that make it difficult to enable commit-gating. Total CPU execution time is a good indicator of overall performance characteristics that is much less variable according to our internal research projects (see #6775). It could be a nice middle ground between metric assertions and resource assertions.

How is this beneficial to Lighthouse?
Provides users with critical warnings on CPU performance changes that would otherwise go unnoticed.

Support budget for categories

It's useful to keep Lighthouse categories in check, especially those, that rely on static page analysis, like accessibility, seo, and best-practices. Decrease of the score is often a sign of a quality regression.

This feature will allow analyzing pages with Lighthouse in CI and will help to make projects like https://github.com/treosh/lighthouse-ci-action more useful.

Proposed format:

[
  {
    "path": "/*",
    "categories": [
      {
        "id": "accessibility",
        "minimumScore": 1
      },
      {
        "id": "seo",
        "minimumScore": 0.9
      },
      {
        "id": "best-practices",
        "minimumScore": 0.8
      }
    ]
  }
]

The format is open for debate. The proposed one is inspired the current Lighthouse report on categories with id and minimumScore value between 0 and 1.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.