profile
viewpoint

GoogleChrome/lighthouse 19422

Automated auditing, performance metrics, and best practices for the web.

aFarkas/html5shiv 9644

This script is the defacto way to enable use of HTML5 sectioning elements in legacy Internet Explorer.

google/ios-webkit-debug-proxy 4766

A DevTools proxy (Chrome Remote Debugging Protocol) for iOS devices (Safari Remote Web Inspector).

ChromeDevTools/awesome-chrome-devtools 4032

Awesome tooling and resources in the Chrome DevTools & DevTools Protocol ecosystem

GoogleChrome/lighthouse-ci 2568

Automate running Lighthouse for every commit, viewing the changes, and preventing regressions

csnover/TraceKit 825

Attempts to create stack traces for unhandled JavaScript exceptions in all major browsers.

borismus/device.js 764

Semantic client-side device detection with Media Queries

GoogleChrome/devtools-docs 603

The legacy documentation for Chrome DevTools.

GoogleChrome/chrome-launcher 583

Launch Google Chrome with ease from node.

benschwarz/metaquery 328

A declarative responsive web design syntax. Breakpoints, defined in `<meta>`

issue closedGoogleChrome/lighthouse

Facebook 1 Audit

https://www.facebook.com/

1 Performance 82 Accessibility 86 Best Practices 70 SEO Progressive Web App 0–49 50–89 90–100 1 Performance Metrics

First Contentful Paint 7.8 s Speed Index 66.6 s Time to Interactive 96.5 s First Meaningful Paint 20.5 s First CPU Idle 89.8 s Max Potential First Input Delay 5,270 ms Values are estimated and may vary. The performance score is based only on these metrics. Screenshot Screenshot Screenshot Screenshot Screenshot Screenshot Screenshot Screenshot Screenshot Screenshot OpportunitiesThese suggestions can help your page load faster. They don't directly affect the Performance score. Opportunity Estimated Savings Preconnect to required origins 0.52 s DiagnosticsMore information about the performance of your application. These numbers don't directly affect the Performance score. Avoid an excessive DOM size 4,902 elements Reduce JavaScript execution time 72.5 s Minimize main-thread work 146.5 s Reduce the impact of third-party code Third-party code blocked the main thread for 56,600 ms Avoid enormous network payloads Total size was 8,233 KB Serve static assets with an efficient cache policy 113 resources found Avoid chaining critical requests 4 chains found User Timing marks and measures 147 user timings Keep request counts low and transfer sizes small 405 requests • 8,233 KB Passed audits (14) 82 Accessibility These checks highlight opportunities to improve the accessibility of your web app. Only a subset of accessibility issues can be automatically detected so manual testing is also encouraged. NavigationThese are opportunities to improve keyboard navigation in your application. [accesskey] values are not unique ARIAThese are opportunities to improve the usage of ARIA in your application which may enhance the experience for users of assistive technology, like a screen reader. [role]s are not contained by their required parent element Names and labelsThese are opportunities to improve the semantics of the controls in your application. This may enhance the experience for users of assistive technology, like a screen reader. Buttons do not have an accessible name Links do not have a discernible name ContrastThese are opportunities to improve the legibility of your content. Background and foreground colors do not have a sufficient contrast ratio. Additional items to manually check (11) These items address areas which an automated testing tool cannot cover. Learn more in our guide on conducting an accessibility review. Passed audits (20) Not applicable (10) 86 Best Practices Requests the notification permission on page load Displays images with incorrect aspect ratio Passed audits (13) 70 SEO These checks ensure that your page is optimized for search engine results ranking. There are additional factors Lighthouse does not check that may affect your search ranking. Learn more. Mobile FriendlyMake sure your pages are mobile friendly so users don’t have to pinch or zoom in order to read the content pages. Learn more. Does not have a <meta name="viewport"> tag with width or initial-scaleNo <meta name="viewport"> tag found Content Best PracticesFormat your HTML in a way that enables crawlers to better understand your app’s content. Document does not have a meta description Crawling and IndexingTo appear in search results, crawlers need access to your app. Page is blocked from indexing Additional items to manually check (1) Run these additional validators on your site to check additional SEO best practices. Passed audits (7) Not applicable (3) Progressive Web App These checks validate the aspects of a Progressive Web App. Learn more. Fast and reliable Page load is not fast enough on mobile networksYour page loads too slowly and is not interactive within 10 seconds. Look at the opportunities and diagnostics in the "Performance" section to learn how to improve. Interactive at 96.5 s Current page does not respond with a 200 when offline start_url does not respond with a 200 when offlineTimed out waiting for start_url to respond. Installable Uses HTTPS Does not register a service worker that controls page and start_url Web app manifest does not meet the installability requirementsFailures: Manifest does not have a PNG icon of at least 192px, Manifest's display value is not one of: minimal-ui | fullscreen | standalone, Manifest does not have short_name, Manifest does not have name. PWA Optimized Redirects HTTP traffic to HTTPS Is not configured for a custom splash screenFailures: Manifest does not have a PNG icon of at least 512px, Manifest does not have background_color, Manifest does not have theme_color, Manifest does not have name. Does not set a theme color for the address bar.Failures: Manifest does not have theme_color, No <meta name="theme-color"> tag found. Content is sized correctly for the viewport Does not have a <meta name="viewport"> tag with width or initial-scaleNo <meta name="viewport"> tag found Contains some content when JavaScript is not available Does not provide a valid apple-touch-icon Additional items to manually check (3) These checks are required by the baseline PWA Checklist but are not automatically checked by Lighthouse. They do not affect your score but it's important that you verify them manually. Runtime Settings URL https://www.facebook.com/ Fetch time Apr 1, 2020, 8:01 PM EDT Device Emulated Desktop Network throttling 150 ms TCP RTT, 1,638.4 Kbps throughput (Simulated) CPU throttling 4x slowdown (Simulated) User agent (host) Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36 Edg/80.0.361.69 User agent (network) Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3694.0 Safari/537.36 Chrome-Lighthouse CPU/Memory Power 192 Generated by Lighthouse 5.7.0 | File an issue /*# sourceURL=audits/lighthouse/template.html */

closed time in 8 hours

Str84DaHead

delete branch GoogleChrome/chrome-launcher

delete branch : prepublish

delete time in 11 hours

create barnchGoogleChrome/chrome-launcher

branch : prepublish

created branch time in 11 hours

delete branch GoogleChrome/chrome-launcher

delete branch : prepublish

delete time in 11 hours

push eventGoogleChrome/chrome-launcher

Paul Irish

commit sha 9aa64d642d3af13e447f8f84cacb05e556ff036e

add prepublish script (#193)

view details

push time in 11 hours

PR merged GoogleChrome/chrome-launcher

add prepublish script

Just want to make sure I build before publishing.

lol prepublish vs prepublishOnly: https://docs.npmjs.com/misc/scripts#prepublish-and-prepare

+2 -1

0 comment

1 changed file

paulirish

pr closed time in 11 hours

PR opened GoogleChrome/lighthouse

deps: upgrade chrome-launcher@0.13.1

fixes #10534

+26 -7

0 comment

2 changed files

pr created time in 11 hours

create barnchGoogleChrome/lighthouse

branch : depscl

created branch time in 11 hours

release GoogleChrome/chrome-launcher

v0.13.1

released time in 12 hours

push eventGoogleChrome/chrome-launcher

Paul Irish

commit sha 2289dcd2ada22b7418511b2ce818fffdd9e9035a

update changelog

view details

push time in 12 hours

PR opened GoogleChrome/chrome-launcher

add prepublish script

Just want to make sure I build before publishing.

lol prepublish vs prepublishOnly: https://docs.npmjs.com/misc/scripts#prepublish-and-prepare

+2 -1

0 comment

1 changed file

pr created time in 12 hours

create barnchGoogleChrome/chrome-launcher

branch : prepublish

created branch time in 12 hours

push eventGoogleChrome/chrome-launcher

Paul Irish

commit sha d4d82213f3704437ffbb3a3dd3b8d21c56d65cc7

v0.13.1

view details

push time in 12 hours

created tagGoogleChrome/chrome-launcher

tagv0.13.1

Launch Google Chrome with ease from node.

created time in 12 hours

issue commentWICG/element-timing

non-timing-allow images fall back to load time

Ahhhhhh the renderTime is 0, but startTime handles this fallback scenario just fine.

paulirish

comment created time in a day

issue closedWICG/element-timing

non-timing-allow images fall back to load time

The spec says renderTime falls back to the onload time, right? https://wicg.github.io/element-timing/#sec-security

There's two spots in the explainer where it says those cases fallback to 0.\

L35 and L56

cc https://github.com/WICG/largest-contentful-paint/issues/54

closed time in a day

paulirish

issue openedWICG/element-timing

non-timing-allow images fall back to load time

The spec says renderTime falls back to the onload time, right? https://wicg.github.io/element-timing/#sec-security

There's two spots in the explainer where it says those cases fallback to 0.\

L35 and L56

cc https://github.com/WICG/largest-contentful-paint/issues/54

created time in a day

fork paulirish/element-timing

A proposal for an Element Timing specification.

https://wicg.github.io/element-timing/

fork in a day

issue commentWICG/largest-contentful-paint

Call back to indicate that the observer is about to stop

I was hoping that the first-input entries with PO would indicate this, but they don't fire on trusted scrolls, so it's not a reliable signal. :/

DanShappir

comment created time in a day

push eventpaulirish/lh-scorecalc

Paul Irish

commit sha e65c5e77e84835d69eed693266f5562126e945c2

debounce at 500ms intead of 1000ms

view details

Paul Irish

commit sha 658c500a62f82b7f8fe6bc55fa5389d84b782a67

rollup workin

view details

Paul Irish

commit sha 31e09a7a739e94d586c4691ba075f28ed4a8d502

local webfont

view details

Paul Irish

commit sha 63d91d878f3cf14acd2e4bcdafda6d3a410b34be

opportunity

view details

Paul Irish

commit sha 7c40f3a25c5147f052ada3765e4708d8049a368e

add dist

view details

Paul Irish

commit sha 5fc37e78770d59fa443f8e9e25b59f34de439c54

add util.js

view details

Paul Irish

commit sha e38854600952e7bcf13d4a639336e1bbac6f52a6

CLIENT SIDE RENDER WEEEE

view details

Paul Irish

commit sha 96e4d356aa483bcedf466c8df245954234ea0f22

move into main() func and reformat. no functional changes.

view details

Paul Irish

commit sha 8fd0735e54f9c483fa470b99c9a9ea190ba32f5f

v5 and v6

view details

Paul Irish

commit sha ddb53eb3912b733c93eaebdec05bee83d606f751

more narrow display

view details

Paul Irish

commit sha 51372fb94e139b8d128bc104f5f77ca9dbaa0a7a

drop commented out weird thing

view details

Paul Irish

commit sha 1fff493b560b7ef03f68059f8c4cfba6991f88ed

output style

view details

Paul Irish

commit sha 99bffeecde1b444bfc4683a63950c8df7ca9fde7

responsive layout

view details

Paul Irish

commit sha dc70ef577031073a877fcd56ede341e7d0af9f2a

tweak breakpoint

view details

Paul Irish

commit sha 5d8bbef177a4e4c085f69eb8276a5502adc5be6f

v5 on top

view details

Paul Irish

commit sha 61fca0a6c4fa8722046ad079f076dbe1fa63b17b

add step attribute on sliders

view details

Paul Irish

commit sha af6e27f995a71a3b7bf4afd73a7f4ae13086062a

readme. screenshot etc

view details

Paul Irish

commit sha a96e72be0dc87be8ddacdcddae503eba045f64b5

weighting column at end

view details

Paul Irish

commit sha b969d1868bd9c76b655cdd43408b372ab536c3c0

npm run watch

view details

Paul Irish

commit sha ab3b93075fb91371050d40e867d2d4bb7fc36f9a

adding CLS. first bits.

view details

push time in a day

create barnchpaulirish/lh-scorecalc

branch : prerebase

created branch time in a day

issue commentHTTPArchive/httparchive.org

Replace the Loading Speed report with CrUX

Strong +1. It's far too easy to draw wrong conclusions based on current synthetic tests running on oversubscribed VMs.

FWIW, WPT uses n1-standard-2, which should be fine according to the Lighthouse recommended machine specs. It'd be concerning if it were using n1-standard-1. (And of course a beefier machine may improve variability, but we currently haven't collected data to quantify the degree.)

rviscomi

comment created time in 2 days

push eventChromeDevTools/devtools-protocol

devtools-bot

commit sha 166a751add4234be0064a16ffb22ed0ff43fbb17

Updates

view details

push time in 2 days

pull request commentGoogleChrome/lighthouse

core: surface LCP element in Lighthouse Report (WIP)

@Beytoven could you also add the CLS nodes into this PR as well?

Beytoven

comment created time in 3 days

pull request commentGoogleChrome/lighthouse

i18n: make double dollar validation less strict

@piotrzarycki will you be able to look at this?

piotrzarycki

comment created time in 3 days

push eventGoogleChrome/lighthouse

Paul Irish

commit sha 2df154402059a3a8ea9e0d9cc1ace085c04977a4

Update new-audits.md

view details

push time in 3 days

push eventGoogleChrome/lighthouse

Paul Irish

commit sha 2edad0df4e81d5e7cfc7210a9ab9ad11fb4efa34

empty

view details

push time in 3 days

Pull request review commentGoogleChrome/lighthouse

core: surface LCP element in Lighthouse Report (WIP)

 class LargestContentfulPaint extends Audit {     };   } +  /**+   * @param {LH.Artifacts.TraceNode[]} traceNodes+   * @return {LH.Audit.Details.Table['items']}+   */+  static getNodeData(traceNodes) {+    const lcpNode = traceNodes.find(node => node.type === 'lcp');

seeing this type so close to the type thats on L59 makes me think this one should have a different name.. we could go all the way to auditRef or stay with a fairly loose tag.

Beytoven

comment created time in 5 days

Pull request review commentGoogleChrome/lighthouse

core: surface LCP element in Lighthouse Report (WIP)

   75% { opacity: 1; }   100% { opacity: 1;  filter: drop-shadow(1px 0px 1px #aaa) drop-shadow(0px 2px 4px hsla(206, 6%, 25%, 0.15)); pointer-events: auto; } }++/*# sourceURL=report-styles.css */

👍

Beytoven

comment created time in 5 days

Pull request review commentGoogleChrome/lighthouse

core: surface LCP element in Lighthouse Report (WIP)

 class PerformanceCategoryRenderer extends CategoryRenderer {     const descriptionEl = this.dom.find('.lh-metric__description', tmpl);     descriptionEl.appendChild(this.dom.convertMarkdownLinkSnippets(audit.result.description)); +    if (audit.result.details) {

convention would be adding something like // HACK! to call out this is a temporary thing ;)

Beytoven

comment created time in 5 days

Pull request review commentGoogleChrome/lighthouse

core: surface LCP element in Lighthouse Report (WIP)

 class Driver {     return flattenedDocument.nodes ? flattenedDocument.nodes : [];   } +  /**+   * @param {number} nodeId+   * @param {string} attributeName+   * @param {string} attributeValue +   */+  async setNodeAttribute(nodeId, attributeName, attributeValue) {

IMO its fine to move this method back into your trace-nodes gatherer. and just inline it.

Beytoven

comment created time in 5 days

Pull request review commentGoogleChrome/lighthouse

core: surface LCP element in Lighthouse Report (WIP)

+/**+ * @license Copyright 2020 Google Inc. All Rights Reserved.+ * Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0+ * Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.+ */+'use strict';++const Gatherer = require('./gatherer.js');+const pageFunctions = require('../../lib/page-functions.js');+const TraceProcessor = require('../../lib/tracehouse/trace-processor.js');++/**+ * @return {LH.Artifacts['TraceNodes']}+ */+function collectTraceNodes() {+	/** @type {Array<HTMLElement>} */+	// @ts-ignore - put into scope via stringification+	const markedElements = getElementsInDocument('[lhtemp]'); // eslint-disable-line no-undef+	/** @type {LH.Artifacts['TraceNodes']} */+	const traceNodes = [];+

we should remove the lhtemp attribute here, in order to avoid this:

image

Beytoven

comment created time in 5 days

Pull request review commentGoogleChrome/lighthouse

core: surface LCP element in Lighthouse Report (WIP)

+/**+ * @license Copyright 2020 Google Inc. All Rights Reserved.+ * Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0+ * Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.+ */+'use strict';++const Gatherer = require('./gatherer.js');+const pageFunctions = require('../../lib/page-functions.js');+const TraceProcessor = require('../../lib/tracehouse/trace-processor.js');++/**+ * @return {LH.Artifacts['TraceNodes']}+ */+function collectTraceNodes() {+	/** @type {Array<HTMLElement>} */+	// @ts-ignore - put into scope via stringification

could you take care of these lint issues?

Beytoven

comment created time in 5 days

Pull request review commentGoogleChrome/lighthouse

misc(compare-runs): fix filter, allow for resume, reorganize output

 function aggregateResults(name) { }  /**- * @param {*[]} results+ * @param {Array<{name: string}>} results  */ function filter(results) {   const includeFilter = argv.filter ? new RegExp(argv.filter, 'i') : null;    results.forEach((result, i) => {     for (const propName of Object.keys(result)) {-      if (reportExcludeRegex && reportExcludeRegex.test(propName)) delete result[propName];+      if (reportExcludeRegex && reportExcludeRegex.test(propName)) {+        // @ts-ignore: propName is a key.+        delete result[propName];+      }     } -    if (includeFilter && !includeFilter.test(result.key)) {+    if (includeFilter && !includeFilter.test(result.name)) {

keeping it on key meant you can do --filter=metric (which is documented and i really like)

we could use something else for metric/timing filtering vs this regex on name tho.

connorjclark

comment created time in 5 days

Pull request review commentGoogleChrome/lighthouse

misc(compare-runs): fix filter, allow for resume, reorganize output

 function round(value) {  * @return {string}  */ function getProgressBar(i, total = argv.n * argv.urls.length) {-  return new Array(Math.round(i * 40 / total)).fill('▄').join('').padEnd(40);+  const bars = new Array(Math.round(i * 40 / total)).fill('▄').join('').padEnd(40);+  return `${i} / ${total} [${bars}]`;

the math here is off. i is unique per URL and you want i+1

here's a good repro:

node lighthouse-core/scripts/compare-runs.js --name my-collectiondeleteme --gather -n 2 --urls https://www.example.com http://example.com
connorjclark

comment created time in 5 days

issue openedtreosh/lighthouse-ci-action

Recipe for separate Lighthouse job

@snugug shared a cool Github Actions pattern he's using to run multiple jobs in parallel but only after the project has been built. Basically it's a combo of the needs job property combined with uploading/downloading artifacts.

it gives two benefits:

  1. you can do jobs in parallel, to get all CI finishing faster.
  2. a separate 'commit status' item for Lighthouse. Sam sez he likes this especially depending on how he did his budgets. maybe some are required and others more optional.

https://github.com/chromeos/static-site-scaffold/blob/master/.github/workflows/nodejs.yml shows it in use. pretend the commented-out job is still there. ;)


users of this action probably would like to use this kinda pattern.

created time in 6 days

issue commentGoogleChrome/lighthouse

Installable section passes but Chrome doesn't allow install

Yup agreed with @patrickhulce. let's look for a fetch handler. (artifacts.InstallabilityErrors should actually have this, so it should be straightforward)

connorjclark

comment created time in 6 days

push eventChromeDevTools/devtools-protocol

devtools-bot

commit sha 19b8ef98a11a0c98407cd2794a8f0cfb83711e38

Updates

view details

push time in 7 days

issue commentGoogleChrome/lighthouse

Lighthouse commandline utility doesnt display results under categories

you were so close!

run --help and you'll see the valid arguments:

  --only-categories              Only run the specified categories. Available categories: accessibility, best-practices, performance, pwa, seo

basically instead of "Best Practices" you want "best-practices", etc..

so you want

lighthouse "https:\\www.xxx.com" --only-categories=seo --only-categories=performance --only-categories=accessibility --only-categories=best-practices --output html --outputPath C:\sample\sample.html
waniparag

comment created time in 7 days

push eventGoogleChrome/lighthouse

Paul Irish

commit sha 025c778fd28f7e13fc2709d6e6b84d6327efc1d0

wording

view details

push time in 7 days

PR opened GoogleChrome/lighthouse

docs: add a guide to running Lighthouse at scale

A partner wanted some high level guidance on this topic and I thought it'd make decent sense to have here in the repo.

Any high level thoughts before ya'll tear me apart in the details?

+42 -0

0 comment

1 changed file

pr created time in 7 days

push eventGoogleChrome/lighthouse

Paul Irish

commit sha d7dbdd47d3fd2c2f6a085c22618a268fa82ffbfe

wording

view details

push time in 7 days

push eventGoogleChrome/lighthouse

Paul Irish

commit sha b7d001eb76b21927afa0f936d6ae780f4e728f64

add another link to variability

view details

push time in 7 days

create barnchGoogleChrome/lighthouse

branch : atscale

created branch time in 7 days

pull request commentGoogleChrome/lighthouse

docs: add recipe for using lighthouse modules directly

we can improve as necessary. seems fine to start with it rough.

Can I interest you in a gist, then? Or an entry in https://github.com/GoogleChrome/lighthouse/blob/master/docs/hacking-tips.md ? :)

okay yeah. sounds good. a gist that's linked from hacking-tips!

connorjclark

comment created time in 7 days

Pull request review commentGoogleChrome/lighthouse

docs: add recipe for using lighthouse modules directly

+/**+ * @license Copyright 2020 The Lighthouse Authors. All Rights Reserved.+ * Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0+ * Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.+ */+'use strict';++const fs = require('fs');++const makeDevtoolsLog = require('lighthouse/lighthouse-core/test/network-records-to-devtools-log.js');+const ModuleDuplication = require('lighthouse/lighthouse-core/computed/module-duplication.js');+const DuplicatedJavascript = require('lighthouse/lighthouse-core/audits/byte-efficiency/duplicated-javascript.js');+const LegacyJavascript = require('lighthouse/lighthouse-core/audits/legacy-javascript.js');++/**+ * @param {Array<{url: string, content: string, map: any}>} scriptDatas+ */+function createGathererData(scriptDatas) {+  const SourceMaps = scriptDatas.map(data => {+    return {+      scriptUrl: data.url,+      map: data.map,+    };+  });+  const ScriptElements = scriptDatas.map((data, i) => {+    return {+      requestId: `1000.${i}`,+      src: data.url,+      content: data.content,+    };+  });+  const networkRecords = scriptDatas.map((data, i) => {+    return {+      requestId: `1000.${i}`,+      url: data.url,+      content: data.content,+    };+  });+  networkRecords.push({url: 'https://www.example.com', resourceType: 'Document'});++  const artifacts = {+    URL: {finalUrl: 'https://www.example.com'},+    devtoolsLogs: {defaultPass: makeDevtoolsLog(networkRecords)},+    SourceMaps,+    ScriptElements,+  };++  return {+    artifacts,+    networkRecords,+  };+}++async function run() {

@prateekbh connor convinced me its fine to keep this recipe super hardcoded because anyone we expect to use it is gonna have to do some work. :).

but basically feel free to take the file and do the changes i suggested on your own.

if you continue using this and it makes sense for us to offer this as a real supported API, we can do that (eg. lighthouse.analyzedJSBundles(arr)), but it's too early right now to commit to that.

connorjclark

comment created time in 7 days

issue closedGoogleChrome/lighthouse

Bug report

<!-- Before creating an issue please make sure you are using the latest version and have checked for duplicate issues. -->

<!-- Before creating an Accessibility issue please test that it is reproducible upstream with axe (https://www.deque.com/axe/) first and file the issue there if necessary. -->

Provide the steps to reproduce

  1. Run LH on <affected url>

<!-- If your page is only local, or is liable to change, consider uploading a repro so that we can more easily debug the problem. Some services that will help are: https://jsbin.com/, https://surge.sh/ -->

What is the current behavior?

What is the expected behavior?

Environment Information

  • Affected Channels: <!-- CLI, Node, Extension, DevTools -->
  • Lighthouse version:
  • Chrome version: <!-- chrome://version/ -->
  • Node.js version:
  • Operating System:

Related issues

closed time in 7 days

pubgpartnership

issue closedGoogleChrome/lighthouse

فاعل خير

يقدم لكم اليوم موقع

تهكير ببجي موبايل اخر اصدار 2020

رابط الموقع http://pubgmobile.coolcheat.club/

للتعليم كيفيه استخدام الموقع

رابط الفيديو التعليم

[https://youtu.be/w8HdumIJHUQ]

ارجو الاشتراك بل قناه الجديد تبع الفيديو التعليمي

اي استفسار حول الموقع ارجو التواصل اترك تعليق

closed time in 7 days

pubgpartnership

issue closedGoogleChrome/lighthouse

فاعل خير

يقدم لكم اليوم موقع

تهكير ببجي موبايل اخر اصدار 2020

رابط الموقع http://pubgmobile.coolcheat.club/

للتعليم كيفيه استخدام الموقع

رابط الفيديو التعليمي https://youtu.be/w8HdumIJHUQ

ارجو الاشتراك بل قناه الجديد تبع الفيديو التعليمي

اي استفسار حول الموقع ارجو التواصل فل تعليقات وانشاء الله ارد عليكم باسرع وقت

closed time in 7 days

pubgpartnership

Pull request review commentGoogleChrome/lighthouse

docs(variability): expand on hardware recommendations

 Below is a table containing several common sources of metric variability, the ty  ## Strategies for Dealing With Variance +### Run on Adequate Hardware++Loading modern webpages on a modern browser is not an easy task. Using appropriately powerful hardware can make a world of difference when it comes to variability.++- Minimum 2 dedicated cores

and 4+ vCPU recommended?

patrickhulce

comment created time in 8 days

Pull request review commentGoogleChrome/lighthouse

docs(variability): expand on hardware recommendations

 Below is a table containing several common sources of metric variability, the ty  ## Strategies for Dealing With Variance +### Run on Adequate Hardware++Loading modern webpages on a modern browser is not an easy task. Using appropriately powerful hardware can make a world of difference when it comes to variability.++- Minimum 2 dedicated cores+- Minimum 2GB RAM (4-8GB recommended)+- Avoid non-standard Chromium flags (`--single-process` is not supported, `--no-sandbox` and `--headless` should be OK, though educate yourself about [sandbox tradeoffs](https://github.com/GoogleChrome/lighthouse-ci/tree/fbb540507c031100ee13bf7eb1a4b61c79c5e1e6/docs/recipes/docker-client#--no-sandbox-issues-explained))+- Avoid function-as-a-service infrastructure (Lambda, GCF, etc)+- Avoid "burstable" or "shared-core" instance types (AWS `t` instances, GCP shared-core N1 and E2 instances, etc)++`m5.large` on AWS, `n2-standard-2` on GCP, and `D2` on Azure or better all should be sufficient to run a single Lighthouse run at a time (~$0.10/hour for these instance types, ~30s/test, ~$0.0008/Lighthouse report). While some environments that don't meet the requirements above will still be able to run Lighthouse and the non-performance results will still be usable, we'd advise Remember, running on inconsistent hardware will lead to inconsistent results!+ ### Isolate External Factors  - Isolate your page from third-party influence as much as possible. It’s never fun to be blamed for someone else's variable failures. - Isolate your own code’s nondeterminism during testing. If you’ve got an animation that randomly shows up, your performance numbers might be random too! - Isolate your test server from as much network volatility as possible. Use localhost or a machine on the same exact network whenever stability is a concern.-- Isolate your client environment from external influences like anti-virus software and browser extensions. Use a dedicated device for testing when possible.+- Isolate your client environment from external influences like anti-virus software and browser extensions. **DO NOT RUN MULTIPLE LIGHTHOUSE RUNS AT THE SAME TIME**. Use a dedicated device for testing when possible.  If your machine has really limited resources or creating a clean environment has been difficult, use a hosted lab environment like PageSpeed Insights or WebPageTest to run your tests for you. In continuous integration situations, use dedicated servers when possible. Free CI environments and “burstable” instances are typically quite volatile.  ### Run Lighthouse Multiple Times  When creating your thresholds for failure, either mental or programmatic, use aggregate values like the median, 90th percentile, or even min instead of single tests. -The median Lighthouse score of 5 runs is twice as stable as 1 run, and tools like [pwmetrics](https://github.com/paulirish/pwmetrics) can run Lighthouse for you automatically. Using the minimum value is also a big improvement over not testing at all and is incredibly simple to implement, just run Lighthouse up to 5 times until it passes!+The median Lighthouse score of 5 runs is twice as stable as 1 run, and tools like [pwmetrics](https://github.com/paulirish/pwmetrics) or [lighthouse-ci](https://github.com/GoogleChrome/lighthouse-ci/) can run Lighthouse multiple times for you automatically. Using the minimum value is also a big improvement over not testing at all and is incredibly simple to implement, just run Lighthouse up to 5 times until it passes!

yeah lets :)

patrickhulce

comment created time in 8 days

Pull request review commentGoogleChrome/lighthouse

docs(variability): expand on hardware recommendations

 Below is a table containing several common sources of metric variability, the ty  ## Strategies for Dealing With Variance +### Run on Adequate Hardware++Loading modern webpages on a modern browser is not an easy task. Using appropriately powerful hardware can make a world of difference when it comes to variability.++- Minimum 2 dedicated cores+- Minimum 2GB RAM (4-8GB recommended)+- Avoid non-standard Chromium flags (`--single-process` is not supported, `--no-sandbox` and `--headless` should be OK, though educate yourself about [sandbox tradeoffs](https://github.com/GoogleChrome/lighthouse-ci/tree/fbb540507c031100ee13bf7eb1a4b61c79c5e1e6/docs/recipes/docker-client#--no-sandbox-issues-explained))+- Avoid function-as-a-service infrastructure (Lambda, GCF, etc)+- Avoid "burstable" or "shared-core" instance types (AWS `t` instances, GCP shared-core N1 and E2 instances, etc)++`m5.large` on AWS, `n2-standard-2` on GCP, and `D2` on Azure or better all should be sufficient to run a single Lighthouse run at a time (~$0.10/hour for these instance types, ~30s/test, ~$0.0008/Lighthouse report). While some environments that don't meet the requirements above will still be able to run Lighthouse and the non-performance results will still be usable, we'd advise against it and won't be able to support those environments should any bugs arise. Remember, running on inconsistent hardware will lead to inconsistent results!
AWS's `m5.large`, GCP's `n2-standard-2`, and Azure's `D2` all should be sufficient to run a single Lighthouse run at a time (~$0.10/hour for these instance types, ~30s/test, ~$0.0008/Lighthouse report). While some environments that don't meet the requirements above will still be able to run Lighthouse and the non-performance results will still be usable, we'd advise against it and won't be able to support those environments should any bugs arise. Remember, running on inconsistent hardware will lead to inconsistent results!
patrickhulce

comment created time in 8 days

Pull request review commentGoogleChrome/lighthouse

docs(variability): expand on hardware recommendations

 Below is a table containing several common sources of metric variability, the ty  ## Strategies for Dealing With Variance +### Run on Adequate Hardware++Loading modern webpages on a modern browser is not an easy task. Using appropriately powerful hardware can make a world of difference when it comes to variability.++- Minimum 2 dedicated cores+- Minimum 2GB RAM (4-8GB recommended)+- Avoid non-standard Chromium flags (`--single-process` is not supported, `--no-sandbox` and `--headless` should be OK, though educate yourself about [sandbox tradeoffs](https://github.com/GoogleChrome/lighthouse-ci/tree/fbb540507c031100ee13bf7eb1a4b61c79c5e1e6/docs/recipes/docker-client#--no-sandbox-issues-explained))+- Avoid function-as-a-service infrastructure (Lambda, GCF, etc)+- Avoid "burstable" or "shared-core" instance types (AWS `t` instances, GCP shared-core N1 and E2 instances, etc)++`m5.large` on AWS, `n2-standard-2` on GCP, and `D2` on Azure or better all should be sufficient to run a single Lighthouse run at a time (~$0.10/hour for these instance types, ~30s/test, ~$0.0008/Lighthouse report). While some environments that don't meet the requirements above will still be able to run Lighthouse and the non-performance results will still be usable, we'd advise against it and won't be able to support those environments should any bugs arise. Remember, running on inconsistent hardware will lead to inconsistent results!++**DO NOT** collect multiple Lighthouse reports at the same time on the same machine. The lighthouse node module is built as a singleton and concurrent runs can interfere with the results. When it comes to Lighthouse runs, scaling horizontally is better than scaling vertically (i.e. run with 4 `n2-standard-2` instead of 1 `n2-standard-8`).
**DO NOT** collect multiple Lighthouse reports at the same time on the same machine. Concurrent runs can skew performance results due to resource contention. When it comes to Lighthouse runs, scaling horizontally is better than scaling vertically (i.e. run with 4 `n2-standard-2` instead of 1 `n2-standard-8`).

how about emphasizing the perf skew instead of the technical reasons? (we dont want them using child processes to solve the singleton)

patrickhulce

comment created time in 8 days

push eventChromeDevTools/devtools-protocol

devtools-bot

commit sha 270ebae7a2ead5c6884cd3dec019b61ca52e4308

Updates

view details

push time in 8 days

push eventpaulirish/lh-scorecalc

Glitch (how-much-faster)

commit sha 190bed715a3589601f314b3c8a50fb0fb147c121

add todo

view details

push time in 8 days

pull request commentGoogleChrome/web.dev

adds article for preloading optional fonts

@housseindjirdeh got a link to a crbug or chromium CL regarding this chrome change? i'm curious.

housseindjirdeh

comment created time in 8 days

push eventpaulirish/lh-scorecalc

Glitch (how-much-faster)

commit sha 928d3177d6f2c2c95796f15283a99232437ac4e4

localstorage fixups mostly

view details

Glitch (how-much-faster)

commit sha 0f529678fde34a282474eb2eb1b0a0e96ee1cb88

dont need to dispatch input event

view details

Glitch (how-much-faster)

commit sha 044f1e693b31325b36e51ebff7560f34cb7d3749

sourcemap

view details

push time in 8 days

push eventChromeDevTools/devtools-protocol

devtools-bot

commit sha 6128b45385587d3dc8d89d2247517174254f54a8

Updates

view details

push time in 8 days

push eventChromeDevTools/devtools-protocol

devtools-bot

commit sha 7c4cfa7c1d20423743c45957928ca7a66683cfb2

Updates

view details

push time in 8 days

push eventpaulirish/lh-scorecalc

Glitch (how-much-faster)

commit sha ac54ec6840e1842d33dc6f14af7d378c1a174b05

weighting column at end

view details

Glitch (how-much-faster)

commit sha a3e5c25f1e90baa5008a2e3616127815679c9663

npm run watch

view details

Glitch (how-much-faster)

commit sha 955cca236609b62864bdc5cdeb97b4dc9eccc72d

adding CLS. first bits.

view details

Glitch (how-much-faster)

commit sha 66b71cb5c32151e077a7012975b99f424b3b01f7

CLS is done

view details

Glitch (how-much-faster)

commit sha 16159c35b29001962444038897f9e38d3bfbc1d6

lighthouse-y styling. LOTS of css vars i could delete.

view details

Glitch (how-much-faster)

commit sha 59c74876b2d632fd8c6ab691b145120f3b2383c3

fix temp storage of v5 and v6

view details

Glitch (how-much-faster)

commit sha bdaceaea724a86f8ff84f5258b344e6332ebd017

gitignore and yarn.lock

view details

push time in 9 days

Pull request review commentGoogleChrome/lighthouse-ci

fix(server): use friendly error message for statistic computation

 const Resource404 = () => {  /**  * @template T- * @param {{loadingState: LoadingState, asyncData: T | undefined, render: (data: T) => JSX.Element, renderLoading?: () => JSX.Element}} props */+ * @param {{loadingState: LoadingState, asyncData: T | undefined, render: (data: T) => JSX.Element, renderLoading?: () => JSX.Element, renderError?: () => JSX.Element}} props */ export const AsyncLoader = props => {-  const {asyncData, loadingState, render, renderLoading} = props;+  const {asyncData, loadingState, render, renderLoading, renderError} = props;    if (loadingState === 'loaded') {     return asyncData === undefined ? <Resource404 /> : render(asyncData);   } else if (loadingState === 'error') {-    return <h1>Lighthouse Error</h1>;+    return renderError ? renderError() : <h1>Lighthouse Error</h1>;

is it more accurate to say "Lighthouse CI Server Error" instead of "Lighthouse Error" ? if so, i'd love to, just to help people understand .

patrickhulce

comment created time in 9 days

Pull request review commentGoogleChrome/lighthouse-ci

fix(server): use friendly error message for statistic computation

 export const CategoryCard = props => {           loadingState={props.loadingState}           asyncData={props.statistics}           renderLoading={() => <span>Loading, please wait...</span>}+          renderError={() => (+            <span style={{textAlign: 'center'}}>+              Woah, looks like there&apos;s a lot of data here!+              <br />+              Statistics are being computed now. Please try again in a few minutes.

👍

patrickhulce

comment created time in 9 days

PR opened GoogleChrome/lighthouse

core(scoring): update CLS score curve - 0.25 is now failing

keeping up with the joneses.

CLS of 0.25 and above is now considered failing tweak the PODR to make sure CLS 0.10 is still a score of 90/100

+5 -5

0 comment

3 changed files

pr created time in 10 days

create barnchGoogleChrome/lighthouse

branch : clsscurve

created branch time in 10 days

push eventChromeDevTools/devtools-protocol

devtools-bot

commit sha 25ae62b8f35d927b22b9842b3fd8a6d592bfcedf

Updates

view details

push time in 10 days

PR opened paularmstrong/build-tracker

include date in tooltip

Problem

When using buildtracker I had a hard time understanding where I was in the X axis.

Solution

I added the date of the build into the tooltip.

image

TODO

  • [ ] 🤓 Add & update tests (always try to increase test coverage)
  • [ ] 🔬 Ensure CI is passing (yarn lint:ci, yarn test, yarn tsc:ci)
  • [ ] 📖 Update relevant documentation

I didn't write a test yet but wanted to get your early feedback on this. :)

+23 -5

0 comment

2 changed files

pr created time in 12 days

push eventpaulirish/build-tracker

Paul Irish

commit sha 79cc013f71d2907df75a13cba1917beec101d517

use timestamp directly

view details

push time in 12 days

push eventChromeDevTools/debugger-protocol-viewer

Tom Bridgwater

commit sha d7926fef4a2605191c7aba83efb14c698399ad65

readme: add instructions to run bower install (#129)

view details

push time in 12 days

create barnchpaulirish/build-tracker

branch : tooltip

created branch time in 12 days

PR opened gsuitedevs/apps-script-samples

notification quickstart: remove destination sheet link

Forms nowadays do not have a destination, by default.

So this script ends up failing silently (to the user). In the error logs you'll see Exception: The form currently has no response destination

image

Since there's a link to the form summary already, I think the UX is still pretty fine.


The quickstart will be functional again once this PR, #144 and the docs CL are merged. \o/

+1 -4

0 comment

2 changed files

pr created time in 12 days

push eventpaulirish/apps-script-samples

Paul Irish

commit sha 52900602983a313fbaea910fa77a1cd9bb39b108

remove HTML link

view details

push time in 12 days

push eventpaulirish/apps-script-samples

Paul Irish

commit sha cf9897716ec9e5b7d5192a7bab9452e2614299d0

remove form destination URL gathering

view details

push time in 12 days

push eventpaulirish/apps-script-samples

Paul Irish

commit sha ac466d733b44160c1a788e0a31e6c9d9539eb5ff

and make HTML file casing consistent

view details

push time in 12 days

push eventpaulirish/apps-script-samples

Paul Irish

commit sha 1ad82ae41fc1835793d180dd716530b483c80927

Fix filename casing in notifications quickstart

view details

push time in 12 days

issue commentGoogleChrome/lighthouse

Lighthouse v6: cumulativeLayoutShift is rounded to 0 in metrics section

Great catch. I'll take care of this.

alekseykulikov

comment created time in 13 days

issue openedpaularmstrong/build-tracker-action

Usage for master branch

as you can tell i'm adopting bundletracker for Lighthouse. :)

we were using bundlesize but it's terrible and i hate it.

the first priority is to get the historical trendlines of our build sizes. I managed to iterate through 18 months of git history and upload all those builds: https://lh-build-tracker.herokuapp.com/builds/limit/1000

then, i wanted to get some CI set up to upload build stats for all our new commits on master. so I wrote a ghaction workflow to do that: https://github.com/paulirish/lighthouse/pull/57

However, the build-tracker-action basically expects to only run on: pull_request, it appears.
image (from https://github.com/paulirish/lighthouse/runs/520463822)

It's erroring on context.payload.pull_request.

For whatever reason I didn't think a workflow that's on: pull_request would run on push to master, but... does it?

created time in 13 days

delete branch paulirish/lighthouse

delete branch : buildtracker

delete time in 14 days

push eventpaulirish/lighthouse

Paul Irish

commit sha 3ff7933caeb5811971a1da9ab5a07e3485dd5b79

build: report to buildtracker on commit via ghactions (#57)

view details

push time in 14 days

PR merged paulirish/lighthouse

build: report to buildtracker on commit via ghactions

testing this out in my fork first...


I've set up https://buildtracker.dev/ and backfilled it with the last 18months of commits: https://lh-build-tracker.herokuapp.com/builds/limit/1000

image

The UX takes some clicking around to get used to but its pretty powerful.

This PR adds a github action workflow that will report to buildtracker for every master commit.

+53 -1

0 comment

3 changed files

paulirish

pr closed time in 14 days

push eventpaulirish/lighthouse

Paul Irish

commit sha 55578fec8eeae221cda959f1c8c7c9df785ab5f8

lint

view details

push time in 14 days

push eventpaulirish/lighthouse

Paul Irish

commit sha 1f6ceac0fae80cf3aa53f7b0a474e4b7fe1dcd59

lint

view details

Paul Irish

commit sha 9cebb718b4cba6928bd1086cf0236e4a5fb14672

workflow syntax

view details

push time in 14 days

PR opened paulirish/lighthouse

build: report to buildtracker on commit via ghactions

testing this out in my fork first...


I've set up https://buildtracker.dev/ and backfilled it with the last 18months of commits: https://lh-build-tracker.herokuapp.com/builds/limit/1000

image

The UX takes some clicking around to get used to but its pretty powerful.

This PR adds a github action workflow that will report to buildtracker for every master commit.

+48 -1

0 comment

3 changed files

pr created time in 14 days

create barnchpaulirish/lighthouse

branch : buildtracker

created branch time in 14 days

push eventpaulirish/lighthouse

Sebastian Kreft

commit sha 7904efb3d4526e7529fef0ff2566d1aff74c6306

core(ImageElements): add usesPixelArtScaling and usesSrcSetDensityDescriptor properties (#10481) * feature: add usesPixelArtScaling flag to images This new flag will be used by the ImageSizeResponsive audit (#10245), as those images are intendedly displayed in a pixelated form, so the audit should not flag them. Note that `image-rendering: -mo-crisp-edges;` is also an accepted value in Firefox, however in such case, the computed style will return `crips-edges`. * Fix how usesPixelArtRendering is computed Apparently the code is executed in another process, which means, that functions mus be inlined, otherwise the code needs to go through some extra hoops. * Add usesSrcSetDensityDescriptor

view details

push time in 14 days

create barnchGoogleChrome/lighthouse

branch : buildtracker

created branch time in 14 days

pull request commentGoogleChrome/lighthouse

docs: add recipe for using lighthouse modules directly

t's not really (just) using lighthouse modules directly (we've had example code for that for ages), it's more about

i was originally thinking audit-as-lib though it's not perfectly suited.

connorjclark

comment created time in 14 days

issue commentGoogleChrome/lighthouse-ci

"Lighthouse Error" after extending dashboard view to >=100 builds

I think the nicest UX would be something along the lines of "we've started computing those results, try again in a minute" or something and just keep you on the lower limit.

yeah i like this. Just changing the message to this is a great UX upgrade. :)

When you request ~100-200 at once it takes awhile and the underpowered heroku free tier times out.

presumably the nonfreetier would just take a while but definitely succeed?

paulirish

comment created time in 14 days

issue openedGoogleChrome/lighthouse-ci

"Lighthouse Error" after extending dashboard view to >=100 builds

At least that's what i'm seeing sometimes on the lhci canary instance.

https://lhci-canary.herokuapp.com/app/projects/ffb1f9c0-465f-4dc5-9407-1ed7e06ac7c4/dashboard?runUrl=http%3A%2F%2Flocalhost%3APORT%2Fapp%2Fprojects%2Flighthouse-viewer

What I saw:

  1. I tried MAX and got an error
  2. I tried 100 and got an error
  3. I tried 50 and it worked
  4. I tried 100 again and it worked.
  5. I tried MAX again and it worked.

Soooooooo it fails intermittently. 🤷‍♂

Since it works now I can't get a screenshot. Sorry.

created time in 14 days

push eventChromeDevTools/devtools-protocol

devtools-bot

commit sha 948385a8f5fcf8c0dfec80688c2a93fe23ec40de

Updates

view details

push time in 14 days

issue commentpaularmstrong/build-tracker

Error: [object Object]

Ahhh, so that's what it is :) We can definitely fix that over at paularmstrong/build-tracker-action

Hmmm. I haven't used the gh action at all yet, fwiw. This was just between my heroku instance and the CLI (that i globally installed with npm)

To get visibility I added a console.log({response}); right here: https://github.com/paularmstrong/build-tracker/blob/4c4e5e89c5bc237ed1fffb96864ac853b3f1a6c8/src/api-client/src/modules/upload-build.ts#L55


I've noticed that the GH action doesn't include secrets when it's run for PRs from forks of a repo. Searching around the forums, people have been complaining about it since actions were introduced :(

Yup. We ran into that with the lighthouse github action too. its frustrating, but from a security POV i totally get it.

paulirish

comment created time in 14 days

PR opened paularmstrong/build-tracker

docs: install the CLI not API client

What you had didn't work for me. I imagine you split out the CLI package later on?

:)

+1 -1

0 comment

1 changed file

pr created time in 14 days

push eventpaulirish/build-tracker

Paul Irish

commit sha d03a37215574277c3dde0eda7a37e62bbc75d586

docs: install the CLI not API client

view details

push time in 14 days

Pull request review commentpaularmstrong/build-tracker

docs: Fix CLI docs link & specific applicationUrl

 yarn add @build-tracker/api-client@latest  Create a configuration file, `build-tracker.config.js` -You will need, at a minimum, the `applicationUrl` string, and `artifacts` search locations set. For the full set of CLI options, refer to the [cli docs](cli).+You will need, at a minimum, the `applicationUrl` string, and `artifacts` search locations set. For the full set of CLI options, refer to the [cli docs](packages/cli/).  ```js module.exports = {-  applicationUrl: 'https://your-build-tracker-app', // The same as your server config `url`+  applicationUrl: 'https://your-build-tracker-app.herokuapp.com', // The same as your server config `url`

yah i had a feeling that was the case. changed. :)

paulirish

comment created time in 14 days

push eventpaulirish/build-tracker

Paul Irish

commit sha f1aeffb5128ed045008297df598b0ef364fd2db2

example.com

view details

push time in 14 days

pull request commentGoogleChrome/lighthouse

misc: ignore duplicate builds in lhci dogfood

oops didnt mean to steal from @brendankenny

patrickhulce

comment created time in 14 days

Pull request review commentGoogleChrome/lighthouse

misc: ignore duplicate builds in lhci dogfood

 npm install -g @lhci/cli@0.3.x # Collect our LHCI results. lhci collect --staticDistDir=./dist/now/english/ # Upload the results to our canary server.-lhci upload --serverBaseUrl="$LHCI_CANARY_SERVER_URL" --token="$LHCI_CANARY_SERVER_TOKEN" --github-token="$BUNDLESIZE_GITHUB_TOKEN"+lhci upload \+  --serverBaseUrl="$LHCI_CANARY_SERVER_URL" \+  --token="$LHCI_CANARY_SERVER_TOKEN" \+  --github-token="$BUNDLESIZE_GITHUB_TOKEN" \

hah just noticed this. funny that we just reuse.

admittedly all the GH tokens necessary within CI makes a mess so i'm not entirely surprised. :)

patrickhulce

comment created time in 14 days

push eventpaulirish/lh-build-tracker

Paul Irish

commit sha 71891516fcff2f167a8215811bf27b6e34f4451a

Update README.md

view details

push time in 14 days

more