{"_id":"web-vitals","_rev":"71-ca528f0c9e092c8fc4a2c6bd1ba7fd2b","name":"web-vitals","dist-tags":{"latest":"3.5.2","next":"4.0.0-beta.2","soft-navs":"3.5.2-soft-navs-16"},"versions":{"0.1.0":{"name":"web-vitals","version":"0.1.0","description":"Easily measure performance metrics in JavaScript","type":"module","main":"dist/web-vitals.min.js","exports":{".":"./dist/web-vitals.min.js","getCLS.js":"./dist/getCLS.js","getFCP.js":"./dist/getFCP.js","getFID.js":"./dist/getFID.js","getLCP.js":"./dist/getLCP.js"},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch serve","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build"},"keywords":["crux","performance","metrics","cls","fcp","fid","lcp","ttfb"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.9.0","@babel/preset-env":"^7.9.0","@typescript-eslint/eslint-plugin":"^2.24.0","@typescript-eslint/parser":"^2.24.0","@wdio/cli":"^5.22.3","@wdio/local-runner":"^5.22.3","@wdio/mocha-framework":"^5.18.7","@wdio/selenium-standalone-service":"^5.16.10","@wdio/spec-reporter":"^5.18.7","babel-eslint":"^10.1.0","body-parser":"^1.19.0","chromedriver":"^80.0.1","eslint":"^6.8.0","eslint-config-google":"^0.14.0","express":"^4.17.1","fs-extra":"^9.0.0","husky":"^4.2.3","npm-run-all":"^4.1.5","nunjucks":"^3.2.1","rollup":"^2.1.0","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^5.3.0","typescript":"^3.8.3","wdio-chromedriver-service":"^5.0.2"},"gitHead":"306fb9f6218dd00592f0e714dc513e62c0550f87","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@0.1.0","_nodeVersion":"10.17.0","_npmVersion":"6.14.3","dist":{"integrity":"sha512-6DuJUKRtNfpWpCuX63senthhK5+CbE3U4J/TRCoqMEMjZnxA+y9ovGtrnXwEtgoVoAn7d4JGDBqGQPT30NyT3Q==","shasum":"812ba4497d0035930a5fa7347117ea43d9f6eade","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-0.1.0.tgz","fileCount":73,"unpackedSize":125245,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJeoz+ZCRA9TVsSAnZWagAAx6QP/3yhGYVq+1MzC/+92dQH\nIQo7HVq5yjBpzmASWy5Sd6vPG+2cLdjLDoELB2O90mbPUyttXCCnflK4a1s0\n1Ur1uMVAh2HjIUN6KDmLTJIiroigo/SuPdUnYPvcyEmcEd3yGfIiCCNPHRjx\nnAszJKKl9k4vku9SPjxbBnRogkV0cU9HIHxQgrOZyEpAItNZtkThfYXrKfjL\nmGZVuFz2M3wsEv7wLjXXFxKhkWGxMItVEC8DzG29r5z+PBseTTv8NTxwI477\nbLVueRBre2uHzz1fQC1qXc28sKwC66svVeAJunbudsYHrQG+/+PJIpcnLQnO\nngEH+bol6ryI+JkDJ5wPhG6QdO43NhE5u7Lzc3aKaPOD4VtzQ4ukiM7kjoQU\nQzgppPs4vSu8x4WfENJa7UvOVb/5ZU2JA3kjXN1ogJoXu/CfhV7XdKAM4w1n\nkvNf/1KbF4pQDtOPH9C/HKD6FGLHgNNEF/Q4JQPyBBcX27HjzNeyMoodiRUp\n7XaOFHcFXrtmDOZQcgoEF9Zz9gH81HqSFdz21eqimHsehXdyvygm5JDHavVJ\n1hGNwnbs4BvGnH9gU08rlT7g3ifR0J2IXpPdF/YSiP9JMNEK2gwjKAvCs9AS\nz2QejkbzG01NES/4zp3tFoOQS7w6V5NhW+SvKBjPsCtGuFgeo0JeBg0XAua+\n1M+f\r\n=Kauw\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIGfR7kLi5DSTrCGIFtFDXYBmfyohNQzohVqtRo+6E+mkAiEAtgGA9zV/XkntCwPAFgfNkZpv5SOiGBeJFtjnwaXc/j0="}]},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_0.1.0_1587756953111_0.7389730549860394"},"_hasShrinkwrap":false},"0.2.0":{"name":"web-vitals","version":"0.2.0","description":"Easily measure performance metrics in JavaScript","type":"module","main":"dist/web-vitals.min.js","module":"dist/web-vitals.min.js","exports":{".":"./dist/index.js","getCLS.js":"./dist/getCLS.js","getFCP.js":"./dist/getFCP.js","getFID.js":"./dist/getFID.js","getLCP.js":"./dist/getLCP.js","getTTFB.js":"./dist/getTTFB.js"},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch serve","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build"},"keywords":["crux","performance","metrics","CLS","FCP","FID","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.9.0","@babel/preset-env":"^7.9.0","@typescript-eslint/eslint-plugin":"^2.24.0","@typescript-eslint/parser":"^2.24.0","@wdio/cli":"^5.22.3","@wdio/local-runner":"^5.22.3","@wdio/mocha-framework":"^5.18.7","@wdio/selenium-standalone-service":"^5.16.10","@wdio/spec-reporter":"^5.18.7","babel-eslint":"^10.1.0","body-parser":"^1.19.0","chromedriver":"^80.0.1","eslint":"^6.8.0","eslint-config-google":"^0.14.0","express":"^4.17.1","fs-extra":"^9.0.0","husky":"^4.2.3","npm-run-all":"^4.1.5","nunjucks":"^3.2.1","rollup":"^2.1.0","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^5.3.0","typescript":"^3.8.3","wdio-chromedriver-service":"^5.0.2"},"gitHead":"18e700501daeaea01aa9b8f8c3d9d7911c20d1fb","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@0.2.0","_nodeVersion":"10.17.0","_npmVersion":"6.14.3","dist":{"integrity":"sha512-ona3a5ZCoDopElyhLh0xGhGgz00h8uQVMx7lWJqvA33Px7amFAnfHm4R/oGQ29I3zZcC0rKBc1QO/5r9bY7iJg==","shasum":"a8531ad6c3f028b47074367a4ba531884c655c74","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-0.2.0.tgz","fileCount":50,"unpackedSize":81513,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJer6AYCRA9TVsSAnZWagAABrMQAJEt7QYQEw3lkv6zS+Z1\nQJcmITL/KslRIac57q7AO77cX3QvfD7eKkyOZGQAmprRYDxEkWSd7eTD6wyI\n2Vj5cgRf8ac9K24ahrOjAdRuhtDgsIbfcHRukQ2MECf/jHX4TvQwIjJdBcx8\n8oxwmu0hFaJmwh+ccXNPem79BrxtEfKUdr/59MO9hpL8tIGRkWQw9RqmqSXV\ng14z0n93mXhohmFLlm9IvtrmYB7odjjuz0jApogBluRNhJFsLSdkTdmhHg1u\nLtqPeNGp+zM/rKub/QtzrwTGDPfu5h5gjJXJRx5khmZYlfhEYGWvshDfW6i+\nr51XLH9eOeAj018LaN875/8KDgqi9wuhSNuhDNClCb0YCdYhmE1P0la5U5lj\nEvjB99W+U8ax+pGjPgLMMpatzLFQHpqI/qbf1hM2w11Zbr1beDp1p+Wqw5+J\nUtFD2QTsj4J0gXCsJ8t/5eciVkIR8tpUEES74QLh52CRqWzLSk3An8xQvcAx\nRYBsUkleGZDkNAQQ0Ii7T3GJpePv2+5ILo11c9bq4oire1gralqmrWIoqbA+\nR5RrDOlhnWwE3B80DM76MFN7mCzygJFSF+SWFtMoHPN9JpOFc727qwIhWu1U\nuvOa87CuvknmZttWAAqYQ/rN7MkoZIZKbOjALrTDJXIuVxedUV62MCbC0nJB\n/Zlq\r\n=3yHk\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIFMq+1rCyEU3vIMVz6pzQziVtaHsx2J7xwzckdPlZs+WAiEAlwn/EG0/292ow7cRQCXkY8pjhCMcsqToouhjaamMAVI="}]},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_0.2.0_1588568088209_0.10484684426014756"},"_hasShrinkwrap":false},"0.2.1":{"name":"web-vitals","version":"0.2.1","description":"Easily measure performance metrics in JavaScript","type":"module","main":"dist/web-vitals.es5.umd.min.js","module":"dist/web-vitals.es5.min.js","typings":"dist/index.d.ts","scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch serve","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build"},"keywords":["crux","performance","metrics","CLS","FCP","FID","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.9.0","@babel/preset-env":"^7.9.0","@typescript-eslint/eslint-plugin":"^2.24.0","@typescript-eslint/parser":"^2.24.0","@wdio/cli":"^5.22.3","@wdio/local-runner":"^5.22.3","@wdio/mocha-framework":"^5.18.7","@wdio/selenium-standalone-service":"^5.16.10","@wdio/spec-reporter":"^5.18.7","babel-eslint":"^10.1.0","body-parser":"^1.19.0","chromedriver":"^80.0.1","eslint":"^6.8.0","eslint-config-google":"^0.14.0","express":"^4.17.1","fs-extra":"^9.0.0","husky":"^4.2.3","npm-run-all":"^4.1.5","nunjucks":"^3.2.1","rollup":"^2.1.0","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^5.3.0","typescript":"^3.8.3","wdio-chromedriver-service":"^5.0.2"},"gitHead":"285c23ebdcb14fae8d5ecdc56106300f2d1d7a4b","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@0.2.1","_nodeVersion":"10.17.0","_npmVersion":"6.14.3","dist":{"integrity":"sha512-2pdRlp6gJpOCg0oMMqwFF0axjk5D9WInc09RSYtqFgPXQ15+YKNQ7YnBBEqAL5jvmfH9WvoXDMb8DHwux7pIew==","shasum":"60782fa690243fe35613759a0c26431f57ba7b2d","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-0.2.1.tgz","fileCount":48,"unpackedSize":82348,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJes7B3CRA9TVsSAnZWagAAbAIP/3Rt/4SEm1jYygJZEG3W\n7Fk27nDJsqfChnnz4IsCZBswqZhcpsBe4LCb1zFaIKmwZ+Ejy0hYX2NTFx4O\n45LDdbcYQIvFLtK8d5NJxWzqQxvqZRi9T5y4Tmiq4wmZrhIbR588ZmzLk3xO\nyxp33GJ7M+nbVTrs53gGwzKIXtu45vo6B/gEJbRwiRQMRhBYu6i0izaWrXfe\nboqP0dFVsiuBvuye9SXJaJrnPmqYNcYm7BnwhQjJFPBFcMK+mcb/ymmlHDMI\nFoh+VnFV37HXR9xUpd2UCRZSGUQkjuY0typA0UKDCX1XM2BMocNe6TkD0yBS\njtumrGtIKUBe94PHg59v8rtbVd6hGResG0IytHycUwsbdgRvYrl4shZ2VD0+\njS1D4AlMBDoLBwZIjNLefmYFL2rEvBZZwMGIABtZ3OexzhuqTWO5iWTmbayt\nZeUKY3lmMf51t8XGW+kwCSq8v926lpkot4wLPY8xvxy+7o3vHOlR9+lGKPqQ\nSU9PEkppsrxyLgYcPeMwOS/YoabU/PGfKoaOVxAU6ItCCs/jX6KixNkxZJhE\nJ9h3IinRmvkJTf1vb4lbbA3YvsTF1oXTiaooLLmol8QQ+vOWnWHw6oBGo0H1\nseEtPr0yq24459soPDP2adttP/xKAC7bCK7DaGd8OANOD1OGdXJxHQBdlLB+\nwWs+\r\n=cyCA\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIFBp5NuR1XdL0njV/lykzYyRfZd4zbgP/LwdvTZV5tu7AiEA/eh5x78Mfb6d/WZQPke30UUaQVZd74u46HLq/NReVhI="}]},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_0.2.1_1588834423280_0.9555804751502794"},"_hasShrinkwrap":false},"0.2.2":{"name":"web-vitals","version":"0.2.2","description":"Easily measure performance metrics in JavaScript","main":"dist/web-vitals.es5.umd.min.js","module":"dist/web-vitals.es5.min.js","typings":"dist/index.d.ts","scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch serve","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build"},"keywords":["crux","performance","metrics","CLS","FCP","FID","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.9.0","@babel/preset-env":"^7.9.0","@typescript-eslint/eslint-plugin":"^2.24.0","@typescript-eslint/parser":"^2.24.0","@wdio/cli":"^5.22.3","@wdio/local-runner":"^5.22.3","@wdio/mocha-framework":"^5.18.7","@wdio/selenium-standalone-service":"^5.16.10","@wdio/spec-reporter":"^5.18.7","babel-eslint":"^10.1.0","body-parser":"^1.19.0","chromedriver":"^80.0.1","eslint":"^6.8.0","eslint-config-google":"^0.14.0","express":"^4.17.1","fs-extra":"^9.0.0","husky":"^4.2.3","npm-run-all":"^4.1.5","nunjucks":"^3.2.1","rollup":"^2.1.0","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^5.3.0","typescript":"^3.8.3","wdio-chromedriver-service":"^5.0.2"},"gitHead":"256c3d9f84dca6e1d5427974e5f39d96e9374b23","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@0.2.2","_nodeVersion":"12.16.1","_npmVersion":"6.13.4","dist":{"integrity":"sha512-6xR6kxa70XXnSHV4sZMDXKPvcrUfl2xaNUN1ENedcDbvcinzlWgaDD5Hn5mAnfHfKZVlSHe2/XCXKweuRnfWqw==","shasum":"365d361590bf1a707c484d1196bd3c69e65523e0","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-0.2.2.tgz","fileCount":48,"unpackedSize":84633,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJeuzOhCRA9TVsSAnZWagAAh8QP/RgJ2jLOU+6UNxZ0jWss\nkWWKjz2YtsdcPly+Zd2PdcZeeCDCe2+juGPVG1Ksz/0o/iMpwXC7h27ocDch\nZnn9I1OjcX1Iy0FAI1UZC1bcmPpJ9EjP4xgplyb+IrnREvxIwB+Cx/nwPZ30\n+JrBCU8Pdnz1Q6PaFfTL4XGwUQXP14nEDhgqyIQXaS1CzPCtFntslte9Rus4\nIpcRHMFuxwMfwuIXtoi+Ho4uB2ViIiv7tHO4dA70PN0z7NW2jd+KD0d62p0t\npna0iLD/QElBBUGbXiENepJ8RaMSLSgs41ovvdyckuWUIHYN8t3amQixgbiH\nvSuN5ddPPocAjQv0RG3Kfy0uwlqohIFqjHlQqqwas7LQXFCEA9jW9yoPH6Sd\nwdvOzb11zGPLwUhL3Qvh+s332azfIrWr9cdrUFcTqx4lbz649/vSpnReZKli\nmkNCdRkwRVueoLTByGDcavHTp7IS/OcjxNj9smX8/93kG2C1++hJBTbmfeF1\nHDakIqMJ5ZFHo5vEq6U/zkr54uCMpnAniHcFNzI32N2sa+MUu23FB81ocsK1\nzenP68M++N7EdmkyFIq+Mf3BzrRvBEZWfa4ZPo4MdbX7I2gaCvtH7FjMA3Gx\nMdGuCsETQiK59LCTtIIygJAtJu8SECzOIfvfxNT6awHfctGEwXskn2f3Qfl4\nxfp0\r\n=fM2q\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDCS9De2CQ/74PgqgrsPUTTXGRVI9DBT5/MaXwgIExslAIgDnjLYtQPWVs7E3LRvn6or9IAadDk7YYTzHP86rr05bA="}]},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_0.2.2_1589326753462_0.6684351776729405"},"_hasShrinkwrap":false},"0.2.3":{"name":"web-vitals","version":"0.2.3","description":"Easily measure performance metrics in JavaScript","main":"dist/web-vitals.es5.umd.min.js","module":"dist/web-vitals.es5.min.js","typings":"dist/index.d.ts","scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch serve","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build"},"keywords":["crux","performance","metrics","CLS","FCP","FID","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.9.0","@babel/preset-env":"^7.9.0","@typescript-eslint/eslint-plugin":"^2.24.0","@typescript-eslint/parser":"^2.24.0","@wdio/cli":"^5.22.3","@wdio/local-runner":"^5.22.3","@wdio/mocha-framework":"^5.18.7","@wdio/selenium-standalone-service":"^5.16.10","@wdio/spec-reporter":"^5.18.7","babel-eslint":"^10.1.0","body-parser":"^1.19.0","chromedriver":"^80.0.1","eslint":"^6.8.0","eslint-config-google":"^0.14.0","express":"^4.17.1","fs-extra":"^9.0.0","husky":"^4.2.3","npm-run-all":"^4.1.5","nunjucks":"^3.2.1","rollup":"^2.1.0","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^5.3.0","typescript":"^3.8.3","wdio-chromedriver-service":"^5.0.2"},"gitHead":"59fcf4b2340ab68a7e41b390a7d7d3b53f4f550d","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@0.2.3","_nodeVersion":"10.17.0","_npmVersion":"6.14.3","dist":{"integrity":"sha512-6idlbUoL38El+QS320Qz6h4QSZLaWw3CHiJWBtQDmFGs72ro+fnukfavTxTdQSlsaoaBuNL/0bqlIhfdtlrx4A==","shasum":"950adea6da9e3cfd3ee2ffe868c7126a6d87b2d1","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-0.2.3.tgz","fileCount":48,"unpackedSize":85266,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJe9lO0CRA9TVsSAnZWagAAExIP/j0+3uL/WbuASjF9jbEx\n+wi29Yw2QfJ0/P4KxiKbs+fevvvwv/PFdpM4L1KWJbu2G5iRtI/kMnuyGEAm\ntoRoY/IX9gd3GqT4vJXyDwmHyhJYSHPQV0LLCF6zptfTn8Vzu7vkyqhmW36E\ns0Be4SryQpYeslKYrc+IwyYKi8NqL6an3/Q4xjC00nkZ568UBOBeMTaejzBl\nq7gDDFWrtsn8auHrJU7tUmF9LyRUWgHDEgEbSrZTNg68GYGCD7/aeeagd4W/\n7K+Md9zIL0SLgn7/nAfBogwNj7sAhHRNoO9Z616uizqzgRENL941wkipB7Nl\ndn7CltyOow/L7GBFfyK/LVfcX1dSjkg4IPW/liJUXQgSYtg2JGNoBv+TSxkk\n1xcauzETinyvD3Aj286EwpZZ/Sk+CCWCN+qXiew+Fyt4Q4S++SUO/GBqPBEs\ns6GAMEE0fhPRzCXH4LWemm7xPVxWEGTWTarqE5iJl4kq+cjSY+XwvP2B7OJN\nAUhm2xPYNxfCqiF2I6LMn4yU8t/OL16OeTqRUAsKPNU9/+cvOti7PxivVxcT\noGaqnamFEhjiEmxjDmRb+9H2BWm5OGWIusMvc1cophmPblg+gpHj8eirHYb+\nqaP9W6jol5HvRyJmX+7WCXQfxo68RcO5LhyKNUMjBnS0yMtuN+07pjuu4+j5\nfoDU\r\n=b+yI\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIB0vbe4pr7TivlDespvITl25ZfY3Me40zF6dZJsp2veCAiA4mkPndXh3kRPdFY87nPdfwA2TtlGB2Fxg4XCGcx4ZBg=="}]},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_0.2.3_1593201587991_0.5991581306677847"},"_hasShrinkwrap":false},"0.2.4":{"name":"web-vitals","version":"0.2.4","description":"Easily measure performance metrics in JavaScript","main":"dist/web-vitals.es5.umd.min.js","module":"dist/web-vitals.es5.min.js","typings":"dist/index.d.ts","scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch serve","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build"},"keywords":["crux","performance","metrics","CLS","FCP","FID","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.10.5","@babel/preset-env":"^7.10.4","@typescript-eslint/eslint-plugin":"^3.7.0","@typescript-eslint/parser":"^3.7.0","@wdio/cli":"^6.3.4","@wdio/local-runner":"^6.3.4","@wdio/mocha-framework":"^6.3.0","@wdio/selenium-standalone-service":"^6.1.14","@wdio/spec-reporter":"^6.3.0","babel-eslint":"^10.1.0","body-parser":"^1.19.0","chromedriver":"^84.0.1","eslint":"^7.5.0","eslint-config-google":"^0.14.0","express":"^4.17.1","fs-extra":"^9.0.1","husky":"^4.2.5","npm-run-all":"^4.1.5","nunjucks":"^3.2.2","rollup":"^2.23.0","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^6.1.0","typescript":"^3.9.7","wdio-chromedriver-service":"^6.0.3"},"gitHead":"ab52d6706c3104058e39a7ace2a09f70997ca1f0","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@0.2.4","_nodeVersion":"10.17.0","_npmVersion":"6.14.3","dist":{"integrity":"sha512-6BjspCO9VriYy12z356nL6JBS0GYeEcA457YyRzD+dD6XYCQ75NKhcOHUMHentOE7OcVCIXXDvOm0jKFfQG2Gg==","shasum":"ec3df43c834a207fd7cdefd732b2987896e08511","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-0.2.4.tgz","fileCount":48,"unpackedSize":85500,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.4\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJfGj17CRA9TVsSAnZWagAAyyEQAIvVituI08IIpbzJ9Rcv\n9p/XF2aubTQPUNbRpLvN6lB95ed+yqXPAGVmGGncfuxQmDHNvH5v0CaO1p+g\nQzYvA7kkr8z6vYo35E3mDvqYW6Dm/9RuxH6+3yt0V37PbNoFp6CVkJjQRsvE\nhYSY6TrdZn/DYSXBFog9X5P/LPkj5AmB/37OJbHzCrYi7wI6jqW5TbPzQ5Pi\nPBorp/oCMEGIwhfwE/A1RiO57Xi97/b0w61A8/d2QEFwewnCGwkq/fRE8uqT\nhiM6TJA6fQoucb+OFTs+8PN0v2+7/tKbqNEx9sG1IZwJCDMvqctls3oHVJ+R\n1jhcE9alzyBfDFuDqzRe2v+JnYEPqUUCyHQathfr/FWGIaYlqHiuQ8qPPGaS\nkbIGimGFtP34etsjdJ0TiIEzWFmVndKkLooj8Rah5s4Tdi7jLk+jayuEIfg0\ntaXXx74/nwOh6FHhjXsCDsVibgci7LYqEs1I1wHTa+xXMD52MUWEnFlhVhzf\nSgzYxlD3pqw3zXL0Kx1Uo/scDT0kYHAAPUzcw2ybLZbgO+/XlnccNErMCdS1\n3XqzVpyhisjnEXmRibN9bjolnnX6FnDcW5aE4vdRc+f5B1Vppmd9ew6qQ+VN\njTzO9xkohEm+/jG5rUN07i9zeGRmyjY3xIc5566yQ60HrybZCoyoc//psbw9\nuFZX\r\n=Mqi0\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIGRgjxysM9s+OkutRgYALV8jMHADw9DuFbgNuTgn8dbvAiEA7z+zXFzmhfiSOE9FtLSgEhzYCvkFN/uO1z0ynkJimy8="}]},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_0.2.4_1595555194565_0.13297130873702856"},"_hasShrinkwrap":false},"1.0.0":{"name":"web-vitals","version":"1.0.0","description":"Easily measure performance metrics in JavaScript","main":"dist/web-vitals.umd.js","module":"dist/web-vitals.js","typings":"dist/index.d.ts","scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build"},"keywords":["crux","performance","metrics","CLS","FCP","FID","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.12.3","@babel/preset-env":"^7.12.1","@rollup/plugin-replace":"^2.3.4","@typescript-eslint/eslint-plugin":"^4.7.0","@typescript-eslint/parser":"^4.7.0","@wdio/cli":"^6.7.4","@wdio/local-runner":"^6.7.3","@wdio/mocha-framework":"^6.7.3","@wdio/selenium-standalone-service":"^6.7.3","@wdio/spec-reporter":"^6.7.0","babel-eslint":"^10.1.0","body-parser":"^1.19.0","chromedriver":"^86.0.0","eslint":"^7.13.0","eslint-config-google":"^0.14.0","express":"^4.17.1","fs-extra":"^9.0.1","husky":"^4.3.0","npm-run-all":"^4.1.5","nunjucks":"^3.2.2","rollup":"^2.33.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.0.5","wdio-chromedriver-service":"^6.0.4"},"gitHead":"7deb4aa8988ba01b4c6378a844911c676d90a8fd","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@1.0.0","_nodeVersion":"12.18.3","_npmVersion":"6.14.6","dist":{"integrity":"sha512-J0/3tfwcpE8S6tpFLOx78m16fslrhYCv9DZ7hTKjki7AnOjuylIQ0V6DXm21isBqMtq0Q7DU0IquwT+2joDOMA==","shasum":"fc3b93e0cdd0bc6f2d0bbb4ee46ab4a877772115","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-1.0.0.tgz","fileCount":63,"unpackedSize":127120,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJfsy6iCRA9TVsSAnZWagAATy0QAJ3UF/3z4WK7Iif5IdyL\n4h5SNeK/JjyAfg9NHCBoFp8ZrPF65N2jLtPCgDdZm/0tad3hxqV+DK/8zghA\nZUr1MduGh9ed+AlOt1IL5Lcw7Wl9pU0ulDUbC30lFRXZoLqucw5sixy8PpKc\nXuQQa9u77UqJxGFsP5hlNhtzL5dFbJU7aHgeqJFn43jwrLEql8PdIR0U/LlF\nVwJ+aKRu0HFFCBTsQ1zmN9rOLWvnaHixQVBaZ7DUSyxbRote9obcNM1uzDW8\n7YQYQ5qHTEvmyRQL9nNHmA58ER80kMfiN/w8SxGIgEmq00OpMxqgFK518vyg\n0+WsafE7ZK5paECIcTTUIksEt6u9rXyqBBXsCpfn23lJcv0rHAoWAUuvTfMw\nc4GOFmmXf2odOW58pJu38D8siKaGYrOM12Wy0/oVZa1g/XXEIOcvGNDERJJP\n8LlbwG1TR0cKmBkIApgdiCA9qhhZbvHnI6d+8v/hEngxJA7tYptOM0cCAD0+\nL98gc+Q24aIdKcNrvG+t6UMcb7D8/fnq9Vk/JdeCb4IxiP1slNzlbwLviYjZ\nQctLyXdtwNagYQ8yA8c64SMuXDq1WBhwG1n1X10X1/b+vbwERAjnpufkhho4\nC98I6eUOZMHnT6dD6xzB58msFSAeirQ+BjCX029feaIOpS0iSQlrpexqWnbX\n5I6/\r\n=zN/g\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIGfJ7G+1nC+baFVfMR1s8NHtpMWpJ2kUYalijy1+Yu41AiEAxvFZ+A44m0S1nxwAr5DDSBm7UuQjgFUlkYN/NzKnKq8="}]},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_1.0.0_1605578401801_0.9778076220157972"},"_hasShrinkwrap":false},"1.0.1":{"name":"web-vitals","version":"1.0.1","description":"Easily measure performance metrics in JavaScript","main":"dist/web-vitals.umd.js","module":"dist/web-vitals.js","typings":"dist/modules/index.d.ts","scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build"},"keywords":["crux","performance","metrics","CLS","FCP","FID","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.12.3","@babel/preset-env":"^7.12.1","@rollup/plugin-replace":"^2.3.4","@typescript-eslint/eslint-plugin":"^4.7.0","@typescript-eslint/parser":"^4.7.0","@wdio/cli":"^6.7.4","@wdio/local-runner":"^6.7.3","@wdio/mocha-framework":"^6.7.3","@wdio/selenium-standalone-service":"^6.7.3","@wdio/spec-reporter":"^6.7.0","babel-eslint":"^10.1.0","body-parser":"^1.19.0","chromedriver":"^86.0.0","eslint":"^7.13.0","eslint-config-google":"^0.14.0","express":"^4.17.1","fs-extra":"^9.0.1","husky":"^4.3.0","npm-run-all":"^4.1.5","nunjucks":"^3.2.2","rollup":"^2.33.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.0.5","wdio-chromedriver-service":"^6.0.4"},"gitHead":"d8c7b455642731dc1e9c1a60cec2335ba7e52472","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@1.0.1","_nodeVersion":"12.18.3","_npmVersion":"6.14.6","dist":{"integrity":"sha512-io/H/D18edTL1D2lcaUTLNLFEVZIPhNd4IdXDB9bEb+uDv2m/6NfyHiXKLFjbmI1ubeYpoQpR1gl9nlcWdI0vA==","shasum":"025a7ffd9d8f5e4a030e3aee6061dcb38a4b6654","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-1.0.1.tgz","fileCount":65,"unpackedSize":127496,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJfs07OCRA9TVsSAnZWagAAf/EP/ismSF+JPAgFAN3UMID+\nwFIyA4SaVYXIOSJEIe2+xH9irsjB+jqxinWnbSPeUZQRCtx+BF8HmaHScn/m\n4MeHObDkxPRO6rmNYCbrBHG0rqQg0CQzOQuO2ZTGhW+pmYOLZH7D6l59CcU4\n586mEli1mb0llUQuLwHzXuGgJqz94/uhNjJmqIdZyQBcp5qIk6vXZ9mnUGa/\nURW4Jtkz2TEmEdVqb9eKKwxpHCta+OIXQVM6QFAzCr099TJ91/pSou72ib4Q\neWJwj4GERDqB6i/zim7YPY6XWfxoOhVeXggoztP3AEL/4TonwZQ+sPL3HTyM\nB1Ir8hSN0Ldj/55EfvwrK9M11fICQNvL2oMx2Lrz2vFiq/PxrPAsA6QwKpmK\nS0FgtujZgOY1xqPtABDd5RMRxDMvPnGp+hrKdKWV3fvJuPsM1Pulyu75C8Zm\n3qtuujoog36eh7JCbpn9Uuxb2Snqceai1KBsb0g/Vu3fGiGtWNXo6tvkm7+h\nCl1CIaEuN9uxQXXNNydAAFQZ5xihos+f7Dp9+CDGE+4q+QwHDcvsdyCqwqRZ\nravqGh013PrCWb7O7yJ+lNsT4yc9YYaDq6ODxwYED2Vys4hJXk/wF7RwcUtq\nfvK+myoyd9zgZo8L1zDhC5kinaVzhkjp/3A5yS7Y062E/vP8RCbTPKZPXT40\n17ib\r\n=DMc/\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIFBy4NyDvOf673e21IddLD6iaPFdMIF0L21WXkGo3HPOAiA6KDyX+zfGriwaY5ziWx94PnoDOjgWXjM3tqkpSgfoaw=="}]},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_1.0.1_1605586637744_0.6997090377662547"},"_hasShrinkwrap":false},"1.1.0":{"name":"web-vitals","version":"1.1.0","description":"Easily measure performance metrics in JavaScript","main":"dist/web-vitals.umd.js","module":"dist/web-vitals.js","typings":"dist/modules/index.d.ts","scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build"},"keywords":["crux","performance","metrics","CLS","FCP","FID","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.12.9","@babel/preset-env":"^7.12.7","@rollup/plugin-replace":"^2.3.4","@typescript-eslint/eslint-plugin":"^4.8.2","@typescript-eslint/parser":"^4.8.2","@wdio/cli":"^6.10.0","@wdio/local-runner":"^6.10.0","@wdio/mocha-framework":"^6.8.0","@wdio/selenium-standalone-service":"^6.10.0","@wdio/spec-reporter":"^6.8.1","babel-eslint":"^10.1.0","body-parser":"^1.19.0","chromedriver":"^87.0.5","eslint":"^7.14.0","eslint-config-google":"^0.14.0","express":"^4.17.1","fs-extra":"^9.0.1","husky":"^4.3.0","npm-run-all":"^4.1.5","nunjucks":"^3.2.2","rollup":"^2.33.3","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.1.2","wdio-chromedriver-service":"^6.0.4"},"gitHead":"8b536cc97e77137fef7db1a8aab021316bd9970f","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@1.1.0","_nodeVersion":"12.20.0","_npmVersion":"6.14.8","dist":{"integrity":"sha512-1cx54eRxY/+M0KNKdNpNnuXAXG+vJEvwScV4DiV9rOYDguHoeDIzm09ghBohOPtkqPO5OtPC14FWkNva3SDisg==","shasum":"7f410d9a1f7a1cd5d952806b45776204b47dc274","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-1.1.0.tgz","fileCount":65,"unpackedSize":128708,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJf/6+kCRA9TVsSAnZWagAAEV0QAImFgmkpYptuuExQv36h\nex0IMDKM4pdGlnAkzDJc6ZY7VsQ9g7XFnZvQDeSvv80lJG/X9kloAN2zhXKS\npe9CGDZ31cHo1nVOuMLajGZA1ejgG+FlXDljcncfAw8tbhe46ytJbXq/SKyo\nPR77ZMFMGCJ0apLIEWLm0x5n5YZBi85aUdHg6BwWKbfhMK7gTJr0jb70ZGYk\nB58GDpLuVAXxrcVpbiCRU05bJKKA52sqtIFTPEiRJRpJ0lVwOPlK5pKraipj\nkTZuP3WOHgTuhZlRWoJOmV+UU1ajA2lr6CAma3+7dzYHdSSS9xsp1RmULuZI\nEyBu78JlFgeiYoDtWs4qqnU1ijZNbaLNdISm4yEJ5ZKTDLrIQoJfUTVlQck8\npn+La6pXq4qTthAelgUt1jrdHM9WmZOHlQVbp7vy3cVYx/ftMtRU1w8u3SeS\njyaKKHqHFSDnq7YrmrzmH1W+UYJfzcQP+cRZhQsak8cVqLSoQP7WVp++JAzn\nj7Ap5im9M9xr3KI5Ou7UjKGb91J5cslAfVOwi8gavMAo45ZWa5KzKQaDfsvY\n/wh3wrwLMHBdV84Hwhi1mnzuuqcjREzoQRYk+GCinveimnhAdzaplWOIGIdB\ngcKckvYojc2x2A6z4biFehP+nnnb5+pGX8lYXNFCYESiYOCqdubZvMulZuGh\n2/OE\r\n=stl0\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQDxDN8CIOR4l7rXAAWzyWPhj2PE91/T/PmHj/sPWi3+/gIhANAwTa+Cw4zDle1Z7ZCll26ltkSLEi+8fuS8SFoGLsKA"}]},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_1.1.0_1610592164229_0.8481069570028432"},"_hasShrinkwrap":false},"1.1.1":{"name":"web-vitals","version":"1.1.1","description":"Easily measure performance metrics in JavaScript","main":"dist/web-vitals.umd.js","module":"dist/web-vitals.js","typings":"dist/modules/index.d.ts","scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","start":"run-p watch test:server","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","CLS","FCP","FID","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.13.10","@babel/preset-env":"^7.13.10","@rollup/plugin-replace":"^2.4.1","@typescript-eslint/eslint-plugin":"^4.17.0","@typescript-eslint/parser":"^4.17.0","@wdio/cli":"^7.1.2","@wdio/local-runner":"^7.1.2","@wdio/mocha-framework":"^7.1.2","@wdio/selenium-standalone-service":"^7.1.1","@wdio/spec-reporter":"^7.1.1","babel-eslint":"^10.1.0","body-parser":"^1.19.0","chromedriver":"^89.0.0","eslint":"^7.22.0","eslint-config-google":"^0.14.0","express":"^4.17.1","fs-extra":"^9.1.0","husky":"^5.1.3","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","rollup":"^2.41.2","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.2.3","wdio-chromedriver-service":"^7.0.0"},"gitHead":"b673a8598f7be5c14571586d43545587c54e0a3b","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@1.1.1","_nodeVersion":"12.20.0","_npmVersion":"7.6.3","dist":{"integrity":"sha512-jYOaqu01Ny1NvMwJ3dBJDUOJ2PGWknZWH4AUnvFOscvbdHMERIKT2TlgiAey5rVyfOePG7so2JcXXZdSnBvioQ==","shasum":"2df535e3355fb7fbe34787b44b736e270e539377","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-1.1.1.tgz","fileCount":65,"unpackedSize":129622,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJgTSivCRA9TVsSAnZWagAAiJ8P/1tyxm6q+V/FgWFBJtxp\nt5pX+KRN4PORkyYDsxgXNDtIv+m7xLXTFxE2YpEZFVb4+1UuA5SqKAhGYcoW\nTYspSiLS2Hrm0dNmu4BPi/7Y8aU5tJfzIwAYJxUSwklNlMNH7qcHD5jT5DVC\nahe9qW1fNwE8wBjyRM5ylHvR8D7p0RRLG5HrtZuGSZdiVyAUiinNWS/nol2r\nSvxkbz5a6g4/EEyrs8+G/1l/VRoE8HdCBQU6eTFEv3GqJGHyY4+aPvct2LIW\niKkZ7X9xEzEU5dGS9ss6rsS4i+Ar5SH39pSKpQyqH3YRSgG9WdFCGGmfNRhO\njxQ8gqTfKQ0dyGPjq6jGWZ36LypgJqsf0JiFzx+eryT0pq0pCceZIFPUsxmM\nKPFEmYdyKwraEss1vUOi8KH97Er2/itkr01tpWwOSBbt4LKxrkwbvO9gGN2l\n5IcOn/+UlsObLDkuQZsJjf7Tv4GB+MUECQ12WhPiOzUguhJVEg/FqH+FJjjp\ngq50BIpKmVwyBnhDLRdNTk52n0bFOmWXX5jcK8d6MOthXnvMAv9V0KS7ZOPn\n7ydcnJm7EaO5j0xpMHYmdiW82ynM+mlQPUkDyPmLLx1ohQFtA0pXkgcsVNW2\nPebBVueZtT2/+7DAhDIX+S6K5RZetuJKgrHutNmAroC6TfB+sQFnAe/EYRiR\n3qbH\r\n=kY3A\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIAYm1mYchEE+ss1zuYgp1zpvVQjWtTrD3bolv9Ap3PVYAiEAjrO1hil7vifuQXN+IB7/2lK342u6c8DZ7vcwQgapKUs="}]},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_1.1.1_1615669422914_0.5881938657889385"},"_hasShrinkwrap":false},"1.1.2":{"name":"web-vitals","version":"1.1.2","description":"Easily measure performance metrics in JavaScript","main":"dist/web-vitals.umd.js","module":"dist/web-vitals.js","typings":"dist/modules/index.d.ts","scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","start":"run-p watch test:server","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","CLS","FCP","FID","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.13.10","@babel/preset-env":"^7.13.10","@rollup/plugin-replace":"^2.4.1","@typescript-eslint/eslint-plugin":"^4.17.0","@typescript-eslint/parser":"^4.17.0","@wdio/cli":"^7.1.2","@wdio/local-runner":"^7.1.2","@wdio/mocha-framework":"^7.1.2","@wdio/selenium-standalone-service":"^7.1.1","@wdio/spec-reporter":"^7.1.1","babel-eslint":"^10.1.0","body-parser":"^1.19.0","chromedriver":"^89.0.0","eslint":"^7.22.0","eslint-config-google":"^0.14.0","express":"^4.17.1","fs-extra":"^9.1.0","husky":"^5.1.3","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","rollup":"^2.41.2","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.2.3","wdio-chromedriver-service":"^7.0.0"},"gitHead":"d51aa10f68eda421ed90f2a966c3e9e2611d6d57","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@1.1.2","_nodeVersion":"14.16.0","_npmVersion":"6.14.11","dist":{"integrity":"sha512-PFMKIY+bRSXlMxVAQ+m2aw9c/ioUYfDgrYot0YUa+/xa0sakubWhSDyxAKwzymvXVdF4CZI71g06W+mqhzu6ig==","shasum":"06535308168986096239aa84716e68b4c6ae6d1c","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-1.1.2.tgz","fileCount":65,"unpackedSize":132473,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJgk1NhCRA9TVsSAnZWagAAj8kP/1NFq9I/rUW/EdGwT8HS\nEc/tsFxGrLAlshxZsv0CphjEiPJAX9dlfpTy+WIPVxcY6Zc5ETyxFk6OO+XC\njZlYmil+IvRsTJ5r2EvPQumCTG417M/dEe0E/XLWqt5rMxxcGbT+GKqp6UFD\nAiMtZjhstixtqVafIoMZHDN6XqrlEj+LWCQUwdQj82zJ6E+F70LV3+Skc1uz\nkCuPyilueEoMao54NszOoWJcFiRChA1EfhpeEle0K2ZLkgAUAHvlF+4Gex0T\nxklnfOvmrnoPBeA7Mu02waeVoFEvUvRg09edXv2hT34ZufR+Qkw6HltZUU2+\no62MHCOH0i2Yy1iGIeHG5SRD+//CheKKlJovzBkXFRukLrS310jgE0+rdn75\nDm8pyJw2k2uqEnZYHw+7XVoFc+Ml0RAsS1s+jDplFO0bD65JezD1vpE4z3xQ\nO2KcS4DW7G1wE9D6neMuoEFnNJDxfHmIeEZgvzpqbOh87W5tFd7skWkTFLU8\nl/oZoy4FN9TE/TGs/Rkkadw5zmH8pe0Vi/fXjmIqGswWIkUWkysI9nOVoWKS\nqRwXpqjiZF7HXnS1qN9gem6Rcsu+v4SXlq3BW2tiPt3o9PCy7CkIXN/Pciq1\nIw2quZCpPxsj7xEe7fqZTsEWuj5JnxOorUTyRniK4Jn561W7mTVWzZ4A0+sS\nzJG2\r\n=+d2o\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDDj7uRxTZ31R6SSvvg75ojKgNB17d60Ku2RZSBzBQgIgIgcmPaYq6k1FTdQoRbhPvJND7t4tdPVHRI/0rg53fdkyY="}]},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_1.1.2_1620267872693_0.8926446698816302"},"_hasShrinkwrap":false},"2.0.0-beta.0":{"name":"web-vitals","version":"2.0.0-beta.0","description":"Easily measure performance metrics in JavaScript","main":"dist/web-vitals.umd.js","module":"dist/web-vitals.js","typings":"dist/modules/index.d.ts","scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","start":"run-p watch test:server","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","CLS","FCP","FID","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.13.10","@babel/preset-env":"^7.13.10","@rollup/plugin-replace":"^2.4.1","@typescript-eslint/eslint-plugin":"^4.17.0","@typescript-eslint/parser":"^4.17.0","@wdio/cli":"^7.1.2","@wdio/local-runner":"^7.1.2","@wdio/mocha-framework":"^7.1.2","@wdio/selenium-standalone-service":"^7.1.1","@wdio/spec-reporter":"^7.1.1","babel-eslint":"^10.1.0","body-parser":"^1.19.0","chromedriver":"^89.0.0","eslint":"^7.22.0","eslint-config-google":"^0.14.0","express":"^4.17.1","fs-extra":"^9.1.0","husky":"^5.1.3","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","rollup":"^2.41.2","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.2.3","wdio-chromedriver-service":"^7.0.0"},"readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n- [Bundle versions](#bundle-versions)\n  - [Which bundle is right for you?](#which-bundle-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1K), modular library for measuring all the [Web Vitals](https://web.dev/vitals/) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/vitals/#core-web-vitals) as well as all of the [other Web Vitals](https://web.dev/vitals/#other-web-vitals) that can be measured [in the field](https://web.dev/user-centric-performance-metrics/#how-metrics-are-measured):\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/cls/)\n- [First Input Delay (FID)](https://web.dev/fid/)\n- [Largest Contentful Paint (LCP)](https://web.dev/lcp/)\n\n### Other Web Vitals\n\n- [First Contentful Paint (FCP)](https://web.dev/fcp/)\n- [Time to First Byte (TTFB)](https://web.dev/time-to-first-byte/)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are two different versions of the `web-vitals` library (the \"standard\" version and the \"base+polyfill\" version), and how you load the library depends on which version you want to use.\n\nFor details on the difference between the two versions, see <a href=\"#which-bundle-is-right-for-you\">which bundle is right for you</a>.\n\n**1. The \"standard\" version**\n\nTo load the \"standard\" version, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {getLCP, getFID, getCLS} from 'web-vitals';\n\ngetCLS(console.log);\ngetFID(console.log);\ngetLCP(console.log);\n```\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**2. The \"base+polyfill\" version**\n\nLoading the \"base+polyfill\" version is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {getLCP, getFID, getCLS} from 'web-vitals';\n+ import {getLCP, getFID, getCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nNote that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com), whether your targeting just Chromium-based browsers (using the \"standard\" version) or additional browsers (using the \"base+polyfill\" version):\n\n**Load the \"standard\" version** (using a module script)\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {getCLS, getFID, getLCP} from 'https://unpkg.com/web-vitals?module';\n\n  getCLS(console.log);\n  getFID(console.log);\n  getLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" version** _(using a classic script)_\n\n```html\n<script>\n(function() {\n  var script = document.createElement('script');\n  script.src = 'https://unpkg.com/web-vitals';\n  script.onload = function() {\n    // When loading `web-vitals` using a classic script, all the public\n    // methods can be found on the `webVitals` global namespace.\n    webVitals.getCLS(console.log);\n    webVitals.getFID(console.log);\n    webVitals.getLCP(console.log);\n  }\n  document.head.appendChild(script);\n}())\n</script>\n```\n\n**Load the \"base+polyfill\" version** _(using a classic script)_\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `https://unpkg.com/web-vitals/dist/polyfill.js` here.\n    </script>\n  </head>\n  <body>\n    ...\n    <!-- Load the UMD version of the \"base\" bundle. -->\n    <script>\n    (function() {\n      var script = document.createElement('script');\n      script.src = 'https://unpkg.com/web-vitals';\n      script.onload = function() {\n        // When loading `web-vitals` using a classic script, all the public\n        // methods can be found on the `webVitals` global namespace.\n        webVitals.getCLS(console.log);\n        webVitals.getFID(console.log);\n        webVitals.getLCP(console.log);\n      }\n      document.head.appendChild(script);\n    }())\n    </script>\n  </body>\n</html>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes an `onReport` callback. This callback will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" version, but they will work with the polyfill version as well.)_\n\n```js\nimport {getCLS, getFID, getLCP} from 'web-vitals';\n\ngetCLS(console.log);\ngetFID(console.log);\ngetLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developers.google.com/web/tools/chrome-devtools/console/reference#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID is not reported if the user never interacts with the page.\n- FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS should be reported any time the [page's `visibilityState` changes to hidden](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#advice-hidden).\n- CLS, FCP, FID, and LCP are reported again after a page is restored from the [back/forward cache](https://web.dev/bfcache/).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `getCLS()`, `getFID()`, `getLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want `onReport` to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each layout shift as it happens) by setting the optional, second argument (`reportAllChanges`) to `true`.\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended).\n\n```js\nimport {getCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\ngetCLS(console.log, true);\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {getCLS, getFID, getLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\ngetCLS(logDelta);\ngetFID(logDelta);\ngetLCP(logDelta);\n```\n\n_**Note:** the first time the `onReport` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {getCLS, getFID, getLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  const body = JSON.stringify({[metric.name]: metric.value});\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\ngetCLS(sendToAnalytics);\ngetFID(sendToAnalytics);\ngetLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique dimension value (in this case, the metric `id`, as shown in the examples below) on every metric instance that you send to Google Analytics, you can create a report yourself using the [Google Analytics Reporting API](https://developers.google.com/analytics/devguides/reporting) and any data visualization library you choose.\n\nAs an example of this, the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) is a free and open-source tool you can use to create visualizations of the Web Vitals data that you've sent to Google Analytics.\n\n[![web-vitals-report](https://user-images.githubusercontent.com/326742/101584324-3f9a0900-3992-11eb-8f2d-182f302fb67b.png)](https://github.com/GoogleChromeLabs/web-vitals-report)\n\nIn order to use the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) (or build your own custom reports using the API) you need to send your data to Google Analytics following one of the examples outlined below:\n\n#### Using `analytics.js`\n\n```js\nimport {getCLS, getFID, getLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `ga()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/analyticsjs\n  ga('send', 'event', {\n    eventCategory: 'Web Vitals',\n    eventAction: name,\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    eventLabel: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    nonInteraction: true,\n    // Use `sendBeacon()` if the browser supports it.\n    transport: 'beacon',\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-web-vitals-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\ngetCLS(sendToGoogleAnalytics);\ngetFID(sendToGoogleAnalytics);\ngetLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Universal Analytics)\n\n```js\nimport {getCLS, getFID, getLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/gtagjs\n  gtag('event', name, {\n    event_category: 'Web Vitals',\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    event_label: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    value: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    non_interaction: true,\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-web-vitals-in-the-field/\n    // metric_rating: 'good' | 'ni' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\ngetCLS(sendToGoogleAnalytics);\ngetFID(sendToGoogleAnalytics);\ngetLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Google Analytics 4)\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {getCLS, getFID, getLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-web-vitals-in-the-field/\n    // metric_rating: 'good' | 'ni' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\ngetCLS(sendToGoogleAnalytics);\ngetFID(sendToGoogleAnalytics);\ngetLCP(sendToGoogleAnalytics);\n```\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n## Bundle versions\n\nThe `web-vitals` package includes builds for both the \"standard\" and \"base+polyfill\" versions, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the bundles distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any extra polyfills to expand browser support.</p>\n      This is the \"standard\" version and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.js</code></td>\n    <td><code>pgk.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.js</code></td>\n    <td><code>--</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code> or <code>web-vitals.base.umd.js</code> (it will not work with the <code>web-vitals.js</code> or <code>web-vitals.umd.js</code> bundles).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n### Which bundle is right for you?\n\nMost developers will generally want to use the \"standard\" bundle (either the ES module or UMD version, depending on your build system), as it's the easiest to use out of the box and integrate into existing build tools.\n\nHowever, developers willing to manage the additional usage complexity should consider the \"base+polyfill\" bundle if they would like to measure FID in all browsers.\n\n### How the polyfill works\n\nThe `polyfill.js` script adds event listeners that record the event processing delay of the first input, and then removes those event listeners after the first input occurs.\n\nIn order for it to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" version of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" version, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  // The name of the metric (in acronym form).\n  name: 'CLS' | 'FCP' | 'FID' | 'LCP' | 'TTFB';\n\n  // The current value of the metric.\n  value: number;\n\n  // The delta between the current value and the last-reported value.\n  // On the first report, `delta` and `value` will always be the same.\n  delta: number;\n\n  // A unique ID representing this particular metric that's specific to the\n  // current page. This ID can be used by an analytics tool to dedupe\n  // multiple values sent for the same metric, or to group multiple deltas\n  // together and calculate a total.\n  id: string;\n\n  // Any performance entries used in the metric value calculation.\n  // Note, entries will be added to the array as the value changes.\n  entries: (PerformanceEntry | FirstInputPolyfillEntry | NavigationTimingPolyfillEntry)[];\n}\n```\n\n#### `ReportHandler`\n\n```ts\ninterface ReportHandler {\n  (metric: Metric): void;\n}\n```\n\n#### `FirstInputPolyfillEntry`\n\nWhen using the FID polyfill (and if the browser doesn't natively support the Event Timing API), `metric.entries` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<PerformanceEventTiming,\n  'processingEnd' | 'processingEnd', 'toJSON'>\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nWhen calling `getTTFB()`, if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface, it will polyfill the entry object using timings from `performance.timing`:\n\n```ts\nexport type NavigationTimingPolyfillEntry = Omit<PerformanceNavigationTiming,\n  'initiatorType' | 'nextHopProtocol' | 'redirectCount' | 'transferSize' |\n  'encodedBodySize' | 'decodedBodySize' | 'toJSON'>\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n}\n```\n\n### Functions:\n\n#### `getCLS()`\n\n```ts\ntype getCLS = (onReport: ReportHandler, reportAllChanges?: boolean) => void\n```\n\nCalculates the [CLS](https://web.dev/cls/) value for the current page and calls the `onReport` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/cls/#layout-shift-score)).\n\nIf the `reportAllChanges` param is `true`, the `onReport` function will be called any time a new `layout-shift` performance entry is dispatched, or once the final value of the metric has been determined.\n\n_**Important:** unlike other metrics, CLS continues to monitor changes for the entire lifespan of the page&mdash;including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#advice-hidden), `onReport` is always called when the page's visibility state changes to hidden. As a result, the `onReport` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `getFCP()`\n\n```ts\ntype getFCP = (onReport: ReportHandler, reportAllChanges?: boolean) => void\n```\n\nCalculates the [FCP](https://web.dev/fcp/) value for the current page and calls the `onReport` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n#### `getFID()`\n\n```ts\ntype getFID = (onReport: ReportHandler, reportAllChanges?: boolean) => void\n```\n\nCalculates the [FID](https://web.dev/fid/) value for the current page and calls the `onReport` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value (and optionally the input event if using the [FID polyfill](#fid-polyfill)). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `getLCP()`\n\n```ts\ntype getLCP = (onReport: ReportHandler, reportAllChanges?: boolean) => void\n```\n\nCalculates the [LCP](https://web.dev/lcp/) value for the current page and calls the `onReport` function once the value is ready (along with the relevant `largest-contentful-paint` performance entries used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` param is `true`, the `onReport` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `getTTFB()`\n\n```ts\ntype getTTFB = (onReport: ReportHandler, reportAllChanges?: boolean) => void\n```\n\nCalculates the [TTFB](https://web.dev/time-to-first-byte/) value for the current page and calls the `onReport` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `onReport` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it [includes](https://developers.google.com/web/fundamentals/performance/navigation-and-resource-timing#the_life_and_timings_of_a_network_request) time spent on DNS lookup, connection negotiation, network latency, and unloading the previous document. If, in addition to TTFB, you want a metric that excludes these timings and _just_ captures the time spent making the request and receiving the first byte of the response, you could compute that from data found on the performance entry:\n\n```js\nimport {getTTFB} from 'web-vitals';\n\ngetTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `getCLS()`: Chromium,\n- `getFCP()`: Chromium, Firefox, Safari\n- `getFID()`: Chromium, Firefox, Safari, Internet Explorer (with the [polyfill](#how-to-use-the-polyfill))\n- `getLCP()`: Chromium\n- `getTTFB()`: Chromium, Firefox, Safari, Internet Explorer\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that\nmeasure the Web Vitals metrics, which means the limitations of those APIs will\nmostly apply to this library as well.\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `getCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"bc33e38674d0a8f153695c23616b6824be646819","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@2.0.0-beta.0","_nodeVersion":"14.16.0","_npmVersion":"6.14.11","dist":{"integrity":"sha512-KkGoEmRxWopyLYXxhdD2vj+4lWiyIlinxuBi2gAg1k/Q9VDEpIIo4onKvSQqhn2K23EzH+7/cShwjRNWAAl8tg==","shasum":"4460c81212fea5aba2b45620917fac7fa3d6017a","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-2.0.0-beta.0.tgz","fileCount":23,"unpackedSize":80756,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJgnKymCRA9TVsSAnZWagAABCoP/1NkW9nvf5vg7auHfFW8\nZgYbe2HYYZEPzR/9TL1j1mPiWB7820khKFtc7CD2koAbTogvWhdRoNcFVaZY\nslFEIskpy2ZLfi48lYQNbv5gsQycfivF6pkjzodlb8vXbV1N0vyza1yj7kVn\ni0cApwA6jdvC4F3A3yIj+OBGXJFHGjRIpx6haUT+/2PYtGWwRN1h8gBEUqqc\nEFxRbBemcb/CaAHyVYujd63EYhBuVaiwzmldjV8J6xF3vwPbY7v41vLMzinI\nBhDamymNRvNJJAi+HUpzcFjJhuBhhxY83RFI+hZRw9i1fVIZ6dMn6mBy0lbT\nL/9oWPXeJIrW+ksYuRJXayHVWvryaspQfFf2+jJkOTQu4T+OkOFgUSp+R1Vj\nTuk8fntqH83q7dqSFOraoDY7xhpzaycO/UWbgjIxozRJFZgXFw2vMQl6kUC4\nOlM7FAU+vo8ywcPPsVEe1qh90Z1czin4XCjozSmwIEQ1XUj7y93rafT4+2O+\nkfYMLHNmWPk672JkYzk331NSrK+dILF4z4FtwQz2Jw5KkiSZvNBoZStYdUXV\nQPBCPCHxaNovp837SwjbQ0EoEQwUG2eFCutYcEyA71Q8e16QD5p9q7nIdIrb\nmIw3AS9OO7ZITRhRnlfFYOsVPUB1YMYD7a0MaYWVAaUszjz0YXsOPgUlPuqI\n5L80\r\n=RZbL\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIGuQk6UCPc7yaVtIG06ygm+IS5TWaOuo+JWBkHh1eVo4AiBaATDwrFyM20K3COk0SSrFj/CkIzvWQ6VQ1ZR5oSv2IA=="}]},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_2.0.0-beta.0_1620880549674_0.6906679242904536"},"_hasShrinkwrap":false},"2.0.0-beta.1":{"name":"web-vitals","version":"2.0.0-beta.1","description":"Easily measure performance metrics in JavaScript","main":"dist/web-vitals.umd.js","module":"dist/web-vitals.js","typings":"dist/modules/index.d.ts","scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","start":"run-p watch test:server","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","CLS","FCP","FID","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.13.10","@babel/preset-env":"^7.13.10","@rollup/plugin-replace":"^2.4.1","@typescript-eslint/eslint-plugin":"^4.17.0","@typescript-eslint/parser":"^4.17.0","@wdio/cli":"^7.1.2","@wdio/local-runner":"^7.1.2","@wdio/mocha-framework":"^7.1.2","@wdio/selenium-standalone-service":"^7.1.1","@wdio/spec-reporter":"^7.1.1","babel-eslint":"^10.1.0","body-parser":"^1.19.0","chromedriver":"^89.0.0","eslint":"^7.22.0","eslint-config-google":"^0.14.0","express":"^4.17.1","fs-extra":"^9.1.0","husky":"^5.1.3","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","rollup":"^2.41.2","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.2.3","wdio-chromedriver-service":"^7.0.0"},"readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n- [Bundle versions](#bundle-versions)\n  - [Which bundle is right for you?](#which-bundle-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1K), modular library for measuring all the [Web Vitals](https://web.dev/vitals/) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/vitals/#core-web-vitals) as well as all of the [other Web Vitals](https://web.dev/vitals/#other-web-vitals) that can be measured [in the field](https://web.dev/user-centric-performance-metrics/#how-metrics-are-measured):\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/cls/)\n- [First Input Delay (FID)](https://web.dev/fid/)\n- [Largest Contentful Paint (LCP)](https://web.dev/lcp/)\n\n### Other Web Vitals\n\n- [First Contentful Paint (FCP)](https://web.dev/fcp/)\n- [Time to First Byte (TTFB)](https://web.dev/time-to-first-byte/)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are two different versions of the `web-vitals` library (the \"standard\" version and the \"base+polyfill\" version), and how you load the library depends on which version you want to use.\n\nFor details on the difference between the two versions, see <a href=\"#which-bundle-is-right-for-you\">which bundle is right for you</a>.\n\n**1. The \"standard\" version**\n\nTo load the \"standard\" version, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {getLCP, getFID, getCLS} from 'web-vitals';\n\ngetCLS(console.log);\ngetFID(console.log);\ngetLCP(console.log);\n```\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**2. The \"base+polyfill\" version**\n\nLoading the \"base+polyfill\" version is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {getLCP, getFID, getCLS} from 'web-vitals';\n+ import {getLCP, getFID, getCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nNote that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com), whether your targeting just Chromium-based browsers (using the \"standard\" version) or additional browsers (using the \"base+polyfill\" version):\n\n**Load the \"standard\" version** (using a module script)\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {getCLS, getFID, getLCP} from 'https://unpkg.com/web-vitals?module';\n\n  getCLS(console.log);\n  getFID(console.log);\n  getLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" version** _(using a classic script)_\n\n```html\n<script>\n(function() {\n  var script = document.createElement('script');\n  script.src = 'https://unpkg.com/web-vitals';\n  script.onload = function() {\n    // When loading `web-vitals` using a classic script, all the public\n    // methods can be found on the `webVitals` global namespace.\n    webVitals.getCLS(console.log);\n    webVitals.getFID(console.log);\n    webVitals.getLCP(console.log);\n  }\n  document.head.appendChild(script);\n}())\n</script>\n```\n\n**Load the \"base+polyfill\" version** _(using a classic script)_\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `https://unpkg.com/web-vitals/dist/polyfill.js` here.\n    </script>\n  </head>\n  <body>\n    ...\n    <!-- Load the UMD version of the \"base\" bundle. -->\n    <script>\n    (function() {\n      var script = document.createElement('script');\n      script.src = 'https://unpkg.com/web-vitals';\n      script.onload = function() {\n        // When loading `web-vitals` using a classic script, all the public\n        // methods can be found on the `webVitals` global namespace.\n        webVitals.getCLS(console.log);\n        webVitals.getFID(console.log);\n        webVitals.getLCP(console.log);\n      }\n      document.head.appendChild(script);\n    }())\n    </script>\n  </body>\n</html>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes an `onReport` callback. This callback will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" version, but they will work with the polyfill version as well.)_\n\n```js\nimport {getCLS, getFID, getLCP} from 'web-vitals';\n\ngetCLS(console.log);\ngetFID(console.log);\ngetLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developers.google.com/web/tools/chrome-devtools/console/reference#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID is not reported if the user never interacts with the page.\n- FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS should be reported any time the [page's `visibilityState` changes to hidden](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#advice-hidden).\n- CLS, FCP, FID, and LCP are reported again after a page is restored from the [back/forward cache](https://web.dev/bfcache/).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `getCLS()`, `getFID()`, `getLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want `onReport` to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each layout shift as it happens) by setting the optional, second argument (`reportAllChanges`) to `true`.\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended).\n\n```js\nimport {getCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\ngetCLS(console.log, true);\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {getCLS, getFID, getLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\ngetCLS(logDelta);\ngetFID(logDelta);\ngetLCP(logDelta);\n```\n\n_**Note:** the first time the `onReport` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {getCLS, getFID, getLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  const body = JSON.stringify({[metric.name]: metric.value});\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\ngetCLS(sendToAnalytics);\ngetFID(sendToAnalytics);\ngetLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique dimension value (in this case, the metric `id`, as shown in the examples below) on every metric instance that you send to Google Analytics, you can create a report yourself using the [Google Analytics Reporting API](https://developers.google.com/analytics/devguides/reporting) and any data visualization library you choose.\n\nAs an example of this, the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) is a free and open-source tool you can use to create visualizations of the Web Vitals data that you've sent to Google Analytics.\n\n[![web-vitals-report](https://user-images.githubusercontent.com/326742/101584324-3f9a0900-3992-11eb-8f2d-182f302fb67b.png)](https://github.com/GoogleChromeLabs/web-vitals-report)\n\nIn order to use the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) (or build your own custom reports using the API) you need to send your data to Google Analytics following one of the examples outlined below:\n\n#### Using `analytics.js`\n\n```js\nimport {getCLS, getFID, getLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `ga()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/analyticsjs\n  ga('send', 'event', {\n    eventCategory: 'Web Vitals',\n    eventAction: name,\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    eventLabel: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    nonInteraction: true,\n    // Use `sendBeacon()` if the browser supports it.\n    transport: 'beacon',\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-web-vitals-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\ngetCLS(sendToGoogleAnalytics);\ngetFID(sendToGoogleAnalytics);\ngetLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Universal Analytics)\n\n```js\nimport {getCLS, getFID, getLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/gtagjs\n  gtag('event', name, {\n    event_category: 'Web Vitals',\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    event_label: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    value: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    non_interaction: true,\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-web-vitals-in-the-field/\n    // metric_rating: 'good' | 'ni' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\ngetCLS(sendToGoogleAnalytics);\ngetFID(sendToGoogleAnalytics);\ngetLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Google Analytics 4)\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {getCLS, getFID, getLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-web-vitals-in-the-field/\n    // metric_rating: 'good' | 'ni' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\ngetCLS(sendToGoogleAnalytics);\ngetFID(sendToGoogleAnalytics);\ngetLCP(sendToGoogleAnalytics);\n```\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n## Bundle versions\n\nThe `web-vitals` package includes builds for both the \"standard\" and \"base+polyfill\" versions, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the bundles distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any extra polyfills to expand browser support.</p>\n      This is the \"standard\" version and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.js</code></td>\n    <td><code>pgk.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.js</code></td>\n    <td><code>--</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code> or <code>web-vitals.base.umd.js</code> (it will not work with the <code>web-vitals.js</code> or <code>web-vitals.umd.js</code> bundles).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n### Which bundle is right for you?\n\nMost developers will generally want to use the \"standard\" bundle (either the ES module or UMD version, depending on your build system), as it's the easiest to use out of the box and integrate into existing build tools.\n\nHowever, developers willing to manage the additional usage complexity should consider the \"base+polyfill\" bundle if they would like to measure FID in all browsers.\n\n### How the polyfill works\n\nThe `polyfill.js` script adds event listeners that record the event processing delay of the first input, and then removes those event listeners after the first input occurs.\n\nIn order for it to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" version of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" version, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  // The name of the metric (in acronym form).\n  name: 'CLS' | 'FCP' | 'FID' | 'LCP' | 'TTFB';\n\n  // The current value of the metric.\n  value: number;\n\n  // The delta between the current value and the last-reported value.\n  // On the first report, `delta` and `value` will always be the same.\n  delta: number;\n\n  // A unique ID representing this particular metric that's specific to the\n  // current page. This ID can be used by an analytics tool to dedupe\n  // multiple values sent for the same metric, or to group multiple deltas\n  // together and calculate a total.\n  id: string;\n\n  // Any performance entries used in the metric value calculation.\n  // Note, entries will be added to the array as the value changes.\n  entries: (PerformanceEntry | FirstInputPolyfillEntry | NavigationTimingPolyfillEntry)[];\n}\n```\n\n#### `ReportHandler`\n\n```ts\ninterface ReportHandler {\n  (metric: Metric): void;\n}\n```\n\n#### `FirstInputPolyfillEntry`\n\nWhen using the FID polyfill (and if the browser doesn't natively support the Event Timing API), `metric.entries` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<PerformanceEventTiming,\n  'processingEnd' | 'processingEnd', 'toJSON'>\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nWhen calling `getTTFB()`, if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface, it will polyfill the entry object using timings from `performance.timing`:\n\n```ts\nexport type NavigationTimingPolyfillEntry = Omit<PerformanceNavigationTiming,\n  'initiatorType' | 'nextHopProtocol' | 'redirectCount' | 'transferSize' |\n  'encodedBodySize' | 'decodedBodySize' | 'toJSON'>\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n}\n```\n\n### Functions:\n\n#### `getCLS()`\n\n```ts\ntype getCLS = (onReport: ReportHandler, reportAllChanges?: boolean) => void\n```\n\nCalculates the [CLS](https://web.dev/cls/) value for the current page and calls the `onReport` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/cls/#layout-shift-score)).\n\nIf the `reportAllChanges` param is `true`, the `onReport` function will be called any time a new `layout-shift` performance entry is dispatched, or once the final value of the metric has been determined.\n\n_**Important:** unlike other metrics, CLS continues to monitor changes for the entire lifespan of the page&mdash;including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#advice-hidden), `onReport` is always called when the page's visibility state changes to hidden. As a result, the `onReport` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `getFCP()`\n\n```ts\ntype getFCP = (onReport: ReportHandler, reportAllChanges?: boolean) => void\n```\n\nCalculates the [FCP](https://web.dev/fcp/) value for the current page and calls the `onReport` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n#### `getFID()`\n\n```ts\ntype getFID = (onReport: ReportHandler, reportAllChanges?: boolean) => void\n```\n\nCalculates the [FID](https://web.dev/fid/) value for the current page and calls the `onReport` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value (and optionally the input event if using the [FID polyfill](#fid-polyfill)). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `getLCP()`\n\n```ts\ntype getLCP = (onReport: ReportHandler, reportAllChanges?: boolean) => void\n```\n\nCalculates the [LCP](https://web.dev/lcp/) value for the current page and calls the `onReport` function once the value is ready (along with the relevant `largest-contentful-paint` performance entries used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` param is `true`, the `onReport` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `getTTFB()`\n\n```ts\ntype getTTFB = (onReport: ReportHandler, reportAllChanges?: boolean) => void\n```\n\nCalculates the [TTFB](https://web.dev/time-to-first-byte/) value for the current page and calls the `onReport` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `onReport` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it [includes](https://developers.google.com/web/fundamentals/performance/navigation-and-resource-timing#the_life_and_timings_of_a_network_request) time spent on DNS lookup, connection negotiation, network latency, and unloading the previous document. If, in addition to TTFB, you want a metric that excludes these timings and _just_ captures the time spent making the request and receiving the first byte of the response, you could compute that from data found on the performance entry:\n\n```js\nimport {getTTFB} from 'web-vitals';\n\ngetTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `getCLS()`: Chromium,\n- `getFCP()`: Chromium, Firefox, Safari\n- `getFID()`: Chromium, Firefox, Safari, Internet Explorer (with the [polyfill](#how-to-use-the-polyfill))\n- `getLCP()`: Chromium\n- `getTTFB()`: Chromium, Firefox, Safari, Internet Explorer\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that\nmeasure the Web Vitals metrics, which means the limitations of those APIs will\nmostly apply to this library as well.\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `getCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"21915c4be1e967a05e4e2b21e264ba2a83f1b84a","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@2.0.0-beta.1","_nodeVersion":"14.16.0","_npmVersion":"6.14.11","dist":{"integrity":"sha512-UZ57B8x8s2t8MR+4LwVCKUTUf/nX9e49C2mCEQaiJuTscUOrbq+7PSziGXodFWwDXSVeR4xZ25BUvktXge94sA==","shasum":"e40c9b3d88f1a61a8e7821cee942cb97ec1b8f32","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-2.0.0-beta.1.tgz","fileCount":62,"unpackedSize":134536,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJgnK1jCRA9TVsSAnZWagAA9c0P/0Y/0Ee5xV9q6sOkq2Cn\nuwhxXiLPLN604MLSR6imTwIg9YFIVgnG7Vw81XyO5vHVfMA4EgrjYw+9Iq21\nauOPM00RGehNjI6fDVOwwVo7n8sa28qEr8Qc2d7W1F+nwERa4Vhea1WiJ7VC\niynIB7TDa93eIGv/MWhMEXIokQxroDT2JLsVbpTxKqw55/xpgAyIFm4nqSgL\nffFapxjr5TcJ6KKjsjnOvHwY7/3Oq7YleUSaaeDWhpDz/TFwxG0lAwciNGZM\nGK7g1a0uTuVOmxqFKbOzE+7Cn7ytZGawq/tx8nofCzONfQWuNKw6WgPNW1kx\n0X/lolKja+4xbEz6mxrna2Lb3UT/o/YfNQ4q8Rn7wunGuv9/GJiGEw91WhZ7\n8tFj5JEDH1Ga2l8hEn6r6yB1jTCwNrC/ppbXhR7YR1zHaO09BQcfUsYpojea\nGYDvdahpGIHD8oS+Zf57s8WpjMkdP65O02vqyRdz7kSmPl2qgA+QsMTUIOfP\nZcIf7DT/sdALqOTEhbpe0PQxwoMX/rJfmWuWQncFURehosrjbmnFYc1zPjkI\nZtEieX9TFiFvrFDxrXwD+pwXRFTSP6Gc7rY3W00ESdwmQk5U6MuoNTauxsyf\nPJXp7+kcIbKkPfuYPyRejPZEz+959Join4ilh24hBqjUt5ZhgXjqsFkfBhis\nRNew\r\n=39dN\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIEZy9k5gsaP8r8+xZOKFmaIXfkPZUBzhZD8pobizt+yhAiEAwdiLmwFFCgNjCxL0eJIw4FIUsor4XeqjxWvQEdymGOc="}]},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_2.0.0-beta.1_1620880739143_0.9687735569090727"},"_hasShrinkwrap":false},"2.0.0-beta.2":{"name":"web-vitals","version":"2.0.0-beta.2","description":"Easily measure performance metrics in JavaScript","main":"dist/web-vitals.umd.js","module":"dist/web-vitals.js","typings":"dist/modules/index.d.ts","scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","start":"run-p watch test:server","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","CLS","FCP","FID","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.13.10","@babel/preset-env":"^7.13.10","@rollup/plugin-replace":"^2.4.1","@typescript-eslint/eslint-plugin":"^4.17.0","@typescript-eslint/parser":"^4.17.0","@wdio/cli":"^7.1.2","@wdio/local-runner":"^7.1.2","@wdio/mocha-framework":"^7.1.2","@wdio/selenium-standalone-service":"^7.1.1","@wdio/spec-reporter":"^7.1.1","babel-eslint":"^10.1.0","body-parser":"^1.19.0","chromedriver":"^89.0.0","eslint":"^7.22.0","eslint-config-google":"^0.14.0","express":"^4.17.1","fs-extra":"^9.1.0","husky":"^5.1.3","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","rollup":"^2.41.2","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.2.3","wdio-chromedriver-service":"^7.0.0"},"gitHead":"f64dc13eeb4f7f89c291f65cca2f07f6d21614c9","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@2.0.0-beta.2","_nodeVersion":"14.16.0","_npmVersion":"6.14.11","dist":{"integrity":"sha512-Hc0ivPDyIthU8m/Ls8Z8h/8/CvSZYOBsrw3d6LUAAfp96c7MRnpyvgh1ZP0dzs1qtDPaJ1uzW2h7SZaZmltkvA==","shasum":"82328dee4a7c9dda8d429e0404a79da341759b69","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-2.0.0-beta.2.tgz","fileCount":65,"unpackedSize":135990,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJgsVEmCRA9TVsSAnZWagAAKhwP/jRezCWMW95Qjs4WjUc0\niWUr8TjNuiqmytT4TMEadhldXk1tVgU09UYnjblmtZ8PCVOi+pjINGpfLUEK\nyGOEY1l2LivWI3IZhxq27DQhAl8pIlEaf+H2E23P8WoTm9wGECciJW/XTGzS\ntgN3OlrR4lqJoq+ZWc6Bmbz89j6uq1+kn8GLhDHrU7+BVLApj59py6VilcGT\nOOiDuAqOGcBVKaacYhthNRJqq/Nbqv2OKDjbqivpb4LTC3a9Nr9viy1w5I/r\nWwvy+BC366/nvdm+CYkysdxNpwjMU0HvdHhaZ8D39m5lzfHYqqdC9kS+yp66\nm6TOD1RlCZbWnnK7ufMFzkCTBI1ElCVzQWbpbYkSHv8FyAbpDqsW3eMSZZbD\n+GLY/FjncgDu7T9iMxxq8tryGg4OnqDI247yO07HGJxJvXMy94m+mpuVHB5Q\ngzPXir9aeCTs0hBk0jqg8xj9i+LVA4IA7YuNYATs6l+oOGu3+64LfLg8rlA4\nrvNcC/WGpyf6nz9F/viC4owy5uBJ1w7Nv23QzMD8zkmbuUNCkx1ntg8Q/I56\nHNi4/kKWTeCJJMDioOW/oGOLCobvRx+REoEmylJQ6KJFSDknwGbxN3Y3n5yk\nOPf3deqsfY1QagpaoPgwTAuqqGcPPMpWSgkn8jeORhWc6XaX71xhfa4Q1mcc\nH6+m\r\n=2n15\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCfYv1nY6cg7Wiq6onjO2Nt0HW2klc6EKRF7Lb3t2Vo9AIhAJ+Ehxov0TvDVCT3HOZeEEEX0+EI6DoeCVI2E61rYvDc"}]},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_2.0.0-beta.2_1622233381173_0.5581473220755231"},"_hasShrinkwrap":false},"2.0.0":{"name":"web-vitals","version":"2.0.0","description":"Easily measure performance metrics in JavaScript","main":"dist/web-vitals.umd.js","module":"dist/web-vitals.js","typings":"dist/modules/index.d.ts","scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","CLS","FCP","FID","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.14.3","@babel/preset-env":"^7.14.4","@rollup/plugin-replace":"^2.4.2","@typescript-eslint/eslint-plugin":"^4.26.0","@typescript-eslint/parser":"^4.26.0","@wdio/cli":"^7.7.2","@wdio/local-runner":"^7.7.2","@wdio/mocha-framework":"^7.7.2","@wdio/selenium-standalone-service":"^7.7.0","@wdio/spec-reporter":"^7.7.0","babel-eslint":"^10.1.0","body-parser":"^1.19.0","chromedriver":"^90.0.1","eslint":"^7.27.0","eslint-config-google":"^0.14.0","express":"^4.17.1","fs-extra":"^10.0.0","husky":"^6.0.0","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","rollup":"^2.50.5","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.3.2","wdio-chromedriver-service":"^7.1.0"},"gitHead":"7fd9ce5bf754adb9934bf7ec06db36a27a8b473e","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@2.0.0","_nodeVersion":"14.17.0","_npmVersion":"7.15.0","dist":{"integrity":"sha512-aCB1sYxt2eeBufybFRrDQNBg2cOcq2f6Q1He7T+qPHAwpodDXhAoWwBUavwppQQ4kfUcT5eIAfjPc9PdqAxPEw==","shasum":"7fcfb5fd2f439c2936822573cb4d5e8e4caaa22b","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-2.0.0.tgz","fileCount":66,"unpackedSize":142661,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJgttehCRA9TVsSAnZWagAATm0P/0vw8wYvXpXQWX77VJgk\nkgwj3ZErpfKkSEBS7QQaSOaqAE9/Y87UntzdQfn1zu3l2/OcT2GHgOhHKCYs\nmRRug2puHdAL73o7Oj280iGF0gTcP0yK1m5C9RthhMKLLWxALPaDkzBc/luj\n3LvwCMVbSrNsW6z7oRSnygwMzqUJgCEywQptTpTRNhuGkOu9YmYCF2Ksazqd\nPI73ToJUNsArqqoMrBdam3Kxr+IzkmAGsOV9hDtvxmlw3JY7wmXXwUh3F3kS\nbPpEZewx8MMBDue6DPvWqRRI7KZqnQMdl1dvgP5FyDNeB+UTzr+Btc7h1EWN\ne99bZdYB5ODD0cXS2q9vKSksuhDNtBdslpbmwjYdjCw7UereoijkmpM3DwVb\n0QBKUF93dOTHuxfppMg/+4C3ohmvurQHrvSUrZXmLuLxgj9RcTUy5oEajima\nAoIIL+dhybsWWH/EFfZChBUkbvIlr98M/Gn+V0oi5uTgnGjMfJ4WMVyTfHHp\nwyGHsr5XyrHtq0CQ4307jgHAIM54s31QbpQXnhtT9NFTvF+uPspfS5hYsYZ1\n6QH/v14UwPo2+Zr0GzwPfBcDwCbEOhKppCyt+qQbu4FV87aihsWz2feoIZDw\nOBXx59byneVPQWpluNekg4P8zyMs27ZULo84AZO49/dzAkH4C4SLmqhnu9Hs\nBxTK\r\n=CgsY\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCUfrKwiCcYnm8fkY3HwNXIfKxHyYfK1lzPcVeSdVdB7gIgYPZQrn9yBoYm3c7kO8RoATs8JecmASG17NahjrajtfI="}]},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_2.0.0_1622595489114_0.3711573122050682"},"_hasShrinkwrap":false},"2.0.1":{"name":"web-vitals","version":"2.0.1","description":"Easily measure performance metrics in JavaScript","main":"dist/web-vitals.umd.js","module":"dist/web-vitals.js","typings":"dist/modules/index.d.ts","scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","CLS","FCP","FID","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.14.3","@babel/preset-env":"^7.14.4","@rollup/plugin-replace":"^2.4.2","@typescript-eslint/eslint-plugin":"^4.26.0","@typescript-eslint/parser":"^4.26.0","@wdio/cli":"^7.7.2","@wdio/local-runner":"^7.7.2","@wdio/mocha-framework":"^7.7.2","@wdio/selenium-standalone-service":"^7.7.0","@wdio/spec-reporter":"^7.7.0","babel-eslint":"^10.1.0","body-parser":"^1.19.0","chromedriver":"^90.0.1","eslint":"^7.27.0","eslint-config-google":"^0.14.0","express":"^4.17.1","fs-extra":"^10.0.0","husky":"^6.0.0","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","rollup":"^2.50.5","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.3.2","wdio-chromedriver-service":"^7.1.0"},"gitHead":"b60c8c3600cd68e38c661f66dd0817f9426ce959","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@2.0.1","_nodeVersion":"14.17.0","_npmVersion":"7.15.0","dist":{"integrity":"sha512-niqKyp2T6xF9EzSi+xx+V6qitE0YfagzfUmDAa9qeCrIVeyfzQQ85Uy0ykeRlEVDCCqkhYccoUunNf9ZIQcvtA==","shasum":"d122720bd9c8dd69792b19c0f6ab0346861a880f","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-2.0.1.tgz","fileCount":66,"unpackedSize":143186,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJgt9oSCRA9TVsSAnZWagAA6wQP/RC8YaNsNcy3mhSnJakb\nSZiMHwz1oM5uIGjP98GskeT1gY44pF4DGq+JBiC48tB9wo29alxKnlKct1L0\nlTx6k9pd0LrBXkkI06QfJiFYQXom3CeBBl+C2zQPNofgS5q+aVZd+3yE79w3\nevMDWqN7O2qFdxfxWl3MY9jQq5lpElr4Rt3gjJu+WnQ7opf/z68ZAYD6kw9z\n/QkuhE2kpnjkY2U1HFDrDoeyX4lM+eoQ+tjC4kB0JuIRHrPLHGbRaM6IbV7N\nnOMPSlBON7ptpJn9TbMLmNke0hZKWjy3YL9aLbBMkHfUDmW55GHuV7GtgBVX\nlLX3sUewy8Jwpw+XwrKIqgdjTWZozAPscXImf8jNgSH41ALMDA1Peowj2Emm\n9dgEV445D2uE35xBYIR348LrZQIeHy6kqCvg9uG7zyr+7Dm3RLzP7JWQsG/c\nlGiHmTSDV7JAmwoyoGZlYWB7uwGMNZ+kR9efQ3sHcaFlKN95uWMJqZw8TNAo\nWLMYxv+gYb1h4nvZFqvSC64OomjPZfiVJfKsvZADT6Kfm6dDrEtuH3pJNnL4\nbvQBzYOBQcZfvT1wP1eeddHG8sAm/Li/UrPNkyLXuxY7wWHltj/yspbmttmi\nMdWS1ioYA8xSqu5p7CfSD13b0Huvil0zb7x1ZwmK9stAaAgp64FJdZsyiYVg\nvNlS\r\n=rntO\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQD2ylQ2qNigvhdv626HLOzKQ1Ju146juX/+0PQgBK0dGAIhANIi/mM9WxDTxTTzJWr8GxTLf/O9Kr4U+vLwwXTtAi7j"}]},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_2.0.1_1622661650232_0.9544658856752475"},"_hasShrinkwrap":false},"2.1.0":{"name":"web-vitals","version":"2.1.0","description":"Easily measure performance metrics in JavaScript","main":"dist/web-vitals.umd.js","module":"dist/web-vitals.js","typings":"dist/modules/index.d.ts","scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","CLS","FCP","FID","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.14.6","@babel/preset-env":"^7.14.7","@rollup/plugin-replace":"^2.4.2","@typescript-eslint/eslint-plugin":"^4.28.1","@typescript-eslint/parser":"^4.28.1","@wdio/cli":"^7.7.4","@wdio/local-runner":"^7.7.4","@wdio/mocha-framework":"^7.7.4","@wdio/selenium-standalone-service":"^7.7.4","@wdio/spec-reporter":"^7.7.3","babel-eslint":"^10.1.0","body-parser":"^1.19.0","chromedriver":"^91.0.1","eslint":"^7.29.0","eslint-config-google":"^0.14.0","express":"^4.17.1","fs-extra":"^10.0.0","husky":"^7.0.0","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","rollup":"^2.52.6","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.3.5","wdio-chromedriver-service":"^7.1.1"},"gitHead":"3f3338d994f182172d5b97b22a0fcce0c2846908","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@2.1.0","_nodeVersion":"14.17.0","_npmVersion":"7.15.0","dist":{"integrity":"sha512-npEyJP8jHf3J71t1tRTEtz9FeKp8H2udWJUUq5ykfPhhstr//TUxiYhIEzLNwk4zv2ybAilMn7v7N6Mxmuitmg==","shasum":"ebf5428875ab5bfc1056c2e80cd177001287de7b","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-2.1.0.tgz","fileCount":63,"unpackedSize":143767,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJg3k7lCRA9TVsSAnZWagAA1QgP/jUh7t8ekZRJ2O/VTOIJ\nexMx1Pexj0c1TpCwnsEIEAQIS+04Si/O0XM1bxGoypmeu2KoJ5iIp4BMtRM8\n8isoCRG0T8x2iU+fmhWtJwDcB5CwEDe8/7SYJth8IzLdmA3Qr0gEQ81txE4/\nQb4LrRW5UxlDXiqyGVEmtUOT7ltRoC+5spgNg4+teYesT+NMzWg/RFGjt1zS\nCPkH3He7/3REo9iMATH1gzX/oBZJzv0PORGo+HofztNE3sXf49mzJOu9+SkM\nSQMzKtNye5eMTTrSsxOza0DYzAs18B3VO7i8xY7OVM+2ACLZV/al4dh4QXep\nS71XX4ddZQi4BvC+mIrE03fwRY4HGA7207ul597DGWADAdJz3Ib1fyS5o2qb\n5PREMZyAFbI4JBDXKlCMo/1IZ1+9UvOQHAvkzJv8Fi/ZN81vOc5Mdorov4iS\n7FOr0YAIay11LHJl5GjhyNaOP42WrZV2tOLQI8vmAgh+DLSoYdKEohMJ0OBp\n3fibzwx9lvQ6G6s34AXjkMJ/JDOj7u/BkszaP39EBs6rg1tQPHmfY9u7ZRh0\nOhjGr66/EkwqFNlo0+ho4rwzgYEiaSSDDh1ZkZFfIeIG/G8amN4xY+Pqmaaj\nfxbl/HhpNvnoAauDQAamebBC2hHYXbj6G6/ThgC6st0xVOTemIkW3bxd2Cp7\nuVUc\r\n=+7/a\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCfy4zCCIOZl3Di4/rBhonylrVhvOlBp0g5nkTEFWrpWwIgGKTRYiUrPpIdDzUGV4cPaR93EY7FZ6H/6bIW/w8Ot2Q="}]},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_2.1.0_1625181924227_0.8508747979168674"},"_hasShrinkwrap":false},"2.1.1":{"name":"web-vitals","version":"2.1.1","description":"Easily measure performance metrics in JavaScript","main":"dist/web-vitals.umd.js","module":"dist/web-vitals.js","typings":"dist/modules/index.d.ts","scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","CLS","FCP","FID","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.14.6","@babel/preset-env":"^7.14.7","@rollup/plugin-replace":"^2.4.2","@typescript-eslint/eslint-plugin":"^4.28.1","@typescript-eslint/parser":"^4.28.1","@wdio/cli":"^7.7.4","@wdio/local-runner":"^7.7.4","@wdio/mocha-framework":"^7.7.4","@wdio/selenium-standalone-service":"^7.7.4","@wdio/spec-reporter":"^7.7.3","babel-eslint":"^10.1.0","body-parser":"^1.19.0","chromedriver":"^91.0.1","eslint":"^7.29.0","eslint-config-google":"^0.14.0","express":"^4.17.1","fs-extra":"^10.0.0","husky":"^7.0.0","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","rollup":"^2.52.6","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.3.5","wdio-chromedriver-service":"^7.1.1"},"gitHead":"225ed1460f23e4eb0e45b70c73a892eb7964483e","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@2.1.1","_nodeVersion":"14.18.0","_npmVersion":"6.14.15","dist":{"integrity":"sha512-6i/cE+7l095Etvjo2kbtVC8OXzLc9D8XMIWBPWAt2CME/7qmIMZWQwVoKDD277poVHNdPcLgW5Jruhbi8+8Vcw==","shasum":"9ae64fa9054b8865a3fa093cd8db302676822c2a","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-2.1.1.tgz","fileCount":64,"unpackedSize":147092,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIAUrSLYHffoBppx03No6eK2VqV3+PTHdC/XQi9nKSgcLAiBRLKJJi6rvr89GxiM3Iv8nke8Etr0qGTRt6pOxhuxI6A=="}]},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_2.1.1_1633566353168_0.5021990524077569"},"_hasShrinkwrap":false},"2.1.2":{"name":"web-vitals","version":"2.1.2","description":"Easily measure performance metrics in JavaScript","main":"dist/web-vitals.umd.js","module":"dist/web-vitals.js","typings":"dist/modules/index.d.ts","scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","CLS","FCP","FID","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.14.6","@babel/preset-env":"^7.14.7","@rollup/plugin-replace":"^2.4.2","@typescript-eslint/eslint-plugin":"^4.28.1","@typescript-eslint/parser":"^4.28.1","@wdio/cli":"^7.7.4","@wdio/local-runner":"^7.7.4","@wdio/mocha-framework":"^7.7.4","@wdio/selenium-standalone-service":"^7.7.4","@wdio/spec-reporter":"^7.7.3","babel-eslint":"^10.1.0","body-parser":"^1.19.0","chromedriver":"^91.0.1","eslint":"^7.29.0","eslint-config-google":"^0.14.0","express":"^4.17.1","fs-extra":"^10.0.0","husky":"^7.0.0","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","rollup":"^2.52.6","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.3.5","wdio-chromedriver-service":"^7.1.1"},"gitHead":"ee6adc118ed14b6e2069924bfd765234bbebc867","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@2.1.2","_nodeVersion":"14.18.0","_npmVersion":"6.14.15","dist":{"integrity":"sha512-nZnEH8dj+vJFqCRYdvYv0a59iLXsb8jJkt+xvXfwgnkyPdsSLtKNlYmtTDiHmTNGXeSXtpjTTUcNvFtrAk6VMQ==","shasum":"3a6c8faebf9097a6ccd17f5f45c9485d8d62dab1","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-2.1.2.tgz","fileCount":64,"unpackedSize":147716,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDkz2Yn0fpFIZ28uxfhWrGDY01khITyNipQxod4G1grPQIgMoQMzgSYSpgmHoRzPXzDepbTnSN0GsAF3w7Tava+EFo="}]},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_2.1.2_1633992197116_0.4255673594619809"},"_hasShrinkwrap":false},"2.1.3":{"name":"web-vitals","version":"2.1.3","description":"Easily measure performance metrics in JavaScript","main":"dist/web-vitals.umd.js","module":"dist/web-vitals.js","typings":"dist/modules/index.d.ts","scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","CLS","FCP","FID","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.16.7","@babel/preset-env":"^7.16.7","@rollup/plugin-replace":"^3.0.1","@typescript-eslint/eslint-plugin":"^5.9.0","@typescript-eslint/parser":"^5.9.0","@wdio/cli":"^7.16.12","@wdio/local-runner":"^7.16.12","@wdio/mocha-framework":"^7.16.11","@wdio/selenium-standalone-service":"^7.16.11","@wdio/spec-reporter":"^7.16.11","body-parser":"^1.19.1","chromedriver":"^97.0.0","eslint":"^8.6.0","eslint-config-google":"^0.14.0","express":"^4.17.2","fs-extra":"^10.0.0","husky":"^7.0.4","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","rollup":"^2.63.0","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.5.4","wdio-chromedriver-service":"^7.2.6"},"gitHead":"c38944c0e7cffc64384888d49c4421839a5e8470","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@2.1.3","_nodeVersion":"14.18.0","_npmVersion":"8.1.1","dist":{"integrity":"sha512-+ijpniAzcnQicXaXIN0/eHQAiV/jMt1oHGHTmz7VdAJPPkzzDhmoYPSpLgJTuFtUh+jCjxCoeTZPg7Ic+g8o7w==","shasum":"6dca59f41dbc3fcccdb889da06191b437b18f534","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-2.1.3.tgz","fileCount":63,"unpackedSize":144596,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJh14gYCRA9TVsSAnZWagAA8q4QAIFTaqLvODYzT/xIGQZs\nx53wyJyKbSz4wG66g7uzGSQ3NDHA4IScZ3DNfwgMF9DKkyrYY7q3/4wXgK/s\nJGNWWfec6ewQc2oippg5Eai24F72Vzt90GO2UwEGEbJ+DxnsH0TmWmRGo+G/\nmGkyyE8bwu2plTzPd/Po1LXhHdHO7Znrw7cX9f7g7sgviaXlnzZktRjDp6bq\nzLB3I3He9zWj/nWAuvcJC2Vky9+U3cazmDQNw0Eh9T9G6e3CUwqpEje0x9yE\nqImO3/pJzSYxqh8hRh0rM78bVk5lw8JH/9eKmyQ1omicm6TEQ6V1dHrVLdk6\nheGRdE8590mwtzKh8uqPfJ8ethLNehrsD9vIcIYnaw8hWScdpTg8oFCif37d\ncDYufabOWCdUQsOiKsntTVcgT9VWtf3/UDOWIzaTrSesnP2Fkz+x1VPpSNbV\nHEkz47+YqnP0b0xmZKQFHPBnDIb/CZn//Fmtc8i+N0ZgMoQyatf0pFUeDuVK\nrfX5/ji2ok5ox3JxsyJ/bzszhOHfb72Tva/R2cgZMnN1Fvo2e1dqbfRYos8Y\nAS1HJAAgkwkLvAaF/IV2iSUAJ0bJP5Cx6CFaCnFujcMXZe/9EaJIbWy4C4eN\nSvHfJaJsgFNReMnzjGRLdimODCkSxA7PPcJXd5gPFizz0QI3+Yt8Y8aXKE/x\nbUHO\r\n=A7Rj\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIGwoALng2J9Zv9p1XZbWszOQHSaGP1J30jAC69SlxPgLAiBN0lZ7WUVtNiDV/14gsjAV0MBMLKJqc54c8tUp4pPwlA=="}]},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_2.1.3_1641515032467_0.7429609739162821"},"_hasShrinkwrap":false},"2.1.4":{"name":"web-vitals","version":"2.1.4","description":"Easily measure performance metrics in JavaScript","main":"dist/web-vitals.umd.js","module":"dist/web-vitals.js","typings":"dist/modules/index.d.ts","scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","CLS","FCP","FID","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.16.10","@babel/preset-env":"^7.16.11","@rollup/plugin-replace":"^3.0.1","@typescript-eslint/eslint-plugin":"^5.10.0","@typescript-eslint/parser":"^5.10.0","@wdio/cli":"^7.16.13","@wdio/local-runner":"^7.16.13","@wdio/mocha-framework":"^7.16.13","@wdio/selenium-standalone-service":"^7.16.13","@wdio/spec-reporter":"^7.16.13","body-parser":"^1.19.1","chromedriver":"^97.0.0","eslint":"^8.7.0","eslint-config-google":"^0.14.0","express":"^4.17.2","fs-extra":"^10.0.0","husky":"^7.0.4","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","rollup":"^2.64.0","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.5.5","wdio-chromedriver-service":"^7.2.6"},"gitHead":"71ac4a03c4c71861196925275e803a05ad017723","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@2.1.4","_nodeVersion":"14.18.0","_npmVersion":"8.1.1","dist":{"integrity":"sha512-sVWcwhU5mX6crfI5Vd2dC4qchyTqxV8URinzt25XqVh+bHEPGH4C3NPrNionCP7Obx59wrYEbNlw4Z8sjALzZg==","shasum":"76563175a475a5e835264d373704f9dde718290c","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-2.1.4.tgz","fileCount":63,"unpackedSize":144816,"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v3.0.13\r\nComment: https://openpgpjs.org\r\n\r\nwsFcBAEBCAAQBQJh6hYRCRA9TVsSAnZWagAALdgQAIpro+vlmeegNcIfTidQ\n5FcNy7ydWqlGlpq5S6p3cXfyqGFIjTC9mzZiyexuKylft3Z3IU5Hp9yyzpQD\nnULxahsuEE5SXZ2lDZKJ9lP1LQ25w/t7uazYMjC5p5ZClhRhGw41kXloB7iH\nSB0IQ3UEJ2b8lCSCFad4upB7c6LU9F9zsVikLSSTYJ9N7e8aRmufuaPPEIQS\ngmPh8lm+Ft2YTxavWsrFFIaZZQ9a8pZHeVY6qTw1VxLnABeTDkljEdsUP1Ms\nUPwp2H1GA7QteMOrirDdPagMRqpmrw4OuczhC7ldUFOomxhqDP5bUBnkzR5S\nI4T2+eoM7/y1eRTZl8Fi+Ij/kaesQmswu6N9pVBSeUCMFt06ies7JtoNnJiy\niHkxTi4z8ahSs4nvXGBI0LdsxoXeY3OjTPVlHmKMNC/mbGzrwi0zI4ZmW0Pp\n52Be08Yx9ugFqZdlFJQb5RxTwALrQ6d9e06BngQck29/SRO/BZB72sP2XwgN\nqrArefNh0VWabVyHQvqkKV5vUTE/ZQVs1M3F/LkRHkrkZzeKjbePAm0IBt95\nYytsf6CIrLSJux1Y5+K4MJ1zCueJuVTMeWpGvb2n9ETMXMkUZS4KINEk8O2G\nA/Vs9Fy7KnhR0sNCgB8fdrouwSUTg1h9bbpvjnQPAXsQXKkVuLrcHnZXFzv6\nAA7M\r\n=hybY\r\n-----END PGP SIGNATURE-----\r\n","signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQDIyUyqSrMgXet2IkXItBl76L4ayubeqX7yvhXHIXuWRgIhANG1Lzpma7qQJUtOuRphEeKADjYHRinkZS2igUMBGTzb"}]},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_2.1.4_1642731025039_0.9405957101377838"},"_hasShrinkwrap":false},"3.0.0-beta.0":{"name":"web-vitals","version":"3.0.0-beta.0","description":"Easily measure performance metrics in JavaScript","main":"dist/web-vitals.umd.js","module":"dist/web-vitals.js","typings":"dist/modules/index.d.ts","scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","CLS","FCP","FID","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.17.9","@babel/preset-env":"^7.16.11","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.20.0","@typescript-eslint/parser":"^5.20.0","@wdio/cli":"^7.19.6","@wdio/local-runner":"^7.19.5","@wdio/mocha-framework":"^7.19.5","@wdio/selenium-standalone-service":"^7.19.5","@wdio/spec-reporter":"^7.19.5","body-parser":"^1.20.0","chromedriver":"^100.0.0","eslint":"^8.14.0","eslint-config-google":"^0.14.0","express":"^4.17.3","fs-extra":"^10.1.0","husky":"^7.0.4","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","rollup":"^2.70.2","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.6.3","wdio-chromedriver-service":"^7.3.2"},"readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Bundle versions](#bundle-versions)\n  - [Which bundle is right for you?](#which-bundle-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/vitals/) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/vitals/#core-web-vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/user-centric-performance-metrics/) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/cls/)\n- [First Input Delay (FID)](https://web.dev/fid/)\n- [Largest Contentful Paint (LCP)](https://web.dev/lcp/)\n\n### Other metrics\n\n- [Interaction to next Paint (INP)](https://web.dev/responsiveness/) _(experimental)_\n- [First Contentful Paint (FCP)](https://web.dev/fcp/)\n- [Time to First Byte (TTFB)](https://web.dev/ttfb/)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\n# Install the latest version 3 beta (which includes INP).\nnpm install web-vitals@next\n\n# Install the current stable version (version 2).\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are two different versions of the `web-vitals` library (the \"standard\" version and the \"base+polyfill\" version), and how you load the library depends on which version you want to use.\n\nFor details on the difference between the two versions, see <a href=\"#which-bundle-is-right-for-you\">which bundle is right for you</a>.\n\n**1. The \"standard\" version**\n\nTo load the \"standard\" version, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onFID, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functioned were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**2. The \"base+polyfill\" version**\n\nLoading the \"base+polyfill\" version is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nNote that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com), whether your targeting just Chromium-based browsers (using the \"standard\" version) or additional browsers (using the \"base+polyfill\" version):\n\n_**Important!** users who want to load version 3 beta from the unpkg CDN should specify a version number or link to the [web-vitals@next](https://unpkg.com/web-vitals@next?module) tag._\n\n**Load the \"standard\" version** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" version** _(using a classic script)_\n\n```html\n<script>\n(function() {\n  var script = document.createElement('script');\n  script.src = 'https://unpkg.com/web-vitals/dist/web-vitals.iife.js';\n  script.onload = function() {\n    // When loading `web-vitals` using a classic script, all the public\n    // methods can be found on the `webVitals` global namespace.\n    webVitals.onCLS(console.log);\n    webVitals.onFID(console.log);\n    webVitals.onLCP(console.log);\n  }\n  document.head.appendChild(script);\n}())\n</script>\n```\n\n**Load the \"base+polyfill\" version** _(using a classic script)_\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `https://unpkg.com/web-vitals/dist/polyfill.js` here.\n    </script>\n  </head>\n  <body>\n    ...\n    <!-- Load the UMD version of the \"base\" bundle. -->\n    <script>\n    (function() {\n      var script = document.createElement('script');\n      script.src = 'https://unpkg.com/web-vitals/dist/web-vitals.base.iife.js';\n      script.onload = function() {\n        // When loading `web-vitals` using a classic script, all the public\n        // methods can be found on the `webVitals` global namespace.\n        webVitals.onCLS(console.log);\n        webVitals.onFID(console.log);\n        webVitals.onLCP(console.log);\n      }\n      document.head.appendChild(script);\n    }())\n    </script>\n  </body>\n</html>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes an `onReport` callback. This callback will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" version, but they will work with the polyfill version as well.)_\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developers.google.com/web/tools/chrome-devtools/console/reference#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID is not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS should be reported any time the [page's `visibilityState` changes to hidden](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/bfcache/).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onFID()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want `onReport` to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each layout shift as it happens) by setting the optional, second argument (`reportAllChanges`) to `true`.\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended).\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, true);\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonFID(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `onReport` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonFID(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique dimension value (in this case, the metric `id`, as shown in the examples below) on every metric instance that you send to Google Analytics, you can create a report yourself using the [Google Analytics Reporting API](https://developers.google.com/analytics/devguides/reporting) and any data visualization library you choose.\n\nAs an example of this, the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) is a free and open-source tool you can use to create visualizations of the Web Vitals data that you've sent to Google Analytics.\n\n[![web-vitals-report](https://user-images.githubusercontent.com/326742/101584324-3f9a0900-3992-11eb-8f2d-182f302fb67b.png)](https://github.com/GoogleChromeLabs/web-vitals-report)\n\nIn order to use the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) (or build your own custom reports using the API) you need to send your data to Google Analytics following one of the examples outlined below:\n\n#### Using `analytics.js`\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `ga()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/analyticsjs\n  ga('send', 'event', {\n    eventCategory: 'Web Vitals',\n    eventAction: name,\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    eventLabel: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    nonInteraction: true,\n    // Use `sendBeacon()` if the browser supports it.\n    transport: 'beacon',\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-web-vitals-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Universal Analytics)\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/gtagjs\n  gtag('event', name, {\n    event_category: 'Web Vitals',\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    event_label: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    value: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    non_interaction: true,\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-web-vitals-in-the-field/\n    // metric_rating: 'good' | 'ni' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Google Analytics 4)\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-web-vitals-in-the-field/\n    // metric_rating: 'good' | 'ni' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n          fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonFID(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n## Bundle versions\n\nThe `web-vitals` package includes builds for both the \"standard\" and \"base+polyfill\" versions, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the bundles distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any extra polyfills to expand browser support.</p>\n      This is the \"standard\" version and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.js</code></td>\n    <td><code>pgk.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.js</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code>, <code>web-vitals.base.umd.js</code>, or <code>web-vitals.base.iife.js</code> (it will not work with any script that doesn't have \"base\" in the filename).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n### Which bundle is right for you?\n\nMost developers will generally want to use the \"standard\" bundle (either the ES module or UMD version, depending on your build system), as it's the easiest to use out of the box and integrate into existing build tools.\n\nHowever, there are a few good reasons to consider using the \"base+polyfill\" version, for example:\n\n- FID can be measured in all browsers.\n- CLS, FCP, FID, and LCP will be more accurate in some cases (since the polyfill detects the page's initial `visibilityState` earlier).\n\n### How the polyfill works\n\nThe `polyfill.js` script adds event listeners (to track FID cross-browser), and it records initial page visibility state as well as the timestamp of the first visibility change to hidden (to improve the accuracy of CLS, FCP, LCP, and FID).\n\nIn order for it to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" version of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" version, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  // The name of the metric (in acronym form).\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  // The current value of the metric.\n  value: number;\n\n  // The delta between the current value and the last-reported value.\n  // On the first report, `delta` and `value` will always be the same.\n  delta: number;\n\n  // A unique ID representing this particular metric that's specific to the\n  // current page. This ID can be used by an analytics tool to dedupe\n  // multiple values sent for the same metric, or to group multiple deltas\n  // together and calculate a total.\n  id: string;\n\n  // Any performance entries relevant to the metric value calculation.\n  // The array may also be empty if the metric value was not based on any\n  // entries (e.g. a CLS value of 0 given no layout shifts).\n  entries: (PerformanceEntry | LayoutShift | FirstInputPolyfillEntry | NavigationTimingPolyfillEntry)[];\n\n  // For regular navigations, the type will be the same as the type indicated\n  // by the Navigation Timing API (or `undefined` if the browser doesn't\n  // support that API). For pages that are restored from the bfcache, this\n  // value will be 'back_forward_cache'.\n  navigationType:  NavigationType | 'back_forward_cache' | undefined;\n}\n```\n\n#### `ReportHandler`\n\n```ts\ninterface ReportHandler {\n  (metric: Metric): void;\n}\n```\n\n#### `FirstInputPolyfillEntry`\n\nWhen using the FID polyfill (and if the browser doesn't natively support the Event Timing API), `metric.entries` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<PerformanceEventTiming, 'processingEnd' | 'toJSON'>\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nWhen calling `onTTFB()`, if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface, it will polyfill the entry object using timings from `performance.timing`:\n\n```ts\nexport type NavigationTimingPolyfillEntry = Omit<PerformanceNavigationTiming,\n  'initiatorType' | 'nextHopProtocol' | 'redirectCount' | 'transferSize' |\n  'encodedBodySize' | 'decodedBodySize' | 'toJSON'>\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n  firstHiddenTime: number;\n}\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (onReport: ReportHandler, reportAllChanges?: boolean) => void\n```\n\nCalculates the [CLS](https://web.dev/cls/) value for the current page and calls the `onReport` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/cls/#layout-shift-score)).\n\nIf the `reportAllChanges` param is `true`, the `onReport` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#advice-hidden), `onReport` is always called when the page's visibility state changes to hidden. As a result, the `onReport` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (onReport: ReportHandler, reportAllChanges?: boolean) => void\n```\n\nCalculates the [FCP](https://web.dev/fcp/) value for the current page and calls the `onReport` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n```ts\ntype onFID = (onReport: ReportHandler, reportAllChanges?: boolean) => void\n```\n\nCalculates the [FID](https://web.dev/fid/) value for the current page and calls the `onReport` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value (and optionally the input event if using the [FID polyfill](#fid-polyfill)). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (onReport: ReportHandler, reportAllChanges?: boolean) => void\n```\n\nCalculates the [INP](https://web.dev/responsiveness/) value for the current page and calls the `onReport` function once the value is ready, along with the  `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` param is `true`, the `onReport` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#advice-hidden), `onReport` is always called when the page's visibility state changes to hidden. As a result, the `onReport` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (onReport: ReportHandler, reportAllChanges?: boolean) => void\n```\n\nCalculates the [LCP](https://web.dev/lcp/) value for the current page and calls the `onReport` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` param is `true`, the `onReport` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (onReport: ReportHandler, reportAllChanges?: boolean) => void\n```\n\nCalculates the [TTFB](https://web.dev/time-to-first-byte/) value for the current page and calls the `onReport` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `onReport` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it [includes](https://developers.google.com/web/fundamentals/performance/navigation-and-resource-timing#the_life_and_timings_of_a_network_request) time spent on DNS lookup, connection negotiation, network latency, and unloading the previous document. If, in addition to TTFB, you want a metric that excludes these timings and _just_ captures the time spent making the request and receiving the first byte of the response, you could compute that from data found on the performance entry:\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium,\n- `onFCP()`: Chromium, Firefox, Safari\n- `onFID()`: Chromium, Firefox, Safari, Internet Explorer (with the [polyfill](#how-to-use-the-polyfill))\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari, Internet Explorer\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that\nmeasure the Web Vitals metrics, which means the limitations of those APIs will\nmostly apply to this library as well.\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/vitals-ga4/).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `onReport` callbacks and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"fb7e0586403a1e20ccad70358cde39104c003fa4","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.0.0-beta.0","_nodeVersion":"14.18.0","_npmVersion":"8.1.1","dist":{"integrity":"sha512-Iq2uJxmAe0DnAX+Y06XByU4l+L8xqVXk+gW2qghnMR43blzh+HfOxl/KmkvcQYBFNgMYFULvPeHCH5FohaDkKw==","shasum":"e8924e909783e223879a36b9a70078c3b578ea73","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.0.0-beta.0.tgz","fileCount":75,"unpackedSize":179850,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCtpJEn+oabkWbQuqcVj2CBQ5YtUIcQl6vDPu6CyDAQ3AIhALMpXNMc7gDJW2djvSLpJ9pzhhCqy6samNyOXjTN7UQl"}],"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v4.10.10\r\nComment: https://openpgpjs.org\r\n\r\nwsFzBAEBCAAGBQJiZzLcACEJED1NWxICdlZqFiEECWMYAoorWMhJKdjhPU1b\r\nEgJ2Vmq0Bw/+NOwUBeYStLyHUah0UiCFEe8QRYGCqs/LBVt5JvDjyhxOvpwK\r\nt1+W6TBopY5CDGmf2/VsQsRdowNj0CA4P2tsuVT3L+d6Z8dbzudzTWfJneQL\r\nz57cJzdmFCipGWt6Uvm/k6pfZut7/IWNa67amKmWpAEVA8zH1/+LYqmV6KKY\r\n1rYGnGSMv2fYYIMf+30PXZMZ1nlMkyKzq78ZM7yc9kVw+Orv2hE732MZAW9I\r\nmciqieIIgBQeBhEYGvI6gWH8aPpsodIbz2scM8Y9ZKtF087MX97bEzruwXU6\r\nObgk2hXhk1Nslpum6NXcXhgWWHD2Tn7yQLYzEJ2bzMFphK8+0FT7GILvqmAG\r\n9Do3AmNx3nqehsirJe5QD1RW+A6ifyBGxxkqYNVJWnnT1MlbDtOStP5UI2mY\r\nur82APqN0XF6lajCf+VZrEHykIB0zGt7eIrET9Yn01bpRt/hQKFbWT0KjPqT\r\noAqMasGPTOaSvRh0cyGJe8ds+jsgUde7JSKOmIFwIB9jK3QnDlim/Ny0MuhL\r\nRKl+tsWiHG3iVJ10WbmISkFucYZ4ko3AMPteryL67/QkXl5Voh5Vjof5s/QA\r\ncxuvr8GMPStb+obwn2B9W5HyV/TETFwHVkYr0WolyzRiaZNOjWdJ0y2ZcbX9\r\noCfkbxrexXrsRm7d4jU11eXs+wijQpryp+M=\r\n=g3ri\r\n-----END PGP SIGNATURE-----\r\n"},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.0.0-beta.0_1650930396227_0.28471274598228447"},"_hasShrinkwrap":false},"3.0.0-beta.1":{"name":"web-vitals","version":"3.0.0-beta.1","description":"Easily measure performance metrics in JavaScript","main":"dist/web-vitals.umd.js","module":"dist/web-vitals.js","typings":"dist/modules/index.d.ts","scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","CLS","FCP","FID","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.17.9","@babel/preset-env":"^7.16.11","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.20.0","@typescript-eslint/parser":"^5.20.0","@wdio/cli":"^7.19.6","@wdio/local-runner":"^7.19.5","@wdio/mocha-framework":"^7.19.5","@wdio/selenium-standalone-service":"^7.19.5","@wdio/spec-reporter":"^7.19.5","body-parser":"^1.20.0","chromedriver":"^100.0.0","eslint":"^8.14.0","eslint-config-google":"^0.14.0","express":"^4.17.3","fs-extra":"^10.1.0","husky":"^7.0.4","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","rollup":"^2.70.2","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.6.3","wdio-chromedriver-service":"^7.3.2"},"readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Bundle versions](#bundle-versions)\n  - [Which bundle is right for you?](#which-bundle-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/vitals/) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/vitals/#core-web-vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/user-centric-performance-metrics/) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/cls/)\n- [First Input Delay (FID)](https://web.dev/fid/)\n- [Largest Contentful Paint (LCP)](https://web.dev/lcp/)\n\n### Other metrics\n\n- [Interaction to next Paint (INP)](https://web.dev/responsiveness/) _(experimental)_\n- [First Contentful Paint (FCP)](https://web.dev/fcp/)\n- [Time to First Byte (TTFB)](https://web.dev/ttfb/)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\n# Install the latest version 3 beta (which includes INP).\nnpm install web-vitals@next\n\n# Install the current stable version (version 2).\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are two different versions of the `web-vitals` library (the \"standard\" version and the \"base+polyfill\" version), and how you load the library depends on which version you want to use.\n\nFor details on the difference between the two versions, see <a href=\"#which-bundle-is-right-for-you\">which bundle is right for you</a>.\n\n**1. The \"standard\" version**\n\nTo load the \"standard\" version, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onFID, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functioned were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**2. The \"base+polyfill\" version**\n\nLoading the \"base+polyfill\" version is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nNote that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com), whether your targeting just Chromium-based browsers (using the \"standard\" version) or additional browsers (using the \"base+polyfill\" version):\n\n_**Important!** users who want to load version 3 beta from the unpkg CDN should specify a version number or link to the [web-vitals@next](https://unpkg.com/web-vitals@next?module) tag._\n\n**Load the \"standard\" version** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" version** _(using a classic script)_\n\n```html\n<script>\n(function() {\n  var script = document.createElement('script');\n  script.src = 'https://unpkg.com/web-vitals/dist/web-vitals.iife.js';\n  script.onload = function() {\n    // When loading `web-vitals` using a classic script, all the public\n    // methods can be found on the `webVitals` global namespace.\n    webVitals.onCLS(console.log);\n    webVitals.onFID(console.log);\n    webVitals.onLCP(console.log);\n  }\n  document.head.appendChild(script);\n}())\n</script>\n```\n\n**Load the \"base+polyfill\" version** _(using a classic script)_\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `https://unpkg.com/web-vitals/dist/polyfill.js` here.\n    </script>\n  </head>\n  <body>\n    ...\n    <!-- Load the UMD version of the \"base\" bundle. -->\n    <script>\n    (function() {\n      var script = document.createElement('script');\n      script.src = 'https://unpkg.com/web-vitals/dist/web-vitals.base.iife.js';\n      script.onload = function() {\n        // When loading `web-vitals` using a classic script, all the public\n        // methods can be found on the `webVitals` global namespace.\n        webVitals.onCLS(console.log);\n        webVitals.onFID(console.log);\n        webVitals.onLCP(console.log);\n      }\n      document.head.appendChild(script);\n    }())\n    </script>\n  </body>\n</html>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes a `callback` function that will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" version, but they will work with the polyfill version as well.)_\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developers.google.com/web/tools/chrome-devtools/console/reference#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID is not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS should be reported any time the [page's `visibilityState` changes to hidden](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/bfcache/).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onFID()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want the `callback` function to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each layout shift as it happens) by setting `reportAllChanges` to `true` in the optional, [configuration object](#reportopts) (second parameter).\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended) for measuring these metrics in production.\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, {reportAllChange: true});\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonFID(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `callback` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonFID(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique dimension value (in this case, the metric `id`, as shown in the examples below) on every metric instance that you send to Google Analytics, you can create a report yourself using the [Google Analytics Reporting API](https://developers.google.com/analytics/devguides/reporting) and any data visualization library you choose.\n\nAs an example of this, the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) is a free and open-source tool you can use to create visualizations of the Web Vitals data that you've sent to Google Analytics.\n\n[![web-vitals-report](https://user-images.githubusercontent.com/326742/101584324-3f9a0900-3992-11eb-8f2d-182f302fb67b.png)](https://github.com/GoogleChromeLabs/web-vitals-report)\n\nIn order to use the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) (or build your own custom reports using the API) you need to send your data to Google Analytics following one of the examples outlined below:\n\n#### Using `analytics.js`\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `ga()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/analyticsjs\n  ga('send', 'event', {\n    eventCategory: 'Web Vitals',\n    eventAction: name,\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    eventLabel: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    nonInteraction: true,\n    // Use `sendBeacon()` if the browser supports it.\n    transport: 'beacon',\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-web-vitals-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Universal Analytics)\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/gtagjs\n  gtag('event', name, {\n    event_category: 'Web Vitals',\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    event_label: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    value: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    non_interaction: true,\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-web-vitals-in-the-field/\n    // metric_rating: 'good' | 'ni' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Google Analytics 4)\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-web-vitals-in-the-field/\n    // metric_rating: 'good' | 'ni' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n          fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonFID(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n## Bundle versions\n\nThe `web-vitals` package includes builds for both the \"standard\" and \"base+polyfill\" versions, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the bundles distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any extra polyfills to expand browser support.</p>\n      This is the \"standard\" version and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.js</code></td>\n    <td><code>pgk.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.js</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code>, <code>web-vitals.base.umd.js</code>, or <code>web-vitals.base.iife.js</code> (it will not work with any script that doesn't have \"base\" in the filename).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n### Which bundle is right for you?\n\nMost developers will generally want to use the \"standard\" bundle (either the ES module or UMD version, depending on your build system), as it's the easiest to use out of the box and integrate into existing build tools.\n\nHowever, there are a few good reasons to consider using the \"base+polyfill\" version, for example:\n\n- FID can be measured in all browsers.\n- CLS, FCP, FID, and LCP will be more accurate in some cases (since the polyfill detects the page's initial `visibilityState` earlier).\n\n### How the polyfill works\n\nThe `polyfill.js` script adds event listeners (to track FID cross-browser), and it records initial page visibility state as well as the timestamp of the first visibility change to hidden (to improve the accuracy of CLS, FCP, LCP, and FID).\n\nIn order for it to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" version of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" version, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  // The name of the metric (in acronym form).\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  // The current value of the metric.\n  value: number;\n\n  // The delta between the current value and the last-reported value.\n  // On the first report, `delta` and `value` will always be the same.\n  delta: number;\n\n  // A unique ID representing this particular metric that's specific to the\n  // current page. This ID can be used by an analytics tool to dedupe\n  // multiple values sent for the same metric, or to group multiple deltas\n  // together and calculate a total.\n  id: string;\n\n  // Any performance entries relevant to the metric value calculation.\n  // The array may also be empty if the metric value was not based on any\n  // entries (e.g. a CLS value of 0 given no layout shifts).\n  entries: (PerformanceEntry | LayoutShift | FirstInputPolyfillEntry | NavigationTimingPolyfillEntry)[];\n\n  // For regular navigations, the type will be the same as the type indicated\n  // by the Navigation Timing API (or `undefined` if the browser doesn't\n  // support that API). For pages that are restored from the bfcache, this\n  // value will be 'back_forward_cache'.\n  navigationType:  NavigationType | 'back_forward_cache' | undefined;\n}\n```\n\n#### `ReportCallback`\n\n```ts\ninterface ReportCallback {\n  (metric: Metric): void;\n}\n```\n\n#### `ReportOpts`\n\n```ts\ninterface ReportOpts {\n  reportAllChanges?: boolean;\n  durationThreshold?: number;\n}\n```\n\n#### `FirstInputPolyfillEntry`\n\nWhen using the FID polyfill (and if the browser doesn't natively support the Event Timing API), `metric.entries` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<PerformanceEventTiming, 'processingEnd' | 'toJSON'>\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nWhen calling `onTTFB()`, if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface, it will polyfill the entry object using timings from `performance.timing`:\n\n```ts\nexport type NavigationTimingPolyfillEntry = Omit<PerformanceNavigationTiming,\n  'initiatorType' | 'nextHopProtocol' | 'redirectCount' | 'transferSize' |\n  'encodedBodySize' | 'decodedBodySize' | 'toJSON'>\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n  firstHiddenTime: number;\n}\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (callback: ReportCallback, opts?: ReportOpts) => void\n```\n\nCalculates the [CLS](https://web.dev/cls/) value for the current page and calls the `callback` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/cls/#layout-shift-score)).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (callback: ReportCallback, opts?: ReportOpts) => void\n```\n\nCalculates the [FCP](https://web.dev/fcp/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n```ts\ntype onFID = (callback: ReportCallback, opts?: ReportOpts) => void\n```\n\nCalculates the [FID](https://web.dev/fid/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value (and optionally the input event if using the [FID polyfill](#fid-polyfill)). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (callback: ReportCallback, opts?: ReportOpts) => void\n```\n\nCalculates the [INP](https://web.dev/responsiveness/) value for the current page and calls the `callback` function once the value is ready, along with the  `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nA custom `durationThreshold` [configuration option](#reportopts) can optionally be passed to control what `event-timing` entries are considered for INP reporting. The default threshold is `40`, which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended [good](https://web.dev/inp/#what-is-a-good-inp-score) threshold).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (callback: ReportCallback, opts?: ReportOpts) => void\n```\n\nCalculates the [LCP](https://web.dev/lcp/) value for the current page and calls the `callback` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (callback: ReportCallback, opts?: ReportOpts) => void\n```\n\nCalculates the [TTFB](https://web.dev/time-to-first-byte/) value for the current page and calls the `callback` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `callback` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it [includes](https://developers.google.com/web/fundamentals/performance/navigation-and-resource-timing#the_life_and_timings_of_a_network_request) time spent on DNS lookup, connection negotiation, network latency, and unloading the previous document. If, in addition to TTFB, you want a metric that excludes these timings and _just_ captures the time spent making the request and receiving the first byte of the response, you could compute that from data found on the performance entry:\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium,\n- `onFCP()`: Chromium, Firefox, Safari\n- `onFID()`: Chromium, Firefox, Safari, Internet Explorer (with the [polyfill](#how-to-use-the-polyfill))\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari, Internet Explorer\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that\nmeasure the Web Vitals metrics, which means the limitations of those APIs will\nmostly apply to this library as well.\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/vitals-ga4/).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `callback` functions and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"4a3465fbded7253b6230f5c3cbeb162dd92d4e3b","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.0.0-beta.1","_nodeVersion":"14.18.0","_npmVersion":"8.1.1","dist":{"integrity":"sha512-iXNgLB8vrEfeBEfKZYmJSQCcw3fUBP1TuO/3lorvD3L8Jn77ZLnU1oh2a9olUxuiAcEdfOdP98H4Idfigy8llg==","shasum":"cfa887f270be52d0bee1249d246d78271a71e55d","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.0.0-beta.1.tgz","fileCount":75,"unpackedSize":183098,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIALG2aJSp6mb5xXUEJTCWzQtWYYpikH3lFBQjtUmUD/aAiBLsvjA5hWhIJhlshjer8Ic+QLrJeohIKyuaHKU3nkYUg=="}],"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v4.10.10\r\nComment: https://openpgpjs.org\r\n\r\nwsFzBAEBCAAGBQJifA0PACEJED1NWxICdlZqFiEECWMYAoorWMhJKdjhPU1b\r\nEgJ2VmqD5BAAlH3Y5Nj+div0nxZQEDrE9Kv8xtCTKjLDV8Yqiq5Xb36hW7P5\r\n0C5RBI2gyOxXiMO0rRyIotJt/UHLAQ9mVSqRwjULbB0lKdNy/dw1B71Iql8U\r\nt8+R5lJUSkF0XGjF4PmZSpF/VmGwX9SaRaa1tdKJ6tikOSjlKTyW4sPiSmLo\r\nSWaSuBf1QOsJIdnyWvPkOc+DQtMINlykuI04jwbCyN/ALjgoIgvMsovJyFPq\r\nwTRIs/+6YfPPSlE6C4OFMBo373lxarjh1Ip0Jn87EtlleBvZnwc9yeGxJIpy\r\nDcM4WZdPmSuu3xngjOh3vQBSNzZLXLQhrSGpfTrc5MuqgPYgTWuJLtJKlWyV\r\niRzsAPDiRALw3w7IBJWMxNjl2J11zyhv5N0lnPVXgxXC7+19pJXp99iFq96s\r\nJsRGxlg+hAPeVX5/t3u319ypegfhkSV3AVwUfJN8uUXu1AM9lPih3x3wk2Nm\r\nj+rkCqxu4drqGrAFkmuYHxOif6v0GjGOVf+Dfhq9SrvcdgWpw1JxfCA+sglq\r\nLGtukOaMcxR0fXH465whtKb1AvQIaSWC5jT8Lqgb1rmTreaPgNpaxavrfZBE\r\nR2nw97Myg6Pt5cqXFmWBPcEIa8K35mVMwvIutP3br3VXOJFlH0VAuWjikVJg\r\naEvufTOT7lSh11yc64J/K1xVqvC3H5qkYuU=\r\n=kcSk\r\n-----END PGP SIGNATURE-----\r\n"},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.0.0-beta.1_1652296975016_0.24032205925890104"},"_hasShrinkwrap":false},"3.0.0-beta.2":{"name":"web-vitals","version":"3.0.0-beta.2","description":"Easily measure performance metrics in JavaScript","main":"dist/web-vitals.umd.js","module":"dist/web-vitals.js","typings":"dist/modules/index.d.ts","scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.js","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","CLS","FCP","FID","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.17.9","@babel/preset-env":"^7.16.11","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.20.0","@typescript-eslint/parser":"^5.20.0","@wdio/cli":"^7.19.6","@wdio/local-runner":"^7.19.5","@wdio/mocha-framework":"^7.19.5","@wdio/selenium-standalone-service":"^7.19.5","@wdio/spec-reporter":"^7.19.5","body-parser":"^1.20.0","chromedriver":"^100.0.0","eslint":"^8.14.0","eslint-config-google":"^0.14.0","express":"^4.17.3","fs-extra":"^10.1.0","husky":"^7.0.4","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","rollup":"^2.70.2","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.6.3","wdio-chromedriver-service":"^7.3.2"},"readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Bundle versions](#bundle-versions)\n  - [Which bundle is right for you?](#which-bundle-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/vitals/) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/vitals/#core-web-vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/user-centric-performance-metrics/) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/cls/)\n- [First Input Delay (FID)](https://web.dev/fid/)\n- [Largest Contentful Paint (LCP)](https://web.dev/lcp/)\n\n### Other metrics\n\n- [Interaction to next Paint (INP)](https://web.dev/responsiveness/) _(experimental)_\n- [First Contentful Paint (FCP)](https://web.dev/fcp/)\n- [Time to First Byte (TTFB)](https://web.dev/ttfb/)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\n# Install the latest version 3 beta (which includes INP).\nnpm install web-vitals@next\n\n# Install the current stable version (version 2).\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are two different versions of the `web-vitals` library (the \"standard\" version and the \"base+polyfill\" version), and how you load the library depends on which version you want to use.\n\nFor details on the difference between the two versions, see <a href=\"#which-bundle-is-right-for-you\">which bundle is right for you</a>.\n\n**1. The \"standard\" version**\n\nTo load the \"standard\" version, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onFID, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functioned were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**2. The \"base+polyfill\" version**\n\nLoading the \"base+polyfill\" version is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nNote that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com), whether your targeting just Chromium-based browsers (using the \"standard\" version) or additional browsers (using the \"base+polyfill\" version):\n\n_**Important!** users who want to load version 3 beta from the unpkg CDN should specify a version number or link to the [web-vitals@next](https://unpkg.com/web-vitals@next?module) tag._\n\n**Load the \"standard\" version** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" version** _(using a classic script)_\n\n```html\n<script>\n(function() {\n  var script = document.createElement('script');\n  script.src = 'https://unpkg.com/web-vitals/dist/web-vitals.iife.js';\n  script.onload = function() {\n    // When loading `web-vitals` using a classic script, all the public\n    // methods can be found on the `webVitals` global namespace.\n    webVitals.onCLS(console.log);\n    webVitals.onFID(console.log);\n    webVitals.onLCP(console.log);\n  }\n  document.head.appendChild(script);\n}())\n</script>\n```\n\n**Load the \"base+polyfill\" version** _(using a classic script)_\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `https://unpkg.com/web-vitals/dist/polyfill.js` here.\n    </script>\n  </head>\n  <body>\n    ...\n    <!-- Load the UMD version of the \"base\" bundle. -->\n    <script>\n    (function() {\n      var script = document.createElement('script');\n      script.src = 'https://unpkg.com/web-vitals/dist/web-vitals.base.iife.js';\n      script.onload = function() {\n        // When loading `web-vitals` using a classic script, all the public\n        // methods can be found on the `webVitals` global namespace.\n        webVitals.onCLS(console.log);\n        webVitals.onFID(console.log);\n        webVitals.onLCP(console.log);\n      }\n      document.head.appendChild(script);\n    }())\n    </script>\n  </body>\n</html>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes a `callback` function that will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" version, but they will work with the polyfill version as well.)_\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developers.google.com/web/tools/chrome-devtools/console/reference#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID is not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS should be reported any time the [page's `visibilityState` changes to hidden](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/bfcache/).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onFID()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want the `callback` function to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each layout shift as it happens) by setting `reportAllChanges` to `true` in the optional, [configuration object](#reportopts) (second parameter).\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended) for measuring these metrics in production.\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, {reportAllChange: true});\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonFID(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `callback` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonFID(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique dimension value (in this case, the metric `id`, as shown in the examples below) on every metric instance that you send to Google Analytics, you can create a report yourself using the [Google Analytics Reporting API](https://developers.google.com/analytics/devguides/reporting) and any data visualization library you choose.\n\nAs an example of this, the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) is a free and open-source tool you can use to create visualizations of the Web Vitals data that you've sent to Google Analytics.\n\n[![web-vitals-report](https://user-images.githubusercontent.com/326742/101584324-3f9a0900-3992-11eb-8f2d-182f302fb67b.png)](https://github.com/GoogleChromeLabs/web-vitals-report)\n\nIn order to use the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) (or build your own custom reports using the API) you need to send your data to Google Analytics following one of the examples outlined below:\n\n#### Using `analytics.js`\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `ga()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/analyticsjs\n  ga('send', 'event', {\n    eventCategory: 'Web Vitals',\n    eventAction: name,\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    eventLabel: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    nonInteraction: true,\n    // Use `sendBeacon()` if the browser supports it.\n    transport: 'beacon',\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-web-vitals-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Universal Analytics)\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/gtagjs\n  gtag('event', name, {\n    event_category: 'Web Vitals',\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    event_label: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    value: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    non_interaction: true,\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-web-vitals-in-the-field/\n    // metric_rating: 'good' | 'ni' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Google Analytics 4)\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-web-vitals-in-the-field/\n    // metric_rating: 'good' | 'ni' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n          fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonFID(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n## Bundle versions\n\nThe `web-vitals` package includes builds for both the \"standard\" and \"base+polyfill\" versions, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the bundles distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any extra polyfills to expand browser support.</p>\n      This is the \"standard\" version and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.js</code></td>\n    <td><code>pgk.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.js</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code>, <code>web-vitals.base.umd.js</code>, or <code>web-vitals.base.iife.js</code> (it will not work with any script that doesn't have \"base\" in the filename).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n### Which bundle is right for you?\n\nMost developers will generally want to use the \"standard\" bundle (either the ES module or UMD version, depending on your build system), as it's the easiest to use out of the box and integrate into existing build tools.\n\nHowever, there are a few good reasons to consider using the \"base+polyfill\" version, for example:\n\n- FID can be measured in all browsers.\n- CLS, FCP, FID, and LCP will be more accurate in some cases (since the polyfill detects the page's initial `visibilityState` earlier).\n\n### How the polyfill works\n\nThe `polyfill.js` script adds event listeners (to track FID cross-browser), and it records initial page visibility state as well as the timestamp of the first visibility change to hidden (to improve the accuracy of CLS, FCP, LCP, and FID).\n\nIn order for it to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" version of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" version, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  // The name of the metric (in acronym form).\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  // The current value of the metric.\n  value: number;\n\n  // The delta between the current value and the last-reported value.\n  // On the first report, `delta` and `value` will always be the same.\n  delta: number;\n\n  // A unique ID representing this particular metric that's specific to the\n  // current page. This ID can be used by an analytics tool to dedupe\n  // multiple values sent for the same metric, or to group multiple deltas\n  // together and calculate a total.\n  id: string;\n\n  // Any performance entries relevant to the metric value calculation.\n  // The array may also be empty if the metric value was not based on any\n  // entries (e.g. a CLS value of 0 given no layout shifts).\n  entries: (PerformanceEntry | LayoutShift | FirstInputPolyfillEntry | NavigationTimingPolyfillEntry)[];\n\n  // For regular navigations, the type will be the same as the type indicated\n  // by the Navigation Timing API (or `undefined` if the browser doesn't\n  // support that API). For pages that are restored from the bfcache, this\n  // value will be 'back_forward_cache'.\n  navigationType:  NavigationType | 'back_forward_cache' | undefined;\n}\n```\n\n#### `ReportCallback`\n\n```ts\ninterface ReportCallback {\n  (metric: Metric): void;\n}\n```\n\n#### `ReportOpts`\n\n```ts\ninterface ReportOpts {\n  reportAllChanges?: boolean;\n  durationThreshold?: number;\n}\n```\n\n#### `FirstInputPolyfillEntry`\n\nWhen using the FID polyfill (and if the browser doesn't natively support the Event Timing API), `metric.entries` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<PerformanceEventTiming, 'processingEnd' | 'toJSON'>\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nWhen calling `onTTFB()`, if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface, it will polyfill the entry object using timings from `performance.timing`:\n\n```ts\nexport type NavigationTimingPolyfillEntry = Omit<PerformanceNavigationTiming,\n  'initiatorType' | 'nextHopProtocol' | 'redirectCount' | 'transferSize' |\n  'encodedBodySize' | 'decodedBodySize' | 'toJSON'>\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n  firstHiddenTime: number;\n}\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (callback: ReportCallback, opts?: ReportOpts) => void\n```\n\nCalculates the [CLS](https://web.dev/cls/) value for the current page and calls the `callback` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/cls/#layout-shift-score)).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (callback: ReportCallback, opts?: ReportOpts) => void\n```\n\nCalculates the [FCP](https://web.dev/fcp/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n```ts\ntype onFID = (callback: ReportCallback, opts?: ReportOpts) => void\n```\n\nCalculates the [FID](https://web.dev/fid/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value (and optionally the input event if using the [FID polyfill](#fid-polyfill)). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (callback: ReportCallback, opts?: ReportOpts) => void\n```\n\nCalculates the [INP](https://web.dev/responsiveness/) value for the current page and calls the `callback` function once the value is ready, along with the  `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nA custom `durationThreshold` [configuration option](#reportopts) can optionally be passed to control what `event-timing` entries are considered for INP reporting. The default threshold is `40`, which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended [good](https://web.dev/inp/#what-is-a-good-inp-score) threshold).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (callback: ReportCallback, opts?: ReportOpts) => void\n```\n\nCalculates the [LCP](https://web.dev/lcp/) value for the current page and calls the `callback` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (callback: ReportCallback, opts?: ReportOpts) => void\n```\n\nCalculates the [TTFB](https://web.dev/time-to-first-byte/) value for the current page and calls the `callback` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `callback` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it [includes](https://developers.google.com/web/fundamentals/performance/navigation-and-resource-timing#the_life_and_timings_of_a_network_request) time spent on DNS lookup, connection negotiation, network latency, and unloading the previous document. If, in addition to TTFB, you want a metric that excludes these timings and _just_ captures the time spent making the request and receiving the first byte of the response, you could compute that from data found on the performance entry:\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium,\n- `onFCP()`: Chromium, Firefox, Safari\n- `onFID()`: Chromium, Firefox, Safari, Internet Explorer (with the [polyfill](#how-to-use-the-polyfill))\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari, Internet Explorer\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that\nmeasure the Web Vitals metrics, which means the limitations of those APIs will\nmostly apply to this library as well.\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/vitals-ga4/).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `callback` functions and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"f33da096d689a5a8809b58c19e8546cb88a8f78c","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.0.0-beta.2","_nodeVersion":"14.18.0","_npmVersion":"8.1.1","dist":{"integrity":"sha512-W9OALsWK4RkA5GWvLhsfszy+Q29WJBB27Dnucc3eYP6/0kz1XsfMgm+4au9X/KjXMIo92ZRU1fWBaSdNsaVjJg==","shasum":"08c605295f36484256ee3acb5735b1f4dc9cd565","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.0.0-beta.2.tgz","fileCount":75,"unpackedSize":184266,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCj8R4TM/QWEj6W67rJQiTFeQaAe2obGoer1AtwcNbNOwIgREbH3r73BH3MMtbq/uzUNMQnhPG0LWyf/CDBnw2LF4w="}],"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v4.10.10\r\nComment: https://openpgpjs.org\r\n\r\nwsFzBAEBCAAGBQJifFBLACEJED1NWxICdlZqFiEECWMYAoorWMhJKdjhPU1b\r\nEgJ2VmpCnA//dxmUzabkw3wBCBZXAXrSI+DfdBT7IHH1NE4mjkz0ySXFrpDg\r\nt2r+W/WewnurXuykUyW4CAIO6Zhov2crWDNSiBiN6bc/4FpGB15QL6Nu0LZr\r\nWcN0c/bVnFjQzFYOMBS8CbF62helghUb4V7EkR1jB0ozAyA4zQUpY3013Opw\r\na+f0FU8GZFLe802dyVQev8g6Nvg6ymVyUN6Uy8vl+Rl072JppuQM23ahvJu+\r\n6Pfc8kU29YpBb86T7Ya2rqRdma93S58NluLx75bM9Yy1Yqhp8IIsXrSb1gDu\r\ndw57JDmA6+9aReUGAoQSa3wokjq8hiOOVX6ILhecUC9h4zhQwTW7uHfmuBUo\r\nWXGYO2GaRdSr9lHKfowu3vDJmr2IDcS7o2hU0NxNofWIRtL0QkedDtb+iJgI\r\npS8gbFw2EIGP0HRrhVjfsFjlYazYMcBGjdHyoRBHa7eThN32lVRgF0qhLGIa\r\nbeXfa1I1A4fZZMeb5u/Qf0rvB7kAwSbdG4iIwnRITYzim+vAe9NgOBQA0UfS\r\nNoBMDmrrTkrWKYMJ2HWwhb0l3jqNMjnZFInfppbv1gNGw9m6Ew10tVygMX+m\r\n0xnH/MPZgXgf4qroz58Hr9MEhM8nQIDApQ4u9DhMq123nM80pPmZY62fWuq9\r\nZTPDVUyDzCb0oWYu0Dyu7J+icPxrgPwg5dM=\r\n=f+69\r\n-----END PGP SIGNATURE-----\r\n"},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.0.0-beta.2_1652314186814_0.016899512928435945"},"_hasShrinkwrap":false},"3.0.0-rc.0":{"name":"web-vitals","version":"3.0.0-rc.0","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.js","module":"dist/web-vitals.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.js","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.js","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.js","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.js","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.js","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.18.5","@babel/preset-env":"^7.18.2","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.29.0","@typescript-eslint/parser":"^5.29.0","@wdio/cli":"^7.20.5","@wdio/local-runner":"^7.20.5","@wdio/mocha-framework":"^7.20.3","@wdio/selenium-standalone-service":"^7.20.3","@wdio/spec-reporter":"^7.20.3","body-parser":"^1.20.0","chromedriver":"^103.0.0","eslint":"^8.18.0","eslint-config-google":"^0.14.0","express":"^4.18.1","fs-extra":"^10.1.0","husky":"^8.0.1","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","rollup":"^2.75.7","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.7.4","wdio-chromedriver-service":"^7.3.2"},"gitHead":"4ca38ae64b8d1e899028c692f94d4c56acfc996c","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.0.0-rc.0","_nodeVersion":"14.18.0","_npmVersion":"8.1.1","dist":{"integrity":"sha512-GHS5aiK2r9oQ8V0xf4avZU2dzCTP3osAWa/9jBzxzrvHKPu0IxuuntNWpg1E4Ytu8HAj2lZM+7qj+SjsaL2ZHA==","shasum":"7cc659576f1659a5257338efc23960ac8183a633","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.0.0-rc.0.tgz","fileCount":134,"unpackedSize":358682,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIEv3QRXoMehWxqgprVE4FJDniZoai91o3SiZPxudjT0EAiBJwzagRhivXa4vxTzA0RkSi6X9QV+2bkQI4laTE/yxxA=="}],"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v4.10.10\r\nComment: https://openpgpjs.org\r\n\r\nwsFzBAEBCAAGBQJi4JZvACEJED1NWxICdlZqFiEECWMYAoorWMhJKdjhPU1b\r\nEgJ2VmoswA//Uxrtmve3+ctL1HHTSeM1J7vk3Bv4RS84SYjKrjtl0cQmOpsr\r\nEoXgZhwwn09NsekTwVw49W+TbzHdXdReEHlcx7DH++NM0hby3YRwIX6tG0f1\r\nxNcsz+RttXcpf7pbAxIIuRLg1KBLLL1mxDxUFa1a3DAjzwrGKjelMPMwd5uF\r\naJjJ99dTEgQvVeoxrn3f+J6hfS0jQLs0LM48sHZbf0Vf6cP4TYGIxWb+51FR\r\nNPWj26Osh5GuUBCBmRGykHfD7xTKdC3za2/RAjbjtTUFMRUjAP0+Gol1/H3K\r\nJZBwpTQSxBiG/7njwpXVXdS8/fWlz2YlEepyQmNdxlZcSs9ndH706kmHWr+T\r\nyZ7Z/KR3bXjq3rH6LEHuGOPnEmem9VIdOI1dH1W+Rt6McArGr3bNbqPjizHU\r\nEUOsu0j/R9Se+o75tX4/Otv/G4myEgm3oC4hvVYEQVtiilWASrTN9ysNYGZ8\r\naZAFqrVFDu0qQbPK7LL0YbnnN0+1lL35zRXN6dMWbxOOYw2/vH9c02bZu5oQ\r\nAuw7m8W2gRYpV8pK0pVO8O3UXbmCfMXq6vE1S4mHhVipLBjOBbJsX7HSfuVG\r\nCVd6OqzsLPJl4YwJ9h6IELAa+QlAPWAwmdIa3W6PxC96E94KLpABQtX9kY7U\r\nKAeWC90q5x93yCFzPAoBBFyGBUSi9gulHQI=\r\n=/iLa\r\n-----END PGP SIGNATURE-----\r\n"},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.0.0-rc.0_1658885743634_0.8086691450557619"},"_hasShrinkwrap":false},"3.0.0":{"name":"web-vitals","version":"3.0.0","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.js","module":"dist/web-vitals.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.js","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.js","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.js","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.js","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.js","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.18.13","@babel/preset-env":"^7.18.10","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.34.0","@typescript-eslint/parser":"^5.34.0","@wdio/cli":"^7.23.0","@wdio/local-runner":"^7.23.0","@wdio/mocha-framework":"^7.23.0","@wdio/selenium-standalone-service":"^7.23.0","@wdio/spec-reporter":"^7.23.0","body-parser":"^1.20.0","chromedriver":"^104.0.0","eslint":"^8.22.0","eslint-config-google":"^0.14.0","express":"^4.18.1","fs-extra":"^10.1.0","husky":"^8.0.1","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","rollup":"^2.78.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.7.4","wdio-chromedriver-service":"^7.3.2"},"gitHead":"ab67c29403cca356bc0fc385780cc43011f5fb76","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.0.0","_nodeVersion":"16.16.0","_npmVersion":"8.18.0","dist":{"integrity":"sha512-3Gh6rH5aetFYqfkl9V59KCvjj9vp9U2Tkaep9MO+xpAVg+JULmQfi5zEkcPLkE6iU8pNYVwdjHvIU8RFAchYyQ==","shasum":"db8a32fd62738a439343309336720ee5685ac71e","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.0.0.tgz","fileCount":134,"unpackedSize":358479,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCmDNsyRwFBw05ReWlbZcvv8OVkXzs/5g2eWEKEyH2BwQIhAMYlY36nL113GOSEKh7/cK3ACP4/i27IYR1TxA8b1lrZ"}],"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v4.10.10\r\nComment: https://openpgpjs.org\r\n\r\nwsFzBAEBCAAGBQJjBmaqACEJED1NWxICdlZqFiEECWMYAoorWMhJKdjhPU1b\r\nEgJ2VmpjJg/+ONOlESzw0s6CPe8taZUQBEU4YpjVhes2umhVJX6nQSJ2MTuy\r\nLbfTPahVSGYvSrSo/n8E5diH46HEiSPzlMR5UxjATH2eUHh3kz/JC7nYNhUP\r\nyOoEXTiIPRyvMzlH2sYdvPJtj+yBq5XiMdKL/vqoxdNH/ySZP7swbJ5LgZpa\r\nZ8ge+NMVwxxjluga9KZO5cWhzLzM7DjfMhJB99n4CU3Zv2odYBjdji7mWZ/J\r\nsR8OPv/va7cTeEg5FxIJnhusWkJ0JUhBL7KKfFDdGfCEyWXaeo3v9zoQIzdF\r\n+rIlqWMoC6WIyR/C96w/AntL5RDSh3xbz58ScB5yVKo0patfrtEUetcYVBaP\r\nlBGWCUaObvbHtixPoCxj/UHrv/DE1rTItR6VZNvgtU2M8TM4bXfDCu6pm1Gq\r\nKCKwJxqwkmIM0bBRdJifCg3rwLdz/P3PNLs61WmyUph4K+JQ4k9cWn4sc8jH\r\nRD7F6PIBz3qFCakT3YYW7x68rApBdmiwmDMlN/chVRaRqhACb1uQtygfC282\r\n1ZKRqf0xy3dug9ENd+TKoKuf+rJdVatI3TFcxLE+fKXDbm7KTsW6+qmYvTW7\r\neorwOOO6NAeZga4t1lmQaJJ3DrJwYv6b20TbozBKiToXA1nYAbnAzfTF4BCr\r\nf7z63RDLlLzwhup41cY+HIvW3godJKO1VZI=\r\n=Otjz\r\n-----END PGP SIGNATURE-----\r\n"},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.0.0_1661363882597_0.7729234399049021"},"_hasShrinkwrap":false},"3.0.1":{"name":"web-vitals","version":"3.0.1","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.18.13","@babel/preset-env":"^7.18.10","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.34.0","@typescript-eslint/parser":"^5.34.0","@wdio/cli":"^7.23.0","@wdio/local-runner":"^7.23.0","@wdio/mocha-framework":"^7.23.0","@wdio/selenium-standalone-service":"^7.23.0","@wdio/spec-reporter":"^7.23.0","body-parser":"^1.20.0","chromedriver":"^104.0.0","eslint":"^8.22.0","eslint-config-google":"^0.14.0","express":"^4.18.1","fs-extra":"^10.1.0","husky":"^8.0.1","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","rollup":"^2.78.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.7.4","wdio-chromedriver-service":"^7.3.2"},"gitHead":"05cbc53aebe858dcaf6aa38f32d47a05a8bd9435","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.0.1","_nodeVersion":"16.16.0","_npmVersion":"8.18.0","dist":{"integrity":"sha512-n8LgBynM5BU4C8ZMiTWPu6zbv31AfPnuNXEjWClvPWD5g8h2WkcecR0EtAiQaiMcj1iG0LADyHndR+MKYu5Zog==","shasum":"7129668af2d1598ff4a574535a46b1432af337c8","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.0.1.tgz","fileCount":134,"unpackedSize":358489,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQD5vIxOmnXYlzGs/KXnIPmtRGqcuGDl4t8B1q1kY+lm/gIgERFWkW7Mi18MeXnaR6UMOmnlUnlI8ET7VNweRTMY9lk="}],"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v4.10.10\r\nComment: https://openpgpjs.org\r\n\r\nwsFzBAEBCAAGBQJjD8AiACEJED1NWxICdlZqFiEECWMYAoorWMhJKdjhPU1b\r\nEgJ2VmpPAhAAjgs8DIJs2DbFM2wgYYcZG0l6o/OWZ7wL4/y1RwrRPwopIKS5\r\ndCTIXUj9N+elwrPw8Rx+vm17rUT2AE2gOUjPr+pf2Ive5wpaKHa0t2/ZwE+z\r\nPASukRWqwKT2aHVVbcRvnPDud2ibN5QzpLGxdUmaPRlCTLoxv5GCPEXBXlkw\r\nA/QA2sWjP9SH1i+NDSwzlNKMGyNWDTz4ypxk60PbT/qSMkOzN3eGCt/2r02o\r\nc1aXAifeLVByO3VLO7onST7lr2bVlKc98mn26zUu1iQG67+TSUPSHqPRHIUO\r\nYpwQS2DcFrtYPLoU0iSB3EgDLaHls3SLxDtwMamKruzNrSe+07I/xjOEfDZK\r\n+90R9V8u9a50cqwiOuRbXw7ePpNElHR55D6AiwP2a8Bn/oq+Fe71Yy8/b6MZ\r\n1V5wqUBRPkhVkTWgXzmjQ6necoaoSL5x3SFtUH3byk+oHQ2GidlB6RgrlxC6\r\n6gxPIYbthYheACWGS5udai18XqxsuU16l9wsH6u/w7arvCn11ZE58zFF46J5\r\n9CiBwOgWGcao7fKAKTnVfAZSR3XIenilXfndP+Kmero70gjnzMl8qAUHBmNV\r\n488uFokRVN9KdNt1wEMY9rk74PJdTsv7XivjcQX7IJ6+qG4uAImR14M14ZG1\r\nyH7yKw5S6a5A4I9nHrp/lN2BUEt/MoYPOzU=\r\n=QEkA\r\n-----END PGP SIGNATURE-----\r\n"},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.0.1_1661976610405_0.6478934130515797"},"_hasShrinkwrap":false},"3.0.2":{"name":"web-vitals","version":"3.0.2","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.18.13","@babel/preset-env":"^7.18.10","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.34.0","@typescript-eslint/parser":"^5.34.0","@wdio/cli":"^7.23.0","@wdio/local-runner":"^7.23.0","@wdio/mocha-framework":"^7.23.0","@wdio/selenium-standalone-service":"^7.23.0","@wdio/spec-reporter":"^7.23.0","body-parser":"^1.20.0","chromedriver":"^104.0.0","eslint":"^8.22.0","eslint-config-google":"^0.14.0","express":"^4.18.1","fs-extra":"^10.1.0","husky":"^8.0.1","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","rollup":"^2.78.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.7.4","wdio-chromedriver-service":"^7.3.2"},"gitHead":"10b584593060ede911f409e01ef7871fe662d226","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.0.2","_nodeVersion":"16.16.0","_npmVersion":"8.18.0","dist":{"integrity":"sha512-YygzeCdGpNrCHIjW14AI4SxMX2IcONhDvwhHc9KswCIixfSeVl08WdKDfzZaypq2ynRIG3lzGO3CO5dXYzc9+w==","shasum":"a484109dc5d64bc4924f174267ce20e7cd4c7934","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.0.2.tgz","fileCount":134,"unpackedSize":358599,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIA60ARePPycnqs9hf0LP09kHdIBzPcNWviAqZatJtBMIAiEA2lqbnyRSVJMZ8mxhGoOAkyGPpl9fNVKzSdSLowu7X0k="}],"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v4.10.10\r\nComment: https://openpgpjs.org\r\n\r\nwsFzBAEBCAAGBQJjIsQ1ACEJED1NWxICdlZqFiEECWMYAoorWMhJKdjhPU1b\r\nEgJ2VmrVuQ//RuUDrk9LXCVUgUXN3ECZpQTrPE1oxWfJmqupTenUMusx03Ve\r\nHk1jv/2XAV/RmoL9WZ+JJmou8qo2ZKoL785riqw/Ua7p1FthzM8UfnJwcMFo\r\nLnXn+HIFmVow0U9sac5lof2ZIK/7FvC82ndA/jpPgMLN7XSzPAgurYhoXRTv\r\ne0koGpcsusw285Jj7hMppFfNMChuiq7fzEHxqnSNKOGOMw4cbMDmhbdsO+GB\r\nYL0ZMX6JA0UGx6XOktRvDTSdWXd+YVDEVvSIcQo/8jQ9CkxQUd0nfL5aoU9b\r\n/DpceVxFaMbEz1cxRFarbZ0vDVnHhHgPhKkIhWGzxTxxq854JEgCEJriXWhd\r\nXhiS+5rDszjFkCc/glyqXRGuYSCibTdWXutJK3kmODBD4r0NrG+RV0OarZlr\r\nmXlyghjO9qZ/Dsn4Q62Kssr5inUbbSYXT09HtgNa/GqtU6Mzs/jYpEk8PgGF\r\n40pSq/GZ1yXaLBtBDNhu4hbVDgCeP/1qIb/ibg4jt+HcWin/OlF7KR6K0+Ik\r\nCzZaPfh2PXfSAfxeYzQJ0FaeoMi4WZ/xAIlAomrlMgReormsQ2YVvFIut11a\r\n7g4WF8prGHeWZ318h6LMXScLVFmDa2xcTH/oXMs712TZhMetR8GDMs0+zKlR\r\nFwJ8yFFUraIiVhl/Iw16fwIgsQhJJGkYSXI=\r\n=v54K\r\n-----END PGP SIGNATURE-----\r\n"},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.0.2_1663222837341_0.4088454625225346"},"_hasShrinkwrap":false},"3.0.3":{"name":"web-vitals","version":"3.0.3","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.19.3","@babel/preset-env":"^7.19.3","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.38.1","@typescript-eslint/parser":"^5.38.1","@wdio/cli":"^7.25.1","@wdio/local-runner":"^7.25.1","@wdio/mocha-framework":"^7.25.1","@wdio/selenium-standalone-service":"^7.25.1","@wdio/spec-reporter":"^7.25.1","body-parser":"^1.20.0","chromedriver":"^106.0.1","eslint":"^8.24.0","eslint-config-google":"^0.14.0","express":"^4.18.1","fs-extra":"^10.1.0","husky":"^8.0.1","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.8.4","wdio-chromedriver-service":"^8.0.0"},"gitHead":"dfbd06e2fbdf8d8c8c7e252f710d66c5bbad10a0","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.0.3","_nodeVersion":"16.16.0","_npmVersion":"8.18.0","dist":{"integrity":"sha512-8K6cl3alkVhwv7RQm3WAWFzvP9dBTH4CwOE7G3DfQDEnBJTdtNgX5XMqgE7aE79wac/kJ8fHWftUfH3AVxxbBw==","shasum":"e08cf4d30398baf91984f230a87872d6049e173f","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.0.3.tgz","fileCount":134,"unpackedSize":358987,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQD36qoXGiyUDAdQcdEJIDhv+bbqNLUoYqHeE6diKGoshQIgUUXkhOqn5zi/Oh+f+sXkZhM12oCydQiFdE6VUgmmcIg="}],"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v4.10.10\r\nComment: https://openpgpjs.org\r\n\r\nwsFzBAEBCAAGBQJjPHkTACEJED1NWxICdlZqFiEECWMYAoorWMhJKdjhPU1b\r\nEgJ2Vmo3iQ//VT3oX6uliM82C+atVM58Fp0DKJtnW/6qliJtvTfKGUQG8suC\r\ndmwOZ1pczO82tNv0PM7QZMl666mxJifnLIH8ms8l+i/lSyY6rZtMD4peOmih\r\nJnJEqXPraV9VatCl5POtGCxOHsHqwLJQD6XWsvSRNUcyQtlT+3aJjnqBrXDK\r\nxSIuosauW92RidfUN0KvTNl3IbHJYrcYOYJ51oH+bz8+SIcE8bBj5aE9mgTs\r\nGMIRRivD1zT7iQdWqPE8vYss8KCfQyU2qSx6V0iZ174XOzWYck5kWNjnFVz/\r\n7RON0uH7en0wVirhtJNFCsg1XzH0vlWybCDX4fyHbV1Yp7KoEo2QawROKSa8\r\nG1Jz2cYEFS7iWWC1khcpCjpmvHJz7G1D4SRddgEwWdxtt6ch3ImoCDcWZo5C\r\npJ4zAK0Tq3vkKMo5Rhhjt/jz74s8HBF+W+Fx9G967Zi1ZsVBTyYgA825yD4x\r\n3oR8n6tfVgWvW1mMUbxhPPwX/04xChGebGT5pZDsiYbnFy/nwT+AKMpZl5a7\r\nudFA+zSne+dk+Ox4EenOUfaPMirGEUzeacBYfDJDlOzBMBU11PN6HP8rTznc\r\n4b6h4RxDf1WBcQZXkG1yARB9Ve720QWCSnMpzdb/PayC7E/DaFdB8HHWkiP4\r\nw/gv99UghxrHMKai3IIRNJKvb/ea8/a10Ds=\r\n=hFqw\r\n-----END PGP SIGNATURE-----\r\n"},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.0.3_1664907539359_0.25260101218670084"},"_hasShrinkwrap":false},"3.0.4":{"name":"web-vitals","version":"3.0.4","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.19.3","@babel/preset-env":"^7.19.3","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.38.1","@typescript-eslint/parser":"^5.38.1","@wdio/cli":"^7.25.1","@wdio/local-runner":"^7.25.1","@wdio/mocha-framework":"^7.25.1","@wdio/selenium-standalone-service":"^7.25.1","@wdio/spec-reporter":"^7.25.1","body-parser":"^1.20.0","chromedriver":"^106.0.1","eslint":"^8.24.0","eslint-config-google":"^0.14.0","express":"^4.18.1","fs-extra":"^10.1.0","husky":"^8.0.1","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.8.4","wdio-chromedriver-service":"^8.0.0"},"gitHead":"7f0ed0bfb03c356e348a558a3eda111b498a2a11","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.0.4","_nodeVersion":"16.16.0","_npmVersion":"8.18.0","dist":{"integrity":"sha512-Yau8qf1AJ/dm6MY180Bi0qpCIuWmAfKAnOqmxLecGfIHn0+ND3H4JOhXeY73Pyi9zjSF5J4SNUewHLNUzU7mmA==","shasum":"a78ea93e95f7d7961dd151e0a76ac132c5dee2c9","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.0.4.tgz","fileCount":134,"unpackedSize":359714,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQDLtZi88kTyuZv72KzwcZ0w7dJNrT0V+Y4dNvjcHfzVmwIhANU3RPIEWU44SK2wvBBWLk8fIvJ6kHnaR7Q7M/mAU752"}],"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v4.10.10\r\nComment: https://openpgpjs.org\r\n\r\nwsFzBAEBCAAGBQJjT1jnACEJED1NWxICdlZqFiEECWMYAoorWMhJKdjhPU1b\r\nEgJ2VmpY3BAAkzQYdBaQkiWAoxLyIVo8VNmiz6d6B6k5qYG2hM27HjDOji5h\r\n/0LzIlY4D8u3BTiUmBCnwVU3KR++Ns6Dwoh+WnYNNtx9hLxRRQ2wrtyzFzMk\r\nsMRnJSlF5H514JVRLXswGHPEadUNruTYBvuyU9sHXLrJq12MJdwR64CZl5Kl\r\ntrLuDOJ8kcZpxPsE4w4a0QodE23phBSzyajVPvZYxQwpHUQjNbnUJ5K98n3f\r\nvRhjP+/4Vq24HhrscD3tmizk3OASC9Ogekv5XqcuPyrJ6bIX/P9+0jKN5A24\r\nYVVHtFk9d1Smr/WUGek49vxgk9yGwjUvXfP5bzEz4JrsiEDBFj8XVihOwV3W\r\nvmywYpdF5YZlKFpLYK8vm166XdispTj+CfTkeKbYj7wjKdw5d73asojXjSKj\r\nH5o8Ds5evy6jIFQ0NKWhX/xMcMtloXe72lcs8/gjS6o9QxK7qfkm6kx3jcue\r\nqvwzRHS5N6PB0ytKhJQ94yBo3RQLkAPeK7lgWtxE7Unm5kvl9Qg3l/EOpOGR\r\ndHzOSmpF77oy/thWFNjDfvL3gjuuQHjWLvbitk2tqpaoHnqDZPdKw0l1qstU\r\nhSNmfRn7YL1QodiSfZLm5tVzp/HLsyFJuNwaiO4Au3I0ec96hlfiueINNSI5\r\nXg+P9V6FD9wkjV0DkZ2u7YVbiQgiGHpsd+Q=\r\n=6Rin\r\n-----END PGP SIGNATURE-----\r\n"},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.0.4_1666144486809_0.021221418390112712"},"_hasShrinkwrap":false},"3.1.0":{"name":"web-vitals","version":"3.1.0","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"devDependencies":{"@babel/core":"^7.19.3","@babel/preset-env":"^7.19.3","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.38.1","@typescript-eslint/parser":"^5.38.1","@wdio/cli":"^7.25.1","@wdio/local-runner":"^7.25.1","@wdio/mocha-framework":"^7.25.1","@wdio/selenium-standalone-service":"^7.25.1","@wdio/spec-reporter":"^7.25.1","body-parser":"^1.20.0","chromedriver":"^107.0.3","eslint":"^8.24.0","eslint-config-google":"^0.14.0","express":"^4.18.1","fs-extra":"^10.1.0","husky":"^8.0.1","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","typescript":"^4.8.4","wdio-chromedriver-service":"^8.0.0"},"gitHead":"39f178242afbb96dca3d48b216d60e7cd4cfa633","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.1.0","_nodeVersion":"16.16.0","_npmVersion":"8.18.0","dist":{"integrity":"sha512-zCeQ+bOjWjJbXv5ZL0r8Py3XP2doCQMZXNKlBGfUjPAVZWokApdeF/kFlK1peuKlCt8sL9TFkKzyXE9/cmNJQA==","shasum":"a6f5156cb6c7fee562da46078540265ac2cd2d16","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.1.0.tgz","fileCount":140,"unpackedSize":372701,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIAEhSK6TA+dxHWvi3850ou94gkBRHcd+1I34inHi3bIQAiEA76t7bdzKcWhoMnVwTUL9LyeTo/TDeebYW4EgoH85XNA="}],"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v4.10.10\r\nComment: https://openpgpjs.org\r\n\r\nwsFzBAEBCAAGBQJjdDtHACEJED1NWxICdlZqFiEECWMYAoorWMhJKdjhPU1b\r\nEgJ2VmoPfhAAnjqO4gj/1ZLZiX2ScKAw7Wpiq2YUSujLqL9Rzh0hr0gND83Q\r\nZdp+8VMzomZT1UoBH73ueVAtXB49F1nOek1FrGJORlUcUt6Eb7rGN6ZX8Te0\r\n1It/TfRiZcnXvXVcVA8KafLeCycT8mBWP2Gj7x9YFhsiH3mfwOJ1ZE5CSN7t\r\nvw7dF2UAE9Fujn0yWHkWfrHNnzu5Vbv7brE9j8gtLEI5TY5+RcRr6xFCeJ6g\r\nDQiwq8Vy/BwghMUiHUM/bNnDewS5a+WyT/1V3axaMVAPlJSuDikSFmTcdoEf\r\nUguPoIWJDVU+7rkSCAoS1Si+CpzsXs1Hq3VX9uJ9Ii5rK6A7Wtt9k+Ja/C/0\r\nwLIWlRcitcdCsGFWKvZ0I9udROkYykxaBi8vPVyN24mzEW8LWp0u6JHHZyv6\r\nxlp280s4bYYwXhmCY2sMbwMZz4vrdQWg+AqWRr/1HO+xmBHMdsBID9G1Iz6r\r\nGFTIc4smpH016NTNi+2vAseQLYeCVlXPdYjjkI0QJl8agenxAXyFPSBobK2M\r\nXQ/AkSk34dR/ZlBdlO/6ao0Ckoh65Eji4gWz8ReFGzXaKEk+TYmt/rwy/yl6\r\nBdJL3KvX4OeL1Mla/7r1iqfjxYBmo2uK9ar3UwyzXCHTgqOhsxG3juN59OGs\r\nobqgb1hSeKoDekRcs+oMu1n+NAWjSgBvJ0s=\r\n=DlHU\r\n-----END PGP SIGNATURE-----\r\n"},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.1.0_1668561735413_0.5226557087064878"},"_hasShrinkwrap":false},"3.1.1":{"name":"web-vitals","version":"3.1.1","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.19.3","@babel/preset-env":"^7.19.3","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.38.1","@typescript-eslint/parser":"^5.38.1","@wdio/cli":"^7.25.1","@wdio/local-runner":"^7.25.1","@wdio/mocha-framework":"^7.25.1","@wdio/selenium-standalone-service":"^7.26.0","@wdio/spec-reporter":"^7.25.1","body-parser":"^1.20.0","chromedriver":"^107.0.3","eslint":"^8.24.0","express":"^4.18.1","fs-extra":"^10.1.0","husky":"^8.0.1","lint-staged":"^13.0.3","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","prettier":"^2.8.0","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","selenium-standalone":"^8.2.3","typescript":"^4.8.4","wdio-chromedriver-service":"^8.0.0"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"gitHead":"9c095c5d8403e05dd53181cb178183fb3ddcae96","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.1.1","_nodeVersion":"16.15.1","_npmVersion":"8.13.0","dist":{"integrity":"sha512-qvllU+ZeQChqzBhZ1oyXmWsjJ8a2jHYpH8AMaVuf29yscOPZfTQTjQFRX6+eADTdsDE8IanOZ0cetweHMs8/2A==","shasum":"bb124a03df7a135617f495c5bb7dbc30ecf2cce3","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.1.1.tgz","fileCount":143,"unpackedSize":374726,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQC2VH89W7dE62t6Kbt2wNL4mQRGJjmvGvKH1G79qGpuRAIhAIxN/mOuy3gWC63luQalXTqiYJQm0ZA1wL/bijjem1nd"}],"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v4.10.10\r\nComment: https://openpgpjs.org\r\n\r\nwsFzBAEBCAAGBQJjvd+zACEJED1NWxICdlZqFiEECWMYAoorWMhJKdjhPU1b\r\nEgJ2Vmr+WBAAn2u21GKkem5WbE/c/ZEETAJR/g80Y+CFYctZ+X/Egp8E/JrU\r\nhOIuWEVrsilsQ5iJVXS834R9L7XEqqTwU9W2Qc4fRQtXcM+B20BsntVrpeo7\r\n9/ywsvPjqyOhd6DfQpkyOB1Z5k5NOmUVqFnpll/D0TPdoSvYlbb3/tLAcoeJ\r\npX5X/i8R35wmORZbhBw/pSgeKGhi0zAWFSE2uqzOwhgDQu7ufQ61PLpwpZb7\r\nylSkI3pAhxdWfegc3FD8VbpRIviOYS+qmrZiNE65A6cqGeJgzu29lq/x1TvX\r\nL8eiHsFOadCVbHMaLObTI9tktqPqY4H1ElFS99mkOS277U5bF/A8SHE9CQgb\r\n8BQDsF72blp0EjEIutzeAjl8DIOoC/gv4cxDfd2fP2U9gHHtXVdKbyfQI765\r\nUScgYPXsmfKErZc9LKSfoejZ2yQogm96kkeqt+7sq2xk5/fnlSDMdFsZGQiM\r\nijM6Pd4O5xCPxlKl6wt7dPozmBfVhCJd+/Z1dmfh9/wNbQpCki/t1NvxrsPh\r\nXx1/MUU8NN3A3aNdbHbd5CTwqK7CaY3oXVytn08ivokVm0AE37Lx4cVMIgvS\r\nzcFxT7Kv1RJRvll/70xTf3zEgq1mvD4UuFdOUnrfu0Uy+GcIav7Uy1j6ui9I\r\nMZYrLoGpwjNbSXXr8iARr8MpIq6p30NGtuc=\r\n=GfVB\r\n-----END PGP SIGNATURE-----\r\n"},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.1.1_1673387955686_0.2911799261533279"},"_hasShrinkwrap":false},"3.1.1-soft-navs":{"name":"web-vitals","version":"3.1.1-soft-navs","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.19.3","@babel/preset-env":"^7.19.3","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.38.1","@typescript-eslint/parser":"^5.38.1","@wdio/cli":"^7.25.1","@wdio/local-runner":"^7.25.1","@wdio/mocha-framework":"^7.25.1","@wdio/selenium-standalone-service":"^7.26.0","@wdio/spec-reporter":"^7.25.1","body-parser":"^1.20.0","chromedriver":"^107.0.3","eslint":"^8.24.0","express":"^4.18.1","fs-extra":"^10.1.0","husky":"^8.0.1","lint-staged":"^13.0.3","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","prettier":"^2.8.0","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","selenium-standalone":"^8.2.3","typescript":"^4.8.4","wdio-chromedriver-service":"^8.0.0"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Send attribution data](#send-attribution-data)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Build options](#build-options)\n  - [Which build is right for you?](#which-build-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n  - [Attribution](#attribution)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1.5K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/vitals/) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/vitals/#core-web-vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/user-centric-performance-metrics/) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/cls/)\n- [First Input Delay (FID)](https://web.dev/fid/)\n- [Largest Contentful Paint (LCP)](https://web.dev/lcp/)\n\n### Other metrics\n\n- [Interaction to next Paint (INP)](https://web.dev/inp/) _(experimental)_\n- [First Contentful Paint (FCP)](https://web.dev/fcp/)\n- [Time to First Byte (TTFB)](https://web.dev/ttfb/)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\nThe `web-vitals` library uses the `buffered` flag for [PerformanceObserver](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver/observe), allowing it to access performance entries that occurred before the library was loaded.\n\nThis means you do not need to load this library early in order to get accurate performance data. In general, this library should be deferred until after other user-impacting code has loaded.\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are a few different builds of the `web-vitals` library, and how you load the library depends on which build you want to use.\n\nFor details on the difference between the builds, see <a href=\"#which-build-is-right-for-you\">which build is right for you</a>.\n\n**1. The \"standard\" build**\n\nTo load the \"standard\" build, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onFID, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functions were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"attribution-build\"><a>\n\n**2. The \"attribution\" build**\n\nMeasuring the Web Vitals scores for your real users is a great first step toward optimizing the user experience. But if your scores aren't _good_, the next step is to understand why they're not good and work to improve them.\n\nThe \"attribution\" build helps you do that by including additional diagnostic information with each metric to help you identify the root cause of poor performance as well as prioritize the most important things to fix.\n\nThe \"attribution\" build is slightly larger than the \"standard\" build (by about 600 bytes, brotli'd), so while the code size is still small, it's only recommended if you're actually using these features.\n\nTo load the \"attribution\" build, change any `import` statements that reference `web-vitals` to `web-vitals/attribution`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/attribution';\n```\n\nUsage for each of the imported function is identical to the standard build, but when importing from the attribution build, the [`Metric`](#metric) object will contain an additional [`attribution`](#metricwithattribution) property.\n\nSee [Send attribution data](#send-attribution-data) for usage examples, and the [`attribution` reference](#attribution) for details on what values are added for each metric.\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**3. The \"base+polyfill\" build**\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nLoading the \"base+polyfill\" build is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nIt's important that the code is inlined directly into the HTML. _Do not link to an external script file, as that will negatively affect performance:_\n\n```html\n<!-- GOOD -->\n<script>\n  // Inline code from `dist/polyfill.js` here\n</script>\n\n<!-- BAD! DO NOT DO! -->\n<script src=\"/path/to/polyfill.js\"></script>\n```\n\nAlso note that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com):\n\n_**Important!** The [unpkg.com](https://unpkg.com) CDN is shown here for example purposes only. `unpkg.com` is not affiliated with Google, and there are no guarantees that the URLs shown in these examples will continue to work in the future._\n\n**Load the \"standard\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals@3?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src = 'https://unpkg.com/web-vitals@3/dist/web-vitals.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n**Load the \"attribution\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {\n    onCLS,\n    onFID,\n    onLCP,\n  } from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"attribution\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src =\n      'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes a `callback` function that will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" build, but they will work with the \"attribution\" build as well.)_\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developer.chrome.com/docs/devtools/console/reference/#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID is not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS should be reported any time the [page's `visibilityState` changes to hidden](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/bfcache/).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onFID()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want the `callback` function to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each layout shift as it happens) by setting `reportAllChanges` to `true` in the optional, [configuration object](#reportopts) (second parameter).\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended) for measuring these metrics in production.\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, {reportAllChanges: true});\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonFID(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `callback` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Report metrics for soft navigations (experimental)\n\n_**Note:** this is experimental and subject to change._\n\nCurrently Core Web Vitals are only tracked for full page navigations, which can affect how [Single Page Applications](https://web.dev/vitals-spa-faq/) that use so called \"soft navigations\" to update the browser URL and history outside of the normal browser's handling of this. The Chrome team are experimenting with being able to [measure these soft navigations](https://github.com/WICG/soft-navigations) separately and report on Core Web Vitals separately for them.\n\nThis experimental support allows sites to measure how their Core Web Vitals might be measured differently should this happen.\n\nAt present a \"soft navigation\" is defined as happening after the following three things happen:\n\n- A user interaction occurs\n- The URL changes\n- Content is added to the DOM\n- Something is painted to screen.\n\nFor some sites, these heuristics may lead to false positives (that users would not really consider a \"navigation\"), or false negatives (where the user does consider a navigation to have happened despite not missing the above criteria). We welcome feedback at https://github.com/WICG/soft-navigations/issues on the heuristics, at https://crbug.com for bugs in the Chrome implementation, and on [https://github.com/GoogleChrome/web-vitals/pull/308](this pull request) for implementation issues with web-vitals.js.\n\n_**Note:** At this time it is not known if this experiment will be something we want to move forward with. Until such time, this support will likely remain in a separate branch of this project, rather than be included in any production builds. If we decide not to move forward with this, the support of this will likely be removed from this project since this library is intended to mirror the Core Web Vitals as much as possible._\n\nSome important points to note:\n\n- TTFB is reported as 0, and not the time of the first network call (if any) after the soft navigation.\n- FCP and LCP are the first and largest contentful paints after the soft navigation. Prior reported paint times will not be counted for these metrics, even though these elements may remain between soft navigations, and may be the first or largest contentful item.\n- FID is reset to measure the first interaction after the soft navigation.\n- INP is reset to measure only interactions after the the soft navigation.\n- CLS is reset to measure again separate to the first page.\n\n_**Note:** It is not known at this time whether soft navigations will be weighted the same as full navigations. No weighting is included in this library at present and metrics are reported in the same way as full page load metrics._\n\nThe metrics can be reported for Soft Navigations using the `reportSoftNavs: true` reporting option:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(console.log, {reportSoftNavs: true});\nonFID(console.log, {reportSoftNavs: true});\nonLCP(console.log, {reportSoftNavs: true});\n```\n\nNote that this will change the way the first page loads are measured as the metrics for the inital URL will be finalized once the first soft nav occurs. To measure both you need to register two callbacks:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(doTraditionalProcessing);\nonFID(doTraditionalProcessing);\nonLCP(doTraditionalProcessing);\n\nonCLS(doSoftNavProcessing, {reportSoftNavs: true});\nonFID(doSoftNavProcessing, {reportSoftNavs: true});\nonLCP(doSoftNavProcessing, {reportSoftNavs: true});\n```\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n    fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonFID(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique dimension value (in this case, the metric `id`, as shown in the examples below) on every metric instance that you send to Google Analytics, you can create a report yourself using the [Google Analytics Reporting API](https://developers.google.com/analytics/devguides/reporting) and any data visualization library you choose.\n\nAs an example of this, the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) is a free and open-source tool you can use to create visualizations of the Web Vitals data that you've sent to Google Analytics.\n\n[![web-vitals-report](https://user-images.githubusercontent.com/326742/101584324-3f9a0900-3992-11eb-8f2d-182f302fb67b.png)](https://github.com/GoogleChromeLabs/web-vitals-report)\n\nIn order to use the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) (or build your own custom reports using the API) you need to send your data to Google Analytics following one of the examples outlined below:\n\n#### Using `analytics.js`\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `ga()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/analyticsjs\n  ga('send', 'event', {\n    eventCategory: 'Web Vitals',\n    eventAction: name,\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    eventLabel: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    nonInteraction: true,\n    // Use `sendBeacon()` if the browser supports it.\n    transport: 'beacon',\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Universal Analytics)\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/gtagjs\n  gtag('event', name, {\n    event_category: 'Web Vitals',\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    event_label: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    value: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    non_interaction: true,\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Google Analytics 4)\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // metric_rating: 'good' | 'needs-improvement' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n### Send attribution data\n\nWhen using the [attribution build](#attribution-build), you can send additional data to help you debug _why_ the metric values are they way they are.\n\nThis example sends an additional `debug_target` param to Google Analytics, corresponding to the element most associated with each metric.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals/attribution';\n\nfunction sendToGoogleAnalytics({name, delta, value, id, attribution}) {\n  const eventParams = {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n  };\n\n  switch (name) {\n    case 'CLS':\n      eventParams.debug_target = attribution.largestShiftTarget;\n      break;\n    case 'FID':\n      eventParams.debug_target = attribution.eventTarget;\n      break;\n    case 'LCP':\n      eventParams.debug_target = attribution.element;\n      break;\n  }\n\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, eventParams);\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n_**Note:** this example relies on custom [event parameters](https://support.google.com/analytics/answer/11396839) in Google Analytics 4. For Universal Analytics the attribution data should be set using a [custom dimension](https://support.google.com/analytics/answer/2709828) rather than `debug_target` as shown above._\n\nSee [Debug performance in the field](https://web.dev/debug-performance-in-the-field/) for more information and examples.\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonFID(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n<a name=\"bundle-versions\"><a>\n\n## Build options\n\nThe `web-vitals` package includes builds for the \"standard\", \"attribution\", and \"base+polyfill\" ([deprecated](https://github.com/GoogleChrome/web-vitals/issues/238)) builds, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the builds distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any attribution features.</p>\n      This is the \"standard\" build and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.cjs</code></td>\n    <td><code>pgk.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.attribution.js</code></td>\n    <td>--</td>\n    <td>\n      An ES module version of all metric functions that includes <a href=\"#attribution-build\">attribution</a> features.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.iife.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An IIFE version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code>, <code>web-vitals.base.umd.cjs</code>, or <code>web-vitals.base.iife.js</code> (it will not work with any script that doesn't have \"base\" in the filename).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n<a name=\"which-build-is-right-for-you\"><a>\n\n### Which build is right for you?\n\nMost developers will generally want to use \"standard\" build (via either the ES module or UMD version, depending on your bundler/build system), as it's the easiest to use out of the box and integrate into existing tools.\n\nHowever, if you'd lke to collect additional debug information to help you diagnose performance bottlenecks based on real-user issues, use the [\"attribution\" build](#attribution-build).\n\nFor guidance on how to collect and use real-user data to debug performance issues, see [Debug performance in the field](https://web.dev/debug-performance-in-the-field/).\n\n### How the polyfill works\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nThe `polyfill.js` script adds event listeners (to track FID cross-browser), and it records initial page visibility state as well as the timestamp of the first visibility change to hidden (to improve the accuracy of CLS, FCP, LCP, and FID). It also polyfills the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) in browsers that only support the original (now deprecated) [Navigation Timing API](https://www.w3.org/TR/navigation-timing/).\n\nIn order for the polyfill to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" build of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" build, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  /**\n   * The name of the metric (in acronym form).\n   */\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  /**\n   * The current value of the metric.\n   */\n  value: number;\n\n  /**\n   * The rating as to whether the metric value is within the \"good\",\n   * \"needs improvement\", or \"poor\" thresholds of the metric.\n   */\n  rating: 'good' | 'needs-improvement' | 'poor';\n\n  /**\n   * The delta between the current value and the last-reported value.\n   * On the first report, `delta` and `value` will always be the same.\n   */\n  delta: number;\n\n  /**\n   * A unique ID representing this particular metric instance. This ID can\n   * be used by an analytics tool to dedupe multiple values sent for the same\n   * metric instance, or to group multiple deltas together and calculate a\n   * total. It can also be used to differentiate multiple different metric\n   * instances sent from the same page, which can happen if the page is\n   * restored from the back/forward cache (in that case new metrics object\n   * get created).\n   */\n  id: string;\n\n  /**\n   * Any performance entries relevant to the metric value calculation.\n   * The array may also be empty if the metric value was not based on any\n   * entries (e.g. a CLS value of 0 given no layout shifts).\n   */\n  entries: (\n    | PerformanceEntry\n    | LayoutShift\n    | FirstInputPolyfillEntry\n    | NavigationTimingPolyfillEntry\n  )[];\n\n  /**\n   * The type of navigation.\n   *\n   * This will be the value returned by the Navigation Timing API (or\n   * `undefined` if the browser doesn't support that API), with the following\n   * exceptions:\n   * - 'back-forward-cache': for pages that are restored from the bfcache.\n   * - 'prerender': for pages that were prerendered.\n   * - 'restore': for pages that were discarded by the browser and then\n   * restored by the user.\n   */\n  navigationType:\n    | 'navigate'\n    | 'reload'\n    | 'back-forward'\n    | 'back-forward-cache'\n    | 'prerender'\n    | 'restore'\n    | 'soft-navigation';\n\n  /**\n   * The navigatonId the metric happened for. This is particularly relevent for soft navigations where\n   * the metric may be reported for a previous URL.\n   *\n   * The navigationId can be mapped to the URL with the following:\n   *   1 (or empty) - performance.getEntriesByType('navigation')[0]?.name\n   *   > 1 - performance.getEntriesByType('soft-navigation')[navigationId - 2]?.name\n   */\n  navigatonId: number;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetric`](/src/types/cls.ts#:~:text=interface%20CLSMetric)\n- [`FCPMetric`](/src/types/fcp.ts#:~:text=interface%20FCPMetric)\n- [`FIDMetric`](/src/types/fid.ts#:~:text=interface%20FIDMetric)\n- [`INPMetric`](/src/types/inp.ts#:~:text=interface%20INPMetric)\n- [`LCPMetric`](/src/types/lcp.ts#:~:text=interface%20LCPMetric)\n- [`TTFBMetric`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetric)\n\n#### `MetricWithAttribution`\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n```ts\ninterface MetricWithAttribution extends Metric {\n  /**\n   * An object containing potentially-helpful debugging information that\n   * can be sent along with the metric value for the current page visit in\n   * order to help identify issues happening to real-users in the field.\n   */\n  attribution: {[key: string]: unknown};\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetricWithAttribution`](/src/types/cls.ts#:~:text=interface%20CLSMetricWithAttribution)\n- [`FCPMetricWithAttribution`](/src/types/fcp.ts#:~:text=interface%20FCPMetricWithAttribution)\n- [`FIDMetricWithAttribution`](/src/types/fid.ts#:~:text=interface%20FIDMetricWithAttribution)\n- [`INPMetricWithAttribution`](/src/types/inp.ts#:~:text=interface%20INPMetricWithAttribution)\n- [`LCPMetricWithAttribution`](/src/types/lcp.ts#:~:text=interface%20LCPMetricWithAttribution)\n- [`TTFBMetricWithAttribution`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetricWithAttribution)\n\n#### `ReportCallback`\n\n```ts\ninterface ReportCallback {\n  (metric: Metric): void;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSReportCallback`](/src/types/cls.ts#:~:text=interface%20CLSReportCallback)\n- [`FCPReportCallback`](/src/types/fcp.ts#:~:text=interface%20FCPReportCallback)\n- [`FIDReportCallback`](/src/types/fid.ts#:~:text=interface%20FIDReportCallback)\n- [`INPReportCallback`](/src/types/inp.ts#:~:text=interface%20INPReportCallback)\n- [`LCPReportCallback`](/src/types/lcp.ts#:~:text=interface%20LCPReportCallback)\n- [`TTFBReportCallback`](/src/types/ttfb.ts#:~:text=interface%20TTFBReportCallback)\n\n#### `ReportOpts`\n\n```ts\ninterface ReportOpts {\n  reportAllChanges?: boolean;\n  durationThreshold?: number;\n  reportSoftNavs?: boolean;\n}\n```\n\n#### `LoadState`\n\nThe `LoadState` type is used in several of the metric [attribution objects](#attribution).\n\n```ts\n/**\n * The loading state of the document. Note: this value is similar to\n * `document.readyState` but it subdivides the \"interactive\" state into the\n * time before and after the DOMContentLoaded event fires.\n *\n * State descriptions:\n * - `loading`: the initial document response has not yet been fully downloaded\n *   and parsed. This is equivalent to the corresponding `readyState` value.\n * - `dom-interactive`: the document has been fully loaded and parsed, but\n *   scripts may not have yet finished loading and executing.\n * - `dom-content-loaded`: the document is fully loaded and parsed, and all\n *   scripts (except `async` scripts) have loaded and finished executing.\n * - `complete`: the document and all of its sub-resources have finished\n *   loading. This is equivalent to the corresponding `readyState` value.\n */\ntype LoadState =\n  | 'loading'\n  | 'dom-interactive'\n  | 'dom-content-loaded'\n  | 'complete';\n```\n\n#### `FirstInputPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't natively support the Event Timing API), the `metric.entries` reported by `onFID()` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<\n  PerformanceEventTiming,\n  'processingEnd' | 'toJSON'\n>;\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface), the `metric.entries` reported by `onTTFB()` will contain an object that polyfills the `PerformanceNavigationTiming` entry using timings from the legacy `performance.timing` interface:\n\n```ts\ntype NavigationTimingPolyfillEntry = Omit<\n  PerformanceNavigationTiming,\n  | 'initiatorType'\n  | 'nextHopProtocol'\n  | 'redirectCount'\n  | 'transferSize'\n  | 'encodedBodySize'\n  | 'decodedBodySize'\n  | 'type'\n> & {\n  type: PerformanceNavigationTiming['type'];\n};\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n  firstHiddenTime: number;\n}\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (callback: CLSReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [CLS](https://web.dev/cls/) value for the current page and calls the `callback` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/cls/#layout-shift-score)).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (callback: FCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FCP](https://web.dev/fcp/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n```ts\ntype onFID = (callback: FIDReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FID](https://web.dev/fid/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (callback: INPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [INP](https://web.dev/responsiveness/) value for the current page and calls the `callback` function once the value is ready, along with the `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nA custom `durationThreshold` [configuration option](#reportopts) can optionally be passed to control what `event-timing` entries are considered for INP reporting. The default threshold is `40`, which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended [good](https://web.dev/inp/#what-is-a-good-inp-score) threshold).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (callback: LCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [LCP](https://web.dev/lcp/) value for the current page and calls the `callback` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (callback: TTFBReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [TTFB](https://web.dev/time-to-first-byte/) value for the current page and calls the `callback` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `callback` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it includes time spent on DNS lookup, connection negotiation, network latency, and server processing time.\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n### Attribution:\n\nThe following objects contain potentially-helpful debugging information that can be sent along with the metric values for the current page visit in order to help identify issues happening to real-users in the field.\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n#### CLS `attribution`:\n\n```ts\ninterface CLSAttribution {\n  /**\n   * A selector identifying the first element (in document order) that\n   * shifted when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTarget?: string;\n  /**\n   * The time when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTime?: DOMHighResTimeStamp;\n  /**\n   * The layout shift score of the single largest layout shift contributing to\n   * the page's CLS score.\n   */\n  largestShiftValue?: number;\n  /**\n   * The `LayoutShiftEntry` representing the single largest layout shift\n   * contributing to the page's CLS score. (Useful when you need more than just\n   * `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftEntry?: LayoutShift;\n  /**\n   * The first element source (in document order) among the `sources` list\n   * of the `largestShiftEntry` object. (Also useful when you need more than\n   * just `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftSource?: LayoutShiftAttribution;\n  /**\n   * The loading state of the document at the time when the largest layout\n   * shift contribution to the page's CLS score occurred (see `LoadState`\n   * for details).\n   */\n  loadState?: LoadState;\n}\n```\n\n#### FCP `attribution`:\n\n```ts\ninterface FCPAttribution {\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB).\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and the first contentful paint (FCP).\n   */\n  firstByteToFCP: number;\n  /**\n   * The loading state of the document at the time when FCP `occurred (see\n   * `LoadState` for details). Ideally, documents can paint before they finish\n   * loading (e.g. the `loading` or `dom-interactive` phases).\n   */\n  loadState: LoadState;\n  /**\n   * The `PerformancePaintTiming` entry corresponding to FCP.\n   */\n  fcpEntry?: PerformancePaintTiming;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues.\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n#### FID `attribution`:\n\n```ts\ninterface FIDAttribution {\n  /**\n   * A selector identifying the element that the user interacted with. This\n   * element will be the `target` of the `event` dispatched.\n   */\n  eventTarget: string;\n  /**\n   * The time when the user interacted. This time will match the `timeStamp`\n   * value of the `event` dispatched.\n   */\n  eventTime: number;\n  /**\n   * The `type` of the `event` dispatched from the user interaction.\n   */\n  eventType: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to FID (or the\n   * polyfill entry in browsers that don't support Event Timing).\n   */\n  eventEntry: PerformanceEventTiming | FirstInputPolyfillEntry;\n  /**\n   * The loading state of the document at the time when the first interaction\n   * occurred (see `LoadState` for details). If the first interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long input delays.\n   */\n  loadState: LoadState;\n}\n```\n\n#### INP `attribution`:\n\n```ts\ninterface INPAttribution {\n  /**\n   * A selector identifying the element that the user interacted with for\n   * the event corresponding to INP. This element will be the `target` of the\n   * `event` dispatched.\n   */\n  eventTarget?: string;\n  /**\n   * The time when the user interacted for the event corresponding to INP.\n   * This time will match the `timeStamp` value of the `event` dispatched.\n   */\n  eventTime?: number;\n  /**\n   * The `type` of the `event` dispatched corresponding to INP.\n   */\n  eventType?: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to INP.\n   */\n  eventEntry?: PerformanceEventTiming;\n  /**\n   * The loading state of the document at the time when the even corresponding\n   * to INP occurred (see `LoadState` for details). If the interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long delays.\n   */\n  loadState?: LoadState;\n}\n```\n\n#### LCP `attribution`:\n\n```ts\ninterface LCPAttribution {\n  /**\n   * The element corresponding to the largest contentful paint for the page.\n   */\n  element?: string;\n  /**\n   * The URL (if applicable) of the LCP image resource. If the LCP element\n   * is a text node, this value will not be set.\n   */\n  url?: string;\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB). See\n   * [Optimize LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and when the browser starts loading the LCP\n   * resource (if there is one, otherwise 0). See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  resourceLoadDelay: number;\n  /**\n   * The total time it takes to load the LCP resource itself (if there is one,\n   * otherwise 0). See [Optimize LCP](https://web.dev/optimize-lcp/) for\n   * details.\n   */\n  resourceLoadTime: number;\n  /**\n   * The delta between when the LCP resource finishes loading until the LCP\n   * element is fully rendered. See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  elementRenderDelay: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues.\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n  /**\n   * The `resource` entry for the LCP resource (if applicable), which is useful\n   * for diagnosing resource load issues.\n   */\n  lcpResourceEntry?: PerformanceResourceTiming;\n  /**\n   * The `LargestContentfulPaint` entry corresponding to LCP.\n   */\n  lcpEntry?: LargestContentfulPaint;\n}\n```\n\n#### TTFB `attribution`:\n\n```ts\ninterface TTFBAttribution {\n  /**\n   * The total time from when the user initiates loading the page to when the\n   * DNS lookup begins. This includes redirects, service worker startup, and\n   * HTTP cache lookup times.\n   */\n  waitingTime: number;\n  /**\n   * The total time to resolve the DNS for the current request.\n   */\n  dnsTime: number;\n  /**\n   * The total time to create the connection to the requested domain.\n   */\n  connectionTime: number;\n  /**\n   * The time time from when the request was sent until the first byte of the\n   * response was received. This includes network time as well as server\n   * processing time.\n   */\n  requestTime: number;\n  /**\n   * The `PerformanceNavigationTiming` entry used to determine TTFB (or the\n   * polyfill entry in browsers that don't support Navigation Timing).\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium\n- `onFCP()`: Chromium, Firefox, Safari 14.1+\n- `onFID()`: Chromium, Firefox _(with [polyfill](#how-to-use-the-polyfill): Safari, Internet Explorer)_\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari 15+ _(with [polyfill](#how-to-use-the-polyfill): Safari 8+, Internet Explorer)_\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that\nmeasure the Web Vitals metrics, which means the limitations of those APIs will\nmostly apply to this library as well.\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/vitals-ga4/).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `callback` functions and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"7e316eb8f7825b9bdad852ccfd621249801c827f","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.1.1-soft-navs","_nodeVersion":"16.15.1","_npmVersion":"8.13.0","dist":{"integrity":"sha512-JFTcdoEY303HODobllS9QYgVLn8eIhP7YayAv8HM9ha/Xkjwfq18TSnkmR8h5nqU7V/6FkY+zBJwrKZO2X4CCg==","shasum":"25b20358bc8f1dbcc895c2ec1773847feaa901fa","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.1.1-soft-navs.tgz","fileCount":146,"unpackedSize":438671,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCmYV5LLTTLBwsqeYtDDc1T5CpcCQ8w7AU0Vmy48t0luwIgUh/9dcre8mH3v4wWRlw0I1gZ3uduD8YfrcckvjNBf64="}],"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v4.10.10\r\nComment: https://openpgpjs.org\r\n\r\nwsFzBAEBCAAGBQJj0osLACEJED1NWxICdlZqFiEECWMYAoorWMhJKdjhPU1b\r\nEgJ2VmqBlg/+OwhSIT5zMJiwzd26ZQAMt0skRAjpJSCeca0kKeSVwnOZaJFv\r\n3fZIC3d8+1Ctwok8cK4rogCkzKV6KRTZtIpNiOxFiRsIzr0YxSNgvH8LzLpk\r\nRImkSUTGU7Vcw6c9tQEADz94pVH9KhklMWBY57chZHb5bRC5Vbj2Q9dmPTTV\r\niD91xo6BEu3AN6zu2vXkRRe9gtYpSjj8PUYznjUXRPZKyd32CIzEGJOKDy2E\r\nOdfIFt4f5Y6Ui1f3tAQzPeSnFlYpXfKd3FhkIjaExhfjTR4hNKH6kG8cza/m\r\nObRLTtNpGIVyUjXfo7blnwsewT/HSg20aG4XWOAXYZHuP4HgiQvMFXIg4EH5\r\nwfEf0RliLbFjoYC8utHRuQBLlf4Rs6351gRdnDj66Wx4BcK31fob8tNyVXTv\r\nfyluit4s+d10DR42vJ90EEd/gaj5ajupRJsfRvzjVot2VJNb8YwJdtR94PgX\r\nm5/WlBCNAxGTtsN4BYMBUqekihic5+L12qcQOmhYIrVrheEc98R9YPeMI0e7\r\nug4nSuJ42j1MYq5eKLeBh8SCWAZ5S2IEivHVHgyKkFDsSTTUEisJZ5Ezu5WJ\r\neNUMdf0YqX9x3tgM69u3FAw/IueGiCDla8Q2BxvX+RvkoEN+/6MdUc26LzJ5\r\nCubRhLDBO9HNYiUbzLXpM8sqYdnxHfdJXlg=\r\n=iNcO\r\n-----END PGP SIGNATURE-----\r\n"},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.1.1-soft-navs_1674742538884_0.18287239709290604"},"_hasShrinkwrap":false},"3.1.1-soft-navs-1":{"name":"web-vitals","version":"3.1.1-soft-navs-1","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.19.3","@babel/preset-env":"^7.19.3","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.38.1","@typescript-eslint/parser":"^5.38.1","@wdio/cli":"^7.25.1","@wdio/local-runner":"^7.25.1","@wdio/mocha-framework":"^7.25.1","@wdio/selenium-standalone-service":"^7.26.0","@wdio/spec-reporter":"^7.25.1","body-parser":"^1.20.0","chromedriver":"^107.0.3","eslint":"^8.24.0","express":"^4.18.1","fs-extra":"^10.1.0","husky":"^8.0.1","lint-staged":"^13.0.3","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","prettier":"^2.8.0","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","selenium-standalone":"^8.2.3","typescript":"^4.8.4","wdio-chromedriver-service":"^8.0.0"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Send attribution data](#send-attribution-data)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Build options](#build-options)\n  - [Which build is right for you?](#which-build-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n  - [Attribution](#attribution)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1.5K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/vitals/) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/vitals/#core-web-vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/user-centric-performance-metrics/) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/cls/)\n- [First Input Delay (FID)](https://web.dev/fid/)\n- [Largest Contentful Paint (LCP)](https://web.dev/lcp/)\n\n### Other metrics\n\n- [Interaction to next Paint (INP)](https://web.dev/inp/) _(experimental)_\n- [First Contentful Paint (FCP)](https://web.dev/fcp/)\n- [Time to First Byte (TTFB)](https://web.dev/ttfb/)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\nThe `web-vitals` library uses the `buffered` flag for [PerformanceObserver](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver/observe), allowing it to access performance entries that occurred before the library was loaded.\n\nThis means you do not need to load this library early in order to get accurate performance data. In general, this library should be deferred until after other user-impacting code has loaded.\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are a few different builds of the `web-vitals` library, and how you load the library depends on which build you want to use.\n\nFor details on the difference between the builds, see <a href=\"#which-build-is-right-for-you\">which build is right for you</a>.\n\n**1. The \"standard\" build**\n\nTo load the \"standard\" build, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onFID, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functions were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"attribution-build\"><a>\n\n**2. The \"attribution\" build**\n\nMeasuring the Web Vitals scores for your real users is a great first step toward optimizing the user experience. But if your scores aren't _good_, the next step is to understand why they're not good and work to improve them.\n\nThe \"attribution\" build helps you do that by including additional diagnostic information with each metric to help you identify the root cause of poor performance as well as prioritize the most important things to fix.\n\nThe \"attribution\" build is slightly larger than the \"standard\" build (by about 600 bytes, brotli'd), so while the code size is still small, it's only recommended if you're actually using these features.\n\nTo load the \"attribution\" build, change any `import` statements that reference `web-vitals` to `web-vitals/attribution`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/attribution';\n```\n\nUsage for each of the imported function is identical to the standard build, but when importing from the attribution build, the [`Metric`](#metric) object will contain an additional [`attribution`](#metricwithattribution) property.\n\nSee [Send attribution data](#send-attribution-data) for usage examples, and the [`attribution` reference](#attribution) for details on what values are added for each metric.\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**3. The \"base+polyfill\" build**\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nLoading the \"base+polyfill\" build is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nIt's important that the code is inlined directly into the HTML. _Do not link to an external script file, as that will negatively affect performance:_\n\n```html\n<!-- GOOD -->\n<script>\n  // Inline code from `dist/polyfill.js` here\n</script>\n\n<!-- BAD! DO NOT DO! -->\n<script src=\"/path/to/polyfill.js\"></script>\n```\n\nAlso note that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com):\n\n_**Important!** The [unpkg.com](https://unpkg.com) CDN is shown here for example purposes only. `unpkg.com` is not affiliated with Google, and there are no guarantees that the URLs shown in these examples will continue to work in the future._\n\n**Load the \"standard\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals@3?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src = 'https://unpkg.com/web-vitals@3/dist/web-vitals.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n**Load the \"attribution\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {\n    onCLS,\n    onFID,\n    onLCP,\n  } from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"attribution\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src =\n      'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes a `callback` function that will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" build, but they will work with the \"attribution\" build as well.)_\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developer.chrome.com/docs/devtools/console/reference/#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID is not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS should be reported any time the [page's `visibilityState` changes to hidden](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/bfcache/).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onFID()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want the `callback` function to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each layout shift as it happens) by setting `reportAllChanges` to `true` in the optional, [configuration object](#reportopts) (second parameter).\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended) for measuring these metrics in production.\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, {reportAllChanges: true});\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonFID(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `callback` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Report metrics for soft navigations (experimental)\n\n_**Note:** this is experimental and subject to change._\n\nCurrently Core Web Vitals are only tracked for full page navigations, which can affect how [Single Page Applications](https://web.dev/vitals-spa-faq/) that use so called \"soft navigations\" to update the browser URL and history outside of the normal browser's handling of this. The Chrome team are experimenting with being able to [measure these soft navigations](https://github.com/WICG/soft-navigations) separately and report on Core Web Vitals separately for them.\n\nThis experimental support allows sites to measure how their Core Web Vitals might be measured differently should this happen.\n\nAt present a \"soft navigation\" is defined as happening after the following three things happen:\n\n- A user interaction occurs\n- The URL changes\n- Content is added to the DOM\n- Something is painted to screen.\n\nFor some sites, these heuristics may lead to false positives (that users would not really consider a \"navigation\"), or false negatives (where the user does consider a navigation to have happened despite not missing the above criteria). We welcome feedback at https://github.com/WICG/soft-navigations/issues on the heuristics, at https://crbug.com for bugs in the Chrome implementation, and on [https://github.com/GoogleChrome/web-vitals/pull/308](this pull request) for implementation issues with web-vitals.js.\n\n_**Note:** At this time it is not known if this experiment will be something we want to move forward with. Until such time, this support will likely remain in a separate branch of this project, rather than be included in any production builds. If we decide not to move forward with this, the support of this will likely be removed from this project since this library is intended to mirror the Core Web Vitals as much as possible._\n\nSome important points to note:\n\n- TTFB is reported as 0, and not the time of the first network call (if any) after the soft navigation.\n- FCP and LCP are the first and largest contentful paints after the soft navigation. Prior reported paint times will not be counted for these metrics, even though these elements may remain between soft navigations, and may be the first or largest contentful item.\n- FID is reset to measure the first interaction after the soft navigation.\n- INP is reset to measure only interactions after the the soft navigation.\n- CLS is reset to measure again separate to the first page.\n\n_**Note:** It is not known at this time whether soft navigations will be weighted the same as full navigations. No weighting is included in this library at present and metrics are reported in the same way as full page load metrics._\n\nThe metrics can be reported for Soft Navigations using the `reportSoftNavs: true` reporting option:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(console.log, {reportSoftNavs: true});\nonFID(console.log, {reportSoftNavs: true});\nonLCP(console.log, {reportSoftNavs: true});\n```\n\nNote that this will change the way the first page loads are measured as the metrics for the inital URL will be finalized once the first soft nav occurs. To measure both you need to register two callbacks:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(doTraditionalProcessing);\nonFID(doTraditionalProcessing);\nonLCP(doTraditionalProcessing);\n\nonCLS(doSoftNavProcessing, {reportSoftNavs: true});\nonFID(doSoftNavProcessing, {reportSoftNavs: true});\nonLCP(doSoftNavProcessing, {reportSoftNavs: true});\n```\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n    fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonFID(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique dimension value (in this case, the metric `id`, as shown in the examples below) on every metric instance that you send to Google Analytics, you can create a report yourself using the [Google Analytics Reporting API](https://developers.google.com/analytics/devguides/reporting) and any data visualization library you choose.\n\nAs an example of this, the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) is a free and open-source tool you can use to create visualizations of the Web Vitals data that you've sent to Google Analytics.\n\n[![web-vitals-report](https://user-images.githubusercontent.com/326742/101584324-3f9a0900-3992-11eb-8f2d-182f302fb67b.png)](https://github.com/GoogleChromeLabs/web-vitals-report)\n\nIn order to use the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) (or build your own custom reports using the API) you need to send your data to Google Analytics following one of the examples outlined below:\n\n#### Using `analytics.js`\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `ga()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/analyticsjs\n  ga('send', 'event', {\n    eventCategory: 'Web Vitals',\n    eventAction: name,\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    eventLabel: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    nonInteraction: true,\n    // Use `sendBeacon()` if the browser supports it.\n    transport: 'beacon',\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Universal Analytics)\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/gtagjs\n  gtag('event', name, {\n    event_category: 'Web Vitals',\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    event_label: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    value: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    non_interaction: true,\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Google Analytics 4)\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // metric_rating: 'good' | 'needs-improvement' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n### Send attribution data\n\nWhen using the [attribution build](#attribution-build), you can send additional data to help you debug _why_ the metric values are they way they are.\n\nThis example sends an additional `debug_target` param to Google Analytics, corresponding to the element most associated with each metric.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals/attribution';\n\nfunction sendToGoogleAnalytics({name, delta, value, id, attribution}) {\n  const eventParams = {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n  };\n\n  switch (name) {\n    case 'CLS':\n      eventParams.debug_target = attribution.largestShiftTarget;\n      break;\n    case 'FID':\n      eventParams.debug_target = attribution.eventTarget;\n      break;\n    case 'LCP':\n      eventParams.debug_target = attribution.element;\n      break;\n  }\n\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, eventParams);\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n_**Note:** this example relies on custom [event parameters](https://support.google.com/analytics/answer/11396839) in Google Analytics 4. For Universal Analytics the attribution data should be set using a [custom dimension](https://support.google.com/analytics/answer/2709828) rather than `debug_target` as shown above._\n\nSee [Debug performance in the field](https://web.dev/debug-performance-in-the-field/) for more information and examples.\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonFID(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n<a name=\"bundle-versions\"><a>\n\n## Build options\n\nThe `web-vitals` package includes builds for the \"standard\", \"attribution\", and \"base+polyfill\" ([deprecated](https://github.com/GoogleChrome/web-vitals/issues/238)) builds, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the builds distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any attribution features.</p>\n      This is the \"standard\" build and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.cjs</code></td>\n    <td><code>pgk.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.attribution.js</code></td>\n    <td>--</td>\n    <td>\n      An ES module version of all metric functions that includes <a href=\"#attribution-build\">attribution</a> features.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.iife.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An IIFE version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code>, <code>web-vitals.base.umd.cjs</code>, or <code>web-vitals.base.iife.js</code> (it will not work with any script that doesn't have \"base\" in the filename).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n<a name=\"which-build-is-right-for-you\"><a>\n\n### Which build is right for you?\n\nMost developers will generally want to use \"standard\" build (via either the ES module or UMD version, depending on your bundler/build system), as it's the easiest to use out of the box and integrate into existing tools.\n\nHowever, if you'd lke to collect additional debug information to help you diagnose performance bottlenecks based on real-user issues, use the [\"attribution\" build](#attribution-build).\n\nFor guidance on how to collect and use real-user data to debug performance issues, see [Debug performance in the field](https://web.dev/debug-performance-in-the-field/).\n\n### How the polyfill works\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nThe `polyfill.js` script adds event listeners (to track FID cross-browser), and it records initial page visibility state as well as the timestamp of the first visibility change to hidden (to improve the accuracy of CLS, FCP, LCP, and FID). It also polyfills the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) in browsers that only support the original (now deprecated) [Navigation Timing API](https://www.w3.org/TR/navigation-timing/).\n\nIn order for the polyfill to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" build of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" build, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  /**\n   * The name of the metric (in acronym form).\n   */\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  /**\n   * The current value of the metric.\n   */\n  value: number;\n\n  /**\n   * The rating as to whether the metric value is within the \"good\",\n   * \"needs improvement\", or \"poor\" thresholds of the metric.\n   */\n  rating: 'good' | 'needs-improvement' | 'poor';\n\n  /**\n   * The delta between the current value and the last-reported value.\n   * On the first report, `delta` and `value` will always be the same.\n   */\n  delta: number;\n\n  /**\n   * A unique ID representing this particular metric instance. This ID can\n   * be used by an analytics tool to dedupe multiple values sent for the same\n   * metric instance, or to group multiple deltas together and calculate a\n   * total. It can also be used to differentiate multiple different metric\n   * instances sent from the same page, which can happen if the page is\n   * restored from the back/forward cache (in that case new metrics object\n   * get created).\n   */\n  id: string;\n\n  /**\n   * Any performance entries relevant to the metric value calculation.\n   * The array may also be empty if the metric value was not based on any\n   * entries (e.g. a CLS value of 0 given no layout shifts).\n   */\n  entries: (\n    | PerformanceEntry\n    | LayoutShift\n    | FirstInputPolyfillEntry\n    | NavigationTimingPolyfillEntry\n  )[];\n\n  /**\n   * The type of navigation.\n   *\n   * This will be the value returned by the Navigation Timing API (or\n   * `undefined` if the browser doesn't support that API), with the following\n   * exceptions:\n   * - 'back-forward-cache': for pages that are restored from the bfcache.\n   * - 'prerender': for pages that were prerendered.\n   * - 'restore': for pages that were discarded by the browser and then\n   * restored by the user.\n   */\n  navigationType:\n    | 'navigate'\n    | 'reload'\n    | 'back-forward'\n    | 'back-forward-cache'\n    | 'prerender'\n    | 'restore'\n    | 'soft-navigation';\n\n  /**\n   * The navigatonId the metric happened for. This is particularly relevent for soft navigations where\n   * the metric may be reported for a previous URL.\n   *\n   * The navigationId can be mapped to the URL with the following:\n   *   1 (or empty) - performance.getEntriesByType('navigation')[0]?.name\n   *   > 1 - performance.getEntriesByType('soft-navigation')[navigationId - 2]?.name\n   */\n  navigatonId: number;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetric`](/src/types/cls.ts#:~:text=interface%20CLSMetric)\n- [`FCPMetric`](/src/types/fcp.ts#:~:text=interface%20FCPMetric)\n- [`FIDMetric`](/src/types/fid.ts#:~:text=interface%20FIDMetric)\n- [`INPMetric`](/src/types/inp.ts#:~:text=interface%20INPMetric)\n- [`LCPMetric`](/src/types/lcp.ts#:~:text=interface%20LCPMetric)\n- [`TTFBMetric`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetric)\n\n#### `MetricWithAttribution`\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n```ts\ninterface MetricWithAttribution extends Metric {\n  /**\n   * An object containing potentially-helpful debugging information that\n   * can be sent along with the metric value for the current page visit in\n   * order to help identify issues happening to real-users in the field.\n   */\n  attribution: {[key: string]: unknown};\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetricWithAttribution`](/src/types/cls.ts#:~:text=interface%20CLSMetricWithAttribution)\n- [`FCPMetricWithAttribution`](/src/types/fcp.ts#:~:text=interface%20FCPMetricWithAttribution)\n- [`FIDMetricWithAttribution`](/src/types/fid.ts#:~:text=interface%20FIDMetricWithAttribution)\n- [`INPMetricWithAttribution`](/src/types/inp.ts#:~:text=interface%20INPMetricWithAttribution)\n- [`LCPMetricWithAttribution`](/src/types/lcp.ts#:~:text=interface%20LCPMetricWithAttribution)\n- [`TTFBMetricWithAttribution`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetricWithAttribution)\n\n#### `ReportCallback`\n\n```ts\ninterface ReportCallback {\n  (metric: Metric): void;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSReportCallback`](/src/types/cls.ts#:~:text=interface%20CLSReportCallback)\n- [`FCPReportCallback`](/src/types/fcp.ts#:~:text=interface%20FCPReportCallback)\n- [`FIDReportCallback`](/src/types/fid.ts#:~:text=interface%20FIDReportCallback)\n- [`INPReportCallback`](/src/types/inp.ts#:~:text=interface%20INPReportCallback)\n- [`LCPReportCallback`](/src/types/lcp.ts#:~:text=interface%20LCPReportCallback)\n- [`TTFBReportCallback`](/src/types/ttfb.ts#:~:text=interface%20TTFBReportCallback)\n\n#### `ReportOpts`\n\n```ts\ninterface ReportOpts {\n  reportAllChanges?: boolean;\n  durationThreshold?: number;\n  reportSoftNavs?: boolean;\n}\n```\n\n#### `LoadState`\n\nThe `LoadState` type is used in several of the metric [attribution objects](#attribution).\n\n```ts\n/**\n * The loading state of the document. Note: this value is similar to\n * `document.readyState` but it subdivides the \"interactive\" state into the\n * time before and after the DOMContentLoaded event fires.\n *\n * State descriptions:\n * - `loading`: the initial document response has not yet been fully downloaded\n *   and parsed. This is equivalent to the corresponding `readyState` value.\n * - `dom-interactive`: the document has been fully loaded and parsed, but\n *   scripts may not have yet finished loading and executing.\n * - `dom-content-loaded`: the document is fully loaded and parsed, and all\n *   scripts (except `async` scripts) have loaded and finished executing.\n * - `complete`: the document and all of its sub-resources have finished\n *   loading. This is equivalent to the corresponding `readyState` value.\n */\ntype LoadState =\n  | 'loading'\n  | 'dom-interactive'\n  | 'dom-content-loaded'\n  | 'complete';\n```\n\n#### `FirstInputPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't natively support the Event Timing API), the `metric.entries` reported by `onFID()` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<\n  PerformanceEventTiming,\n  'processingEnd' | 'toJSON'\n>;\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface), the `metric.entries` reported by `onTTFB()` will contain an object that polyfills the `PerformanceNavigationTiming` entry using timings from the legacy `performance.timing` interface:\n\n```ts\ntype NavigationTimingPolyfillEntry = Omit<\n  PerformanceNavigationTiming,\n  | 'initiatorType'\n  | 'nextHopProtocol'\n  | 'redirectCount'\n  | 'transferSize'\n  | 'encodedBodySize'\n  | 'decodedBodySize'\n  | 'type'\n> & {\n  type: PerformanceNavigationTiming['type'];\n};\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n  firstHiddenTime: number;\n}\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (callback: CLSReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [CLS](https://web.dev/cls/) value for the current page and calls the `callback` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/cls/#layout-shift-score)).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (callback: FCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FCP](https://web.dev/fcp/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n```ts\ntype onFID = (callback: FIDReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FID](https://web.dev/fid/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (callback: INPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [INP](https://web.dev/responsiveness/) value for the current page and calls the `callback` function once the value is ready, along with the `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nA custom `durationThreshold` [configuration option](#reportopts) can optionally be passed to control what `event-timing` entries are considered for INP reporting. The default threshold is `40`, which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended [good](https://web.dev/inp/#what-is-a-good-inp-score) threshold).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (callback: LCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [LCP](https://web.dev/lcp/) value for the current page and calls the `callback` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (callback: TTFBReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [TTFB](https://web.dev/time-to-first-byte/) value for the current page and calls the `callback` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `callback` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it includes time spent on DNS lookup, connection negotiation, network latency, and server processing time.\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n### Attribution:\n\nThe following objects contain potentially-helpful debugging information that can be sent along with the metric values for the current page visit in order to help identify issues happening to real-users in the field.\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n#### CLS `attribution`:\n\n```ts\ninterface CLSAttribution {\n  /**\n   * A selector identifying the first element (in document order) that\n   * shifted when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTarget?: string;\n  /**\n   * The time when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTime?: DOMHighResTimeStamp;\n  /**\n   * The layout shift score of the single largest layout shift contributing to\n   * the page's CLS score.\n   */\n  largestShiftValue?: number;\n  /**\n   * The `LayoutShiftEntry` representing the single largest layout shift\n   * contributing to the page's CLS score. (Useful when you need more than just\n   * `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftEntry?: LayoutShift;\n  /**\n   * The first element source (in document order) among the `sources` list\n   * of the `largestShiftEntry` object. (Also useful when you need more than\n   * just `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftSource?: LayoutShiftAttribution;\n  /**\n   * The loading state of the document at the time when the largest layout\n   * shift contribution to the page's CLS score occurred (see `LoadState`\n   * for details).\n   */\n  loadState?: LoadState;\n}\n```\n\n#### FCP `attribution`:\n\n```ts\ninterface FCPAttribution {\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB).\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and the first contentful paint (FCP).\n   */\n  firstByteToFCP: number;\n  /**\n   * The loading state of the document at the time when FCP `occurred (see\n   * `LoadState` for details). Ideally, documents can paint before they finish\n   * loading (e.g. the `loading` or `dom-interactive` phases).\n   */\n  loadState: LoadState;\n  /**\n   * The `PerformancePaintTiming` entry corresponding to FCP.\n   */\n  fcpEntry?: PerformancePaintTiming;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues.\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n#### FID `attribution`:\n\n```ts\ninterface FIDAttribution {\n  /**\n   * A selector identifying the element that the user interacted with. This\n   * element will be the `target` of the `event` dispatched.\n   */\n  eventTarget: string;\n  /**\n   * The time when the user interacted. This time will match the `timeStamp`\n   * value of the `event` dispatched.\n   */\n  eventTime: number;\n  /**\n   * The `type` of the `event` dispatched from the user interaction.\n   */\n  eventType: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to FID (or the\n   * polyfill entry in browsers that don't support Event Timing).\n   */\n  eventEntry: PerformanceEventTiming | FirstInputPolyfillEntry;\n  /**\n   * The loading state of the document at the time when the first interaction\n   * occurred (see `LoadState` for details). If the first interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long input delays.\n   */\n  loadState: LoadState;\n}\n```\n\n#### INP `attribution`:\n\n```ts\ninterface INPAttribution {\n  /**\n   * A selector identifying the element that the user interacted with for\n   * the event corresponding to INP. This element will be the `target` of the\n   * `event` dispatched.\n   */\n  eventTarget?: string;\n  /**\n   * The time when the user interacted for the event corresponding to INP.\n   * This time will match the `timeStamp` value of the `event` dispatched.\n   */\n  eventTime?: number;\n  /**\n   * The `type` of the `event` dispatched corresponding to INP.\n   */\n  eventType?: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to INP.\n   */\n  eventEntry?: PerformanceEventTiming;\n  /**\n   * The loading state of the document at the time when the even corresponding\n   * to INP occurred (see `LoadState` for details). If the interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long delays.\n   */\n  loadState?: LoadState;\n}\n```\n\n#### LCP `attribution`:\n\n```ts\ninterface LCPAttribution {\n  /**\n   * The element corresponding to the largest contentful paint for the page.\n   */\n  element?: string;\n  /**\n   * The URL (if applicable) of the LCP image resource. If the LCP element\n   * is a text node, this value will not be set.\n   */\n  url?: string;\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB). See\n   * [Optimize LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and when the browser starts loading the LCP\n   * resource (if there is one, otherwise 0). See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  resourceLoadDelay: number;\n  /**\n   * The total time it takes to load the LCP resource itself (if there is one,\n   * otherwise 0). See [Optimize LCP](https://web.dev/optimize-lcp/) for\n   * details.\n   */\n  resourceLoadTime: number;\n  /**\n   * The delta between when the LCP resource finishes loading until the LCP\n   * element is fully rendered. See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  elementRenderDelay: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues.\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n  /**\n   * The `resource` entry for the LCP resource (if applicable), which is useful\n   * for diagnosing resource load issues.\n   */\n  lcpResourceEntry?: PerformanceResourceTiming;\n  /**\n   * The `LargestContentfulPaint` entry corresponding to LCP.\n   */\n  lcpEntry?: LargestContentfulPaint;\n}\n```\n\n#### TTFB `attribution`:\n\n```ts\ninterface TTFBAttribution {\n  /**\n   * The total time from when the user initiates loading the page to when the\n   * DNS lookup begins. This includes redirects, service worker startup, and\n   * HTTP cache lookup times.\n   */\n  waitingTime: number;\n  /**\n   * The total time to resolve the DNS for the current request.\n   */\n  dnsTime: number;\n  /**\n   * The total time to create the connection to the requested domain.\n   */\n  connectionTime: number;\n  /**\n   * The time time from when the request was sent until the first byte of the\n   * response was received. This includes network time as well as server\n   * processing time.\n   */\n  requestTime: number;\n  /**\n   * The `PerformanceNavigationTiming` entry used to determine TTFB (or the\n   * polyfill entry in browsers that don't support Navigation Timing).\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium\n- `onFCP()`: Chromium, Firefox, Safari 14.1+\n- `onFID()`: Chromium, Firefox _(with [polyfill](#how-to-use-the-polyfill): Safari, Internet Explorer)_\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari 15+ _(with [polyfill](#how-to-use-the-polyfill): Safari 8+, Internet Explorer)_\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that\nmeasure the Web Vitals metrics, which means the limitations of those APIs will\nmostly apply to this library as well.\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/vitals-ga4/).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `callback` functions and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"f013531cbf5ad6cbd984e17a4b3ebe643dc93032","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.1.1-soft-navs-1","_nodeVersion":"16.15.1","_npmVersion":"8.13.0","dist":{"integrity":"sha512-IhnApyLBxVaHcP7QYYPmoiOqrCySF2kQwGf/lyzkZRbiot+hL549cBFM+W6PLTCpqVHTClPoKssiPsf8Uu1b0Q==","shasum":"081154cfd98a284fb2da2750126c65e46f9464d8","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.1.1-soft-navs-1.tgz","fileCount":146,"unpackedSize":426639,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIF7pWBa6THfHmHnN5phPwoC4DgiqQ5XlNV+Mbozcc/8NAiADoExfGmV+iRhOo5n8I3OJBfadGYsGJiNYT5BMw54URg=="}],"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v4.10.10\r\nComment: https://openpgpjs.org\r\n\r\nwsFzBAEBCAAGBQJj5BZnACEJED1NWxICdlZqFiEECWMYAoorWMhJKdjhPU1b\r\nEgJ2VmoSKhAAkUroMGgCOOXHiVnx0FxiGoA5X3Q2MUlFgovzUifqhkwSX7OK\r\nLV91N+kUaHO1MmhAz+6qNRWxPWiFxg540/JpIJBL4rg2ozULsDE5rIxKjmoe\r\nBG+m5yKwpi59gXsxaRyNIipCcCCYhGdcrYQPe+1RSZpd25Get/TvSx/GGup0\r\nnSn8e6bpT3Zuo5HRBfMZzT98/rXoNvkge6g3IShE5z0C0ZyTA9to3o5hldCg\r\nvmQDkPg9oryXclSXGXVZCiqihVFb6XzLMPFNKIQ/GGjGFxNVUdXRGpVJSIGb\r\nUPwO1hyQBarZYEqjwrkEec+tZK9g7tyAhpHH6NEmeGGGdgY9wLBBJIK0+N7U\r\n02ueW3fEuEq+vPOVkL+xcoHQxWSCWiaCEF05PQlqmLnwOYBs3WUWoWaxRXKF\r\n3x4V6+EBl8bDdSlHCh3QT0B++7rgKihMdavWAjeJz/fXHLxXzWg9mb9xLcOt\r\nwXPyfudKXH41dFILnjh8OOwFhf2SY8ZPah0FyePpNElmcGUfqAmpBRSZg3JB\r\nAZsQ9ERH8G5iRHMIrMN3245jbZZO+FSDJUBW6GU00rQFPObsc/ykwVAaEaaa\r\n8rfT0pUuQLZ5SK6CbVjzUr7lrY7F4Fmg4n8CVaG3hSpuH7AmzuZlWKjG9zH8\r\nrZvh1Wc7ZjgPrYDUhXU+xLR9pXE9XfBPc4M=\r\n=RNOe\r\n-----END PGP SIGNATURE-----\r\n"},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.1.1-soft-navs-1_1675892327661_0.09402816186022855"},"_hasShrinkwrap":false},"3.1.1-soft-navs-2":{"name":"web-vitals","version":"3.1.1-soft-navs-2","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.19.3","@babel/preset-env":"^7.19.3","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.38.1","@typescript-eslint/parser":"^5.38.1","@wdio/cli":"^7.25.1","@wdio/local-runner":"^7.25.1","@wdio/mocha-framework":"^7.25.1","@wdio/selenium-standalone-service":"^7.26.0","@wdio/spec-reporter":"^7.25.1","body-parser":"^1.20.0","chromedriver":"^107.0.3","eslint":"^8.24.0","express":"^4.18.1","fs-extra":"^10.1.0","husky":"^8.0.1","lint-staged":"^13.0.3","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","prettier":"^2.8.0","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","selenium-standalone":"^8.2.3","typescript":"^4.8.4","wdio-chromedriver-service":"^8.0.0"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Send attribution data](#send-attribution-data)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Build options](#build-options)\n  - [Which build is right for you?](#which-build-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n  - [Attribution](#attribution)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1.5K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/vitals/) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/vitals/#core-web-vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/user-centric-performance-metrics/) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/cls/)\n- [First Input Delay (FID)](https://web.dev/fid/)\n- [Largest Contentful Paint (LCP)](https://web.dev/lcp/)\n\n### Other metrics\n\n- [Interaction to next Paint (INP)](https://web.dev/inp/) _(experimental)_\n- [First Contentful Paint (FCP)](https://web.dev/fcp/)\n- [Time to First Byte (TTFB)](https://web.dev/ttfb/)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\nThe `web-vitals` library uses the `buffered` flag for [PerformanceObserver](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver/observe), allowing it to access performance entries that occurred before the library was loaded.\n\nThis means you do not need to load this library early in order to get accurate performance data. In general, this library should be deferred until after other user-impacting code has loaded.\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are a few different builds of the `web-vitals` library, and how you load the library depends on which build you want to use.\n\nFor details on the difference between the builds, see <a href=\"#which-build-is-right-for-you\">which build is right for you</a>.\n\n**1. The \"standard\" build**\n\nTo load the \"standard\" build, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onFID, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functions were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"attribution-build\"><a>\n\n**2. The \"attribution\" build**\n\nMeasuring the Web Vitals scores for your real users is a great first step toward optimizing the user experience. But if your scores aren't _good_, the next step is to understand why they're not good and work to improve them.\n\nThe \"attribution\" build helps you do that by including additional diagnostic information with each metric to help you identify the root cause of poor performance as well as prioritize the most important things to fix.\n\nThe \"attribution\" build is slightly larger than the \"standard\" build (by about 600 bytes, brotli'd), so while the code size is still small, it's only recommended if you're actually using these features.\n\nTo load the \"attribution\" build, change any `import` statements that reference `web-vitals` to `web-vitals/attribution`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/attribution';\n```\n\nUsage for each of the imported function is identical to the standard build, but when importing from the attribution build, the [`Metric`](#metric) object will contain an additional [`attribution`](#metricwithattribution) property.\n\nSee [Send attribution data](#send-attribution-data) for usage examples, and the [`attribution` reference](#attribution) for details on what values are added for each metric.\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**3. The \"base+polyfill\" build**\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nLoading the \"base+polyfill\" build is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nIt's important that the code is inlined directly into the HTML. _Do not link to an external script file, as that will negatively affect performance:_\n\n```html\n<!-- GOOD -->\n<script>\n  // Inline code from `dist/polyfill.js` here\n</script>\n\n<!-- BAD! DO NOT DO! -->\n<script src=\"/path/to/polyfill.js\"></script>\n```\n\nAlso note that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com):\n\n_**Important!** The [unpkg.com](https://unpkg.com) CDN is shown here for example purposes only. `unpkg.com` is not affiliated with Google, and there are no guarantees that the URLs shown in these examples will continue to work in the future._\n\n**Load the \"standard\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals@3?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src = 'https://unpkg.com/web-vitals@3/dist/web-vitals.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n**Load the \"attribution\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {\n    onCLS,\n    onFID,\n    onLCP,\n  } from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"attribution\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src =\n      'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes a `callback` function that will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" build, but they will work with the \"attribution\" build as well.)_\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developer.chrome.com/docs/devtools/console/reference/#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID is not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS should be reported any time the [page's `visibilityState` changes to hidden](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/bfcache/).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onFID()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want the `callback` function to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each layout shift as it happens) by setting `reportAllChanges` to `true` in the optional, [configuration object](#reportopts) (second parameter).\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended) for measuring these metrics in production.\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, {reportAllChanges: true});\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonFID(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `callback` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Report metrics for soft navigations (experimental)\n\n_**Note:** this is experimental and subject to change._\n\nCurrently Core Web Vitals are only tracked for full page navigations, which can affect how [Single Page Applications](https://web.dev/vitals-spa-faq/) that use so called \"soft navigations\" to update the browser URL and history outside of the normal browser's handling of this. The Chrome team are experimenting with being able to [measure these soft navigations](https://github.com/WICG/soft-navigations) separately and report on Core Web Vitals separately for them.\n\nThis experimental support allows sites to measure how their Core Web Vitals might be measured differently should this happen.\n\nAt present a \"soft navigation\" is defined as happening after the following three things happen:\n\n- A user interaction occurs\n- The URL changes\n- Content is added to the DOM\n- Something is painted to screen.\n\nFor some sites, these heuristics may lead to false positives (that users would not really consider a \"navigation\"), or false negatives (where the user does consider a navigation to have happened despite not missing the above criteria). We welcome feedback at https://github.com/WICG/soft-navigations/issues on the heuristics, at https://crbug.com for bugs in the Chrome implementation, and on [https://github.com/GoogleChrome/web-vitals/pull/308](this pull request) for implementation issues with web-vitals.js.\n\n_**Note:** At this time it is not known if this experiment will be something we want to move forward with. Until such time, this support will likely remain in a separate branch of this project, rather than be included in any production builds. If we decide not to move forward with this, the support of this will likely be removed from this project since this library is intended to mirror the Core Web Vitals as much as possible._\n\nSome important points to note:\n\n- TTFB is reported as 0, and not the time of the first network call (if any) after the soft navigation.\n- FCP and LCP are the first and largest contentful paints after the soft navigation. Prior reported paint times will not be counted for these metrics, even though these elements may remain between soft navigations, and may be the first or largest contentful item.\n- FID is reset to measure the first interaction after the soft navigation.\n- INP is reset to measure only interactions after the the soft navigation.\n- CLS is reset to measure again separate to the first page.\n\n_**Note:** It is not known at this time whether soft navigations will be weighted the same as full navigations. No weighting is included in this library at present and metrics are reported in the same way as full page load metrics._\n\nThe metrics can be reported for Soft Navigations using the `reportSoftNavs: true` reporting option:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(console.log, {reportSoftNavs: true});\nonFID(console.log, {reportSoftNavs: true});\nonLCP(console.log, {reportSoftNavs: true});\n```\n\nNote that this will change the way the first page loads are measured as the metrics for the inital URL will be finalized once the first soft nav occurs. To measure both you need to register two callbacks:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(doTraditionalProcessing);\nonFID(doTraditionalProcessing);\nonLCP(doTraditionalProcessing);\n\nonCLS(doSoftNavProcessing, {reportSoftNavs: true});\nonFID(doSoftNavProcessing, {reportSoftNavs: true});\nonLCP(doSoftNavProcessing, {reportSoftNavs: true});\n```\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n    fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonFID(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique dimension value (in this case, the metric `id`, as shown in the examples below) on every metric instance that you send to Google Analytics, you can create a report yourself using the [Google Analytics Reporting API](https://developers.google.com/analytics/devguides/reporting) and any data visualization library you choose.\n\nAs an example of this, the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) is a free and open-source tool you can use to create visualizations of the Web Vitals data that you've sent to Google Analytics.\n\n[![web-vitals-report](https://user-images.githubusercontent.com/326742/101584324-3f9a0900-3992-11eb-8f2d-182f302fb67b.png)](https://github.com/GoogleChromeLabs/web-vitals-report)\n\nIn order to use the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) (or build your own custom reports using the API) you need to send your data to Google Analytics following one of the examples outlined below:\n\n#### Using `analytics.js`\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `ga()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/analyticsjs\n  ga('send', 'event', {\n    eventCategory: 'Web Vitals',\n    eventAction: name,\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    eventLabel: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    nonInteraction: true,\n    // Use `sendBeacon()` if the browser supports it.\n    transport: 'beacon',\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Universal Analytics)\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/gtagjs\n  gtag('event', name, {\n    event_category: 'Web Vitals',\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    event_label: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    value: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    non_interaction: true,\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Google Analytics 4)\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // metric_rating: 'good' | 'needs-improvement' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n### Send attribution data\n\nWhen using the [attribution build](#attribution-build), you can send additional data to help you debug _why_ the metric values are they way they are.\n\nThis example sends an additional `debug_target` param to Google Analytics, corresponding to the element most associated with each metric.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals/attribution';\n\nfunction sendToGoogleAnalytics({name, delta, value, id, attribution}) {\n  const eventParams = {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n  };\n\n  switch (name) {\n    case 'CLS':\n      eventParams.debug_target = attribution.largestShiftTarget;\n      break;\n    case 'FID':\n      eventParams.debug_target = attribution.eventTarget;\n      break;\n    case 'LCP':\n      eventParams.debug_target = attribution.element;\n      break;\n  }\n\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, eventParams);\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n_**Note:** this example relies on custom [event parameters](https://support.google.com/analytics/answer/11396839) in Google Analytics 4. For Universal Analytics the attribution data should be set using a [custom dimension](https://support.google.com/analytics/answer/2709828) rather than `debug_target` as shown above._\n\nSee [Debug performance in the field](https://web.dev/debug-performance-in-the-field/) for more information and examples.\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonFID(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n<a name=\"bundle-versions\"><a>\n\n## Build options\n\nThe `web-vitals` package includes builds for the \"standard\", \"attribution\", and \"base+polyfill\" ([deprecated](https://github.com/GoogleChrome/web-vitals/issues/238)) builds, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the builds distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any attribution features.</p>\n      This is the \"standard\" build and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.cjs</code></td>\n    <td><code>pgk.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.attribution.js</code></td>\n    <td>--</td>\n    <td>\n      An ES module version of all metric functions that includes <a href=\"#attribution-build\">attribution</a> features.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.iife.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An IIFE version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code>, <code>web-vitals.base.umd.cjs</code>, or <code>web-vitals.base.iife.js</code> (it will not work with any script that doesn't have \"base\" in the filename).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n<a name=\"which-build-is-right-for-you\"><a>\n\n### Which build is right for you?\n\nMost developers will generally want to use \"standard\" build (via either the ES module or UMD version, depending on your bundler/build system), as it's the easiest to use out of the box and integrate into existing tools.\n\nHowever, if you'd lke to collect additional debug information to help you diagnose performance bottlenecks based on real-user issues, use the [\"attribution\" build](#attribution-build).\n\nFor guidance on how to collect and use real-user data to debug performance issues, see [Debug performance in the field](https://web.dev/debug-performance-in-the-field/).\n\n### How the polyfill works\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nThe `polyfill.js` script adds event listeners (to track FID cross-browser), and it records initial page visibility state as well as the timestamp of the first visibility change to hidden (to improve the accuracy of CLS, FCP, LCP, and FID). It also polyfills the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) in browsers that only support the original (now deprecated) [Navigation Timing API](https://www.w3.org/TR/navigation-timing/).\n\nIn order for the polyfill to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" build of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" build, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  /**\n   * The name of the metric (in acronym form).\n   */\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  /**\n   * The current value of the metric.\n   */\n  value: number;\n\n  /**\n   * The rating as to whether the metric value is within the \"good\",\n   * \"needs improvement\", or \"poor\" thresholds of the metric.\n   */\n  rating: 'good' | 'needs-improvement' | 'poor';\n\n  /**\n   * The delta between the current value and the last-reported value.\n   * On the first report, `delta` and `value` will always be the same.\n   */\n  delta: number;\n\n  /**\n   * A unique ID representing this particular metric instance. This ID can\n   * be used by an analytics tool to dedupe multiple values sent for the same\n   * metric instance, or to group multiple deltas together and calculate a\n   * total. It can also be used to differentiate multiple different metric\n   * instances sent from the same page, which can happen if the page is\n   * restored from the back/forward cache (in that case new metrics object\n   * get created).\n   */\n  id: string;\n\n  /**\n   * Any performance entries relevant to the metric value calculation.\n   * The array may also be empty if the metric value was not based on any\n   * entries (e.g. a CLS value of 0 given no layout shifts).\n   */\n  entries: (\n    | PerformanceEntry\n    | LayoutShift\n    | FirstInputPolyfillEntry\n    | NavigationTimingPolyfillEntry\n  )[];\n\n  /**\n   * The type of navigation.\n   *\n   * This will be the value returned by the Navigation Timing API (or\n   * `undefined` if the browser doesn't support that API), with the following\n   * exceptions:\n   * - 'back-forward-cache': for pages that are restored from the bfcache.\n   * - 'prerender': for pages that were prerendered.\n   * - 'restore': for pages that were discarded by the browser and then\n   * restored by the user.\n   */\n  navigationType:\n    | 'navigate'\n    | 'reload'\n    | 'back-forward'\n    | 'back-forward-cache'\n    | 'prerender'\n    | 'restore'\n    | 'soft-navigation';\n\n  /**\n   * The navigatonId the metric happened for. This is particularly relevent for soft navigations where\n   * the metric may be reported for a previous URL.\n   *\n   * The navigationId can be mapped to the URL with the following:\n   *   1 (or empty) - performance.getEntriesByType('navigation')[0]?.name\n   *   > 1 - performance.getEntriesByType('soft-navigation')[navigationId - 2]?.name\n   */\n  navigatonId: number;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetric`](/src/types/cls.ts#:~:text=interface%20CLSMetric)\n- [`FCPMetric`](/src/types/fcp.ts#:~:text=interface%20FCPMetric)\n- [`FIDMetric`](/src/types/fid.ts#:~:text=interface%20FIDMetric)\n- [`INPMetric`](/src/types/inp.ts#:~:text=interface%20INPMetric)\n- [`LCPMetric`](/src/types/lcp.ts#:~:text=interface%20LCPMetric)\n- [`TTFBMetric`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetric)\n\n#### `MetricWithAttribution`\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n```ts\ninterface MetricWithAttribution extends Metric {\n  /**\n   * An object containing potentially-helpful debugging information that\n   * can be sent along with the metric value for the current page visit in\n   * order to help identify issues happening to real-users in the field.\n   */\n  attribution: {[key: string]: unknown};\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetricWithAttribution`](/src/types/cls.ts#:~:text=interface%20CLSMetricWithAttribution)\n- [`FCPMetricWithAttribution`](/src/types/fcp.ts#:~:text=interface%20FCPMetricWithAttribution)\n- [`FIDMetricWithAttribution`](/src/types/fid.ts#:~:text=interface%20FIDMetricWithAttribution)\n- [`INPMetricWithAttribution`](/src/types/inp.ts#:~:text=interface%20INPMetricWithAttribution)\n- [`LCPMetricWithAttribution`](/src/types/lcp.ts#:~:text=interface%20LCPMetricWithAttribution)\n- [`TTFBMetricWithAttribution`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetricWithAttribution)\n\n#### `ReportCallback`\n\n```ts\ninterface ReportCallback {\n  (metric: Metric): void;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSReportCallback`](/src/types/cls.ts#:~:text=interface%20CLSReportCallback)\n- [`FCPReportCallback`](/src/types/fcp.ts#:~:text=interface%20FCPReportCallback)\n- [`FIDReportCallback`](/src/types/fid.ts#:~:text=interface%20FIDReportCallback)\n- [`INPReportCallback`](/src/types/inp.ts#:~:text=interface%20INPReportCallback)\n- [`LCPReportCallback`](/src/types/lcp.ts#:~:text=interface%20LCPReportCallback)\n- [`TTFBReportCallback`](/src/types/ttfb.ts#:~:text=interface%20TTFBReportCallback)\n\n#### `ReportOpts`\n\n```ts\ninterface ReportOpts {\n  reportAllChanges?: boolean;\n  durationThreshold?: number;\n  reportSoftNavs?: boolean;\n}\n```\n\n#### `LoadState`\n\nThe `LoadState` type is used in several of the metric [attribution objects](#attribution).\n\n```ts\n/**\n * The loading state of the document. Note: this value is similar to\n * `document.readyState` but it subdivides the \"interactive\" state into the\n * time before and after the DOMContentLoaded event fires.\n *\n * State descriptions:\n * - `loading`: the initial document response has not yet been fully downloaded\n *   and parsed. This is equivalent to the corresponding `readyState` value.\n * - `dom-interactive`: the document has been fully loaded and parsed, but\n *   scripts may not have yet finished loading and executing.\n * - `dom-content-loaded`: the document is fully loaded and parsed, and all\n *   scripts (except `async` scripts) have loaded and finished executing.\n * - `complete`: the document and all of its sub-resources have finished\n *   loading. This is equivalent to the corresponding `readyState` value.\n */\ntype LoadState =\n  | 'loading'\n  | 'dom-interactive'\n  | 'dom-content-loaded'\n  | 'complete';\n```\n\n#### `FirstInputPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't natively support the Event Timing API), the `metric.entries` reported by `onFID()` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<\n  PerformanceEventTiming,\n  'processingEnd' | 'toJSON'\n>;\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface), the `metric.entries` reported by `onTTFB()` will contain an object that polyfills the `PerformanceNavigationTiming` entry using timings from the legacy `performance.timing` interface:\n\n```ts\ntype NavigationTimingPolyfillEntry = Omit<\n  PerformanceNavigationTiming,\n  | 'initiatorType'\n  | 'nextHopProtocol'\n  | 'redirectCount'\n  | 'transferSize'\n  | 'encodedBodySize'\n  | 'decodedBodySize'\n  | 'type'\n> & {\n  type: PerformanceNavigationTiming['type'];\n};\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n  firstHiddenTime: number;\n}\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (callback: CLSReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [CLS](https://web.dev/cls/) value for the current page and calls the `callback` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/cls/#layout-shift-score)).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (callback: FCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FCP](https://web.dev/fcp/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n```ts\ntype onFID = (callback: FIDReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FID](https://web.dev/fid/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (callback: INPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [INP](https://web.dev/responsiveness/) value for the current page and calls the `callback` function once the value is ready, along with the `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nA custom `durationThreshold` [configuration option](#reportopts) can optionally be passed to control what `event-timing` entries are considered for INP reporting. The default threshold is `40`, which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended [good](https://web.dev/inp/#what-is-a-good-inp-score) threshold).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (callback: LCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [LCP](https://web.dev/lcp/) value for the current page and calls the `callback` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (callback: TTFBReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [TTFB](https://web.dev/time-to-first-byte/) value for the current page and calls the `callback` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `callback` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it includes time spent on DNS lookup, connection negotiation, network latency, and server processing time.\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n### Attribution:\n\nThe following objects contain potentially-helpful debugging information that can be sent along with the metric values for the current page visit in order to help identify issues happening to real-users in the field.\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n#### CLS `attribution`:\n\n```ts\ninterface CLSAttribution {\n  /**\n   * A selector identifying the first element (in document order) that\n   * shifted when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTarget?: string;\n  /**\n   * The time when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTime?: DOMHighResTimeStamp;\n  /**\n   * The layout shift score of the single largest layout shift contributing to\n   * the page's CLS score.\n   */\n  largestShiftValue?: number;\n  /**\n   * The `LayoutShiftEntry` representing the single largest layout shift\n   * contributing to the page's CLS score. (Useful when you need more than just\n   * `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftEntry?: LayoutShift;\n  /**\n   * The first element source (in document order) among the `sources` list\n   * of the `largestShiftEntry` object. (Also useful when you need more than\n   * just `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftSource?: LayoutShiftAttribution;\n  /**\n   * The loading state of the document at the time when the largest layout\n   * shift contribution to the page's CLS score occurred (see `LoadState`\n   * for details).\n   */\n  loadState?: LoadState;\n}\n```\n\n#### FCP `attribution`:\n\n```ts\ninterface FCPAttribution {\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB).\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and the first contentful paint (FCP).\n   */\n  firstByteToFCP: number;\n  /**\n   * The loading state of the document at the time when FCP `occurred (see\n   * `LoadState` for details). Ideally, documents can paint before they finish\n   * loading (e.g. the `loading` or `dom-interactive` phases).\n   */\n  loadState: LoadState;\n  /**\n   * The `PerformancePaintTiming` entry corresponding to FCP.\n   */\n  fcpEntry?: PerformancePaintTiming;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues.\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n#### FID `attribution`:\n\n```ts\ninterface FIDAttribution {\n  /**\n   * A selector identifying the element that the user interacted with. This\n   * element will be the `target` of the `event` dispatched.\n   */\n  eventTarget: string;\n  /**\n   * The time when the user interacted. This time will match the `timeStamp`\n   * value of the `event` dispatched.\n   */\n  eventTime: number;\n  /**\n   * The `type` of the `event` dispatched from the user interaction.\n   */\n  eventType: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to FID (or the\n   * polyfill entry in browsers that don't support Event Timing).\n   */\n  eventEntry: PerformanceEventTiming | FirstInputPolyfillEntry;\n  /**\n   * The loading state of the document at the time when the first interaction\n   * occurred (see `LoadState` for details). If the first interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long input delays.\n   */\n  loadState: LoadState;\n}\n```\n\n#### INP `attribution`:\n\n```ts\ninterface INPAttribution {\n  /**\n   * A selector identifying the element that the user interacted with for\n   * the event corresponding to INP. This element will be the `target` of the\n   * `event` dispatched.\n   */\n  eventTarget?: string;\n  /**\n   * The time when the user interacted for the event corresponding to INP.\n   * This time will match the `timeStamp` value of the `event` dispatched.\n   */\n  eventTime?: number;\n  /**\n   * The `type` of the `event` dispatched corresponding to INP.\n   */\n  eventType?: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to INP.\n   */\n  eventEntry?: PerformanceEventTiming;\n  /**\n   * The loading state of the document at the time when the even corresponding\n   * to INP occurred (see `LoadState` for details). If the interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long delays.\n   */\n  loadState?: LoadState;\n}\n```\n\n#### LCP `attribution`:\n\n```ts\ninterface LCPAttribution {\n  /**\n   * The element corresponding to the largest contentful paint for the page.\n   */\n  element?: string;\n  /**\n   * The URL (if applicable) of the LCP image resource. If the LCP element\n   * is a text node, this value will not be set.\n   */\n  url?: string;\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB). See\n   * [Optimize LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and when the browser starts loading the LCP\n   * resource (if there is one, otherwise 0). See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  resourceLoadDelay: number;\n  /**\n   * The total time it takes to load the LCP resource itself (if there is one,\n   * otherwise 0). See [Optimize LCP](https://web.dev/optimize-lcp/) for\n   * details.\n   */\n  resourceLoadTime: number;\n  /**\n   * The delta between when the LCP resource finishes loading until the LCP\n   * element is fully rendered. See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  elementRenderDelay: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues.\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n  /**\n   * The `resource` entry for the LCP resource (if applicable), which is useful\n   * for diagnosing resource load issues.\n   */\n  lcpResourceEntry?: PerformanceResourceTiming;\n  /**\n   * The `LargestContentfulPaint` entry corresponding to LCP.\n   */\n  lcpEntry?: LargestContentfulPaint;\n}\n```\n\n#### TTFB `attribution`:\n\n```ts\ninterface TTFBAttribution {\n  /**\n   * The total time from when the user initiates loading the page to when the\n   * DNS lookup begins. This includes redirects, service worker startup, and\n   * HTTP cache lookup times.\n   */\n  waitingTime: number;\n  /**\n   * The total time to resolve the DNS for the current request.\n   */\n  dnsTime: number;\n  /**\n   * The total time to create the connection to the requested domain.\n   */\n  connectionTime: number;\n  /**\n   * The time time from when the request was sent until the first byte of the\n   * response was received. This includes network time as well as server\n   * processing time.\n   */\n  requestTime: number;\n  /**\n   * The `PerformanceNavigationTiming` entry used to determine TTFB (or the\n   * polyfill entry in browsers that don't support Navigation Timing).\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium\n- `onFCP()`: Chromium, Firefox, Safari 14.1+\n- `onFID()`: Chromium, Firefox _(with [polyfill](#how-to-use-the-polyfill): Safari, Internet Explorer)_\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari 15+ _(with [polyfill](#how-to-use-the-polyfill): Safari 8+, Internet Explorer)_\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that\nmeasure the Web Vitals metrics, which means the limitations of those APIs will\nmostly apply to this library as well.\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/vitals-ga4/).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `callback` functions and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"2e63c8100904fe0f97cfe0d5ad271283c259ed33","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.1.1-soft-navs-2","_nodeVersion":"16.15.1","_npmVersion":"8.13.0","dist":{"integrity":"sha512-TuGFSEk2aIxcNylhf3fwCKXfoA1jzjtkASMbE6pLZd9kDmdpHwS8+eVlL/+GTrUQzv1eEiBgskCUUBLChtQm8A==","shasum":"4bbb89d911393361b3abde1622a4362fd2c6b3ea","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.1.1-soft-navs-2.tgz","fileCount":146,"unpackedSize":426642,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCICLI1FcFIw2GooRG+UbYp21e8VmKxdAEK4rYD4ydYCcvAiBiyOTyOPWQLvQ16FNu4vGGX7NNaQ6vmQ5FT/WvC9X96A=="}],"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v4.10.10\r\nComment: https://openpgpjs.org\r\n\r\nwsFzBAEBCAAGBQJj5MgCACEJED1NWxICdlZqFiEECWMYAoorWMhJKdjhPU1b\r\nEgJ2Vmreag//ZRi0KLlgC/epVmrHRUOsHSGTZVunEl31HV5x6VQPsgv6SO8Z\r\n2rFmqw87y8TBkAuGcjQgfvEjj6Q4nfrwBACSbpsbEz0htwOS5L8S7amazI5p\r\naFn8oqiSnGMS8pDwUJKo69ArycctMOMQCuL/AKK4fvitui9MtVjsh9ZfcO/0\r\nMBtYhg7q/o2ruGTYsl4fMJ5nVWKnxCMk+/ErbvXOG45PC3s9Dz/SFVarbY3w\r\n5XAhUHQgQJ6N+BaKdCYN+JE/lzWS9JtnuBttrnukuS2ZDy15Ml6JfcIJb1en\r\nc25YsJXSjjYh3sGjaH28WggHm3hbqsVM0Q+Hk9ZiAYAxf8hZGPWKR5Mnpbqz\r\nayHWOxb4RVLpva/VNdJR/HcrtvJarTDlbluTZQ6ZmLLdVi/to3x9MamKCG0w\r\ncHsLTdCiQT5J3ABj4rNVRVjWkmVTL9UBrrW+DB7LGCACfenRqNid84Oc+fsp\r\nNkhziSPy8J0zrf3HGdPTYCxkIW0m0x/3MwYIGQ62VgF7Bv9Ndz/GRm6OjaWp\r\nwmAacZH+NxmerxqvfaNgVJ1mSz+4wwsjANL3J4UVz5GCALybdK7ncvz5EawZ\r\nCDv0UsdISDDzH8zwPhlcuxQFfGiJyu5OKN8BlEJL3QZbjX4O5cgubdTsUTAo\r\nL3fjYbYpisPlzMBCcuSHAi37pp10tDl7kRg=\r\n=Y97h\r\n-----END PGP SIGNATURE-----\r\n"},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.1.1-soft-navs-2_1675937794259_0.3446864288335898"},"_hasShrinkwrap":false},"3.1.1-soft-navs-3":{"name":"web-vitals","version":"3.1.1-soft-navs-3","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.19.3","@babel/preset-env":"^7.19.3","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.38.1","@typescript-eslint/parser":"^5.38.1","@wdio/cli":"^7.25.1","@wdio/local-runner":"^7.25.1","@wdio/mocha-framework":"^7.25.1","@wdio/selenium-standalone-service":"^7.26.0","@wdio/spec-reporter":"^7.25.1","body-parser":"^1.20.0","chromedriver":"^107.0.3","eslint":"^8.24.0","express":"^4.18.1","fs-extra":"^10.1.0","husky":"^8.0.1","lint-staged":"^13.0.3","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","prettier":"^2.8.0","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","selenium-standalone":"^8.2.3","typescript":"^4.8.4","wdio-chromedriver-service":"^8.0.0"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Send attribution data](#send-attribution-data)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Build options](#build-options)\n  - [Which build is right for you?](#which-build-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n  - [Attribution](#attribution)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1.5K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/vitals/) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/vitals/#core-web-vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/user-centric-performance-metrics/) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/cls/)\n- [First Input Delay (FID)](https://web.dev/fid/)\n- [Largest Contentful Paint (LCP)](https://web.dev/lcp/)\n\n### Other metrics\n\n- [Interaction to next Paint (INP)](https://web.dev/inp/) _(experimental)_\n- [First Contentful Paint (FCP)](https://web.dev/fcp/)\n- [Time to First Byte (TTFB)](https://web.dev/ttfb/)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\nThe `web-vitals` library uses the `buffered` flag for [PerformanceObserver](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver/observe), allowing it to access performance entries that occurred before the library was loaded.\n\nThis means you do not need to load this library early in order to get accurate performance data. In general, this library should be deferred until after other user-impacting code has loaded.\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are a few different builds of the `web-vitals` library, and how you load the library depends on which build you want to use.\n\nFor details on the difference between the builds, see <a href=\"#which-build-is-right-for-you\">which build is right for you</a>.\n\n**1. The \"standard\" build**\n\nTo load the \"standard\" build, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onFID, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functions were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"attribution-build\"><a>\n\n**2. The \"attribution\" build**\n\nMeasuring the Web Vitals scores for your real users is a great first step toward optimizing the user experience. But if your scores aren't _good_, the next step is to understand why they're not good and work to improve them.\n\nThe \"attribution\" build helps you do that by including additional diagnostic information with each metric to help you identify the root cause of poor performance as well as prioritize the most important things to fix.\n\nThe \"attribution\" build is slightly larger than the \"standard\" build (by about 600 bytes, brotli'd), so while the code size is still small, it's only recommended if you're actually using these features.\n\nTo load the \"attribution\" build, change any `import` statements that reference `web-vitals` to `web-vitals/attribution`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/attribution';\n```\n\nUsage for each of the imported function is identical to the standard build, but when importing from the attribution build, the [`Metric`](#metric) object will contain an additional [`attribution`](#metricwithattribution) property.\n\nSee [Send attribution data](#send-attribution-data) for usage examples, and the [`attribution` reference](#attribution) for details on what values are added for each metric.\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**3. The \"base+polyfill\" build**\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nLoading the \"base+polyfill\" build is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nIt's important that the code is inlined directly into the HTML. _Do not link to an external script file, as that will negatively affect performance:_\n\n```html\n<!-- GOOD -->\n<script>\n  // Inline code from `dist/polyfill.js` here\n</script>\n\n<!-- BAD! DO NOT DO! -->\n<script src=\"/path/to/polyfill.js\"></script>\n```\n\nAlso note that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com):\n\n_**Important!** The [unpkg.com](https://unpkg.com) CDN is shown here for example purposes only. `unpkg.com` is not affiliated with Google, and there are no guarantees that the URLs shown in these examples will continue to work in the future._\n\n**Load the \"standard\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals@3?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src = 'https://unpkg.com/web-vitals@3/dist/web-vitals.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n**Load the \"attribution\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {\n    onCLS,\n    onFID,\n    onLCP,\n  } from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"attribution\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src =\n      'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes a `callback` function that will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" build, but they will work with the \"attribution\" build as well.)_\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developer.chrome.com/docs/devtools/console/reference/#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID is not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS should be reported any time the [page's `visibilityState` changes to hidden](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/bfcache/).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onFID()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want the `callback` function to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each layout shift as it happens) by setting `reportAllChanges` to `true` in the optional, [configuration object](#reportopts) (second parameter).\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended) for measuring these metrics in production.\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, {reportAllChanges: true});\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonFID(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `callback` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Report metrics for soft navigations (experimental)\n\n_**Note:** this is experimental and subject to change._\n\nCurrently Core Web Vitals are only tracked for full page navigations, which can affect how [Single Page Applications](https://web.dev/vitals-spa-faq/) that use so called \"soft navigations\" to update the browser URL and history outside of the normal browser's handling of this. The Chrome team are experimenting with being able to [measure these soft navigations](https://github.com/WICG/soft-navigations) separately and report on Core Web Vitals separately for them.\n\nThis experimental support allows sites to measure how their Core Web Vitals might be measured differently should this happen.\n\nAt present a \"soft navigation\" is defined as happening after the following three things happen:\n\n- A user interaction occurs\n- The URL changes\n- Content is added to the DOM\n- Something is painted to screen.\n\nFor some sites, these heuristics may lead to false positives (that users would not really consider a \"navigation\"), or false negatives (where the user does consider a navigation to have happened despite not missing the above criteria). We welcome feedback at https://github.com/WICG/soft-navigations/issues on the heuristics, at https://crbug.com for bugs in the Chrome implementation, and on [https://github.com/GoogleChrome/web-vitals/pull/308](this pull request) for implementation issues with web-vitals.js.\n\n_**Note:** At this time it is not known if this experiment will be something we want to move forward with. Until such time, this support will likely remain in a separate branch of this project, rather than be included in any production builds. If we decide not to move forward with this, the support of this will likely be removed from this project since this library is intended to mirror the Core Web Vitals as much as possible._\n\nSome important points to note:\n\n- TTFB is reported as 0, and not the time of the first network call (if any) after the soft navigation.\n- FCP and LCP are the first and largest contentful paints after the soft navigation. Prior reported paint times will not be counted for these metrics, even though these elements may remain between soft navigations, and may be the first or largest contentful item.\n- FID is reset to measure the first interaction after the soft navigation.\n- INP is reset to measure only interactions after the the soft navigation.\n- CLS is reset to measure again separate to the first page.\n\n_**Note:** It is not known at this time whether soft navigations will be weighted the same as full navigations. No weighting is included in this library at present and metrics are reported in the same way as full page load metrics._\n\nThe metrics can be reported for Soft Navigations using the `reportSoftNavs: true` reporting option:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(console.log, {reportSoftNavs: true});\nonFID(console.log, {reportSoftNavs: true});\nonLCP(console.log, {reportSoftNavs: true});\n```\n\nNote that this will change the way the first page loads are measured as the metrics for the inital URL will be finalized once the first soft nav occurs. To measure both you need to register two callbacks:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(doTraditionalProcessing);\nonFID(doTraditionalProcessing);\nonLCP(doTraditionalProcessing);\n\nonCLS(doSoftNavProcessing, {reportSoftNavs: true});\nonFID(doSoftNavProcessing, {reportSoftNavs: true});\nonLCP(doSoftNavProcessing, {reportSoftNavs: true});\n```\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n    fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonFID(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique dimension value (in this case, the metric `id`, as shown in the examples below) on every metric instance that you send to Google Analytics, you can create a report yourself using the [Google Analytics Reporting API](https://developers.google.com/analytics/devguides/reporting) and any data visualization library you choose.\n\nAs an example of this, the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) is a free and open-source tool you can use to create visualizations of the Web Vitals data that you've sent to Google Analytics.\n\n[![web-vitals-report](https://user-images.githubusercontent.com/326742/101584324-3f9a0900-3992-11eb-8f2d-182f302fb67b.png)](https://github.com/GoogleChromeLabs/web-vitals-report)\n\nIn order to use the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) (or build your own custom reports using the API) you need to send your data to Google Analytics following one of the examples outlined below:\n\n#### Using `analytics.js`\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `ga()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/analyticsjs\n  ga('send', 'event', {\n    eventCategory: 'Web Vitals',\n    eventAction: name,\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    eventLabel: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    nonInteraction: true,\n    // Use `sendBeacon()` if the browser supports it.\n    transport: 'beacon',\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Universal Analytics)\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/gtagjs\n  gtag('event', name, {\n    event_category: 'Web Vitals',\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    event_label: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    value: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    non_interaction: true,\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Google Analytics 4)\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // metric_rating: 'good' | 'needs-improvement' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n### Send attribution data\n\nWhen using the [attribution build](#attribution-build), you can send additional data to help you debug _why_ the metric values are they way they are.\n\nThis example sends an additional `debug_target` param to Google Analytics, corresponding to the element most associated with each metric.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals/attribution';\n\nfunction sendToGoogleAnalytics({name, delta, value, id, attribution}) {\n  const eventParams = {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n  };\n\n  switch (name) {\n    case 'CLS':\n      eventParams.debug_target = attribution.largestShiftTarget;\n      break;\n    case 'FID':\n      eventParams.debug_target = attribution.eventTarget;\n      break;\n    case 'LCP':\n      eventParams.debug_target = attribution.element;\n      break;\n  }\n\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, eventParams);\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n_**Note:** this example relies on custom [event parameters](https://support.google.com/analytics/answer/11396839) in Google Analytics 4. For Universal Analytics the attribution data should be set using a [custom dimension](https://support.google.com/analytics/answer/2709828) rather than `debug_target` as shown above._\n\nSee [Debug performance in the field](https://web.dev/debug-performance-in-the-field/) for more information and examples.\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonFID(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n<a name=\"bundle-versions\"><a>\n\n## Build options\n\nThe `web-vitals` package includes builds for the \"standard\", \"attribution\", and \"base+polyfill\" ([deprecated](https://github.com/GoogleChrome/web-vitals/issues/238)) builds, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the builds distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any attribution features.</p>\n      This is the \"standard\" build and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.cjs</code></td>\n    <td><code>pgk.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.attribution.js</code></td>\n    <td>--</td>\n    <td>\n      An ES module version of all metric functions that includes <a href=\"#attribution-build\">attribution</a> features.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.iife.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An IIFE version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code>, <code>web-vitals.base.umd.cjs</code>, or <code>web-vitals.base.iife.js</code> (it will not work with any script that doesn't have \"base\" in the filename).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n<a name=\"which-build-is-right-for-you\"><a>\n\n### Which build is right for you?\n\nMost developers will generally want to use \"standard\" build (via either the ES module or UMD version, depending on your bundler/build system), as it's the easiest to use out of the box and integrate into existing tools.\n\nHowever, if you'd lke to collect additional debug information to help you diagnose performance bottlenecks based on real-user issues, use the [\"attribution\" build](#attribution-build).\n\nFor guidance on how to collect and use real-user data to debug performance issues, see [Debug performance in the field](https://web.dev/debug-performance-in-the-field/).\n\n### How the polyfill works\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nThe `polyfill.js` script adds event listeners (to track FID cross-browser), and it records initial page visibility state as well as the timestamp of the first visibility change to hidden (to improve the accuracy of CLS, FCP, LCP, and FID). It also polyfills the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) in browsers that only support the original (now deprecated) [Navigation Timing API](https://www.w3.org/TR/navigation-timing/).\n\nIn order for the polyfill to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" build of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" build, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  /**\n   * The name of the metric (in acronym form).\n   */\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  /**\n   * The current value of the metric.\n   */\n  value: number;\n\n  /**\n   * The rating as to whether the metric value is within the \"good\",\n   * \"needs improvement\", or \"poor\" thresholds of the metric.\n   */\n  rating: 'good' | 'needs-improvement' | 'poor';\n\n  /**\n   * The delta between the current value and the last-reported value.\n   * On the first report, `delta` and `value` will always be the same.\n   */\n  delta: number;\n\n  /**\n   * A unique ID representing this particular metric instance. This ID can\n   * be used by an analytics tool to dedupe multiple values sent for the same\n   * metric instance, or to group multiple deltas together and calculate a\n   * total. It can also be used to differentiate multiple different metric\n   * instances sent from the same page, which can happen if the page is\n   * restored from the back/forward cache (in that case new metrics object\n   * get created).\n   */\n  id: string;\n\n  /**\n   * Any performance entries relevant to the metric value calculation.\n   * The array may also be empty if the metric value was not based on any\n   * entries (e.g. a CLS value of 0 given no layout shifts).\n   */\n  entries: (\n    | PerformanceEntry\n    | LayoutShift\n    | FirstInputPolyfillEntry\n    | NavigationTimingPolyfillEntry\n  )[];\n\n  /**\n   * The type of navigation.\n   *\n   * This will be the value returned by the Navigation Timing API (or\n   * `undefined` if the browser doesn't support that API), with the following\n   * exceptions:\n   * - 'back-forward-cache': for pages that are restored from the bfcache.\n   * - 'prerender': for pages that were prerendered.\n   * - 'restore': for pages that were discarded by the browser and then\n   * restored by the user.\n   */\n  navigationType:\n    | 'navigate'\n    | 'reload'\n    | 'back-forward'\n    | 'back-forward-cache'\n    | 'prerender'\n    | 'restore'\n    | 'soft-navigation';\n\n  /**\n   * The navigatonId the metric happened for. This is particularly relevent for soft navigations where\n   * the metric may be reported for a previous URL.\n   *\n   * The navigationId can be mapped to the URL with the following:\n   *   1 (or empty) - performance.getEntriesByType('navigation')[0]?.name\n   *   > 1 - performance.getEntriesByType('soft-navigation')[navigationId - 2]?.name\n   */\n  navigatonId: number;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetric`](/src/types/cls.ts#:~:text=interface%20CLSMetric)\n- [`FCPMetric`](/src/types/fcp.ts#:~:text=interface%20FCPMetric)\n- [`FIDMetric`](/src/types/fid.ts#:~:text=interface%20FIDMetric)\n- [`INPMetric`](/src/types/inp.ts#:~:text=interface%20INPMetric)\n- [`LCPMetric`](/src/types/lcp.ts#:~:text=interface%20LCPMetric)\n- [`TTFBMetric`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetric)\n\n#### `MetricWithAttribution`\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n```ts\ninterface MetricWithAttribution extends Metric {\n  /**\n   * An object containing potentially-helpful debugging information that\n   * can be sent along with the metric value for the current page visit in\n   * order to help identify issues happening to real-users in the field.\n   */\n  attribution: {[key: string]: unknown};\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetricWithAttribution`](/src/types/cls.ts#:~:text=interface%20CLSMetricWithAttribution)\n- [`FCPMetricWithAttribution`](/src/types/fcp.ts#:~:text=interface%20FCPMetricWithAttribution)\n- [`FIDMetricWithAttribution`](/src/types/fid.ts#:~:text=interface%20FIDMetricWithAttribution)\n- [`INPMetricWithAttribution`](/src/types/inp.ts#:~:text=interface%20INPMetricWithAttribution)\n- [`LCPMetricWithAttribution`](/src/types/lcp.ts#:~:text=interface%20LCPMetricWithAttribution)\n- [`TTFBMetricWithAttribution`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetricWithAttribution)\n\n#### `ReportCallback`\n\n```ts\ninterface ReportCallback {\n  (metric: Metric): void;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSReportCallback`](/src/types/cls.ts#:~:text=interface%20CLSReportCallback)\n- [`FCPReportCallback`](/src/types/fcp.ts#:~:text=interface%20FCPReportCallback)\n- [`FIDReportCallback`](/src/types/fid.ts#:~:text=interface%20FIDReportCallback)\n- [`INPReportCallback`](/src/types/inp.ts#:~:text=interface%20INPReportCallback)\n- [`LCPReportCallback`](/src/types/lcp.ts#:~:text=interface%20LCPReportCallback)\n- [`TTFBReportCallback`](/src/types/ttfb.ts#:~:text=interface%20TTFBReportCallback)\n\n#### `ReportOpts`\n\n```ts\ninterface ReportOpts {\n  reportAllChanges?: boolean;\n  durationThreshold?: number;\n  reportSoftNavs?: boolean;\n}\n```\n\n#### `LoadState`\n\nThe `LoadState` type is used in several of the metric [attribution objects](#attribution).\n\n```ts\n/**\n * The loading state of the document. Note: this value is similar to\n * `document.readyState` but it subdivides the \"interactive\" state into the\n * time before and after the DOMContentLoaded event fires.\n *\n * State descriptions:\n * - `loading`: the initial document response has not yet been fully downloaded\n *   and parsed. This is equivalent to the corresponding `readyState` value.\n * - `dom-interactive`: the document has been fully loaded and parsed, but\n *   scripts may not have yet finished loading and executing.\n * - `dom-content-loaded`: the document is fully loaded and parsed, and all\n *   scripts (except `async` scripts) have loaded and finished executing.\n * - `complete`: the document and all of its sub-resources have finished\n *   loading. This is equivalent to the corresponding `readyState` value.\n */\ntype LoadState =\n  | 'loading'\n  | 'dom-interactive'\n  | 'dom-content-loaded'\n  | 'complete';\n```\n\n#### `FirstInputPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't natively support the Event Timing API), the `metric.entries` reported by `onFID()` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<\n  PerformanceEventTiming,\n  'processingEnd' | 'toJSON'\n>;\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface), the `metric.entries` reported by `onTTFB()` will contain an object that polyfills the `PerformanceNavigationTiming` entry using timings from the legacy `performance.timing` interface:\n\n```ts\ntype NavigationTimingPolyfillEntry = Omit<\n  PerformanceNavigationTiming,\n  | 'initiatorType'\n  | 'nextHopProtocol'\n  | 'redirectCount'\n  | 'transferSize'\n  | 'encodedBodySize'\n  | 'decodedBodySize'\n  | 'type'\n> & {\n  type: PerformanceNavigationTiming['type'];\n};\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n  firstHiddenTime: number;\n}\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (callback: CLSReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [CLS](https://web.dev/cls/) value for the current page and calls the `callback` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/cls/#layout-shift-score)).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (callback: FCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FCP](https://web.dev/fcp/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n```ts\ntype onFID = (callback: FIDReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FID](https://web.dev/fid/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (callback: INPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [INP](https://web.dev/responsiveness/) value for the current page and calls the `callback` function once the value is ready, along with the `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nA custom `durationThreshold` [configuration option](#reportopts) can optionally be passed to control what `event-timing` entries are considered for INP reporting. The default threshold is `40`, which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended [good](https://web.dev/inp/#what-is-a-good-inp-score) threshold).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (callback: LCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [LCP](https://web.dev/lcp/) value for the current page and calls the `callback` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (callback: TTFBReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [TTFB](https://web.dev/time-to-first-byte/) value for the current page and calls the `callback` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `callback` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it includes time spent on DNS lookup, connection negotiation, network latency, and server processing time.\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n### Attribution:\n\nThe following objects contain potentially-helpful debugging information that can be sent along with the metric values for the current page visit in order to help identify issues happening to real-users in the field.\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n#### CLS `attribution`:\n\n```ts\ninterface CLSAttribution {\n  /**\n   * A selector identifying the first element (in document order) that\n   * shifted when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTarget?: string;\n  /**\n   * The time when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTime?: DOMHighResTimeStamp;\n  /**\n   * The layout shift score of the single largest layout shift contributing to\n   * the page's CLS score.\n   */\n  largestShiftValue?: number;\n  /**\n   * The `LayoutShiftEntry` representing the single largest layout shift\n   * contributing to the page's CLS score. (Useful when you need more than just\n   * `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftEntry?: LayoutShift;\n  /**\n   * The first element source (in document order) among the `sources` list\n   * of the `largestShiftEntry` object. (Also useful when you need more than\n   * just `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftSource?: LayoutShiftAttribution;\n  /**\n   * The loading state of the document at the time when the largest layout\n   * shift contribution to the page's CLS score occurred (see `LoadState`\n   * for details).\n   */\n  loadState?: LoadState;\n}\n```\n\n#### FCP `attribution`:\n\n```ts\ninterface FCPAttribution {\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB).\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and the first contentful paint (FCP).\n   */\n  firstByteToFCP: number;\n  /**\n   * The loading state of the document at the time when FCP `occurred (see\n   * `LoadState` for details). Ideally, documents can paint before they finish\n   * loading (e.g. the `loading` or `dom-interactive` phases).\n   */\n  loadState: LoadState;\n  /**\n   * The `PerformancePaintTiming` entry corresponding to FCP.\n   */\n  fcpEntry?: PerformancePaintTiming;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues.\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n#### FID `attribution`:\n\n```ts\ninterface FIDAttribution {\n  /**\n   * A selector identifying the element that the user interacted with. This\n   * element will be the `target` of the `event` dispatched.\n   */\n  eventTarget: string;\n  /**\n   * The time when the user interacted. This time will match the `timeStamp`\n   * value of the `event` dispatched.\n   */\n  eventTime: number;\n  /**\n   * The `type` of the `event` dispatched from the user interaction.\n   */\n  eventType: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to FID (or the\n   * polyfill entry in browsers that don't support Event Timing).\n   */\n  eventEntry: PerformanceEventTiming | FirstInputPolyfillEntry;\n  /**\n   * The loading state of the document at the time when the first interaction\n   * occurred (see `LoadState` for details). If the first interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long input delays.\n   */\n  loadState: LoadState;\n}\n```\n\n#### INP `attribution`:\n\n```ts\ninterface INPAttribution {\n  /**\n   * A selector identifying the element that the user interacted with for\n   * the event corresponding to INP. This element will be the `target` of the\n   * `event` dispatched.\n   */\n  eventTarget?: string;\n  /**\n   * The time when the user interacted for the event corresponding to INP.\n   * This time will match the `timeStamp` value of the `event` dispatched.\n   */\n  eventTime?: number;\n  /**\n   * The `type` of the `event` dispatched corresponding to INP.\n   */\n  eventType?: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to INP.\n   */\n  eventEntry?: PerformanceEventTiming;\n  /**\n   * The loading state of the document at the time when the even corresponding\n   * to INP occurred (see `LoadState` for details). If the interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long delays.\n   */\n  loadState?: LoadState;\n}\n```\n\n#### LCP `attribution`:\n\n```ts\ninterface LCPAttribution {\n  /**\n   * The element corresponding to the largest contentful paint for the page.\n   */\n  element?: string;\n  /**\n   * The URL (if applicable) of the LCP image resource. If the LCP element\n   * is a text node, this value will not be set.\n   */\n  url?: string;\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB). See\n   * [Optimize LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and when the browser starts loading the LCP\n   * resource (if there is one, otherwise 0). See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  resourceLoadDelay: number;\n  /**\n   * The total time it takes to load the LCP resource itself (if there is one,\n   * otherwise 0). See [Optimize LCP](https://web.dev/optimize-lcp/) for\n   * details.\n   */\n  resourceLoadTime: number;\n  /**\n   * The delta between when the LCP resource finishes loading until the LCP\n   * element is fully rendered. See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  elementRenderDelay: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues.\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n  /**\n   * The `resource` entry for the LCP resource (if applicable), which is useful\n   * for diagnosing resource load issues.\n   */\n  lcpResourceEntry?: PerformanceResourceTiming;\n  /**\n   * The `LargestContentfulPaint` entry corresponding to LCP.\n   */\n  lcpEntry?: LargestContentfulPaint;\n}\n```\n\n#### TTFB `attribution`:\n\n```ts\ninterface TTFBAttribution {\n  /**\n   * The total time from when the user initiates loading the page to when the\n   * DNS lookup begins. This includes redirects, service worker startup, and\n   * HTTP cache lookup times.\n   */\n  waitingTime: number;\n  /**\n   * The total time to resolve the DNS for the current request.\n   */\n  dnsTime: number;\n  /**\n   * The total time to create the connection to the requested domain.\n   */\n  connectionTime: number;\n  /**\n   * The time time from when the request was sent until the first byte of the\n   * response was received. This includes network time as well as server\n   * processing time.\n   */\n  requestTime: number;\n  /**\n   * The `PerformanceNavigationTiming` entry used to determine TTFB (or the\n   * polyfill entry in browsers that don't support Navigation Timing).\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium\n- `onFCP()`: Chromium, Firefox, Safari 14.1+\n- `onFID()`: Chromium, Firefox _(with [polyfill](#how-to-use-the-polyfill): Safari, Internet Explorer)_\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari 15+ _(with [polyfill](#how-to-use-the-polyfill): Safari 8+, Internet Explorer)_\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that\nmeasure the Web Vitals metrics, which means the limitations of those APIs will\nmostly apply to this library as well.\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/vitals-ga4/).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `callback` functions and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"bb4965304c58d061b8f9e4af8a036e13c14a8ef3","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.1.1-soft-navs-3","_nodeVersion":"16.15.1","_npmVersion":"8.13.0","dist":{"integrity":"sha512-UNZb7wXE7OxjTyhOtH3tjTLrbuPenU3AbFRecSvAxLsnoN9hR2wEu8vfj3qnArVnYScF8fJQc09d4Me4mmmz9Q==","shasum":"36f25266375a2e2d9c7752b230dc025da79bfb8b","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.1.1-soft-navs-3.tgz","fileCount":146,"unpackedSize":426794,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCUnJ/ceMzrMvUXrPCR2WTRzizBggLh0ZRLZCqp03z48gIgQt0n5VNJJjPwedFXKlfEdUTIwXd4cDh7z8hBVQieJKU="}],"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v4.10.10\r\nComment: https://openpgpjs.org\r\n\r\nwsFzBAEBCAAGBQJj5NwzACEJED1NWxICdlZqFiEECWMYAoorWMhJKdjhPU1b\r\nEgJ2VmqUChAAkBuheEjWaSAzH9ujt/iubu0DvJ+gIwVyWxnMqLAq7RBrkPde\r\nv+GU+cDHRYmyiYv9g4iNEISbAQcJghMewDP0+/apP11Y2RW7TkSlGjcxmZ0H\r\nqjpKyRJn/nrysawL3dTiDHAWDKZaBn+5WdIGVZdwnyXtwFvVGqrTxBGe5All\r\nhGJCs83wOWZMD3K3miuuxM8yfZdM1DY3Ob6Dea5SJHDrlJqkj6WWy7GXNUY0\r\nwa5dwxrUgTAoATpCbhfVWAhRxj7+i8/SdtQ3wnxwVEQCl8+7TPgxKj9Qt5Uf\r\n19EE+i89vRltJRu0aSIOvUU87pl4sqdnxegc5rw8d8LBpFyXwndQXcZ/bk7S\r\ndkBCmGadRvx7LQLdPmQyLXCom6zjn03yzVjRZpLNJTAaxC0iAsPTYQMIsG/k\r\nwT/IyG0xEFwxN4edw8X+tGu3uV2jvafJyKOQjzYoiGvOoZ6WSWVzx1e3RtRC\r\nD7G3k3aNqe0P4EMnRAk6T8XHz8wf384ZIfpcktl2JhZOLDjLYVcqfM3I5ACX\r\nKDpoKPhGwcJq/gyVwaIWJaKeCdm1otsndsi4rSEpla2tassb6uS5UYrwdHVX\r\narExs7ebc83SZpmSY2nxZfCHZoOmsQ9nzR9Lm/4nViXxwLT7dkrgK5OlLsVD\r\n7TFQaT3QYhBi0b1PqYPw5+iDa45PrjGPVvs=\r\n=5xrR\r\n-----END PGP SIGNATURE-----\r\n"},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.1.1-soft-navs-3_1675942963250_0.7522797447021923"},"_hasShrinkwrap":false},"3.1.1-soft-navs-4":{"name":"web-vitals","version":"3.1.1-soft-navs-4","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.19.3","@babel/preset-env":"^7.19.3","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.38.1","@typescript-eslint/parser":"^5.38.1","@wdio/cli":"^7.25.1","@wdio/local-runner":"^7.25.1","@wdio/mocha-framework":"^7.25.1","@wdio/selenium-standalone-service":"^7.26.0","@wdio/spec-reporter":"^7.25.1","body-parser":"^1.20.0","chromedriver":"^107.0.3","eslint":"^8.24.0","express":"^4.18.1","fs-extra":"^10.1.0","husky":"^8.0.1","lint-staged":"^13.0.3","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","prettier":"^2.8.0","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","selenium-standalone":"^8.2.3","typescript":"^4.8.4","wdio-chromedriver-service":"^8.0.0"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Send attribution data](#send-attribution-data)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Build options](#build-options)\n  - [Which build is right for you?](#which-build-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n  - [Attribution](#attribution)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1.5K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/vitals/) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/vitals/#core-web-vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/user-centric-performance-metrics/) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/cls/)\n- [First Input Delay (FID)](https://web.dev/fid/)\n- [Largest Contentful Paint (LCP)](https://web.dev/lcp/)\n\n### Other metrics\n\n- [Interaction to next Paint (INP)](https://web.dev/inp/) _(experimental)_\n- [First Contentful Paint (FCP)](https://web.dev/fcp/)\n- [Time to First Byte (TTFB)](https://web.dev/ttfb/)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\nThe `web-vitals` library uses the `buffered` flag for [PerformanceObserver](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver/observe), allowing it to access performance entries that occurred before the library was loaded.\n\nThis means you do not need to load this library early in order to get accurate performance data. In general, this library should be deferred until after other user-impacting code has loaded.\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are a few different builds of the `web-vitals` library, and how you load the library depends on which build you want to use.\n\nFor details on the difference between the builds, see <a href=\"#which-build-is-right-for-you\">which build is right for you</a>.\n\n**1. The \"standard\" build**\n\nTo load the \"standard\" build, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onFID, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functions were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"attribution-build\"><a>\n\n**2. The \"attribution\" build**\n\nMeasuring the Web Vitals scores for your real users is a great first step toward optimizing the user experience. But if your scores aren't _good_, the next step is to understand why they're not good and work to improve them.\n\nThe \"attribution\" build helps you do that by including additional diagnostic information with each metric to help you identify the root cause of poor performance as well as prioritize the most important things to fix.\n\nThe \"attribution\" build is slightly larger than the \"standard\" build (by about 600 bytes, brotli'd), so while the code size is still small, it's only recommended if you're actually using these features.\n\nTo load the \"attribution\" build, change any `import` statements that reference `web-vitals` to `web-vitals/attribution`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/attribution';\n```\n\nUsage for each of the imported function is identical to the standard build, but when importing from the attribution build, the [`Metric`](#metric) object will contain an additional [`attribution`](#metricwithattribution) property.\n\nSee [Send attribution data](#send-attribution-data) for usage examples, and the [`attribution` reference](#attribution) for details on what values are added for each metric.\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**3. The \"base+polyfill\" build**\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nLoading the \"base+polyfill\" build is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nIt's important that the code is inlined directly into the HTML. _Do not link to an external script file, as that will negatively affect performance:_\n\n```html\n<!-- GOOD -->\n<script>\n  // Inline code from `dist/polyfill.js` here\n</script>\n\n<!-- BAD! DO NOT DO! -->\n<script src=\"/path/to/polyfill.js\"></script>\n```\n\nAlso note that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com):\n\n_**Important!** The [unpkg.com](https://unpkg.com) CDN is shown here for example purposes only. `unpkg.com` is not affiliated with Google, and there are no guarantees that the URLs shown in these examples will continue to work in the future._\n\n**Load the \"standard\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals@3?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src = 'https://unpkg.com/web-vitals@3/dist/web-vitals.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n**Load the \"attribution\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {\n    onCLS,\n    onFID,\n    onLCP,\n  } from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"attribution\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src =\n      'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes a `callback` function that will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" build, but they will work with the \"attribution\" build as well.)_\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developer.chrome.com/docs/devtools/console/reference/#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID is not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS should be reported any time the [page's `visibilityState` changes to hidden](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/bfcache/).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onFID()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want the `callback` function to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each layout shift as it happens) by setting `reportAllChanges` to `true` in the optional, [configuration object](#reportopts) (second parameter).\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended) for measuring these metrics in production.\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, {reportAllChanges: true});\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonFID(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `callback` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Report metrics for soft navigations (experimental)\n\n_**Note:** this is experimental and subject to change._\n\nCurrently Core Web Vitals are only tracked for full page navigations, which can affect how [Single Page Applications](https://web.dev/vitals-spa-faq/) that use so called \"soft navigations\" to update the browser URL and history outside of the normal browser's handling of this. The Chrome team are experimenting with being able to [measure these soft navigations](https://github.com/WICG/soft-navigations) separately and report on Core Web Vitals separately for them.\n\nThis experimental support allows sites to measure how their Core Web Vitals might be measured differently should this happen.\n\nAt present a \"soft navigation\" is defined as happening after the following three things happen:\n\n- A user interaction occurs\n- The URL changes\n- Content is added to the DOM\n- Something is painted to screen.\n\nFor some sites, these heuristics may lead to false positives (that users would not really consider a \"navigation\"), or false negatives (where the user does consider a navigation to have happened despite not missing the above criteria). We welcome feedback at https://github.com/WICG/soft-navigations/issues on the heuristics, at https://crbug.com for bugs in the Chrome implementation, and on [https://github.com/GoogleChrome/web-vitals/pull/308](this pull request) for implementation issues with web-vitals.js.\n\n_**Note:** At this time it is not known if this experiment will be something we want to move forward with. Until such time, this support will likely remain in a separate branch of this project, rather than be included in any production builds. If we decide not to move forward with this, the support of this will likely be removed from this project since this library is intended to mirror the Core Web Vitals as much as possible._\n\nSome important points to note:\n\n- TTFB is reported as 0, and not the time of the first network call (if any) after the soft navigation.\n- FCP and LCP are the first and largest contentful paints after the soft navigation. Prior reported paint times will not be counted for these metrics, even though these elements may remain between soft navigations, and may be the first or largest contentful item.\n- FID is reset to measure the first interaction after the soft navigation.\n- INP is reset to measure only interactions after the the soft navigation.\n- CLS is reset to measure again separate to the first page.\n\n_**Note:** It is not known at this time whether soft navigations will be weighted the same as full navigations. No weighting is included in this library at present and metrics are reported in the same way as full page load metrics._\n\nThe metrics can be reported for Soft Navigations using the `reportSoftNavs: true` reporting option:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(console.log, {reportSoftNavs: true});\nonFID(console.log, {reportSoftNavs: true});\nonLCP(console.log, {reportSoftNavs: true});\n```\n\nNote that this will change the way the first page loads are measured as the metrics for the inital URL will be finalized once the first soft nav occurs. To measure both you need to register two callbacks:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(doTraditionalProcessing);\nonFID(doTraditionalProcessing);\nonLCP(doTraditionalProcessing);\n\nonCLS(doSoftNavProcessing, {reportSoftNavs: true});\nonFID(doSoftNavProcessing, {reportSoftNavs: true});\nonLCP(doSoftNavProcessing, {reportSoftNavs: true});\n```\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n    fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonFID(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique dimension value (in this case, the metric `id`, as shown in the examples below) on every metric instance that you send to Google Analytics, you can create a report yourself using the [Google Analytics Reporting API](https://developers.google.com/analytics/devguides/reporting) and any data visualization library you choose.\n\nAs an example of this, the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) is a free and open-source tool you can use to create visualizations of the Web Vitals data that you've sent to Google Analytics.\n\n[![web-vitals-report](https://user-images.githubusercontent.com/326742/101584324-3f9a0900-3992-11eb-8f2d-182f302fb67b.png)](https://github.com/GoogleChromeLabs/web-vitals-report)\n\nIn order to use the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) (or build your own custom reports using the API) you need to send your data to Google Analytics following one of the examples outlined below:\n\n#### Using `analytics.js`\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `ga()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/analyticsjs\n  ga('send', 'event', {\n    eventCategory: 'Web Vitals',\n    eventAction: name,\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    eventLabel: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    nonInteraction: true,\n    // Use `sendBeacon()` if the browser supports it.\n    transport: 'beacon',\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Universal Analytics)\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/gtagjs\n  gtag('event', name, {\n    event_category: 'Web Vitals',\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    event_label: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    value: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    non_interaction: true,\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Google Analytics 4)\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // metric_rating: 'good' | 'needs-improvement' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n### Send attribution data\n\nWhen using the [attribution build](#attribution-build), you can send additional data to help you debug _why_ the metric values are they way they are.\n\nThis example sends an additional `debug_target` param to Google Analytics, corresponding to the element most associated with each metric.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals/attribution';\n\nfunction sendToGoogleAnalytics({name, delta, value, id, attribution}) {\n  const eventParams = {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n  };\n\n  switch (name) {\n    case 'CLS':\n      eventParams.debug_target = attribution.largestShiftTarget;\n      break;\n    case 'FID':\n      eventParams.debug_target = attribution.eventTarget;\n      break;\n    case 'LCP':\n      eventParams.debug_target = attribution.element;\n      break;\n  }\n\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, eventParams);\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n_**Note:** this example relies on custom [event parameters](https://support.google.com/analytics/answer/11396839) in Google Analytics 4. For Universal Analytics the attribution data should be set using a [custom dimension](https://support.google.com/analytics/answer/2709828) rather than `debug_target` as shown above._\n\nSee [Debug performance in the field](https://web.dev/debug-performance-in-the-field/) for more information and examples.\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonFID(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n<a name=\"bundle-versions\"><a>\n\n## Build options\n\nThe `web-vitals` package includes builds for the \"standard\", \"attribution\", and \"base+polyfill\" ([deprecated](https://github.com/GoogleChrome/web-vitals/issues/238)) builds, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the builds distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any attribution features.</p>\n      This is the \"standard\" build and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.cjs</code></td>\n    <td><code>pgk.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.attribution.js</code></td>\n    <td>--</td>\n    <td>\n      An ES module version of all metric functions that includes <a href=\"#attribution-build\">attribution</a> features.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.iife.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An IIFE version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code>, <code>web-vitals.base.umd.cjs</code>, or <code>web-vitals.base.iife.js</code> (it will not work with any script that doesn't have \"base\" in the filename).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n<a name=\"which-build-is-right-for-you\"><a>\n\n### Which build is right for you?\n\nMost developers will generally want to use \"standard\" build (via either the ES module or UMD version, depending on your bundler/build system), as it's the easiest to use out of the box and integrate into existing tools.\n\nHowever, if you'd lke to collect additional debug information to help you diagnose performance bottlenecks based on real-user issues, use the [\"attribution\" build](#attribution-build).\n\nFor guidance on how to collect and use real-user data to debug performance issues, see [Debug performance in the field](https://web.dev/debug-performance-in-the-field/).\n\n### How the polyfill works\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nThe `polyfill.js` script adds event listeners (to track FID cross-browser), and it records initial page visibility state as well as the timestamp of the first visibility change to hidden (to improve the accuracy of CLS, FCP, LCP, and FID). It also polyfills the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) in browsers that only support the original (now deprecated) [Navigation Timing API](https://www.w3.org/TR/navigation-timing/).\n\nIn order for the polyfill to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" build of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" build, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  /**\n   * The name of the metric (in acronym form).\n   */\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  /**\n   * The current value of the metric.\n   */\n  value: number;\n\n  /**\n   * The rating as to whether the metric value is within the \"good\",\n   * \"needs improvement\", or \"poor\" thresholds of the metric.\n   */\n  rating: 'good' | 'needs-improvement' | 'poor';\n\n  /**\n   * The delta between the current value and the last-reported value.\n   * On the first report, `delta` and `value` will always be the same.\n   */\n  delta: number;\n\n  /**\n   * A unique ID representing this particular metric instance. This ID can\n   * be used by an analytics tool to dedupe multiple values sent for the same\n   * metric instance, or to group multiple deltas together and calculate a\n   * total. It can also be used to differentiate multiple different metric\n   * instances sent from the same page, which can happen if the page is\n   * restored from the back/forward cache (in that case new metrics object\n   * get created).\n   */\n  id: string;\n\n  /**\n   * Any performance entries relevant to the metric value calculation.\n   * The array may also be empty if the metric value was not based on any\n   * entries (e.g. a CLS value of 0 given no layout shifts).\n   */\n  entries: (\n    | PerformanceEntry\n    | LayoutShift\n    | FirstInputPolyfillEntry\n    | NavigationTimingPolyfillEntry\n  )[];\n\n  /**\n   * The type of navigation.\n   *\n   * This will be the value returned by the Navigation Timing API (or\n   * `undefined` if the browser doesn't support that API), with the following\n   * exceptions:\n   * - 'back-forward-cache': for pages that are restored from the bfcache.\n   * - 'prerender': for pages that were prerendered.\n   * - 'restore': for pages that were discarded by the browser and then\n   * restored by the user.\n   */\n  navigationType:\n    | 'navigate'\n    | 'reload'\n    | 'back-forward'\n    | 'back-forward-cache'\n    | 'prerender'\n    | 'restore'\n    | 'soft-navigation';\n\n  /**\n   * The navigatonId the metric happened for. This is particularly relevent for soft navigations where\n   * the metric may be reported for a previous URL.\n   *\n   * The navigationId can be mapped to the URL with the following:\n   *   1 (or empty) - performance.getEntriesByType('navigation')[0]?.name\n   *   > 1 - performance.getEntriesByType('soft-navigation')[navigationId - 2]?.name\n   */\n  navigatonId: number;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetric`](/src/types/cls.ts#:~:text=interface%20CLSMetric)\n- [`FCPMetric`](/src/types/fcp.ts#:~:text=interface%20FCPMetric)\n- [`FIDMetric`](/src/types/fid.ts#:~:text=interface%20FIDMetric)\n- [`INPMetric`](/src/types/inp.ts#:~:text=interface%20INPMetric)\n- [`LCPMetric`](/src/types/lcp.ts#:~:text=interface%20LCPMetric)\n- [`TTFBMetric`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetric)\n\n#### `MetricWithAttribution`\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n```ts\ninterface MetricWithAttribution extends Metric {\n  /**\n   * An object containing potentially-helpful debugging information that\n   * can be sent along with the metric value for the current page visit in\n   * order to help identify issues happening to real-users in the field.\n   */\n  attribution: {[key: string]: unknown};\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetricWithAttribution`](/src/types/cls.ts#:~:text=interface%20CLSMetricWithAttribution)\n- [`FCPMetricWithAttribution`](/src/types/fcp.ts#:~:text=interface%20FCPMetricWithAttribution)\n- [`FIDMetricWithAttribution`](/src/types/fid.ts#:~:text=interface%20FIDMetricWithAttribution)\n- [`INPMetricWithAttribution`](/src/types/inp.ts#:~:text=interface%20INPMetricWithAttribution)\n- [`LCPMetricWithAttribution`](/src/types/lcp.ts#:~:text=interface%20LCPMetricWithAttribution)\n- [`TTFBMetricWithAttribution`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetricWithAttribution)\n\n#### `ReportCallback`\n\n```ts\ninterface ReportCallback {\n  (metric: Metric): void;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSReportCallback`](/src/types/cls.ts#:~:text=interface%20CLSReportCallback)\n- [`FCPReportCallback`](/src/types/fcp.ts#:~:text=interface%20FCPReportCallback)\n- [`FIDReportCallback`](/src/types/fid.ts#:~:text=interface%20FIDReportCallback)\n- [`INPReportCallback`](/src/types/inp.ts#:~:text=interface%20INPReportCallback)\n- [`LCPReportCallback`](/src/types/lcp.ts#:~:text=interface%20LCPReportCallback)\n- [`TTFBReportCallback`](/src/types/ttfb.ts#:~:text=interface%20TTFBReportCallback)\n\n#### `ReportOpts`\n\n```ts\ninterface ReportOpts {\n  reportAllChanges?: boolean;\n  durationThreshold?: number;\n  reportSoftNavs?: boolean;\n}\n```\n\n#### `LoadState`\n\nThe `LoadState` type is used in several of the metric [attribution objects](#attribution).\n\n```ts\n/**\n * The loading state of the document. Note: this value is similar to\n * `document.readyState` but it subdivides the \"interactive\" state into the\n * time before and after the DOMContentLoaded event fires.\n *\n * State descriptions:\n * - `loading`: the initial document response has not yet been fully downloaded\n *   and parsed. This is equivalent to the corresponding `readyState` value.\n * - `dom-interactive`: the document has been fully loaded and parsed, but\n *   scripts may not have yet finished loading and executing.\n * - `dom-content-loaded`: the document is fully loaded and parsed, and all\n *   scripts (except `async` scripts) have loaded and finished executing.\n * - `complete`: the document and all of its sub-resources have finished\n *   loading. This is equivalent to the corresponding `readyState` value.\n */\ntype LoadState =\n  | 'loading'\n  | 'dom-interactive'\n  | 'dom-content-loaded'\n  | 'complete';\n```\n\n#### `FirstInputPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't natively support the Event Timing API), the `metric.entries` reported by `onFID()` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<\n  PerformanceEventTiming,\n  'processingEnd' | 'toJSON'\n>;\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface), the `metric.entries` reported by `onTTFB()` will contain an object that polyfills the `PerformanceNavigationTiming` entry using timings from the legacy `performance.timing` interface:\n\n```ts\ntype NavigationTimingPolyfillEntry = Omit<\n  PerformanceNavigationTiming,\n  | 'initiatorType'\n  | 'nextHopProtocol'\n  | 'redirectCount'\n  | 'transferSize'\n  | 'encodedBodySize'\n  | 'decodedBodySize'\n  | 'type'\n> & {\n  type: PerformanceNavigationTiming['type'];\n};\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n  firstHiddenTime: number;\n}\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (callback: CLSReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [CLS](https://web.dev/cls/) value for the current page and calls the `callback` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/cls/#layout-shift-score)).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (callback: FCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FCP](https://web.dev/fcp/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n```ts\ntype onFID = (callback: FIDReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FID](https://web.dev/fid/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (callback: INPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [INP](https://web.dev/responsiveness/) value for the current page and calls the `callback` function once the value is ready, along with the `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nA custom `durationThreshold` [configuration option](#reportopts) can optionally be passed to control what `event-timing` entries are considered for INP reporting. The default threshold is `40`, which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended [good](https://web.dev/inp/#what-is-a-good-inp-score) threshold).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (callback: LCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [LCP](https://web.dev/lcp/) value for the current page and calls the `callback` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (callback: TTFBReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [TTFB](https://web.dev/time-to-first-byte/) value for the current page and calls the `callback` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `callback` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it includes time spent on DNS lookup, connection negotiation, network latency, and server processing time.\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n### Attribution:\n\nThe following objects contain potentially-helpful debugging information that can be sent along with the metric values for the current page visit in order to help identify issues happening to real-users in the field.\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n#### CLS `attribution`:\n\n```ts\ninterface CLSAttribution {\n  /**\n   * A selector identifying the first element (in document order) that\n   * shifted when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTarget?: string;\n  /**\n   * The time when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTime?: DOMHighResTimeStamp;\n  /**\n   * The layout shift score of the single largest layout shift contributing to\n   * the page's CLS score.\n   */\n  largestShiftValue?: number;\n  /**\n   * The `LayoutShiftEntry` representing the single largest layout shift\n   * contributing to the page's CLS score. (Useful when you need more than just\n   * `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftEntry?: LayoutShift;\n  /**\n   * The first element source (in document order) among the `sources` list\n   * of the `largestShiftEntry` object. (Also useful when you need more than\n   * just `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftSource?: LayoutShiftAttribution;\n  /**\n   * The loading state of the document at the time when the largest layout\n   * shift contribution to the page's CLS score occurred (see `LoadState`\n   * for details).\n   */\n  loadState?: LoadState;\n}\n```\n\n#### FCP `attribution`:\n\n```ts\ninterface FCPAttribution {\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB).\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and the first contentful paint (FCP).\n   */\n  firstByteToFCP: number;\n  /**\n   * The loading state of the document at the time when FCP `occurred (see\n   * `LoadState` for details). Ideally, documents can paint before they finish\n   * loading (e.g. the `loading` or `dom-interactive` phases).\n   */\n  loadState: LoadState;\n  /**\n   * The `PerformancePaintTiming` entry corresponding to FCP.\n   */\n  fcpEntry?: PerformancePaintTiming;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues.\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n#### FID `attribution`:\n\n```ts\ninterface FIDAttribution {\n  /**\n   * A selector identifying the element that the user interacted with. This\n   * element will be the `target` of the `event` dispatched.\n   */\n  eventTarget: string;\n  /**\n   * The time when the user interacted. This time will match the `timeStamp`\n   * value of the `event` dispatched.\n   */\n  eventTime: number;\n  /**\n   * The `type` of the `event` dispatched from the user interaction.\n   */\n  eventType: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to FID (or the\n   * polyfill entry in browsers that don't support Event Timing).\n   */\n  eventEntry: PerformanceEventTiming | FirstInputPolyfillEntry;\n  /**\n   * The loading state of the document at the time when the first interaction\n   * occurred (see `LoadState` for details). If the first interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long input delays.\n   */\n  loadState: LoadState;\n}\n```\n\n#### INP `attribution`:\n\n```ts\ninterface INPAttribution {\n  /**\n   * A selector identifying the element that the user interacted with for\n   * the event corresponding to INP. This element will be the `target` of the\n   * `event` dispatched.\n   */\n  eventTarget?: string;\n  /**\n   * The time when the user interacted for the event corresponding to INP.\n   * This time will match the `timeStamp` value of the `event` dispatched.\n   */\n  eventTime?: number;\n  /**\n   * The `type` of the `event` dispatched corresponding to INP.\n   */\n  eventType?: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to INP.\n   */\n  eventEntry?: PerformanceEventTiming;\n  /**\n   * The loading state of the document at the time when the even corresponding\n   * to INP occurred (see `LoadState` for details). If the interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long delays.\n   */\n  loadState?: LoadState;\n}\n```\n\n#### LCP `attribution`:\n\n```ts\ninterface LCPAttribution {\n  /**\n   * The element corresponding to the largest contentful paint for the page.\n   */\n  element?: string;\n  /**\n   * The URL (if applicable) of the LCP image resource. If the LCP element\n   * is a text node, this value will not be set.\n   */\n  url?: string;\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB). See\n   * [Optimize LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and when the browser starts loading the LCP\n   * resource (if there is one, otherwise 0). See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  resourceLoadDelay: number;\n  /**\n   * The total time it takes to load the LCP resource itself (if there is one,\n   * otherwise 0). See [Optimize LCP](https://web.dev/optimize-lcp/) for\n   * details.\n   */\n  resourceLoadTime: number;\n  /**\n   * The delta between when the LCP resource finishes loading until the LCP\n   * element is fully rendered. See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  elementRenderDelay: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues.\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n  /**\n   * The `resource` entry for the LCP resource (if applicable), which is useful\n   * for diagnosing resource load issues.\n   */\n  lcpResourceEntry?: PerformanceResourceTiming;\n  /**\n   * The `LargestContentfulPaint` entry corresponding to LCP.\n   */\n  lcpEntry?: LargestContentfulPaint;\n}\n```\n\n#### TTFB `attribution`:\n\n```ts\ninterface TTFBAttribution {\n  /**\n   * The total time from when the user initiates loading the page to when the\n   * DNS lookup begins. This includes redirects, service worker startup, and\n   * HTTP cache lookup times.\n   */\n  waitingTime: number;\n  /**\n   * The total time to resolve the DNS for the current request.\n   */\n  dnsTime: number;\n  /**\n   * The total time to create the connection to the requested domain.\n   */\n  connectionTime: number;\n  /**\n   * The time time from when the request was sent until the first byte of the\n   * response was received. This includes network time as well as server\n   * processing time.\n   */\n  requestTime: number;\n  /**\n   * The `PerformanceNavigationTiming` entry used to determine TTFB (or the\n   * polyfill entry in browsers that don't support Navigation Timing).\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium\n- `onFCP()`: Chromium, Firefox, Safari 14.1+\n- `onFID()`: Chromium, Firefox _(with [polyfill](#how-to-use-the-polyfill): Safari, Internet Explorer)_\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari 15+ _(with [polyfill](#how-to-use-the-polyfill): Safari 8+, Internet Explorer)_\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that\nmeasure the Web Vitals metrics, which means the limitations of those APIs will\nmostly apply to this library as well.\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/vitals-ga4/).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `callback` functions and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"aa45395ca4e797fbc8633375841e3de2e9e3fa06","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.1.1-soft-navs-4","_nodeVersion":"16.15.1","_npmVersion":"8.13.0","dist":{"integrity":"sha512-xBXCaaDLnf/U74ASzerDpq/JvlTmHr29m9r2jIXptQHwl59WzzfGh0QhuwlRLrGC/EjDa1pbtx00Hcu6QqKS3g==","shasum":"305d2833e6bfe239de87c1f3ae129913c43d93df","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.1.1-soft-navs-4.tgz","fileCount":146,"unpackedSize":428131,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDy4c5HYf3Z2VkwnJ8tdWBGxhG/noRP0rHXiyT7bhBlPQIgJXgD5Phq5BAE9UGu+02SMj1OprmqmqopLLfLozDNoJk="}],"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v4.10.10\r\nComment: https://openpgpjs.org\r\n\r\nwsFzBAEBCAAGBQJj5jwHACEJED1NWxICdlZqFiEECWMYAoorWMhJKdjhPU1b\r\nEgJ2VmoVag/8CPLmTyuXLNjpQmrbNZHCpfnwOGaIgCxJ/5V8gEVpVqb9jXji\r\nAIZ8ECWUbIcstu9MnhYi6sdI2I0Yy4M14mT3xS19Bxw02IeWF6TKn/uOmoEq\r\nEgGKOmt1SkVYtC1G9M2GNOU0NQsD3r+6BZ406vulnJwoE8ihloG56LEHmN4b\r\nWPBdgblVsGGV1sSSm1MqKBTc3AGZYdti4BQkBqcmGKguwhjmArBr3CkGsrY9\r\ngKbrxYILI8k/rbQG3gix1TGmzzQBo3aXmtH4TOxG7F0/6YFYUk4ncbckVtqA\r\n/gXomvtSxxoVLDepYGmU2eCJMe8oI6kNRwK3pUnQs8Vuehw/9j5oPY7p8pnI\r\ntnaIFeBisDj8M92b1hDnxYhTJUPzb4jdcjkwCTHxbUOycpDRah1qTJDpQJGu\r\nootlcD34Y6TWxyd4RNAema/x2pjJRrVV3DWuYhMGPbE1yewtBo270Wi/wKJs\r\ngdrS4Ym6Jj1XLok6h3liv2HdULPnLAJvLem2jNlO4dgrOt8nsWtgMayYHc0G\r\n73D7zR7g6jBqLvTSqASDBjMBNcAfWK+gMER6PvLJAeHsTTj81qQVSRNTTwi6\r\n7Y/fS9+kj8+sbhaV6G8WWgwzNK0nZ3UPWmVzlewk1CDVnWE/QCIjFClc05e4\r\nhtnsUc5LONWZgdPs7E4p0uG9ceyJYwJdqkc=\r\n=W1gW\r\n-----END PGP SIGNATURE-----\r\n"},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.1.1-soft-navs-4_1676033031281_0.43919623124518603"},"_hasShrinkwrap":false},"3.1.1-soft-navs-5":{"name":"web-vitals","version":"3.1.1-soft-navs-5","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build -p -r test:*","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.19.3","@babel/preset-env":"^7.19.3","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.38.1","@typescript-eslint/parser":"^5.38.1","@wdio/cli":"^7.25.1","@wdio/local-runner":"^7.25.1","@wdio/mocha-framework":"^7.25.1","@wdio/selenium-standalone-service":"^7.26.0","@wdio/spec-reporter":"^7.25.1","body-parser":"^1.20.0","chromedriver":"^107.0.3","eslint":"^8.24.0","express":"^4.18.1","fs-extra":"^10.1.0","husky":"^8.0.1","lint-staged":"^13.0.3","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","prettier":"^2.8.0","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","selenium-standalone":"^8.2.3","typescript":"^4.8.4","wdio-chromedriver-service":"^8.0.0"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Send attribution data](#send-attribution-data)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Build options](#build-options)\n  - [Which build is right for you?](#which-build-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n  - [Attribution](#attribution)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1.5K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/vitals/) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/vitals/#core-web-vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/user-centric-performance-metrics/) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/cls/)\n- [First Input Delay (FID)](https://web.dev/fid/)\n- [Largest Contentful Paint (LCP)](https://web.dev/lcp/)\n\n### Other metrics\n\n- [Interaction to next Paint (INP)](https://web.dev/inp/) _(experimental)_\n- [First Contentful Paint (FCP)](https://web.dev/fcp/)\n- [Time to First Byte (TTFB)](https://web.dev/ttfb/)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\nThe `web-vitals` library uses the `buffered` flag for [PerformanceObserver](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver/observe), allowing it to access performance entries that occurred before the library was loaded.\n\nThis means you do not need to load this library early in order to get accurate performance data. In general, this library should be deferred until after other user-impacting code has loaded.\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are a few different builds of the `web-vitals` library, and how you load the library depends on which build you want to use.\n\nFor details on the difference between the builds, see <a href=\"#which-build-is-right-for-you\">which build is right for you</a>.\n\n**1. The \"standard\" build**\n\nTo load the \"standard\" build, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onFID, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functions were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"attribution-build\"><a>\n\n**2. The \"attribution\" build**\n\nMeasuring the Web Vitals scores for your real users is a great first step toward optimizing the user experience. But if your scores aren't _good_, the next step is to understand why they're not good and work to improve them.\n\nThe \"attribution\" build helps you do that by including additional diagnostic information with each metric to help you identify the root cause of poor performance as well as prioritize the most important things to fix.\n\nThe \"attribution\" build is slightly larger than the \"standard\" build (by about 600 bytes, brotli'd), so while the code size is still small, it's only recommended if you're actually using these features.\n\nTo load the \"attribution\" build, change any `import` statements that reference `web-vitals` to `web-vitals/attribution`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/attribution';\n```\n\nUsage for each of the imported function is identical to the standard build, but when importing from the attribution build, the [`Metric`](#metric) object will contain an additional [`attribution`](#metricwithattribution) property.\n\nSee [Send attribution data](#send-attribution-data) for usage examples, and the [`attribution` reference](#attribution) for details on what values are added for each metric.\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**3. The \"base+polyfill\" build**\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nLoading the \"base+polyfill\" build is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nIt's important that the code is inlined directly into the HTML. _Do not link to an external script file, as that will negatively affect performance:_\n\n```html\n<!-- GOOD -->\n<script>\n  // Inline code from `dist/polyfill.js` here\n</script>\n\n<!-- BAD! DO NOT DO! -->\n<script src=\"/path/to/polyfill.js\"></script>\n```\n\nAlso note that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com):\n\n_**Important!** The [unpkg.com](https://unpkg.com) CDN is shown here for example purposes only. `unpkg.com` is not affiliated with Google, and there are no guarantees that the URLs shown in these examples will continue to work in the future._\n\n**Load the \"standard\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals@3?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src = 'https://unpkg.com/web-vitals@3/dist/web-vitals.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n**Load the \"attribution\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {\n    onCLS,\n    onFID,\n    onLCP,\n  } from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"attribution\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src =\n      'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes a `callback` function that will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" build, but they will work with the \"attribution\" build as well.)_\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developer.chrome.com/docs/devtools/console/reference/#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID is not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS should be reported any time the [page's `visibilityState` changes to hidden](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/bfcache/).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onFID()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want the `callback` function to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each layout shift as it happens) by setting `reportAllChanges` to `true` in the optional, [configuration object](#reportopts) (second parameter).\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended) for measuring these metrics in production.\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, {reportAllChanges: true});\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonFID(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `callback` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Report metrics for soft navigations (experimental)\n\n_**Note:** this is experimental and subject to change._\n\nCurrently Core Web Vitals are only tracked for full page navigations, which can affect how [Single Page Applications](https://web.dev/vitals-spa-faq/) that use so called \"soft navigations\" to update the browser URL and history outside of the normal browser's handling of this. The Chrome team are experimenting with being able to [measure these soft navigations](https://github.com/WICG/soft-navigations) separately and report on Core Web Vitals separately for them.\n\nThis experimental support allows sites to measure how their Core Web Vitals might be measured differently should this happen.\n\nAt present a \"soft navigation\" is defined as happening after the following three things happen:\n\n- A user interaction occurs\n- The URL changes\n- Content is added to the DOM\n- Something is painted to screen.\n\nFor some sites, these heuristics may lead to false positives (that users would not really consider a \"navigation\"), or false negatives (where the user does consider a navigation to have happened despite not missing the above criteria). We welcome feedback at https://github.com/WICG/soft-navigations/issues on the heuristics, at https://crbug.com for bugs in the Chrome implementation, and on [https://github.com/GoogleChrome/web-vitals/pull/308](this pull request) for implementation issues with web-vitals.js.\n\n_**Note:** At this time it is not known if this experiment will be something we want to move forward with. Until such time, this support will likely remain in a separate branch of this project, rather than be included in any production builds. If we decide not to move forward with this, the support of this will likely be removed from this project since this library is intended to mirror the Core Web Vitals as much as possible._\n\nSome important points to note:\n\n- TTFB is reported as 0, and not the time of the first network call (if any) after the soft navigation.\n- FCP and LCP are the first and largest contentful paints after the soft navigation. Prior reported paint times will not be counted for these metrics, even though these elements may remain between soft navigations, and may be the first or largest contentful item.\n- FID is reset to measure the first interaction after the soft navigation.\n- INP is reset to measure only interactions after the the soft navigation.\n- CLS is reset to measure again separate to the first page.\n\n_**Note:** It is not known at this time whether soft navigations will be weighted the same as full navigations. No weighting is included in this library at present and metrics are reported in the same way as full page load metrics._\n\nThe metrics can be reported for Soft Navigations using the `reportSoftNavs: true` reporting option:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(console.log, {reportSoftNavs: true});\nonFID(console.log, {reportSoftNavs: true});\nonLCP(console.log, {reportSoftNavs: true});\n```\n\nNote that this will change the way the first page loads are measured as the metrics for the inital URL will be finalized once the first soft nav occurs. To measure both you need to register two callbacks:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(doTraditionalProcessing);\nonFID(doTraditionalProcessing);\nonLCP(doTraditionalProcessing);\n\nonCLS(doSoftNavProcessing, {reportSoftNavs: true});\nonFID(doSoftNavProcessing, {reportSoftNavs: true});\nonLCP(doSoftNavProcessing, {reportSoftNavs: true});\n```\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n    fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonFID(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique dimension value (in this case, the metric `id`, as shown in the examples below) on every metric instance that you send to Google Analytics, you can create a report yourself using the [Google Analytics Reporting API](https://developers.google.com/analytics/devguides/reporting) and any data visualization library you choose.\n\nAs an example of this, the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) is a free and open-source tool you can use to create visualizations of the Web Vitals data that you've sent to Google Analytics.\n\n[![web-vitals-report](https://user-images.githubusercontent.com/326742/101584324-3f9a0900-3992-11eb-8f2d-182f302fb67b.png)](https://github.com/GoogleChromeLabs/web-vitals-report)\n\nIn order to use the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) (or build your own custom reports using the API) you need to send your data to Google Analytics following one of the examples outlined below:\n\n#### Using `analytics.js`\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `ga()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/analyticsjs\n  ga('send', 'event', {\n    eventCategory: 'Web Vitals',\n    eventAction: name,\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    eventLabel: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    nonInteraction: true,\n    // Use `sendBeacon()` if the browser supports it.\n    transport: 'beacon',\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Universal Analytics)\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/gtagjs\n  gtag('event', name, {\n    event_category: 'Web Vitals',\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    event_label: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    value: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    non_interaction: true,\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Google Analytics 4)\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // metric_rating: 'good' | 'needs-improvement' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n### Send attribution data\n\nWhen using the [attribution build](#attribution-build), you can send additional data to help you debug _why_ the metric values are they way they are.\n\nThis example sends an additional `debug_target` param to Google Analytics, corresponding to the element most associated with each metric.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals/attribution';\n\nfunction sendToGoogleAnalytics({name, delta, value, id, attribution}) {\n  const eventParams = {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n  };\n\n  switch (name) {\n    case 'CLS':\n      eventParams.debug_target = attribution.largestShiftTarget;\n      break;\n    case 'FID':\n      eventParams.debug_target = attribution.eventTarget;\n      break;\n    case 'LCP':\n      eventParams.debug_target = attribution.element;\n      break;\n  }\n\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, eventParams);\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n_**Note:** this example relies on custom [event parameters](https://support.google.com/analytics/answer/11396839) in Google Analytics 4. For Universal Analytics the attribution data should be set using a [custom dimension](https://support.google.com/analytics/answer/2709828) rather than `debug_target` as shown above._\n\nSee [Debug performance in the field](https://web.dev/debug-performance-in-the-field/) for more information and examples.\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonFID(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n<a name=\"bundle-versions\"><a>\n\n## Build options\n\nThe `web-vitals` package includes builds for the \"standard\", \"attribution\", and \"base+polyfill\" ([deprecated](https://github.com/GoogleChrome/web-vitals/issues/238)) builds, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the builds distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any attribution features.</p>\n      This is the \"standard\" build and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.cjs</code></td>\n    <td><code>pgk.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.attribution.js</code></td>\n    <td>--</td>\n    <td>\n      An ES module version of all metric functions that includes <a href=\"#attribution-build\">attribution</a> features.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.iife.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An IIFE version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code>, <code>web-vitals.base.umd.cjs</code>, or <code>web-vitals.base.iife.js</code> (it will not work with any script that doesn't have \"base\" in the filename).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n<a name=\"which-build-is-right-for-you\"><a>\n\n### Which build is right for you?\n\nMost developers will generally want to use \"standard\" build (via either the ES module or UMD version, depending on your bundler/build system), as it's the easiest to use out of the box and integrate into existing tools.\n\nHowever, if you'd lke to collect additional debug information to help you diagnose performance bottlenecks based on real-user issues, use the [\"attribution\" build](#attribution-build).\n\nFor guidance on how to collect and use real-user data to debug performance issues, see [Debug performance in the field](https://web.dev/debug-performance-in-the-field/).\n\n### How the polyfill works\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nThe `polyfill.js` script adds event listeners (to track FID cross-browser), and it records initial page visibility state as well as the timestamp of the first visibility change to hidden (to improve the accuracy of CLS, FCP, LCP, and FID). It also polyfills the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) in browsers that only support the original (now deprecated) [Navigation Timing API](https://www.w3.org/TR/navigation-timing/).\n\nIn order for the polyfill to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" build of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" build, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  /**\n   * The name of the metric (in acronym form).\n   */\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  /**\n   * The current value of the metric.\n   */\n  value: number;\n\n  /**\n   * The rating as to whether the metric value is within the \"good\",\n   * \"needs improvement\", or \"poor\" thresholds of the metric.\n   */\n  rating: 'good' | 'needs-improvement' | 'poor';\n\n  /**\n   * The delta between the current value and the last-reported value.\n   * On the first report, `delta` and `value` will always be the same.\n   */\n  delta: number;\n\n  /**\n   * A unique ID representing this particular metric instance. This ID can\n   * be used by an analytics tool to dedupe multiple values sent for the same\n   * metric instance, or to group multiple deltas together and calculate a\n   * total. It can also be used to differentiate multiple different metric\n   * instances sent from the same page, which can happen if the page is\n   * restored from the back/forward cache (in that case new metrics object\n   * get created).\n   */\n  id: string;\n\n  /**\n   * Any performance entries relevant to the metric value calculation.\n   * The array may also be empty if the metric value was not based on any\n   * entries (e.g. a CLS value of 0 given no layout shifts).\n   */\n  entries: (\n    | PerformanceEntry\n    | LayoutShift\n    | FirstInputPolyfillEntry\n    | NavigationTimingPolyfillEntry\n  )[];\n\n  /**\n   * The type of navigation.\n   *\n   * This will be the value returned by the Navigation Timing API (or\n   * `undefined` if the browser doesn't support that API), with the following\n   * exceptions:\n   * - 'back-forward-cache': for pages that are restored from the bfcache.\n   * - 'prerender': for pages that were prerendered.\n   * - 'restore': for pages that were discarded by the browser and then\n   * restored by the user.\n   */\n  navigationType:\n    | 'navigate'\n    | 'reload'\n    | 'back-forward'\n    | 'back-forward-cache'\n    | 'prerender'\n    | 'restore'\n    | 'soft-navigation';\n\n  /**\n   * The navigatonId the metric happened for. This is particularly relevent for soft navigations where\n   * the metric may be reported for a previous URL.\n   *\n   * The navigationId can be mapped to the URL with the following:\n   *   1 (or empty) - performance.getEntriesByType('navigation')[0]?.name\n   *   > 1 - performance.getEntriesByType('soft-navigation')[navigationId - 2]?.name\n   */\n  navigatonId: number;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetric`](/src/types/cls.ts#:~:text=interface%20CLSMetric)\n- [`FCPMetric`](/src/types/fcp.ts#:~:text=interface%20FCPMetric)\n- [`FIDMetric`](/src/types/fid.ts#:~:text=interface%20FIDMetric)\n- [`INPMetric`](/src/types/inp.ts#:~:text=interface%20INPMetric)\n- [`LCPMetric`](/src/types/lcp.ts#:~:text=interface%20LCPMetric)\n- [`TTFBMetric`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetric)\n\n#### `MetricWithAttribution`\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n```ts\ninterface MetricWithAttribution extends Metric {\n  /**\n   * An object containing potentially-helpful debugging information that\n   * can be sent along with the metric value for the current page visit in\n   * order to help identify issues happening to real-users in the field.\n   */\n  attribution: {[key: string]: unknown};\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetricWithAttribution`](/src/types/cls.ts#:~:text=interface%20CLSMetricWithAttribution)\n- [`FCPMetricWithAttribution`](/src/types/fcp.ts#:~:text=interface%20FCPMetricWithAttribution)\n- [`FIDMetricWithAttribution`](/src/types/fid.ts#:~:text=interface%20FIDMetricWithAttribution)\n- [`INPMetricWithAttribution`](/src/types/inp.ts#:~:text=interface%20INPMetricWithAttribution)\n- [`LCPMetricWithAttribution`](/src/types/lcp.ts#:~:text=interface%20LCPMetricWithAttribution)\n- [`TTFBMetricWithAttribution`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetricWithAttribution)\n\n#### `ReportCallback`\n\n```ts\ninterface ReportCallback {\n  (metric: Metric): void;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSReportCallback`](/src/types/cls.ts#:~:text=interface%20CLSReportCallback)\n- [`FCPReportCallback`](/src/types/fcp.ts#:~:text=interface%20FCPReportCallback)\n- [`FIDReportCallback`](/src/types/fid.ts#:~:text=interface%20FIDReportCallback)\n- [`INPReportCallback`](/src/types/inp.ts#:~:text=interface%20INPReportCallback)\n- [`LCPReportCallback`](/src/types/lcp.ts#:~:text=interface%20LCPReportCallback)\n- [`TTFBReportCallback`](/src/types/ttfb.ts#:~:text=interface%20TTFBReportCallback)\n\n#### `ReportOpts`\n\n```ts\ninterface ReportOpts {\n  reportAllChanges?: boolean;\n  durationThreshold?: number;\n  reportSoftNavs?: boolean;\n}\n```\n\n#### `LoadState`\n\nThe `LoadState` type is used in several of the metric [attribution objects](#attribution).\n\n```ts\n/**\n * The loading state of the document. Note: this value is similar to\n * `document.readyState` but it subdivides the \"interactive\" state into the\n * time before and after the DOMContentLoaded event fires.\n *\n * State descriptions:\n * - `loading`: the initial document response has not yet been fully downloaded\n *   and parsed. This is equivalent to the corresponding `readyState` value.\n * - `dom-interactive`: the document has been fully loaded and parsed, but\n *   scripts may not have yet finished loading and executing.\n * - `dom-content-loaded`: the document is fully loaded and parsed, and all\n *   scripts (except `async` scripts) have loaded and finished executing.\n * - `complete`: the document and all of its sub-resources have finished\n *   loading. This is equivalent to the corresponding `readyState` value.\n */\ntype LoadState =\n  | 'loading'\n  | 'dom-interactive'\n  | 'dom-content-loaded'\n  | 'complete';\n```\n\n#### `FirstInputPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't natively support the Event Timing API), the `metric.entries` reported by `onFID()` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<\n  PerformanceEventTiming,\n  'processingEnd' | 'toJSON'\n>;\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface), the `metric.entries` reported by `onTTFB()` will contain an object that polyfills the `PerformanceNavigationTiming` entry using timings from the legacy `performance.timing` interface:\n\n```ts\ntype NavigationTimingPolyfillEntry = Omit<\n  PerformanceNavigationTiming,\n  | 'initiatorType'\n  | 'nextHopProtocol'\n  | 'redirectCount'\n  | 'transferSize'\n  | 'encodedBodySize'\n  | 'decodedBodySize'\n  | 'type'\n> & {\n  type: PerformanceNavigationTiming['type'];\n};\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n  firstHiddenTime: number;\n}\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (callback: CLSReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [CLS](https://web.dev/cls/) value for the current page and calls the `callback` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/cls/#layout-shift-score)).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (callback: FCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FCP](https://web.dev/fcp/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n```ts\ntype onFID = (callback: FIDReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FID](https://web.dev/fid/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (callback: INPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [INP](https://web.dev/responsiveness/) value for the current page and calls the `callback` function once the value is ready, along with the `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nA custom `durationThreshold` [configuration option](#reportopts) can optionally be passed to control what `event-timing` entries are considered for INP reporting. The default threshold is `40`, which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended [good](https://web.dev/inp/#what-is-a-good-inp-score) threshold).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (callback: LCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [LCP](https://web.dev/lcp/) value for the current page and calls the `callback` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (callback: TTFBReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [TTFB](https://web.dev/time-to-first-byte/) value for the current page and calls the `callback` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `callback` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it includes time spent on DNS lookup, connection negotiation, network latency, and server processing time.\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n### Attribution:\n\nThe following objects contain potentially-helpful debugging information that can be sent along with the metric values for the current page visit in order to help identify issues happening to real-users in the field.\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n#### CLS `attribution`:\n\n```ts\ninterface CLSAttribution {\n  /**\n   * A selector identifying the first element (in document order) that\n   * shifted when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTarget?: string;\n  /**\n   * The time when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTime?: DOMHighResTimeStamp;\n  /**\n   * The layout shift score of the single largest layout shift contributing to\n   * the page's CLS score.\n   */\n  largestShiftValue?: number;\n  /**\n   * The `LayoutShiftEntry` representing the single largest layout shift\n   * contributing to the page's CLS score. (Useful when you need more than just\n   * `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftEntry?: LayoutShift;\n  /**\n   * The first element source (in document order) among the `sources` list\n   * of the `largestShiftEntry` object. (Also useful when you need more than\n   * just `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftSource?: LayoutShiftAttribution;\n  /**\n   * The loading state of the document at the time when the largest layout\n   * shift contribution to the page's CLS score occurred (see `LoadState`\n   * for details).\n   */\n  loadState?: LoadState;\n}\n```\n\n#### FCP `attribution`:\n\n```ts\ninterface FCPAttribution {\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB).\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and the first contentful paint (FCP).\n   */\n  firstByteToFCP: number;\n  /**\n   * The loading state of the document at the time when FCP `occurred (see\n   * `LoadState` for details). Ideally, documents can paint before they finish\n   * loading (e.g. the `loading` or `dom-interactive` phases).\n   */\n  loadState: LoadState;\n  /**\n   * The `PerformancePaintTiming` entry corresponding to FCP.\n   */\n  fcpEntry?: PerformancePaintTiming;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues.\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n#### FID `attribution`:\n\n```ts\ninterface FIDAttribution {\n  /**\n   * A selector identifying the element that the user interacted with. This\n   * element will be the `target` of the `event` dispatched.\n   */\n  eventTarget: string;\n  /**\n   * The time when the user interacted. This time will match the `timeStamp`\n   * value of the `event` dispatched.\n   */\n  eventTime: number;\n  /**\n   * The `type` of the `event` dispatched from the user interaction.\n   */\n  eventType: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to FID (or the\n   * polyfill entry in browsers that don't support Event Timing).\n   */\n  eventEntry: PerformanceEventTiming | FirstInputPolyfillEntry;\n  /**\n   * The loading state of the document at the time when the first interaction\n   * occurred (see `LoadState` for details). If the first interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long input delays.\n   */\n  loadState: LoadState;\n}\n```\n\n#### INP `attribution`:\n\n```ts\ninterface INPAttribution {\n  /**\n   * A selector identifying the element that the user interacted with for\n   * the event corresponding to INP. This element will be the `target` of the\n   * `event` dispatched.\n   */\n  eventTarget?: string;\n  /**\n   * The time when the user interacted for the event corresponding to INP.\n   * This time will match the `timeStamp` value of the `event` dispatched.\n   */\n  eventTime?: number;\n  /**\n   * The `type` of the `event` dispatched corresponding to INP.\n   */\n  eventType?: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to INP.\n   */\n  eventEntry?: PerformanceEventTiming;\n  /**\n   * The loading state of the document at the time when the even corresponding\n   * to INP occurred (see `LoadState` for details). If the interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long delays.\n   */\n  loadState?: LoadState;\n}\n```\n\n#### LCP `attribution`:\n\n```ts\ninterface LCPAttribution {\n  /**\n   * The element corresponding to the largest contentful paint for the page.\n   */\n  element?: string;\n  /**\n   * The URL (if applicable) of the LCP image resource. If the LCP element\n   * is a text node, this value will not be set.\n   */\n  url?: string;\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB). See\n   * [Optimize LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and when the browser starts loading the LCP\n   * resource (if there is one, otherwise 0). See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  resourceLoadDelay: number;\n  /**\n   * The total time it takes to load the LCP resource itself (if there is one,\n   * otherwise 0). See [Optimize LCP](https://web.dev/optimize-lcp/) for\n   * details.\n   */\n  resourceLoadTime: number;\n  /**\n   * The delta between when the LCP resource finishes loading until the LCP\n   * element is fully rendered. See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  elementRenderDelay: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues.\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n  /**\n   * The `resource` entry for the LCP resource (if applicable), which is useful\n   * for diagnosing resource load issues.\n   */\n  lcpResourceEntry?: PerformanceResourceTiming;\n  /**\n   * The `LargestContentfulPaint` entry corresponding to LCP.\n   */\n  lcpEntry?: LargestContentfulPaint;\n}\n```\n\n#### TTFB `attribution`:\n\n```ts\ninterface TTFBAttribution {\n  /**\n   * The total time from when the user initiates loading the page to when the\n   * DNS lookup begins. This includes redirects, service worker startup, and\n   * HTTP cache lookup times.\n   */\n  waitingTime: number;\n  /**\n   * The total time to resolve the DNS for the current request.\n   */\n  dnsTime: number;\n  /**\n   * The total time to create the connection to the requested domain.\n   */\n  connectionTime: number;\n  /**\n   * The time time from when the request was sent until the first byte of the\n   * response was received. This includes network time as well as server\n   * processing time.\n   */\n  requestTime: number;\n  /**\n   * The `PerformanceNavigationTiming` entry used to determine TTFB (or the\n   * polyfill entry in browsers that don't support Navigation Timing).\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium\n- `onFCP()`: Chromium, Firefox, Safari 14.1+\n- `onFID()`: Chromium, Firefox _(with [polyfill](#how-to-use-the-polyfill): Safari, Internet Explorer)_\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari 15+ _(with [polyfill](#how-to-use-the-polyfill): Safari 8+, Internet Explorer)_\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that\nmeasure the Web Vitals metrics, which means the limitations of those APIs will\nmostly apply to this library as well.\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/vitals-ga4/).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `callback` functions and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"b4b28b015eff3fa6dfaedb974b9269d7aa28b016","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.1.1-soft-navs-5","_nodeVersion":"16.15.1","_npmVersion":"8.13.0","dist":{"integrity":"sha512-dezhxkjSZaBYcFN7FPH5Umm0hBgG018rJjllZW2xkCPnGfguUMzFAbSCvl0ZtvBhR1F1K7k0huVLshyof8esaQ==","shasum":"82d231d8e3ebc8c561d94a4f5944f6a9207d202d","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.1.1-soft-navs-5.tgz","fileCount":146,"unpackedSize":428925,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQDk94T3kS4eL5zn9Qd0RfwgPcVjLf4FvqFr3eHsITDObgIhAMimdkwzt6vw4sDTNpUHadCbtQagte/zg69SEIjfbNw8"}],"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v4.10.10\r\nComment: https://openpgpjs.org\r\n\r\nwsFzBAEBCAAGBQJj509KACEJED1NWxICdlZqFiEECWMYAoorWMhJKdjhPU1b\r\nEgJ2VmrGWQ//c9eMBoiBRIJbG9oBXpUChSjf7LoWxuL3yc/BOXl9v9/W+DnC\r\nIPgcLyIJrfnm1n49m956NE3kHKy5E/JqzUV9elAtXnIk+KjDbr1qBJpfq2GO\r\nbbnmIV8u41xDmaK1iQa9U0+az4T65rAV53BkbRc2egjwhn3jWpQ+3KPp8iFj\r\nrTGHmz66b6q9QgCebBvKzAPsh7uCuUgAZRRqMqWtAlA+yvz3bU+H3GzAPat+\r\nHY8ja7cI1UuEmQy1+iLcQa/KNi9yHLoV7hLCZKiKsptm92PjNSAFY0i823PH\r\n1TTO8pjxmn2SNOwjOxbHghtpvXKAfjE9SdnvkZmyUTFWNbAhFvB6tZ8h3Ggy\r\nakOcvDP/7ZmRIUe8YcUNb4atmbGBAqbAJFRuxkt5dZ1qyGIpMffKtrqmEgts\r\nbJWCg0Exfu6VH14VljysW0oh9oy3Bvv3JA9jIl6GZSCILGQGYBEMGBIK31sx\r\nSe8fDR0i3vziUrk+U34Z8zqsfsDFU44Zrd2LArtm8AQ8p/ygZoFyTE4cFRIT\r\n7vyX+DK9ZQIpx0hYsv+AcX7v08eR2AvgOOcGPqntYH47GVIttJDvCTZOErJo\r\n821aS8ihPFO6OxuZJpBIyTT6kQt5LlmzK2w7COKRwrrfDI0PoXaed+XYC0dB\r\nAjQPNkTLbEdyGKu893zL1VYdV6aHKOeNPcw=\r\n=uv4Y\r\n-----END PGP SIGNATURE-----\r\n"},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.1.1-soft-navs-5_1676103498583_0.40349480330248566"},"_hasShrinkwrap":false},"3.3.0":{"name":"web-vitals","version":"3.3.0","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build test:unit -p -r test:e2e test:server","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","test:unit":"node --test test/unit/*test.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.21.0","@babel/preset-env":"^7.20.2","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.54.1","@typescript-eslint/parser":"^5.54.1","@wdio/cli":"^7.30.2","@wdio/local-runner":"^7.30.2","@wdio/mocha-framework":"^7.30.2","@wdio/selenium-standalone-service":"^7.30.2","@wdio/spec-reporter":"^7.30.2","body-parser":"^1.20.2","chromedriver":"^107.0.3","eslint":"^8.35.0","express":"^4.18.2","fs-extra":"^10.1.0","husky":"^8.0.3","lint-staged":"^13.1.2","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","prettier":"^2.8.4","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","selenium-standalone":"^8.3.0","typescript":"^4.9.5","wdio-chromedriver-service":"^8.1.1"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"gitHead":"676e166fd3f909e633c196a2b7996fd97677461f","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.3.0","_nodeVersion":"18.14.2","_npmVersion":"9.5.0","dist":{"integrity":"sha512-GZsEmJBNclIpViS/7QVOTr7Kbt4BgLeR7kQ5zCCtJVuiWsA+K6xTXaoEXssvl8yYFICEyNmA2Nr+vgBYTnS4bA==","shasum":"2e14bcbb3acf71d00c49519ab92cc517511476d5","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.3.0.tgz","fileCount":143,"unpackedSize":381297,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIG5gQSQeRv/VZYeagJarzsEJib224xgzLLCSexBXoMe8AiA/6tb26NOkEcH0oxw54Gu3q3uqNZ9RRCtcLSTYOjuJYw=="}],"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v4.10.10\r\nComment: https://openpgpjs.org\r\n\r\nwsFzBAEBCAAGBQJkCkmlACEJED1NWxICdlZqFiEECWMYAoorWMhJKdjhPU1b\r\nEgJ2VmrmoA/9F0eK130Xi+Pf9wiaPHEJpjP42UmMkSCWfrL9GO7nTCDdJtGL\r\nh2MS78f99Dp3l7eY0jAbBLSVy3/n/BarD1E1Zo1goAgc3jULMsYY91AUwCNf\r\nkfumxl+hMF2g2dq4ikLTMekHXJ97Xo12ZKYC2GeyrjEUX0NfGTdYPJrXNnR/\r\nlxN+0SH9wrbH00Z63S1nlhDifdYguMCcl/RkR1f6Y2XNBjqA0zxbUmGdZ+dY\r\nDFgduxalomIH8KCfjo+y8zmzlOwc69tAZhOCNr+W9yFcNSf8WC1NCBkPl+BY\r\n3aY4tlKvKaJoV14lT30lhUHWVY3qb77mKk2iMIgSNA//AprWUnAYhL1/Huka\r\nzNBhJ2m00aLDxEYWuNNfT9c1K5qv+UNmhXWBAHiS1VsBLpdLfInz4nhOQEKl\r\n1FQVnL9LM6H4P8x35WINnOCwby7lKLYBd2ovVHUaO0PBuAtDOn0kbGFVvDyl\r\nGgSX0yOzMXXIqq44X9FiyoeZenb3AzRi/mXayHIpAEa/GIs9SyWOiyCEmlrz\r\nFsAaR+CtR6tPYxU5O8fcPLoOhER99FkAYue+/tj+KYuzsqd+hOVTSSSvNlW9\r\nty+7h00I0PigD3uqiZCCgiWqbMlE9bQUiFQw9lSpXq37W5cDc6tBrJJBPpy0\r\nAC/EGv2zHreu7dzwImqvlmljXHk3b2xtLg4=\r\n=CIHs\r\n-----END PGP SIGNATURE-----\r\n"},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.3.0_1678395812732_0.9395039309168745"},"_hasShrinkwrap":false},"3.3.0-soft-navs-6":{"name":"web-vitals","version":"3.3.0-soft-navs-6","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build test:unit -p -r test:e2e test:server","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","test:unit":"node --test test/unit/*test.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.21.0","@babel/preset-env":"^7.20.2","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.54.1","@typescript-eslint/parser":"^5.54.1","@wdio/cli":"^7.30.2","@wdio/local-runner":"^7.30.2","@wdio/mocha-framework":"^7.30.2","@wdio/selenium-standalone-service":"^7.30.2","@wdio/spec-reporter":"^7.30.2","body-parser":"^1.20.2","chromedriver":"^107.0.3","eslint":"^8.35.0","express":"^4.18.2","fs-extra":"^10.1.0","husky":"^8.0.3","lint-staged":"^13.1.2","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","prettier":"^2.8.4","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","selenium-standalone":"^8.3.0","typescript":"^4.9.5","wdio-chromedriver-service":"^8.1.1"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Send attribution data](#send-attribution-data)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Build options](#build-options)\n  - [Which build is right for you?](#which-build-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n  - [Rating Thresholds](#rating-thresholds)\n  - [Attribution](#attribution)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1.5K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/vitals/) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/vitals/#core-web-vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/user-centric-performance-metrics/) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/cls/)\n- [First Input Delay (FID)](https://web.dev/fid/)\n- [Largest Contentful Paint (LCP)](https://web.dev/lcp/)\n\n### Other metrics\n\n- [Interaction to next Paint (INP)](https://web.dev/inp/) _(experimental)_\n- [First Contentful Paint (FCP)](https://web.dev/fcp/)\n- [Time to First Byte (TTFB)](https://web.dev/ttfb/)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\nThe `web-vitals` library uses the `buffered` flag for [PerformanceObserver](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver/observe), allowing it to access performance entries that occurred before the library was loaded.\n\nThis means you do not need to load this library early in order to get accurate performance data. In general, this library should be deferred until after other user-impacting code has loaded.\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are a few different builds of the `web-vitals` library, and how you load the library depends on which build you want to use.\n\nFor details on the difference between the builds, see <a href=\"#which-build-is-right-for-you\">which build is right for you</a>.\n\n**1. The \"standard\" build**\n\nTo load the \"standard\" build, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onFID, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functions were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"attribution-build\"><a>\n\n**2. The \"attribution\" build**\n\nMeasuring the Web Vitals scores for your real users is a great first step toward optimizing the user experience. But if your scores aren't _good_, the next step is to understand why they're not good and work to improve them.\n\nThe \"attribution\" build helps you do that by including additional diagnostic information with each metric to help you identify the root cause of poor performance as well as prioritize the most important things to fix.\n\nThe \"attribution\" build is slightly larger than the \"standard\" build (by about 600 bytes, brotli'd), so while the code size is still small, it's only recommended if you're actually using these features.\n\nTo load the \"attribution\" build, change any `import` statements that reference `web-vitals` to `web-vitals/attribution`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/attribution';\n```\n\nUsage for each of the imported function is identical to the standard build, but when importing from the attribution build, the [`Metric`](#metric) object will contain an additional [`attribution`](#metricwithattribution) property.\n\nSee [Send attribution data](#send-attribution-data) for usage examples, and the [`attribution` reference](#attribution) for details on what values are added for each metric.\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**3. The \"base+polyfill\" build**\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nLoading the \"base+polyfill\" build is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nIt's important that the code is inlined directly into the HTML. _Do not link to an external script file, as that will negatively affect performance:_\n\n```html\n<!-- GOOD -->\n<script>\n  // Inline code from `dist/polyfill.js` here\n</script>\n\n<!-- BAD! DO NOT DO! -->\n<script src=\"/path/to/polyfill.js\"></script>\n```\n\nAlso note that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com):\n\n_**Important!** The [unpkg.com](https://unpkg.com) CDN is shown here for example purposes only. `unpkg.com` is not affiliated with Google, and there are no guarantees that the URLs shown in these examples will continue to work in the future._\n\n**Load the \"standard\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals@3?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src = 'https://unpkg.com/web-vitals@3/dist/web-vitals.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n**Load the \"attribution\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {\n    onCLS,\n    onFID,\n    onLCP,\n  } from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"attribution\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src =\n      'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes a `callback` function that will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" build, but they will work with the \"attribution\" build as well.)_\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developer.chrome.com/docs/devtools/console/reference/#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID is not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS should be reported any time the [page's `visibilityState` changes to hidden](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/bfcache/).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onFID()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want the `callback` function to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each layout shift as it happens) by setting `reportAllChanges` to `true` in the optional, [configuration object](#reportopts) (second parameter).\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended) for measuring these metrics in production.\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, {reportAllChanges: true});\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonFID(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `callback` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Report metrics for soft navigations (experimental)\n\n_**Note:** this is experimental and subject to change._\n\nCurrently Core Web Vitals are only tracked for full page navigations, which can affect how [Single Page Applications](https://web.dev/vitals-spa-faq/) that use so called \"soft navigations\" to update the browser URL and history outside of the normal browser's handling of this. The Chrome team are experimenting with being able to [measure these soft navigations](https://github.com/WICG/soft-navigations) separately and report on Core Web Vitals separately for them.\n\nThis experimental support allows sites to measure how their Core Web Vitals might be measured differently should this happen.\n\nAt present a \"soft navigation\" is defined as happening after the following three things happen:\n\n- A user interaction occurs\n- The URL changes\n- Content is added to the DOM\n- Something is painted to screen.\n\nFor some sites, these heuristics may lead to false positives (that users would not really consider a \"navigation\"), or false negatives (where the user does consider a navigation to have happened despite not missing the above criteria). We welcome feedback at https://github.com/WICG/soft-navigations/issues on the heuristics, at https://crbug.com for bugs in the Chrome implementation, and on [https://github.com/GoogleChrome/web-vitals/pull/308](this pull request) for implementation issues with web-vitals.js.\n\n_**Note:** At this time it is not known if this experiment will be something we want to move forward with. Until such time, this support will likely remain in a separate branch of this project, rather than be included in any production builds. If we decide not to move forward with this, the support of this will likely be removed from this project since this library is intended to mirror the Core Web Vitals as much as possible._\n\nSome important points to note:\n\n- TTFB is reported as 0, and not the time of the first network call (if any) after the soft navigation.\n- FCP and LCP are the first and largest contentful paints after the soft navigation. Prior reported paint times will not be counted for these metrics, even though these elements may remain between soft navigations, and may be the first or largest contentful item.\n- FID is reset to measure the first interaction after the soft navigation.\n- INP is reset to measure only interactions after the the soft navigation.\n- CLS is reset to measure again separate to the first page.\n\n_**Note:** It is not known at this time whether soft navigations will be weighted the same as full navigations. No weighting is included in this library at present and metrics are reported in the same way as full page load metrics._\n\nThe metrics can be reported for Soft Navigations using the `reportSoftNavs: true` reporting option:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(console.log, {reportSoftNavs: true});\nonFID(console.log, {reportSoftNavs: true});\nonLCP(console.log, {reportSoftNavs: true});\n```\n\nNote that this will change the way the first page loads are measured as the metrics for the inital URL will be finalized once the first soft nav occurs. To measure both you need to register two callbacks:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(doTraditionalProcessing);\nonFID(doTraditionalProcessing);\nonLCP(doTraditionalProcessing);\n\nonCLS(doSoftNavProcessing, {reportSoftNavs: true});\nonFID(doSoftNavProcessing, {reportSoftNavs: true});\nonLCP(doSoftNavProcessing, {reportSoftNavs: true});\n```\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n    fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonFID(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique dimension value (in this case, the metric `id`, as shown in the examples below) on every metric instance that you send to Google Analytics, you can create a report yourself using the [Google Analytics Reporting API](https://developers.google.com/analytics/devguides/reporting) and any data visualization library you choose.\n\nAs an example of this, the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) is a free and open-source tool you can use to create visualizations of the Web Vitals data that you've sent to Google Analytics.\n\n[![web-vitals-report](https://user-images.githubusercontent.com/326742/101584324-3f9a0900-3992-11eb-8f2d-182f302fb67b.png)](https://github.com/GoogleChromeLabs/web-vitals-report)\n\nIn order to use the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) (or build your own custom reports using the API) you need to send your data to Google Analytics following one of the examples outlined below:\n\n#### Using `analytics.js`\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `ga()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/analyticsjs\n  ga('send', 'event', {\n    eventCategory: 'Web Vitals',\n    eventAction: name,\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    eventLabel: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    nonInteraction: true,\n    // Use `sendBeacon()` if the browser supports it.\n    transport: 'beacon',\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Universal Analytics)\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/gtagjs\n  gtag('event', name, {\n    event_category: 'Web Vitals',\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    event_label: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    value: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    non_interaction: true,\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Google Analytics 4)\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // metric_rating: 'good' | 'needs-improvement' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n### Send attribution data\n\nWhen using the [attribution build](#attribution-build), you can send additional data to help you debug _why_ the metric values are they way they are.\n\nThis example sends an additional `debug_target` param to Google Analytics, corresponding to the element most associated with each metric.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals/attribution';\n\nfunction sendToGoogleAnalytics({name, delta, value, id, attribution}) {\n  const eventParams = {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n  };\n\n  switch (name) {\n    case 'CLS':\n      eventParams.debug_target = attribution.largestShiftTarget;\n      break;\n    case 'FID':\n      eventParams.debug_target = attribution.eventTarget;\n      break;\n    case 'LCP':\n      eventParams.debug_target = attribution.element;\n      break;\n  }\n\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, eventParams);\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n_**Note:** this example relies on custom [event parameters](https://support.google.com/analytics/answer/11396839) in Google Analytics 4. For Universal Analytics the attribution data should be set using a [custom dimension](https://support.google.com/analytics/answer/2709828) rather than `debug_target` as shown above._\n\nSee [Debug performance in the field](https://web.dev/debug-performance-in-the-field/) for more information and examples.\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonFID(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n<a name=\"bundle-versions\"><a>\n\n## Build options\n\nThe `web-vitals` package includes builds for the \"standard\", \"attribution\", and \"base+polyfill\" ([deprecated](https://github.com/GoogleChrome/web-vitals/issues/238)) builds, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the builds distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any attribution features.</p>\n      This is the \"standard\" build and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.cjs</code></td>\n    <td><code>pgk.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.attribution.js</code></td>\n    <td>--</td>\n    <td>\n      An ES module version of all metric functions that includes <a href=\"#attribution-build\">attribution</a> features.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.iife.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An IIFE version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code>, <code>web-vitals.base.umd.cjs</code>, or <code>web-vitals.base.iife.js</code> (it will not work with any script that doesn't have \"base\" in the filename).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n<a name=\"which-build-is-right-for-you\"><a>\n\n### Which build is right for you?\n\nMost developers will generally want to use \"standard\" build (via either the ES module or UMD version, depending on your bundler/build system), as it's the easiest to use out of the box and integrate into existing tools.\n\nHowever, if you'd lke to collect additional debug information to help you diagnose performance bottlenecks based on real-user issues, use the [\"attribution\" build](#attribution-build).\n\nFor guidance on how to collect and use real-user data to debug performance issues, see [Debug performance in the field](https://web.dev/debug-performance-in-the-field/).\n\n### How the polyfill works\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nThe `polyfill.js` script adds event listeners (to track FID cross-browser), and it records initial page visibility state as well as the timestamp of the first visibility change to hidden (to improve the accuracy of CLS, FCP, LCP, and FID). It also polyfills the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) in browsers that only support the original (now deprecated) [Navigation Timing API](https://www.w3.org/TR/navigation-timing/).\n\nIn order for the polyfill to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" build of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" build, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  /**\n   * The name of the metric (in acronym form).\n   */\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  /**\n   * The current value of the metric.\n   */\n  value: number;\n\n  /**\n   * The rating as to whether the metric value is within the \"good\",\n   * \"needs improvement\", or \"poor\" thresholds of the metric.\n   */\n  rating: 'good' | 'needs-improvement' | 'poor';\n\n  /**\n   * The delta between the current value and the last-reported value.\n   * On the first report, `delta` and `value` will always be the same.\n   */\n  delta: number;\n\n  /**\n   * A unique ID representing this particular metric instance. This ID can\n   * be used by an analytics tool to dedupe multiple values sent for the same\n   * metric instance, or to group multiple deltas together and calculate a\n   * total. It can also be used to differentiate multiple different metric\n   * instances sent from the same page, which can happen if the page is\n   * restored from the back/forward cache (in that case new metrics object\n   * get created).\n   */\n  id: string;\n\n  /**\n   * Any performance entries relevant to the metric value calculation.\n   * The array may also be empty if the metric value was not based on any\n   * entries (e.g. a CLS value of 0 given no layout shifts).\n   */\n  entries: (\n    | PerformanceEntry\n    | LayoutShift\n    | FirstInputPolyfillEntry\n    | NavigationTimingPolyfillEntry\n  )[];\n\n  /**\n   * The type of navigation.\n   *\n   * This will be the value returned by the Navigation Timing API (or\n   * `undefined` if the browser doesn't support that API), with the following\n   * exceptions:\n   * - 'back-forward-cache': for pages that are restored from the bfcache.\n   * - 'prerender': for pages that were prerendered.\n   * - 'restore': for pages that were discarded by the browser and then\n   * restored by the user.\n   */\n  navigationType:\n    | 'navigate'\n    | 'reload'\n    | 'back-forward'\n    | 'back-forward-cache'\n    | 'prerender'\n    | 'restore'\n    | 'soft-navigation';\n\n  /**\n   * The navigatonId the metric happened for. This is particularly relevent for soft navigations where\n   * the metric may be reported for a previous URL.\n   *\n   * The navigationId can be mapped to the URL with the following:\n   *   1 (or empty) - performance.getEntriesByType('navigation')[0]?.name\n   *   > 1 - performance.getEntriesByType('soft-navigation')[navigationId - 2]?.name\n   */\n  navigatonId: number;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetric`](/src/types/cls.ts#:~:text=interface%20CLSMetric)\n- [`FCPMetric`](/src/types/fcp.ts#:~:text=interface%20FCPMetric)\n- [`FIDMetric`](/src/types/fid.ts#:~:text=interface%20FIDMetric)\n- [`INPMetric`](/src/types/inp.ts#:~:text=interface%20INPMetric)\n- [`LCPMetric`](/src/types/lcp.ts#:~:text=interface%20LCPMetric)\n- [`TTFBMetric`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetric)\n\n#### `MetricWithAttribution`\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n```ts\ninterface MetricWithAttribution extends Metric {\n  /**\n   * An object containing potentially-helpful debugging information that\n   * can be sent along with the metric value for the current page visit in\n   * order to help identify issues happening to real-users in the field.\n   */\n  attribution: {[key: string]: unknown};\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetricWithAttribution`](/src/types/cls.ts#:~:text=interface%20CLSMetricWithAttribution)\n- [`FCPMetricWithAttribution`](/src/types/fcp.ts#:~:text=interface%20FCPMetricWithAttribution)\n- [`FIDMetricWithAttribution`](/src/types/fid.ts#:~:text=interface%20FIDMetricWithAttribution)\n- [`INPMetricWithAttribution`](/src/types/inp.ts#:~:text=interface%20INPMetricWithAttribution)\n- [`LCPMetricWithAttribution`](/src/types/lcp.ts#:~:text=interface%20LCPMetricWithAttribution)\n- [`TTFBMetricWithAttribution`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetricWithAttribution)\n\n#### `MetricRatingThresholds`\n\nThe thresholds of metric's \"good\", \"needs improvement\", and \"poor\" ratings.\n\n- Metric values up to and including [0] are rated \"good\"\n- Metric values up to and including [1] are rated \"needs improvement\"\n- Metric values above [1] are \"poor\"\n\n| Metric value    | Rating              |\n| --------------- | ------------------- |\n| ≦ [0]           | \"good\"              |\n| > [0] and ≦ [1] | \"needs improvement\" |\n| > [1]           | \"poor\"              |\n\n```ts\nexport type MetricRatingThresholds = [number, number];\n```\n\n_See also [Rating Thresholds](#rating-thresholds)._\n\n#### `ReportCallback`\n\n```ts\ninterface ReportCallback {\n  (metric: Metric): void;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSReportCallback`](/src/types/cls.ts#:~:text=interface%20CLSReportCallback)\n- [`FCPReportCallback`](/src/types/fcp.ts#:~:text=interface%20FCPReportCallback)\n- [`FIDReportCallback`](/src/types/fid.ts#:~:text=interface%20FIDReportCallback)\n- [`INPReportCallback`](/src/types/inp.ts#:~:text=interface%20INPReportCallback)\n- [`LCPReportCallback`](/src/types/lcp.ts#:~:text=interface%20LCPReportCallback)\n- [`TTFBReportCallback`](/src/types/ttfb.ts#:~:text=interface%20TTFBReportCallback)\n\n#### `ReportOpts`\n\n```ts\ninterface ReportOpts {\n  reportAllChanges?: boolean;\n  durationThreshold?: number;\n  reportSoftNavs?: boolean;\n}\n```\n\n#### `LoadState`\n\nThe `LoadState` type is used in several of the metric [attribution objects](#attribution).\n\n```ts\n/**\n * The loading state of the document. Note: this value is similar to\n * `document.readyState` but it subdivides the \"interactive\" state into the\n * time before and after the DOMContentLoaded event fires.\n *\n * State descriptions:\n * - `loading`: the initial document response has not yet been fully downloaded\n *   and parsed. This is equivalent to the corresponding `readyState` value.\n * - `dom-interactive`: the document has been fully loaded and parsed, but\n *   scripts may not have yet finished loading and executing.\n * - `dom-content-loaded`: the document is fully loaded and parsed, and all\n *   scripts (except `async` scripts) have loaded and finished executing.\n * - `complete`: the document and all of its sub-resources have finished\n *   loading. This is equivalent to the corresponding `readyState` value.\n */\ntype LoadState =\n  | 'loading'\n  | 'dom-interactive'\n  | 'dom-content-loaded'\n  | 'complete';\n```\n\n#### `FirstInputPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't natively support the Event Timing API), the `metric.entries` reported by `onFID()` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<\n  PerformanceEventTiming,\n  'processingEnd' | 'toJSON'\n>;\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface), the `metric.entries` reported by `onTTFB()` will contain an object that polyfills the `PerformanceNavigationTiming` entry using timings from the legacy `performance.timing` interface:\n\n```ts\ntype NavigationTimingPolyfillEntry = Omit<\n  PerformanceNavigationTiming,\n  | 'initiatorType'\n  | 'nextHopProtocol'\n  | 'redirectCount'\n  | 'transferSize'\n  | 'encodedBodySize'\n  | 'decodedBodySize'\n  | 'type'\n> & {\n  type: PerformanceNavigationTiming['type'];\n};\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n  firstHiddenTime: number;\n}\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (callback: CLSReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [CLS](https://web.dev/cls/) value for the current page and calls the `callback` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/cls/#layout-shift-score)).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (callback: FCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FCP](https://web.dev/fcp/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n```ts\ntype onFID = (callback: FIDReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FID](https://web.dev/fid/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (callback: INPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [INP](https://web.dev/inp/) value for the current page and calls the `callback` function once the value is ready, along with the `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nA custom `durationThreshold` [configuration option](#reportopts) can optionally be passed to control what `event-timing` entries are considered for INP reporting. The default threshold is `40`, which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended [good](https://web.dev/inp/#what-is-a-good-inp-score) threshold).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (callback: LCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [LCP](https://web.dev/lcp/) value for the current page and calls the `callback` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (callback: TTFBReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [TTFB](https://web.dev/time-to-first-byte/) value for the current page and calls the `callback` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `callback` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it includes time spent on DNS lookup, connection negotiation, network latency, and server processing time.\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n### Rating Thresholds:\n\nThe thresholds of each metric's \"good\", \"needs improvement\", and \"poor\" ratings are available as [`MetricRatingThresholds`](#metricratingthresholds).\n\nExample:\n\n```ts\nimport {CLSThresholds, FIDThresholds, LCPThresholds} from 'web-vitals';\n\nconsole.log(CLSThresholds); // [ 0.1, 0.25 ]\nconsole.log(FIDThresholds); // [ 100, 300 ]\nconsole.log(LCPThresholds); // [ 2500, 4000 ]\n```\n\n_**Note:** It's typically not necessary (or recommended) to manually calculate metric value ratings using these thresholds. Use the [`Metric['rating']`](#metric) supplied by the [`ReportCallback`](#reportcallback) functions instead._\n\n### Attribution:\n\nThe following objects contain potentially-helpful debugging information that can be sent along with the metric values for the current page visit in order to help identify issues happening to real-users in the field.\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n#### CLS `attribution`:\n\n```ts\ninterface CLSAttribution {\n  /**\n   * A selector identifying the first element (in document order) that\n   * shifted when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTarget?: string;\n  /**\n   * The time when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTime?: DOMHighResTimeStamp;\n  /**\n   * The layout shift score of the single largest layout shift contributing to\n   * the page's CLS score.\n   */\n  largestShiftValue?: number;\n  /**\n   * The `LayoutShiftEntry` representing the single largest layout shift\n   * contributing to the page's CLS score. (Useful when you need more than just\n   * `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftEntry?: LayoutShift;\n  /**\n   * The first element source (in document order) among the `sources` list\n   * of the `largestShiftEntry` object. (Also useful when you need more than\n   * just `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftSource?: LayoutShiftAttribution;\n  /**\n   * The loading state of the document at the time when the largest layout\n   * shift contribution to the page's CLS score occurred (see `LoadState`\n   * for details).\n   */\n  loadState?: LoadState;\n}\n```\n\n#### FCP `attribution`:\n\n```ts\ninterface FCPAttribution {\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB).\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and the first contentful paint (FCP).\n   */\n  firstByteToFCP: number;\n  /**\n   * The loading state of the document at the time when FCP `occurred (see\n   * `LoadState` for details). Ideally, documents can paint before they finish\n   * loading (e.g. the `loading` or `dom-interactive` phases).\n   */\n  loadState: LoadState;\n  /**\n   * The `PerformancePaintTiming` entry corresponding to FCP.\n   */\n  fcpEntry?: PerformancePaintTiming;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n#### FID `attribution`:\n\n```ts\ninterface FIDAttribution {\n  /**\n   * A selector identifying the element that the user interacted with. This\n   * element will be the `target` of the `event` dispatched.\n   */\n  eventTarget: string;\n  /**\n   * The time when the user interacted. This time will match the `timeStamp`\n   * value of the `event` dispatched.\n   */\n  eventTime: number;\n  /**\n   * The `type` of the `event` dispatched from the user interaction.\n   */\n  eventType: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to FID (or the\n   * polyfill entry in browsers that don't support Event Timing).\n   */\n  eventEntry: PerformanceEventTiming | FirstInputPolyfillEntry;\n  /**\n   * The loading state of the document at the time when the first interaction\n   * occurred (see `LoadState` for details). If the first interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long input delays.\n   */\n  loadState: LoadState;\n}\n```\n\n#### INP `attribution`:\n\n```ts\ninterface INPAttribution {\n  /**\n   * A selector identifying the element that the user interacted with for\n   * the event corresponding to INP. This element will be the `target` of the\n   * `event` dispatched.\n   */\n  eventTarget?: string;\n  /**\n   * The time when the user interacted for the event corresponding to INP.\n   * This time will match the `timeStamp` value of the `event` dispatched.\n   */\n  eventTime?: number;\n  /**\n   * The `type` of the `event` dispatched corresponding to INP.\n   */\n  eventType?: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to INP.\n   */\n  eventEntry?: PerformanceEventTiming;\n  /**\n   * The loading state of the document at the time when the even corresponding\n   * to INP occurred (see `LoadState` for details). If the interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long delays.\n   */\n  loadState?: LoadState;\n}\n```\n\n#### LCP `attribution`:\n\n```ts\ninterface LCPAttribution {\n  /**\n   * The element corresponding to the largest contentful paint for the page.\n   */\n  element?: string;\n  /**\n   * The URL (if applicable) of the LCP image resource. If the LCP element\n   * is a text node, this value will not be set.\n   */\n  url?: string;\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB). See\n   * [Optimize LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and when the browser starts loading the LCP\n   * resource (if there is one, otherwise 0). See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  resourceLoadDelay: number;\n  /**\n   * The total time it takes to load the LCP resource itself (if there is one,\n   * otherwise 0). See [Optimize LCP](https://web.dev/optimize-lcp/) for\n   * details.\n   */\n  resourceLoadTime: number;\n  /**\n   * The delta between when the LCP resource finishes loading until the LCP\n   * element is fully rendered. See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  elementRenderDelay: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n  /**\n   * The `resource` entry for the LCP resource (if applicable), which is useful\n   * for diagnosing resource load issues.\n   */\n  lcpResourceEntry?: PerformanceResourceTiming;\n  /**\n   * The `LargestContentfulPaint` entry corresponding to LCP.\n   */\n  lcpEntry?: LargestContentfulPaint;\n}\n```\n\n#### TTFB `attribution`:\n\n```ts\ninterface TTFBAttribution {\n  /**\n   * The total time from when the user initiates loading the page to when the\n   * DNS lookup begins. This includes redirects, service worker startup, and\n   * HTTP cache lookup times.\n   */\n  waitingTime: number;\n  /**\n   * The total time to resolve the DNS for the current request.\n   */\n  dnsTime: number;\n  /**\n   * The total time to create the connection to the requested domain.\n   */\n  connectionTime: number;\n  /**\n   * The time time from when the request was sent until the first byte of the\n   * response was received. This includes network time as well as server\n   * processing time.\n   */\n  requestTime: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium\n- `onFCP()`: Chromium, Firefox, Safari 14.1+\n- `onFID()`: Chromium, Firefox _(with [polyfill](#how-to-use-the-polyfill): Safari, Internet Explorer)_\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari 15+ _(with [polyfill](#how-to-use-the-polyfill): Safari 8+, Internet Explorer)_\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that measure the Web Vitals metrics, which means the limitations of those APIs will mostly apply to this library as well. More details on these limitations is available in [this blog post](https://web.dev/crux-and-rum-differences/).\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/vitals-ga4/).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `callback` functions and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"99d2b9b39611d24d99277c90e45f4782cc0b35f1","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.3.0-soft-navs-6","_nodeVersion":"18.14.2","_npmVersion":"9.5.0","dist":{"integrity":"sha512-ZwElZNWSXtdBtz09u79Sp1BBcJZJ7nM61jHZytBtGKISfSZ88M3geJlNF62U0dXEGhrHfY6/r3m+6/WD3rq0TA==","shasum":"96a75c207aae775d19ed428b54ceab6228a80bf0","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.3.0-soft-navs-6.tgz","fileCount":146,"unpackedSize":435184,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCrn3IDSpfRfKKG9wzfo3UZD7yfD2EYERyRIxHedUOxmQIhALQKXvA2T0PHlA4vlrKbTXPbWX/iEdOlH3VlnbGysgvI"}],"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v4.10.10\r\nComment: https://openpgpjs.org\r\n\r\nwsFzBAEBCAAGBQJkCktHACEJED1NWxICdlZqFiEECWMYAoorWMhJKdjhPU1b\r\nEgJ2Vmo5lhAAkc6Bqu9mjs/WjWQ2SeK9eWep6E98sBfw1dkUnwZ4MPNBWDz/\r\nZq6mA4NJrJCwwpBw/aFz0GvOjFmDpOXhNSjm1D5/jYf9j1dLvPvvjkpLQBu7\r\n/pJ0X3f+iXm3sM6TIAwddAqW4/9ajIW+EWWPyAzeMS1y4eSTmbvFOttHedUh\r\nAErgI3eo7iAhRcC/DUf7I6H8dQsbihPuWlax9gMD/stQLYuQndPS6wzwMObW\r\n9y8gCFFsgZFo3Hcw8WUCNbvlt5Fwez3dSBruQT7spcSK1FuAwPu0pPOPwM8t\r\nrHOqaINXHVk8znJ3o/Sn0lrWZrB8xyCSvbjIV30O4SalzjIHbJlb2zNZx4q/\r\nJw3iYNQ48IrnJ3dpkKdz+Y5HT1Z4SYZwVSS7mYCcSHwld9/THr6mQr0A4UNM\r\noBJlap/w+25t0MwzTu3v1P4Apqfyf3cUG3IPiQvHYLAN2vVvex3qHNXhvwkc\r\nhCY2DdbOVyjOoWZ86FgshyjKVaR/sSxr19z7NUA+YHrya7cz4sL/cE/vgXb2\r\nTChK1kPqfbSAi9YtTv2IflsnnE9iAfoxNpWtQmZZGBvuM+95F95t/YtjU4jv\r\nPAPPSkYxTbL9gRHrdXdIEGGUNeaVlyeEhFDUHPLlkiPQVtMp2gp2WXOXtHlR\r\nl8QcNmDYVfO72e7ieH89mkctPsYBzG4UsTg=\r\n=+hog\r\n-----END PGP SIGNATURE-----\r\n"},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.3.0-soft-navs-6_1678396231059_0.7775542905916895"},"_hasShrinkwrap":false},"3.3.1":{"name":"web-vitals","version":"3.3.1","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build test:unit -p -r test:e2e test:server","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","test:unit":"node --test test/unit/*test.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.21.0","@babel/preset-env":"^7.20.2","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.54.1","@typescript-eslint/parser":"^5.54.1","@wdio/cli":"^7.30.2","@wdio/local-runner":"^7.30.2","@wdio/mocha-framework":"^7.30.2","@wdio/selenium-standalone-service":"^7.30.2","@wdio/spec-reporter":"^7.30.2","body-parser":"^1.20.2","chromedriver":"^107.0.3","eslint":"^8.35.0","express":"^4.18.2","fs-extra":"^10.1.0","husky":"^8.0.3","lint-staged":"^13.1.2","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","prettier":"^2.8.4","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","selenium-standalone":"^8.3.0","typescript":"^4.9.5","wdio-chromedriver-service":"^8.1.1"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"gitHead":"e4460bfff17e68448f69435187c1a8e7d38024e9","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.3.1","_nodeVersion":"18.14.2","_npmVersion":"9.5.0","dist":{"integrity":"sha512-LTfY5GjcY3ngFzNsYFSYL+AmVmlWrzPTUxSMDis2rZbf+SzT7HH3NH4Y/l45XOlrAIunOBeURN9qtBHkRskAiA==","shasum":"f80e4fd01784476c023c8b2c4219075bbe96f64d","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.3.1.tgz","fileCount":143,"unpackedSize":382419,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIFlOXcyiPWyyHzWf2CHejf2VBw1+s9cTzSOoVltN84xZAiAHgfDCKWltXeD1k+Rzo7TcEunccZIhrH2lTmeuhhjqsQ=="}],"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v4.10.10\r\nComment: https://openpgpjs.org\r\n\r\nwsFzBAEBCAAGBQJkLA0jACEJED1NWxICdlZqFiEECWMYAoorWMhJKdjhPU1b\r\nEgJ2VmrrNw/+O0sn+7jK9LwuCgpKFeafq8uqHQbLl1D4uyhW3yH8Ggi6HZhk\r\ng7hNHQ4yx3HF1nflWxG1VTbFWWjFAsGOY+pQqHrmHlnCG97jvZWZxLLGJoe/\r\nUPu/o8hb0+HIho+RbZwsUMGuAblZ/XvV+slitBznTaUqsTUab5e1qiF81F75\r\nGMb/3uYVkAuOc7r+5xRWYakAuLsT6upPYU8OOmB5GqI3meZMiA3JcWZiT+ow\r\nQL+vrGTD2k8MXFcWAUFjhrSc06kRzc19gv4l2tL6c4DQu1CfmvSvzpDI+DFW\r\ngX9iJkBezrB6XRGB7sq6X5dlZMUIt837JiBqhXvGEDn5rIoVQsiprfrDvR6K\r\nU8UFeXyiNWZQvPZJdJb4GMkWT+TWXH2gkG0Gm+dWtcG4mlD1WE67OPsKak1b\r\nFkZGhUGg0CCZM1v5ORBuOOvezhPY5kFUulYxcLyK2TdZW65akCG7+D7853VE\r\nToK4pE4QNXRG0CEmclKKWfqxz1I1FLSvWtvke5XRZ2bwXUhsBBuXkYHjpQhS\r\nMoinZ/DgezzWQm6ITt/stMdexWQXF7H/ioXvcMxV4FB0QvKi6HGVhn5lvOQa\r\nw5D0hbyR7hHNFtfU4/ZKuDHcfxEx3vjWO3IKAByxo1OyfpVYzTOncKgNRtQg\r\nz6IFb/mnKNIZphd+mxWqNdwIUhhaE9pAfm8=\r\n=URH+\r\n-----END PGP SIGNATURE-----\r\n"},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.3.1_1680608547157_0.3028254483424222"},"_hasShrinkwrap":false},"3.3.1-soft-navs-7":{"name":"web-vitals","version":"3.3.1-soft-navs-7","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build test:unit -p -r test:e2e test:server","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","test:unit":"node --test test/unit/*test.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.21.0","@babel/preset-env":"^7.20.2","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.54.1","@typescript-eslint/parser":"^5.54.1","@wdio/cli":"^7.30.2","@wdio/local-runner":"^7.30.2","@wdio/mocha-framework":"^7.30.2","@wdio/selenium-standalone-service":"^7.30.2","@wdio/spec-reporter":"^7.30.2","body-parser":"^1.20.2","chromedriver":"^107.0.3","eslint":"^8.35.0","express":"^4.18.2","fs-extra":"^10.1.0","husky":"^8.0.3","lint-staged":"^13.1.2","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","prettier":"^2.8.4","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","selenium-standalone":"^8.3.0","typescript":"^4.9.5","wdio-chromedriver-service":"^8.1.1"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Send attribution data](#send-attribution-data)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Build options](#build-options)\n  - [Which build is right for you?](#which-build-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n  - [Rating Thresholds](#rating-thresholds)\n  - [Attribution](#attribution)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1.5K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/vitals/) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/vitals/#core-web-vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/user-centric-performance-metrics/) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/cls/)\n- [First Input Delay (FID)](https://web.dev/fid/)\n- [Largest Contentful Paint (LCP)](https://web.dev/lcp/)\n\n### Other metrics\n\n- [Interaction to next Paint (INP)](https://web.dev/inp/) _(experimental)_\n- [First Contentful Paint (FCP)](https://web.dev/fcp/)\n- [Time to First Byte (TTFB)](https://web.dev/ttfb/)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\nThe `web-vitals` library uses the `buffered` flag for [PerformanceObserver](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver/observe), allowing it to access performance entries that occurred before the library was loaded.\n\nThis means you do not need to load this library early in order to get accurate performance data. In general, this library should be deferred until after other user-impacting code has loaded.\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are a few different builds of the `web-vitals` library, and how you load the library depends on which build you want to use.\n\nFor details on the difference between the builds, see <a href=\"#which-build-is-right-for-you\">which build is right for you</a>.\n\n**1. The \"standard\" build**\n\nTo load the \"standard\" build, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onFID, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functions were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"attribution-build\"><a>\n\n**2. The \"attribution\" build**\n\nMeasuring the Web Vitals scores for your real users is a great first step toward optimizing the user experience. But if your scores aren't _good_, the next step is to understand why they're not good and work to improve them.\n\nThe \"attribution\" build helps you do that by including additional diagnostic information with each metric to help you identify the root cause of poor performance as well as prioritize the most important things to fix.\n\nThe \"attribution\" build is slightly larger than the \"standard\" build (by about 600 bytes, brotli'd), so while the code size is still small, it's only recommended if you're actually using these features.\n\nTo load the \"attribution\" build, change any `import` statements that reference `web-vitals` to `web-vitals/attribution`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/attribution';\n```\n\nUsage for each of the imported function is identical to the standard build, but when importing from the attribution build, the [`Metric`](#metric) object will contain an additional [`attribution`](#metricwithattribution) property.\n\nSee [Send attribution data](#send-attribution-data) for usage examples, and the [`attribution` reference](#attribution) for details on what values are added for each metric.\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**3. The \"base+polyfill\" build**\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nLoading the \"base+polyfill\" build is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nIt's important that the code is inlined directly into the HTML. _Do not link to an external script file, as that will negatively affect performance:_\n\n```html\n<!-- GOOD -->\n<script>\n  // Inline code from `dist/polyfill.js` here\n</script>\n\n<!-- BAD! DO NOT DO! -->\n<script src=\"/path/to/polyfill.js\"></script>\n```\n\nAlso note that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com):\n\n_**Important!** The [unpkg.com](https://unpkg.com) CDN is shown here for example purposes only. `unpkg.com` is not affiliated with Google, and there are no guarantees that the URLs shown in these examples will continue to work in the future._\n\n**Load the \"standard\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals@3?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src = 'https://unpkg.com/web-vitals@3/dist/web-vitals.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n**Load the \"attribution\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {\n    onCLS,\n    onFID,\n    onLCP,\n  } from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"attribution\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src =\n      'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes a `callback` function that will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" build, but they will work with the \"attribution\" build as well.)_\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developer.chrome.com/docs/devtools/console/reference/#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID is not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS should be reported any time the [page's `visibilityState` changes to hidden](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/bfcache/).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onFID()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want the `callback` function to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each layout shift as it happens) by setting `reportAllChanges` to `true` in the optional, [configuration object](#reportopts) (second parameter).\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended) for measuring these metrics in production.\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, {reportAllChanges: true});\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonFID(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `callback` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Report metrics for soft navigations (experimental)\n\n_**Note:** this is experimental and subject to change._\n\nCurrently Core Web Vitals are only tracked for full page navigations, which can affect how [Single Page Applications](https://web.dev/vitals-spa-faq/) that use so called \"soft navigations\" to update the browser URL and history outside of the normal browser's handling of this. The Chrome team are experimenting with being able to [measure these soft navigations](https://github.com/WICG/soft-navigations) separately and report on Core Web Vitals separately for them.\n\nThis experimental support allows sites to measure how their Core Web Vitals might be measured differently should this happen.\n\nAt present a \"soft navigation\" is defined as happening after the following three things happen:\n\n- A user interaction occurs\n- The URL changes\n- Content is added to the DOM\n- Something is painted to screen.\n\nFor some sites, these heuristics may lead to false positives (that users would not really consider a \"navigation\"), or false negatives (where the user does consider a navigation to have happened despite not missing the above criteria). We welcome feedback at https://github.com/WICG/soft-navigations/issues on the heuristics, at https://crbug.com for bugs in the Chrome implementation, and on [https://github.com/GoogleChrome/web-vitals/pull/308](this pull request) for implementation issues with web-vitals.js.\n\n_**Note:** At this time it is not known if this experiment will be something we want to move forward with. Until such time, this support will likely remain in a separate branch of this project, rather than be included in any production builds. If we decide not to move forward with this, the support of this will likely be removed from this project since this library is intended to mirror the Core Web Vitals as much as possible._\n\nSome important points to note:\n\n- TTFB is reported as 0, and not the time of the first network call (if any) after the soft navigation.\n- FCP and LCP are the first and largest contentful paints after the soft navigation. Prior reported paint times will not be counted for these metrics, even though these elements may remain between soft navigations, and may be the first or largest contentful item.\n- FID is reset to measure the first interaction after the soft navigation.\n- INP is reset to measure only interactions after the the soft navigation.\n- CLS is reset to measure again separate to the first page.\n\n_**Note:** It is not known at this time whether soft navigations will be weighted the same as full navigations. No weighting is included in this library at present and metrics are reported in the same way as full page load metrics._\n\nThe metrics can be reported for Soft Navigations using the `reportSoftNavs: true` reporting option:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(console.log, {reportSoftNavs: true});\nonFID(console.log, {reportSoftNavs: true});\nonLCP(console.log, {reportSoftNavs: true});\n```\n\nNote that this will change the way the first page loads are measured as the metrics for the inital URL will be finalized once the first soft nav occurs. To measure both you need to register two callbacks:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(doTraditionalProcessing);\nonFID(doTraditionalProcessing);\nonLCP(doTraditionalProcessing);\n\nonCLS(doSoftNavProcessing, {reportSoftNavs: true});\nonFID(doSoftNavProcessing, {reportSoftNavs: true});\nonLCP(doSoftNavProcessing, {reportSoftNavs: true});\n```\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n    fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonFID(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique dimension value (in this case, the metric `id`, as shown in the examples below) on every metric instance that you send to Google Analytics, you can create a report yourself using the [Google Analytics Reporting API](https://developers.google.com/analytics/devguides/reporting) and any data visualization library you choose.\n\nAs an example of this, the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) is a free and open-source tool you can use to create visualizations of the Web Vitals data that you've sent to Google Analytics.\n\n[![web-vitals-report](https://user-images.githubusercontent.com/326742/101584324-3f9a0900-3992-11eb-8f2d-182f302fb67b.png)](https://github.com/GoogleChromeLabs/web-vitals-report)\n\nIn order to use the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) (or build your own custom reports using the API) you need to send your data to Google Analytics following one of the examples outlined below:\n\n#### Using `analytics.js`\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `ga()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/analyticsjs\n  ga('send', 'event', {\n    eventCategory: 'Web Vitals',\n    eventAction: name,\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    eventLabel: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    nonInteraction: true,\n    // Use `sendBeacon()` if the browser supports it.\n    transport: 'beacon',\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Universal Analytics)\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/gtagjs\n  gtag('event', name, {\n    event_category: 'Web Vitals',\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    event_label: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    value: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    non_interaction: true,\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Google Analytics 4)\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // metric_rating: 'good' | 'needs-improvement' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n### Send attribution data\n\nWhen using the [attribution build](#attribution-build), you can send additional data to help you debug _why_ the metric values are they way they are.\n\nThis example sends an additional `debug_target` param to Google Analytics, corresponding to the element most associated with each metric.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals/attribution';\n\nfunction sendToGoogleAnalytics({name, delta, value, id, attribution}) {\n  const eventParams = {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n  };\n\n  switch (name) {\n    case 'CLS':\n      eventParams.debug_target = attribution.largestShiftTarget;\n      break;\n    case 'FID':\n      eventParams.debug_target = attribution.eventTarget;\n      break;\n    case 'LCP':\n      eventParams.debug_target = attribution.element;\n      break;\n  }\n\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, eventParams);\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n_**Note:** this example relies on custom [event parameters](https://support.google.com/analytics/answer/11396839) in Google Analytics 4. For Universal Analytics the attribution data should be set using a [custom dimension](https://support.google.com/analytics/answer/2709828) rather than `debug_target` as shown above._\n\nSee [Debug performance in the field](https://web.dev/debug-performance-in-the-field/) for more information and examples.\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonFID(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n<a name=\"bundle-versions\"><a>\n\n## Build options\n\nThe `web-vitals` package includes builds for the \"standard\", \"attribution\", and \"base+polyfill\" ([deprecated](https://github.com/GoogleChrome/web-vitals/issues/238)) builds, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the builds distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any attribution features.</p>\n      This is the \"standard\" build and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.cjs</code></td>\n    <td><code>pgk.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.attribution.js</code></td>\n    <td>--</td>\n    <td>\n      An ES module version of all metric functions that includes <a href=\"#attribution-build\">attribution</a> features.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.iife.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An IIFE version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code>, <code>web-vitals.base.umd.cjs</code>, or <code>web-vitals.base.iife.js</code> (it will not work with any script that doesn't have \"base\" in the filename).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n<a name=\"which-build-is-right-for-you\"><a>\n\n### Which build is right for you?\n\nMost developers will generally want to use \"standard\" build (via either the ES module or UMD version, depending on your bundler/build system), as it's the easiest to use out of the box and integrate into existing tools.\n\nHowever, if you'd lke to collect additional debug information to help you diagnose performance bottlenecks based on real-user issues, use the [\"attribution\" build](#attribution-build).\n\nFor guidance on how to collect and use real-user data to debug performance issues, see [Debug performance in the field](https://web.dev/debug-performance-in-the-field/).\n\n### How the polyfill works\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nThe `polyfill.js` script adds event listeners (to track FID cross-browser), and it records initial page visibility state as well as the timestamp of the first visibility change to hidden (to improve the accuracy of CLS, FCP, LCP, and FID). It also polyfills the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) in browsers that only support the original (now deprecated) [Navigation Timing API](https://www.w3.org/TR/navigation-timing/).\n\nIn order for the polyfill to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" build of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" build, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  /**\n   * The name of the metric (in acronym form).\n   */\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  /**\n   * The current value of the metric.\n   */\n  value: number;\n\n  /**\n   * The rating as to whether the metric value is within the \"good\",\n   * \"needs improvement\", or \"poor\" thresholds of the metric.\n   */\n  rating: 'good' | 'needs-improvement' | 'poor';\n\n  /**\n   * The delta between the current value and the last-reported value.\n   * On the first report, `delta` and `value` will always be the same.\n   */\n  delta: number;\n\n  /**\n   * A unique ID representing this particular metric instance. This ID can\n   * be used by an analytics tool to dedupe multiple values sent for the same\n   * metric instance, or to group multiple deltas together and calculate a\n   * total. It can also be used to differentiate multiple different metric\n   * instances sent from the same page, which can happen if the page is\n   * restored from the back/forward cache (in that case new metrics object\n   * get created).\n   */\n  id: string;\n\n  /**\n   * Any performance entries relevant to the metric value calculation.\n   * The array may also be empty if the metric value was not based on any\n   * entries (e.g. a CLS value of 0 given no layout shifts).\n   */\n  entries: (\n    | PerformanceEntry\n    | LayoutShift\n    | FirstInputPolyfillEntry\n    | NavigationTimingPolyfillEntry\n  )[];\n\n  /**\n   * The type of navigation.\n   *\n   * This will be the value returned by the Navigation Timing API (or\n   * `undefined` if the browser doesn't support that API), with the following\n   * exceptions:\n   * - 'back-forward-cache': for pages that are restored from the bfcache.\n   * - 'prerender': for pages that were prerendered.\n   * - 'restore': for pages that were discarded by the browser and then\n   * restored by the user.\n   */\n  navigationType:\n    | 'navigate'\n    | 'reload'\n    | 'back-forward'\n    | 'back-forward-cache'\n    | 'prerender'\n    | 'restore'\n    | 'soft-navigation';\n\n  /**\n   * The navigatonId the metric happened for. This is particularly relevent for soft navigations where\n   * the metric may be reported for a previous URL.\n   *\n   * The navigationId can be mapped to the URL with the following:\n   *   1 (or empty) - performance.getEntriesByType('navigation')[0]?.name\n   *   > 1 - performance.getEntriesByType('soft-navigation')[navigationId - 2]?.name\n   */\n  navigatonId: number;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetric`](/src/types/cls.ts#:~:text=interface%20CLSMetric)\n- [`FCPMetric`](/src/types/fcp.ts#:~:text=interface%20FCPMetric)\n- [`FIDMetric`](/src/types/fid.ts#:~:text=interface%20FIDMetric)\n- [`INPMetric`](/src/types/inp.ts#:~:text=interface%20INPMetric)\n- [`LCPMetric`](/src/types/lcp.ts#:~:text=interface%20LCPMetric)\n- [`TTFBMetric`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetric)\n\n#### `MetricWithAttribution`\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n```ts\ninterface MetricWithAttribution extends Metric {\n  /**\n   * An object containing potentially-helpful debugging information that\n   * can be sent along with the metric value for the current page visit in\n   * order to help identify issues happening to real-users in the field.\n   */\n  attribution: {[key: string]: unknown};\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetricWithAttribution`](/src/types/cls.ts#:~:text=interface%20CLSMetricWithAttribution)\n- [`FCPMetricWithAttribution`](/src/types/fcp.ts#:~:text=interface%20FCPMetricWithAttribution)\n- [`FIDMetricWithAttribution`](/src/types/fid.ts#:~:text=interface%20FIDMetricWithAttribution)\n- [`INPMetricWithAttribution`](/src/types/inp.ts#:~:text=interface%20INPMetricWithAttribution)\n- [`LCPMetricWithAttribution`](/src/types/lcp.ts#:~:text=interface%20LCPMetricWithAttribution)\n- [`TTFBMetricWithAttribution`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetricWithAttribution)\n\n#### `MetricRatingThresholds`\n\nThe thresholds of metric's \"good\", \"needs improvement\", and \"poor\" ratings.\n\n- Metric values up to and including [0] are rated \"good\"\n- Metric values up to and including [1] are rated \"needs improvement\"\n- Metric values above [1] are \"poor\"\n\n| Metric value    | Rating              |\n| --------------- | ------------------- |\n| ≦ [0]           | \"good\"              |\n| > [0] and ≦ [1] | \"needs improvement\" |\n| > [1]           | \"poor\"              |\n\n```ts\nexport type MetricRatingThresholds = [number, number];\n```\n\n_See also [Rating Thresholds](#rating-thresholds)._\n\n#### `ReportCallback`\n\n```ts\ninterface ReportCallback {\n  (metric: Metric): void;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSReportCallback`](/src/types/cls.ts#:~:text=interface%20CLSReportCallback)\n- [`FCPReportCallback`](/src/types/fcp.ts#:~:text=interface%20FCPReportCallback)\n- [`FIDReportCallback`](/src/types/fid.ts#:~:text=interface%20FIDReportCallback)\n- [`INPReportCallback`](/src/types/inp.ts#:~:text=interface%20INPReportCallback)\n- [`LCPReportCallback`](/src/types/lcp.ts#:~:text=interface%20LCPReportCallback)\n- [`TTFBReportCallback`](/src/types/ttfb.ts#:~:text=interface%20TTFBReportCallback)\n\n#### `ReportOpts`\n\n```ts\ninterface ReportOpts {\n  reportAllChanges?: boolean;\n  durationThreshold?: number;\n  reportSoftNavs?: boolean;\n}\n```\n\n#### `LoadState`\n\nThe `LoadState` type is used in several of the metric [attribution objects](#attribution).\n\n```ts\n/**\n * The loading state of the document. Note: this value is similar to\n * `document.readyState` but it subdivides the \"interactive\" state into the\n * time before and after the DOMContentLoaded event fires.\n *\n * State descriptions:\n * - `loading`: the initial document response has not yet been fully downloaded\n *   and parsed. This is equivalent to the corresponding `readyState` value.\n * - `dom-interactive`: the document has been fully loaded and parsed, but\n *   scripts may not have yet finished loading and executing.\n * - `dom-content-loaded`: the document is fully loaded and parsed, and all\n *   scripts (except `async` scripts) have loaded and finished executing.\n * - `complete`: the document and all of its sub-resources have finished\n *   loading. This is equivalent to the corresponding `readyState` value.\n */\ntype LoadState =\n  | 'loading'\n  | 'dom-interactive'\n  | 'dom-content-loaded'\n  | 'complete';\n```\n\n#### `FirstInputPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't natively support the Event Timing API), the `metric.entries` reported by `onFID()` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<\n  PerformanceEventTiming,\n  'processingEnd' | 'toJSON'\n>;\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface), the `metric.entries` reported by `onTTFB()` will contain an object that polyfills the `PerformanceNavigationTiming` entry using timings from the legacy `performance.timing` interface:\n\n```ts\ntype NavigationTimingPolyfillEntry = Omit<\n  PerformanceNavigationTiming,\n  | 'initiatorType'\n  | 'nextHopProtocol'\n  | 'redirectCount'\n  | 'transferSize'\n  | 'encodedBodySize'\n  | 'decodedBodySize'\n  | 'type'\n> & {\n  type: PerformanceNavigationTiming['type'];\n};\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n  firstHiddenTime: number;\n}\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (callback: CLSReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [CLS](https://web.dev/cls/) value for the current page and calls the `callback` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/cls/#layout-shift-score)).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (callback: FCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FCP](https://web.dev/fcp/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n```ts\ntype onFID = (callback: FIDReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FID](https://web.dev/fid/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (callback: INPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [INP](https://web.dev/inp/) value for the current page and calls the `callback` function once the value is ready, along with the `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nA custom `durationThreshold` [configuration option](#reportopts) can optionally be passed to control what `event-timing` entries are considered for INP reporting. The default threshold is `40`, which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended [good](https://web.dev/inp/#what-is-a-good-inp-score) threshold).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (callback: LCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [LCP](https://web.dev/lcp/) value for the current page and calls the `callback` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (callback: TTFBReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [TTFB](https://web.dev/time-to-first-byte/) value for the current page and calls the `callback` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `callback` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it includes time spent on DNS lookup, connection negotiation, network latency, and server processing time.\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n### Rating Thresholds:\n\nThe thresholds of each metric's \"good\", \"needs improvement\", and \"poor\" ratings are available as [`MetricRatingThresholds`](#metricratingthresholds).\n\nExample:\n\n```ts\nimport {CLSThresholds, FIDThresholds, LCPThresholds} from 'web-vitals';\n\nconsole.log(CLSThresholds); // [ 0.1, 0.25 ]\nconsole.log(FIDThresholds); // [ 100, 300 ]\nconsole.log(LCPThresholds); // [ 2500, 4000 ]\n```\n\n_**Note:** It's typically not necessary (or recommended) to manually calculate metric value ratings using these thresholds. Use the [`Metric['rating']`](#metric) supplied by the [`ReportCallback`](#reportcallback) functions instead._\n\n### Attribution:\n\nThe following objects contain potentially-helpful debugging information that can be sent along with the metric values for the current page visit in order to help identify issues happening to real-users in the field.\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n#### CLS `attribution`:\n\n```ts\ninterface CLSAttribution {\n  /**\n   * A selector identifying the first element (in document order) that\n   * shifted when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTarget?: string;\n  /**\n   * The time when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTime?: DOMHighResTimeStamp;\n  /**\n   * The layout shift score of the single largest layout shift contributing to\n   * the page's CLS score.\n   */\n  largestShiftValue?: number;\n  /**\n   * The `LayoutShiftEntry` representing the single largest layout shift\n   * contributing to the page's CLS score. (Useful when you need more than just\n   * `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftEntry?: LayoutShift;\n  /**\n   * The first element source (in document order) among the `sources` list\n   * of the `largestShiftEntry` object. (Also useful when you need more than\n   * just `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftSource?: LayoutShiftAttribution;\n  /**\n   * The loading state of the document at the time when the largest layout\n   * shift contribution to the page's CLS score occurred (see `LoadState`\n   * for details).\n   */\n  loadState?: LoadState;\n}\n```\n\n#### FCP `attribution`:\n\n```ts\ninterface FCPAttribution {\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB).\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and the first contentful paint (FCP).\n   */\n  firstByteToFCP: number;\n  /**\n   * The loading state of the document at the time when FCP `occurred (see\n   * `LoadState` for details). Ideally, documents can paint before they finish\n   * loading (e.g. the `loading` or `dom-interactive` phases).\n   */\n  loadState: LoadState;\n  /**\n   * The `PerformancePaintTiming` entry corresponding to FCP.\n   */\n  fcpEntry?: PerformancePaintTiming;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n#### FID `attribution`:\n\n```ts\ninterface FIDAttribution {\n  /**\n   * A selector identifying the element that the user interacted with. This\n   * element will be the `target` of the `event` dispatched.\n   */\n  eventTarget: string;\n  /**\n   * The time when the user interacted. This time will match the `timeStamp`\n   * value of the `event` dispatched.\n   */\n  eventTime: number;\n  /**\n   * The `type` of the `event` dispatched from the user interaction.\n   */\n  eventType: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to FID (or the\n   * polyfill entry in browsers that don't support Event Timing).\n   */\n  eventEntry: PerformanceEventTiming | FirstInputPolyfillEntry;\n  /**\n   * The loading state of the document at the time when the first interaction\n   * occurred (see `LoadState` for details). If the first interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long input delays.\n   */\n  loadState: LoadState;\n}\n```\n\n#### INP `attribution`:\n\n```ts\ninterface INPAttribution {\n  /**\n   * A selector identifying the element that the user interacted with for\n   * the event corresponding to INP. This element will be the `target` of the\n   * `event` dispatched.\n   */\n  eventTarget?: string;\n  /**\n   * The time when the user interacted for the event corresponding to INP.\n   * This time will match the `timeStamp` value of the `event` dispatched.\n   */\n  eventTime?: number;\n  /**\n   * The `type` of the `event` dispatched corresponding to INP.\n   */\n  eventType?: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to INP.\n   */\n  eventEntry?: PerformanceEventTiming;\n  /**\n   * The loading state of the document at the time when the even corresponding\n   * to INP occurred (see `LoadState` for details). If the interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long delays.\n   */\n  loadState?: LoadState;\n}\n```\n\n#### LCP `attribution`:\n\n```ts\ninterface LCPAttribution {\n  /**\n   * The element corresponding to the largest contentful paint for the page.\n   */\n  element?: string;\n  /**\n   * The URL (if applicable) of the LCP image resource. If the LCP element\n   * is a text node, this value will not be set.\n   */\n  url?: string;\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB). See\n   * [Optimize LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and when the browser starts loading the LCP\n   * resource (if there is one, otherwise 0). See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  resourceLoadDelay: number;\n  /**\n   * The total time it takes to load the LCP resource itself (if there is one,\n   * otherwise 0). See [Optimize LCP](https://web.dev/optimize-lcp/) for\n   * details.\n   */\n  resourceLoadTime: number;\n  /**\n   * The delta between when the LCP resource finishes loading until the LCP\n   * element is fully rendered. See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  elementRenderDelay: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n  /**\n   * The `resource` entry for the LCP resource (if applicable), which is useful\n   * for diagnosing resource load issues.\n   */\n  lcpResourceEntry?: PerformanceResourceTiming;\n  /**\n   * The `LargestContentfulPaint` entry corresponding to LCP.\n   */\n  lcpEntry?: LargestContentfulPaint;\n}\n```\n\n#### TTFB `attribution`:\n\n```ts\ninterface TTFBAttribution {\n  /**\n   * The total time from when the user initiates loading the page to when the\n   * DNS lookup begins. This includes redirects, service worker startup, and\n   * HTTP cache lookup times.\n   */\n  waitingTime: number;\n  /**\n   * The total time to resolve the DNS for the current request.\n   */\n  dnsTime: number;\n  /**\n   * The total time to create the connection to the requested domain.\n   */\n  connectionTime: number;\n  /**\n   * The time time from when the request was sent until the first byte of the\n   * response was received. This includes network time as well as server\n   * processing time.\n   */\n  requestTime: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium\n- `onFCP()`: Chromium, Firefox, Safari 14.1+\n- `onFID()`: Chromium, Firefox _(with [polyfill](#how-to-use-the-polyfill): Safari, Internet Explorer)_\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari 15+ _(with [polyfill](#how-to-use-the-polyfill): Safari 8+, Internet Explorer)_\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that measure the Web Vitals metrics, which means the limitations of those APIs will mostly apply to this library as well. More details on these limitations is available in [this blog post](https://web.dev/crux-and-rum-differences/).\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/vitals-ga4/).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `callback` functions and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"5cdb8f909dde17f3b0e8a3119924e5bc0e05691f","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.3.1-soft-navs-7","_nodeVersion":"18.14.2","_npmVersion":"9.5.0","dist":{"integrity":"sha512-Xak34MYX/Gf0T1OzObHmmIrEL/egxZsoVidMCXg6ZnBSv49BMRnCbym5tKaA0yL6Sc6nMD5zLFxtV8v5zjV2Cw==","shasum":"a2facc1487df2b447cca5ef028e2ca7a2a8fa5ee","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.3.1-soft-navs-7.tgz","fileCount":146,"unpackedSize":436310,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCmP3sqLXbCFFhbqcrevM1lX3jX40LvwhOilhtlOv4KpQIhAP9q5D0ZhkVWwYlmlymKCImWHnJAhleKV7CSAYDbqoh3"}],"npm-signature":"-----BEGIN PGP SIGNATURE-----\r\nVersion: OpenPGP.js v4.10.10\r\nComment: https://openpgpjs.org\r\n\r\nwsFzBAEBCAAGBQJkLA3AACEJED1NWxICdlZqFiEECWMYAoorWMhJKdjhPU1b\r\nEgJ2VmpSVg//eJNBP5NpME6chSAzS42Z6eVdN/jfKd4DBieb+ZThJHtsFWjp\r\nBRr0xXGSpZtN0YOHaiulJ1WeFKUaxjF61ekPczmDnmsx2LOdH7hscMQkW0rR\r\nNuBt8wKAdTy7ypOxd+wAhOqVTIxgyJq2ePF7zNtG7tUPvrflQyFqBxBWCIbl\r\nBFfFcuzfH+QboPUL52Rt+2sMO6Nshvnui9KVW/6ov0OLhBGHAVe8bOTXlZRQ\r\nHvd9JgIwZwbLMxhkERQ72ToG4LosxRx0stzQke5PAkrDjxKBgSFdHY6eoMF+\r\npQfvrq9OBNzZicO197texpeYfIrNtxgZhIGKaAfFd5I/ZguEovDWwTi/P+rj\r\n4VpHQo3vtKPvZoQN8B+n3A1S2wFLJ0Yh0TAKgOnSt3pSDpQbi/7r1cQ2YV8U\r\ngE+KKX5P0WFZaDRLLWmVPOF/szsr63OXt8Q7wbSOD1dGUh21Kszz3gYmaHRe\r\nWs20zH4WqVn4IPar7WzyT6bWlYRl82smafKigjsii8ApLJAkwSEAUKU/0wx1\r\nzIyxvUYAG8XZi5vTSfxy4JSr3X/9pryh8LI7lldiJCMYW5mzZnn25Wc/XgC0\r\nHwAz/1/lP4hWD8Gy23Eha1d2xGExtALAObEe6FMA+wAuf9mJ9Vjc8wXFsYMN\r\nTArwzy82KPep47pJFIDcsVv0ucUoG2P03RQ=\r\n=+IrV\r\n-----END PGP SIGNATURE-----\r\n"},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.3.1-soft-navs-7_1680608704664_0.13640779314959528"},"_hasShrinkwrap":false},"3.3.1-types":{"name":"web-vitals","version":"3.3.1-types","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build test:unit -p -r test:e2e test:server","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","test:unit":"node --test test/unit/*test.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.21.0","@babel/preset-env":"^7.20.2","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.54.1","@typescript-eslint/parser":"^5.54.1","@wdio/cli":"^7.30.2","@wdio/local-runner":"^7.30.2","@wdio/mocha-framework":"^7.30.2","@wdio/selenium-standalone-service":"^7.30.2","@wdio/spec-reporter":"^7.30.2","body-parser":"^1.20.2","chromedriver":"^107.0.3","eslint":"^8.35.0","express":"^4.18.2","fs-extra":"^10.1.0","husky":"^8.0.3","lint-staged":"^13.1.2","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","prettier":"^2.8.4","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","selenium-standalone":"^8.3.0","typescript":"^4.9.5","wdio-chromedriver-service":"^8.1.1"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"gitHead":"7b4d1d02e5db46c03a76f35983c485a9274f85fc","readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Send attribution data](#send-attribution-data)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Build options](#build-options)\n  - [Which build is right for you?](#which-build-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n  - [Rating Thresholds](#rating-thresholds)\n  - [Attribution](#attribution)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1.5K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/vitals/) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/vitals/#core-web-vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/user-centric-performance-metrics/) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/cls/)\n- [First Input Delay (FID)](https://web.dev/fid/)\n- [Largest Contentful Paint (LCP)](https://web.dev/lcp/)\n\n### Other metrics\n\n- [Interaction to next Paint (INP)](https://web.dev/inp/) _(experimental)_\n- [First Contentful Paint (FCP)](https://web.dev/fcp/)\n- [Time to First Byte (TTFB)](https://web.dev/ttfb/)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\nThe `web-vitals` library uses the `buffered` flag for [PerformanceObserver](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver/observe), allowing it to access performance entries that occurred before the library was loaded.\n\nThis means you do not need to load this library early in order to get accurate performance data. In general, this library should be deferred until after other user-impacting code has loaded.\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are a few different builds of the `web-vitals` library, and how you load the library depends on which build you want to use.\n\nFor details on the difference between the builds, see <a href=\"#which-build-is-right-for-you\">which build is right for you</a>.\n\n**1. The \"standard\" build**\n\nTo load the \"standard\" build, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onFID, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functions were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"attribution-build\"><a>\n\n**2. The \"attribution\" build**\n\nMeasuring the Web Vitals scores for your real users is a great first step toward optimizing the user experience. But if your scores aren't _good_, the next step is to understand why they're not good and work to improve them.\n\nThe \"attribution\" build helps you do that by including additional diagnostic information with each metric to help you identify the root cause of poor performance as well as prioritize the most important things to fix.\n\nThe \"attribution\" build is slightly larger than the \"standard\" build (by about 600 bytes, brotli'd), so while the code size is still small, it's only recommended if you're actually using these features.\n\nTo load the \"attribution\" build, change any `import` statements that reference `web-vitals` to `web-vitals/attribution`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/attribution';\n```\n\nUsage for each of the imported function is identical to the standard build, but when importing from the attribution build, the [`Metric`](#metric) object will contain an additional [`attribution`](#metricwithattribution) property.\n\nSee [Send attribution data](#send-attribution-data) for usage examples, and the [`attribution` reference](#attribution) for details on what values are added for each metric.\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**3. The \"base+polyfill\" build**\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nLoading the \"base+polyfill\" build is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nIt's important that the code is inlined directly into the HTML. _Do not link to an external script file, as that will negatively affect performance:_\n\n```html\n<!-- GOOD -->\n<script>\n  // Inline code from `dist/polyfill.js` here\n</script>\n\n<!-- BAD! DO NOT DO! -->\n<script src=\"/path/to/polyfill.js\"></script>\n```\n\nAlso note that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com):\n\n_**Important!** The [unpkg.com](https://unpkg.com) CDN is shown here for example purposes only. `unpkg.com` is not affiliated with Google, and there are no guarantees that the URLs shown in these examples will continue to work in the future._\n\n**Load the \"standard\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals@3?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src = 'https://unpkg.com/web-vitals@3/dist/web-vitals.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n**Load the \"attribution\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {\n    onCLS,\n    onFID,\n    onLCP,\n  } from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"attribution\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src =\n      'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes a `callback` function that will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" build, but they will work with the \"attribution\" build as well.)_\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developer.chrome.com/docs/devtools/console/reference/#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID is not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS should be reported any time the [page's `visibilityState` changes to hidden](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/bfcache/).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onFID()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want the `callback` function to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each layout shift as it happens) by setting `reportAllChanges` to `true` in the optional, [configuration object](#reportopts) (second parameter).\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended) for measuring these metrics in production.\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, {reportAllChanges: true});\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonFID(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `callback` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n    fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonFID(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique dimension value (in this case, the metric `id`, as shown in the examples below) on every metric instance that you send to Google Analytics, you can create a report yourself using the [Google Analytics Reporting API](https://developers.google.com/analytics/devguides/reporting) and any data visualization library you choose.\n\nAs an example of this, the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) is a free and open-source tool you can use to create visualizations of the Web Vitals data that you've sent to Google Analytics.\n\n[![web-vitals-report](https://user-images.githubusercontent.com/326742/101584324-3f9a0900-3992-11eb-8f2d-182f302fb67b.png)](https://github.com/GoogleChromeLabs/web-vitals-report)\n\nIn order to use the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) (or build your own custom reports using the API) you need to send your data to Google Analytics following one of the examples outlined below:\n\n#### Using `analytics.js`\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `ga()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/analyticsjs\n  ga('send', 'event', {\n    eventCategory: 'Web Vitals',\n    eventAction: name,\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    eventLabel: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    nonInteraction: true,\n    // Use `sendBeacon()` if the browser supports it.\n    transport: 'beacon',\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Universal Analytics)\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/gtagjs\n  gtag('event', name, {\n    event_category: 'Web Vitals',\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    event_label: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    value: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    non_interaction: true,\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Google Analytics 4)\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // metric_rating: 'good' | 'needs-improvement' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n### Send attribution data\n\nWhen using the [attribution build](#attribution-build), you can send additional data to help you debug _why_ the metric values are they way they are.\n\nThis example sends an additional `debug_target` param to Google Analytics, corresponding to the element most associated with each metric.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals/attribution';\n\nfunction sendToGoogleAnalytics({name, delta, value, id, attribution}) {\n  const eventParams = {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n  };\n\n  switch (name) {\n    case 'CLS':\n      eventParams.debug_target = attribution.largestShiftTarget;\n      break;\n    case 'FID':\n      eventParams.debug_target = attribution.eventTarget;\n      break;\n    case 'LCP':\n      eventParams.debug_target = attribution.element;\n      break;\n  }\n\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, eventParams);\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n_**Note:** this example relies on custom [event parameters](https://support.google.com/analytics/answer/11396839) in Google Analytics 4. For Universal Analytics the attribution data should be set using a [custom dimension](https://support.google.com/analytics/answer/2709828) rather than `debug_target` as shown above._\n\nSee [Debug performance in the field](https://web.dev/debug-performance-in-the-field/) for more information and examples.\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonFID(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n<a name=\"bundle-versions\"><a>\n\n## Build options\n\nThe `web-vitals` package includes builds for the \"standard\", \"attribution\", and \"base+polyfill\" ([deprecated](https://github.com/GoogleChrome/web-vitals/issues/238)) builds, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the builds distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any attribution features.</p>\n      This is the \"standard\" build and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.cjs</code></td>\n    <td><code>pgk.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.attribution.js</code></td>\n    <td>--</td>\n    <td>\n      An ES module version of all metric functions that includes <a href=\"#attribution-build\">attribution</a> features.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.iife.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An IIFE version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code>, <code>web-vitals.base.umd.cjs</code>, or <code>web-vitals.base.iife.js</code> (it will not work with any script that doesn't have \"base\" in the filename).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n<a name=\"which-build-is-right-for-you\"><a>\n\n### Which build is right for you?\n\nMost developers will generally want to use \"standard\" build (via either the ES module or UMD version, depending on your bundler/build system), as it's the easiest to use out of the box and integrate into existing tools.\n\nHowever, if you'd lke to collect additional debug information to help you diagnose performance bottlenecks based on real-user issues, use the [\"attribution\" build](#attribution-build).\n\nFor guidance on how to collect and use real-user data to debug performance issues, see [Debug performance in the field](https://web.dev/debug-performance-in-the-field/).\n\n### How the polyfill works\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nThe `polyfill.js` script adds event listeners (to track FID cross-browser), and it records initial page visibility state as well as the timestamp of the first visibility change to hidden (to improve the accuracy of CLS, FCP, LCP, and FID). It also polyfills the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) in browsers that only support the original (now deprecated) [Navigation Timing API](https://www.w3.org/TR/navigation-timing/).\n\nIn order for the polyfill to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" build of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" build, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  /**\n   * The name of the metric (in acronym form).\n   */\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  /**\n   * The current value of the metric.\n   */\n  value: number;\n\n  /**\n   * The rating as to whether the metric value is within the \"good\",\n   * \"needs improvement\", or \"poor\" thresholds of the metric.\n   */\n  rating: 'good' | 'needs-improvement' | 'poor';\n\n  /**\n   * The delta between the current value and the last-reported value.\n   * On the first report, `delta` and `value` will always be the same.\n   */\n  delta: number;\n\n  /**\n   * A unique ID representing this particular metric instance. This ID can\n   * be used by an analytics tool to dedupe multiple values sent for the same\n   * metric instance, or to group multiple deltas together and calculate a\n   * total. It can also be used to differentiate multiple different metric\n   * instances sent from the same page, which can happen if the page is\n   * restored from the back/forward cache (in that case new metrics object\n   * get created).\n   */\n  id: string;\n\n  /**\n   * Any performance entries relevant to the metric value calculation.\n   * The array may also be empty if the metric value was not based on any\n   * entries (e.g. a CLS value of 0 given no layout shifts).\n   */\n  entries: (\n    | PerformanceEntry\n    | LayoutShift\n    | FirstInputPolyfillEntry\n    | NavigationTimingPolyfillEntry\n  )[];\n\n  /**\n   * The type of navigation.\n   *\n   * This will be the value returned by the Navigation Timing API (or\n   * `undefined` if the browser doesn't support that API), with the following\n   * exceptions:\n   * - 'back-forward-cache': for pages that are restored from the bfcache.\n   * - 'prerender': for pages that were prerendered.\n   * - 'restore': for pages that were discarded by the browser and then\n   * restored by the user.\n   */\n  navigationType:\n    | 'navigate'\n    | 'reload'\n    | 'back-forward'\n    | 'back-forward-cache'\n    | 'prerender'\n    | 'restore';\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetric`](/src/types/cls.ts#:~:text=interface%20CLSMetric)\n- [`FCPMetric`](/src/types/fcp.ts#:~:text=interface%20FCPMetric)\n- [`FIDMetric`](/src/types/fid.ts#:~:text=interface%20FIDMetric)\n- [`INPMetric`](/src/types/inp.ts#:~:text=interface%20INPMetric)\n- [`LCPMetric`](/src/types/lcp.ts#:~:text=interface%20LCPMetric)\n- [`TTFBMetric`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetric)\n\n#### `MetricWithAttribution`\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n```ts\ninterface MetricWithAttribution extends Metric {\n  /**\n   * An object containing potentially-helpful debugging information that\n   * can be sent along with the metric value for the current page visit in\n   * order to help identify issues happening to real-users in the field.\n   */\n  attribution: {[key: string]: unknown};\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetricWithAttribution`](/src/types/cls.ts#:~:text=interface%20CLSMetricWithAttribution)\n- [`FCPMetricWithAttribution`](/src/types/fcp.ts#:~:text=interface%20FCPMetricWithAttribution)\n- [`FIDMetricWithAttribution`](/src/types/fid.ts#:~:text=interface%20FIDMetricWithAttribution)\n- [`INPMetricWithAttribution`](/src/types/inp.ts#:~:text=interface%20INPMetricWithAttribution)\n- [`LCPMetricWithAttribution`](/src/types/lcp.ts#:~:text=interface%20LCPMetricWithAttribution)\n- [`TTFBMetricWithAttribution`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetricWithAttribution)\n\n#### `MetricRatingThresholds`\n\nThe thresholds of metric's \"good\", \"needs improvement\", and \"poor\" ratings.\n\n- Metric values up to and including [0] are rated \"good\"\n- Metric values up to and including [1] are rated \"needs improvement\"\n- Metric values above [1] are \"poor\"\n\n| Metric value    | Rating              |\n| --------------- | ------------------- |\n| ≦ [0]           | \"good\"              |\n| > [0] and ≦ [1] | \"needs improvement\" |\n| > [1]           | \"poor\"              |\n\n```ts\nexport type MetricRatingThresholds = [number, number];\n```\n\n_See also [Rating Thresholds](#rating-thresholds)._\n\n#### `ReportCallback`\n\n```ts\ninterface ReportCallback {\n  (metric: Metric): void;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSReportCallback`](/src/types/cls.ts#:~:text=interface%20CLSReportCallback)\n- [`FCPReportCallback`](/src/types/fcp.ts#:~:text=interface%20FCPReportCallback)\n- [`FIDReportCallback`](/src/types/fid.ts#:~:text=interface%20FIDReportCallback)\n- [`INPReportCallback`](/src/types/inp.ts#:~:text=interface%20INPReportCallback)\n- [`LCPReportCallback`](/src/types/lcp.ts#:~:text=interface%20LCPReportCallback)\n- [`TTFBReportCallback`](/src/types/ttfb.ts#:~:text=interface%20TTFBReportCallback)\n\n#### `ReportOpts`\n\n```ts\ninterface ReportOpts {\n  reportAllChanges?: boolean;\n  durationThreshold?: number;\n}\n```\n\n#### `LoadState`\n\nThe `LoadState` type is used in several of the metric [attribution objects](#attribution).\n\n```ts\n/**\n * The loading state of the document. Note: this value is similar to\n * `document.readyState` but it subdivides the \"interactive\" state into the\n * time before and after the DOMContentLoaded event fires.\n *\n * State descriptions:\n * - `loading`: the initial document response has not yet been fully downloaded\n *   and parsed. This is equivalent to the corresponding `readyState` value.\n * - `dom-interactive`: the document has been fully loaded and parsed, but\n *   scripts may not have yet finished loading and executing.\n * - `dom-content-loaded`: the document is fully loaded and parsed, and all\n *   scripts (except `async` scripts) have loaded and finished executing.\n * - `complete`: the document and all of its sub-resources have finished\n *   loading. This is equivalent to the corresponding `readyState` value.\n */\ntype LoadState =\n  | 'loading'\n  | 'dom-interactive'\n  | 'dom-content-loaded'\n  | 'complete';\n```\n\n#### `FirstInputPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't natively support the Event Timing API), the `metric.entries` reported by `onFID()` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<\n  PerformanceEventTiming,\n  'processingEnd' | 'toJSON'\n>;\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface), the `metric.entries` reported by `onTTFB()` will contain an object that polyfills the `PerformanceNavigationTiming` entry using timings from the legacy `performance.timing` interface:\n\n```ts\ntype NavigationTimingPolyfillEntry = Omit<\n  PerformanceNavigationTiming,\n  | 'initiatorType'\n  | 'nextHopProtocol'\n  | 'redirectCount'\n  | 'transferSize'\n  | 'encodedBodySize'\n  | 'decodedBodySize'\n  | 'type'\n> & {\n  type: PerformanceNavigationTiming['type'];\n};\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n  firstHiddenTime: number;\n}\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (callback: CLSReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [CLS](https://web.dev/cls/) value for the current page and calls the `callback` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/cls/#layout-shift-score)).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (callback: FCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FCP](https://web.dev/fcp/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n```ts\ntype onFID = (callback: FIDReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FID](https://web.dev/fid/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (callback: INPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [INP](https://web.dev/inp/) value for the current page and calls the `callback` function once the value is ready, along with the `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nA custom `durationThreshold` [configuration option](#reportopts) can optionally be passed to control what `event-timing` entries are considered for INP reporting. The default threshold is `40`, which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended [good](https://web.dev/inp/#what-is-a-good-inp-score) threshold).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (callback: LCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [LCP](https://web.dev/lcp/) value for the current page and calls the `callback` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (callback: TTFBReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [TTFB](https://web.dev/time-to-first-byte/) value for the current page and calls the `callback` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `callback` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it includes time spent on DNS lookup, connection negotiation, network latency, and server processing time.\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n### Rating Thresholds:\n\nThe thresholds of each metric's \"good\", \"needs improvement\", and \"poor\" ratings are available as [`MetricRatingThresholds`](#metricratingthresholds).\n\nExample:\n\n```ts\nimport {CLSThresholds, FIDThresholds, LCPThresholds} from 'web-vitals';\n\nconsole.log(CLSThresholds); // [ 0.1, 0.25 ]\nconsole.log(FIDThresholds); // [ 100, 300 ]\nconsole.log(LCPThresholds); // [ 2500, 4000 ]\n```\n\n_**Note:** It's typically not necessary (or recommended) to manually calculate metric value ratings using these thresholds. Use the [`Metric['rating']`](#metric) supplied by the [`ReportCallback`](#reportcallback) functions instead._\n\n### Attribution:\n\nThe following objects contain potentially-helpful debugging information that can be sent along with the metric values for the current page visit in order to help identify issues happening to real-users in the field.\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n#### CLS `attribution`:\n\n```ts\ninterface CLSAttribution {\n  /**\n   * A selector identifying the first element (in document order) that\n   * shifted when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTarget?: string;\n  /**\n   * The time when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTime?: DOMHighResTimeStamp;\n  /**\n   * The layout shift score of the single largest layout shift contributing to\n   * the page's CLS score.\n   */\n  largestShiftValue?: number;\n  /**\n   * The `LayoutShiftEntry` representing the single largest layout shift\n   * contributing to the page's CLS score. (Useful when you need more than just\n   * `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftEntry?: LayoutShift;\n  /**\n   * The first element source (in document order) among the `sources` list\n   * of the `largestShiftEntry` object. (Also useful when you need more than\n   * just `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftSource?: LayoutShiftAttribution;\n  /**\n   * The loading state of the document at the time when the largest layout\n   * shift contribution to the page's CLS score occurred (see `LoadState`\n   * for details).\n   */\n  loadState?: LoadState;\n}\n```\n\n#### FCP `attribution`:\n\n```ts\ninterface FCPAttribution {\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB).\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and the first contentful paint (FCP).\n   */\n  firstByteToFCP: number;\n  /**\n   * The loading state of the document at the time when FCP `occurred (see\n   * `LoadState` for details). Ideally, documents can paint before they finish\n   * loading (e.g. the `loading` or `dom-interactive` phases).\n   */\n  loadState: LoadState;\n  /**\n   * The `PerformancePaintTiming` entry corresponding to FCP.\n   */\n  fcpEntry?: PerformancePaintTiming;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n#### FID `attribution`:\n\n```ts\ninterface FIDAttribution {\n  /**\n   * A selector identifying the element that the user interacted with. This\n   * element will be the `target` of the `event` dispatched.\n   */\n  eventTarget: string;\n  /**\n   * The time when the user interacted. This time will match the `timeStamp`\n   * value of the `event` dispatched.\n   */\n  eventTime: number;\n  /**\n   * The `type` of the `event` dispatched from the user interaction.\n   */\n  eventType: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to FID (or the\n   * polyfill entry in browsers that don't support Event Timing).\n   */\n  eventEntry: PerformanceEventTiming | FirstInputPolyfillEntry;\n  /**\n   * The loading state of the document at the time when the first interaction\n   * occurred (see `LoadState` for details). If the first interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long input delays.\n   */\n  loadState: LoadState;\n}\n```\n\n#### INP `attribution`:\n\n```ts\ninterface INPAttribution {\n  /**\n   * A selector identifying the element that the user interacted with for\n   * the event corresponding to INP. This element will be the `target` of the\n   * `event` dispatched.\n   */\n  eventTarget?: string;\n  /**\n   * The time when the user interacted for the event corresponding to INP.\n   * This time will match the `timeStamp` value of the `event` dispatched.\n   */\n  eventTime?: number;\n  /**\n   * The `type` of the `event` dispatched corresponding to INP.\n   */\n  eventType?: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to INP.\n   */\n  eventEntry?: PerformanceEventTiming;\n  /**\n   * The loading state of the document at the time when the even corresponding\n   * to INP occurred (see `LoadState` for details). If the interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long delays.\n   */\n  loadState?: LoadState;\n}\n```\n\n#### LCP `attribution`:\n\n```ts\ninterface LCPAttribution {\n  /**\n   * The element corresponding to the largest contentful paint for the page.\n   */\n  element?: string;\n  /**\n   * The URL (if applicable) of the LCP image resource. If the LCP element\n   * is a text node, this value will not be set.\n   */\n  url?: string;\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB). See\n   * [Optimize LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and when the browser starts loading the LCP\n   * resource (if there is one, otherwise 0). See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  resourceLoadDelay: number;\n  /**\n   * The total time it takes to load the LCP resource itself (if there is one,\n   * otherwise 0). See [Optimize LCP](https://web.dev/optimize-lcp/) for\n   * details.\n   */\n  resourceLoadTime: number;\n  /**\n   * The delta between when the LCP resource finishes loading until the LCP\n   * element is fully rendered. See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  elementRenderDelay: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n  /**\n   * The `resource` entry for the LCP resource (if applicable), which is useful\n   * for diagnosing resource load issues.\n   */\n  lcpResourceEntry?: PerformanceResourceTiming;\n  /**\n   * The `LargestContentfulPaint` entry corresponding to LCP.\n   */\n  lcpEntry?: LargestContentfulPaint;\n}\n```\n\n#### TTFB `attribution`:\n\n```ts\ninterface TTFBAttribution {\n  /**\n   * The total time from when the user initiates loading the page to when the\n   * DNS lookup begins. This includes redirects, service worker startup, and\n   * HTTP cache lookup times.\n   */\n  waitingTime: number;\n  /**\n   * The total time to resolve the DNS for the current request.\n   */\n  dnsTime: number;\n  /**\n   * The total time to create the connection to the requested domain.\n   */\n  connectionTime: number;\n  /**\n   * The time time from when the request was sent until the first byte of the\n   * response was received. This includes network time as well as server\n   * processing time.\n   */\n  requestTime: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium\n- `onFCP()`: Chromium, Firefox, Safari 14.1+\n- `onFID()`: Chromium, Firefox _(with [polyfill](#how-to-use-the-polyfill): Safari, Internet Explorer)_\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari 15+ _(with [polyfill](#how-to-use-the-polyfill): Safari 8+, Internet Explorer)_\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that measure the Web Vitals metrics, which means the limitations of those APIs will mostly apply to this library as well. More details on these limitations is available in [this blog post](https://web.dev/crux-and-rum-differences/).\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/vitals-ga4/).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `callback` functions and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.3.1-types","_nodeVersion":"18.16.0","_npmVersion":"9.5.1","dist":{"integrity":"sha512-CRCJeRRLqn6jJeM1nAQx/OEPglAaV8yNx0O/P9qjeDhUTVo+oWlbdKEmenU9nnYZqHHzlG5rlOkBJZWHofJvFg==","shasum":"e64c040118f8958c17c645534c191411f90dcbbd","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.3.1-types.tgz","fileCount":143,"unpackedSize":383346,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIDALszJqk1P407CQSv1gN/k0yaEgI+vdSIOGWXbY2TX6AiAqlzjx7j+tVFF7vplC1edtHI9N4yWc7QXwl/v2dbShWg=="}]},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.3.1-types_1685096144238_0.9976000815644896"},"_hasShrinkwrap":false},"3.3.1-types-2":{"name":"web-vitals","version":"3.3.1-types-2","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build test:unit -p -r test:e2e test:server","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","test:unit":"node --test test/unit/*test.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.21.0","@babel/preset-env":"^7.20.2","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.54.1","@typescript-eslint/parser":"^5.54.1","@wdio/cli":"^7.30.2","@wdio/local-runner":"^7.30.2","@wdio/mocha-framework":"^7.30.2","@wdio/selenium-standalone-service":"^7.30.2","@wdio/spec-reporter":"^7.30.2","body-parser":"^1.20.2","chromedriver":"^107.0.3","eslint":"^8.35.0","express":"^4.18.2","fs-extra":"^10.1.0","husky":"^8.0.3","lint-staged":"^13.1.2","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","prettier":"^2.8.4","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","selenium-standalone":"^8.3.0","typescript":"^4.9.5","wdio-chromedriver-service":"^8.1.1"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Send attribution data](#send-attribution-data)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Build options](#build-options)\n  - [Which build is right for you?](#which-build-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n  - [Rating Thresholds](#rating-thresholds)\n  - [Attribution](#attribution)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1.5K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/vitals/) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/vitals/#core-web-vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/user-centric-performance-metrics/) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/cls/)\n- [First Input Delay (FID)](https://web.dev/fid/)\n- [Largest Contentful Paint (LCP)](https://web.dev/lcp/)\n\n### Other metrics\n\n- [Interaction to next Paint (INP)](https://web.dev/inp/) _(experimental)_\n- [First Contentful Paint (FCP)](https://web.dev/fcp/)\n- [Time to First Byte (TTFB)](https://web.dev/ttfb/)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\nThe `web-vitals` library uses the `buffered` flag for [PerformanceObserver](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver/observe), allowing it to access performance entries that occurred before the library was loaded.\n\nThis means you do not need to load this library early in order to get accurate performance data. In general, this library should be deferred until after other user-impacting code has loaded.\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are a few different builds of the `web-vitals` library, and how you load the library depends on which build you want to use.\n\nFor details on the difference between the builds, see <a href=\"#which-build-is-right-for-you\">which build is right for you</a>.\n\n**1. The \"standard\" build**\n\nTo load the \"standard\" build, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onFID, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functions were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"attribution-build\"><a>\n\n**2. The \"attribution\" build**\n\nMeasuring the Web Vitals scores for your real users is a great first step toward optimizing the user experience. But if your scores aren't _good_, the next step is to understand why they're not good and work to improve them.\n\nThe \"attribution\" build helps you do that by including additional diagnostic information with each metric to help you identify the root cause of poor performance as well as prioritize the most important things to fix.\n\nThe \"attribution\" build is slightly larger than the \"standard\" build (by about 600 bytes, brotli'd), so while the code size is still small, it's only recommended if you're actually using these features.\n\nTo load the \"attribution\" build, change any `import` statements that reference `web-vitals` to `web-vitals/attribution`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/attribution';\n```\n\nUsage for each of the imported function is identical to the standard build, but when importing from the attribution build, the [`Metric`](#metric) object will contain an additional [`attribution`](#metricwithattribution) property.\n\nSee [Send attribution data](#send-attribution-data) for usage examples, and the [`attribution` reference](#attribution) for details on what values are added for each metric.\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**3. The \"base+polyfill\" build**\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nLoading the \"base+polyfill\" build is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nIt's important that the code is inlined directly into the HTML. _Do not link to an external script file, as that will negatively affect performance:_\n\n```html\n<!-- GOOD -->\n<script>\n  // Inline code from `dist/polyfill.js` here\n</script>\n\n<!-- BAD! DO NOT DO! -->\n<script src=\"/path/to/polyfill.js\"></script>\n```\n\nAlso note that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com):\n\n_**Important!** The [unpkg.com](https://unpkg.com) CDN is shown here for example purposes only. `unpkg.com` is not affiliated with Google, and there are no guarantees that the URLs shown in these examples will continue to work in the future._\n\n**Load the \"standard\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals@3?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src = 'https://unpkg.com/web-vitals@3/dist/web-vitals.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n**Load the \"attribution\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {\n    onCLS,\n    onFID,\n    onLCP,\n  } from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"attribution\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src =\n      'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes a `callback` function that will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" build, but they will work with the \"attribution\" build as well.)_\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developer.chrome.com/docs/devtools/console/reference/#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID is not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS should be reported any time the [page's `visibilityState` changes to hidden](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/bfcache/).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onFID()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want the `callback` function to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each layout shift as it happens) by setting `reportAllChanges` to `true` in the optional, [configuration object](#reportopts) (second parameter).\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended) for measuring these metrics in production.\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, {reportAllChanges: true});\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonFID(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `callback` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n    fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonFID(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique dimension value (in this case, the metric `id`, as shown in the examples below) on every metric instance that you send to Google Analytics, you can create a report yourself using the [Google Analytics Reporting API](https://developers.google.com/analytics/devguides/reporting) and any data visualization library you choose.\n\nAs an example of this, the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) is a free and open-source tool you can use to create visualizations of the Web Vitals data that you've sent to Google Analytics.\n\n[![web-vitals-report](https://user-images.githubusercontent.com/326742/101584324-3f9a0900-3992-11eb-8f2d-182f302fb67b.png)](https://github.com/GoogleChromeLabs/web-vitals-report)\n\nIn order to use the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) (or build your own custom reports using the API) you need to send your data to Google Analytics following one of the examples outlined below:\n\n#### Using `analytics.js`\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `ga()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/analyticsjs\n  ga('send', 'event', {\n    eventCategory: 'Web Vitals',\n    eventAction: name,\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    eventLabel: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    nonInteraction: true,\n    // Use `sendBeacon()` if the browser supports it.\n    transport: 'beacon',\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Universal Analytics)\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/gtagjs\n  gtag('event', name, {\n    event_category: 'Web Vitals',\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    event_label: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    value: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    non_interaction: true,\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Google Analytics 4)\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // metric_rating: 'good' | 'needs-improvement' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n### Send attribution data\n\nWhen using the [attribution build](#attribution-build), you can send additional data to help you debug _why_ the metric values are they way they are.\n\nThis example sends an additional `debug_target` param to Google Analytics, corresponding to the element most associated with each metric.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals/attribution';\n\nfunction sendToGoogleAnalytics({name, delta, value, id, attribution}) {\n  const eventParams = {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n  };\n\n  switch (name) {\n    case 'CLS':\n      eventParams.debug_target = attribution.largestShiftTarget;\n      break;\n    case 'FID':\n      eventParams.debug_target = attribution.eventTarget;\n      break;\n    case 'LCP':\n      eventParams.debug_target = attribution.element;\n      break;\n  }\n\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, eventParams);\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n_**Note:** this example relies on custom [event parameters](https://support.google.com/analytics/answer/11396839) in Google Analytics 4. For Universal Analytics the attribution data should be set using a [custom dimension](https://support.google.com/analytics/answer/2709828) rather than `debug_target` as shown above._\n\nSee [Debug performance in the field](https://web.dev/debug-performance-in-the-field/) for more information and examples.\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonFID(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n<a name=\"bundle-versions\"><a>\n\n## Build options\n\nThe `web-vitals` package includes builds for the \"standard\", \"attribution\", and \"base+polyfill\" ([deprecated](https://github.com/GoogleChrome/web-vitals/issues/238)) builds, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the builds distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any attribution features.</p>\n      This is the \"standard\" build and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.cjs</code></td>\n    <td><code>pgk.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.attribution.js</code></td>\n    <td>--</td>\n    <td>\n      An ES module version of all metric functions that includes <a href=\"#attribution-build\">attribution</a> features.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.iife.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An IIFE version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code>, <code>web-vitals.base.umd.cjs</code>, or <code>web-vitals.base.iife.js</code> (it will not work with any script that doesn't have \"base\" in the filename).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n<a name=\"which-build-is-right-for-you\"><a>\n\n### Which build is right for you?\n\nMost developers will generally want to use \"standard\" build (via either the ES module or UMD version, depending on your bundler/build system), as it's the easiest to use out of the box and integrate into existing tools.\n\nHowever, if you'd lke to collect additional debug information to help you diagnose performance bottlenecks based on real-user issues, use the [\"attribution\" build](#attribution-build).\n\nFor guidance on how to collect and use real-user data to debug performance issues, see [Debug performance in the field](https://web.dev/debug-performance-in-the-field/).\n\n### How the polyfill works\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nThe `polyfill.js` script adds event listeners (to track FID cross-browser), and it records initial page visibility state as well as the timestamp of the first visibility change to hidden (to improve the accuracy of CLS, FCP, LCP, and FID). It also polyfills the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) in browsers that only support the original (now deprecated) [Navigation Timing API](https://www.w3.org/TR/navigation-timing/).\n\nIn order for the polyfill to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" build of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" build, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  /**\n   * The name of the metric (in acronym form).\n   */\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  /**\n   * The current value of the metric.\n   */\n  value: number;\n\n  /**\n   * The rating as to whether the metric value is within the \"good\",\n   * \"needs improvement\", or \"poor\" thresholds of the metric.\n   */\n  rating: 'good' | 'needs-improvement' | 'poor';\n\n  /**\n   * The delta between the current value and the last-reported value.\n   * On the first report, `delta` and `value` will always be the same.\n   */\n  delta: number;\n\n  /**\n   * A unique ID representing this particular metric instance. This ID can\n   * be used by an analytics tool to dedupe multiple values sent for the same\n   * metric instance, or to group multiple deltas together and calculate a\n   * total. It can also be used to differentiate multiple different metric\n   * instances sent from the same page, which can happen if the page is\n   * restored from the back/forward cache (in that case new metrics object\n   * get created).\n   */\n  id: string;\n\n  /**\n   * Any performance entries relevant to the metric value calculation.\n   * The array may also be empty if the metric value was not based on any\n   * entries (e.g. a CLS value of 0 given no layout shifts).\n   */\n  entries: (\n    | PerformanceEntry\n    | LayoutShift\n    | FirstInputPolyfillEntry\n    | NavigationTimingPolyfillEntry\n  )[];\n\n  /**\n   * The type of navigation.\n   *\n   * This will be the value returned by the Navigation Timing API (or\n   * `undefined` if the browser doesn't support that API), with the following\n   * exceptions:\n   * - 'back-forward-cache': for pages that are restored from the bfcache.\n   * - 'prerender': for pages that were prerendered.\n   * - 'restore': for pages that were discarded by the browser and then\n   * restored by the user.\n   */\n  navigationType:\n    | 'navigate'\n    | 'reload'\n    | 'back-forward'\n    | 'back-forward-cache'\n    | 'prerender'\n    | 'restore';\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetric`](/src/types/cls.ts#:~:text=interface%20CLSMetric)\n- [`FCPMetric`](/src/types/fcp.ts#:~:text=interface%20FCPMetric)\n- [`FIDMetric`](/src/types/fid.ts#:~:text=interface%20FIDMetric)\n- [`INPMetric`](/src/types/inp.ts#:~:text=interface%20INPMetric)\n- [`LCPMetric`](/src/types/lcp.ts#:~:text=interface%20LCPMetric)\n- [`TTFBMetric`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetric)\n\n#### `MetricWithAttribution`\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n```ts\ninterface MetricWithAttribution extends Metric {\n  /**\n   * An object containing potentially-helpful debugging information that\n   * can be sent along with the metric value for the current page visit in\n   * order to help identify issues happening to real-users in the field.\n   */\n  attribution: {[key: string]: unknown};\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetricWithAttribution`](/src/types/cls.ts#:~:text=interface%20CLSMetricWithAttribution)\n- [`FCPMetricWithAttribution`](/src/types/fcp.ts#:~:text=interface%20FCPMetricWithAttribution)\n- [`FIDMetricWithAttribution`](/src/types/fid.ts#:~:text=interface%20FIDMetricWithAttribution)\n- [`INPMetricWithAttribution`](/src/types/inp.ts#:~:text=interface%20INPMetricWithAttribution)\n- [`LCPMetricWithAttribution`](/src/types/lcp.ts#:~:text=interface%20LCPMetricWithAttribution)\n- [`TTFBMetricWithAttribution`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetricWithAttribution)\n\n#### `MetricRatingThresholds`\n\nThe thresholds of metric's \"good\", \"needs improvement\", and \"poor\" ratings.\n\n- Metric values up to and including [0] are rated \"good\"\n- Metric values up to and including [1] are rated \"needs improvement\"\n- Metric values above [1] are \"poor\"\n\n| Metric value    | Rating              |\n| --------------- | ------------------- |\n| ≦ [0]           | \"good\"              |\n| > [0] and ≦ [1] | \"needs improvement\" |\n| > [1]           | \"poor\"              |\n\n```ts\nexport type MetricRatingThresholds = [number, number];\n```\n\n_See also [Rating Thresholds](#rating-thresholds)._\n\n#### `ReportCallback`\n\n```ts\ninterface ReportCallback {\n  (metric: Metric): void;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSReportCallback`](/src/types/cls.ts#:~:text=interface%20CLSReportCallback)\n- [`FCPReportCallback`](/src/types/fcp.ts#:~:text=interface%20FCPReportCallback)\n- [`FIDReportCallback`](/src/types/fid.ts#:~:text=interface%20FIDReportCallback)\n- [`INPReportCallback`](/src/types/inp.ts#:~:text=interface%20INPReportCallback)\n- [`LCPReportCallback`](/src/types/lcp.ts#:~:text=interface%20LCPReportCallback)\n- [`TTFBReportCallback`](/src/types/ttfb.ts#:~:text=interface%20TTFBReportCallback)\n\n#### `ReportOpts`\n\n```ts\ninterface ReportOpts {\n  reportAllChanges?: boolean;\n  durationThreshold?: number;\n}\n```\n\n#### `LoadState`\n\nThe `LoadState` type is used in several of the metric [attribution objects](#attribution).\n\n```ts\n/**\n * The loading state of the document. Note: this value is similar to\n * `document.readyState` but it subdivides the \"interactive\" state into the\n * time before and after the DOMContentLoaded event fires.\n *\n * State descriptions:\n * - `loading`: the initial document response has not yet been fully downloaded\n *   and parsed. This is equivalent to the corresponding `readyState` value.\n * - `dom-interactive`: the document has been fully loaded and parsed, but\n *   scripts may not have yet finished loading and executing.\n * - `dom-content-loaded`: the document is fully loaded and parsed, and all\n *   scripts (except `async` scripts) have loaded and finished executing.\n * - `complete`: the document and all of its sub-resources have finished\n *   loading. This is equivalent to the corresponding `readyState` value.\n */\ntype LoadState =\n  | 'loading'\n  | 'dom-interactive'\n  | 'dom-content-loaded'\n  | 'complete';\n```\n\n#### `FirstInputPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't natively support the Event Timing API), the `metric.entries` reported by `onFID()` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<\n  PerformanceEventTiming,\n  'processingEnd' | 'toJSON'\n>;\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface), the `metric.entries` reported by `onTTFB()` will contain an object that polyfills the `PerformanceNavigationTiming` entry using timings from the legacy `performance.timing` interface:\n\n```ts\ntype NavigationTimingPolyfillEntry = Omit<\n  PerformanceNavigationTiming,\n  | 'initiatorType'\n  | 'nextHopProtocol'\n  | 'redirectCount'\n  | 'transferSize'\n  | 'encodedBodySize'\n  | 'decodedBodySize'\n  | 'type'\n> & {\n  type: PerformanceNavigationTiming['type'];\n};\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n  firstHiddenTime: number;\n}\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (callback: CLSReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [CLS](https://web.dev/cls/) value for the current page and calls the `callback` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/cls/#layout-shift-score)).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (callback: FCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FCP](https://web.dev/fcp/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n```ts\ntype onFID = (callback: FIDReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FID](https://web.dev/fid/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (callback: INPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [INP](https://web.dev/inp/) value for the current page and calls the `callback` function once the value is ready, along with the `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nA custom `durationThreshold` [configuration option](#reportopts) can optionally be passed to control what `event-timing` entries are considered for INP reporting. The default threshold is `40`, which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended [good](https://web.dev/inp/#what-is-a-good-inp-score) threshold).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (callback: LCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [LCP](https://web.dev/lcp/) value for the current page and calls the `callback` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (callback: TTFBReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [TTFB](https://web.dev/time-to-first-byte/) value for the current page and calls the `callback` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `callback` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it includes time spent on DNS lookup, connection negotiation, network latency, and server processing time.\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n### Rating Thresholds:\n\nThe thresholds of each metric's \"good\", \"needs improvement\", and \"poor\" ratings are available as [`MetricRatingThresholds`](#metricratingthresholds).\n\nExample:\n\n```ts\nimport {CLSThresholds, FIDThresholds, LCPThresholds} from 'web-vitals';\n\nconsole.log(CLSThresholds); // [ 0.1, 0.25 ]\nconsole.log(FIDThresholds); // [ 100, 300 ]\nconsole.log(LCPThresholds); // [ 2500, 4000 ]\n```\n\n_**Note:** It's typically not necessary (or recommended) to manually calculate metric value ratings using these thresholds. Use the [`Metric['rating']`](#metric) supplied by the [`ReportCallback`](#reportcallback) functions instead._\n\n### Attribution:\n\nThe following objects contain potentially-helpful debugging information that can be sent along with the metric values for the current page visit in order to help identify issues happening to real-users in the field.\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n#### CLS `attribution`:\n\n```ts\ninterface CLSAttribution {\n  /**\n   * A selector identifying the first element (in document order) that\n   * shifted when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTarget?: string;\n  /**\n   * The time when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTime?: DOMHighResTimeStamp;\n  /**\n   * The layout shift score of the single largest layout shift contributing to\n   * the page's CLS score.\n   */\n  largestShiftValue?: number;\n  /**\n   * The `LayoutShiftEntry` representing the single largest layout shift\n   * contributing to the page's CLS score. (Useful when you need more than just\n   * `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftEntry?: LayoutShift;\n  /**\n   * The first element source (in document order) among the `sources` list\n   * of the `largestShiftEntry` object. (Also useful when you need more than\n   * just `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftSource?: LayoutShiftAttribution;\n  /**\n   * The loading state of the document at the time when the largest layout\n   * shift contribution to the page's CLS score occurred (see `LoadState`\n   * for details).\n   */\n  loadState?: LoadState;\n}\n```\n\n#### FCP `attribution`:\n\n```ts\ninterface FCPAttribution {\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB).\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and the first contentful paint (FCP).\n   */\n  firstByteToFCP: number;\n  /**\n   * The loading state of the document at the time when FCP `occurred (see\n   * `LoadState` for details). Ideally, documents can paint before they finish\n   * loading (e.g. the `loading` or `dom-interactive` phases).\n   */\n  loadState: LoadState;\n  /**\n   * The `PerformancePaintTiming` entry corresponding to FCP.\n   */\n  fcpEntry?: PerformancePaintTiming;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n#### FID `attribution`:\n\n```ts\ninterface FIDAttribution {\n  /**\n   * A selector identifying the element that the user interacted with. This\n   * element will be the `target` of the `event` dispatched.\n   */\n  eventTarget: string;\n  /**\n   * The time when the user interacted. This time will match the `timeStamp`\n   * value of the `event` dispatched.\n   */\n  eventTime: number;\n  /**\n   * The `type` of the `event` dispatched from the user interaction.\n   */\n  eventType: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to FID (or the\n   * polyfill entry in browsers that don't support Event Timing).\n   */\n  eventEntry: PerformanceEventTiming | FirstInputPolyfillEntry;\n  /**\n   * The loading state of the document at the time when the first interaction\n   * occurred (see `LoadState` for details). If the first interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long input delays.\n   */\n  loadState: LoadState;\n}\n```\n\n#### INP `attribution`:\n\n```ts\ninterface INPAttribution {\n  /**\n   * A selector identifying the element that the user interacted with for\n   * the event corresponding to INP. This element will be the `target` of the\n   * `event` dispatched.\n   */\n  eventTarget?: string;\n  /**\n   * The time when the user interacted for the event corresponding to INP.\n   * This time will match the `timeStamp` value of the `event` dispatched.\n   */\n  eventTime?: number;\n  /**\n   * The `type` of the `event` dispatched corresponding to INP.\n   */\n  eventType?: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to INP.\n   */\n  eventEntry?: PerformanceEventTiming;\n  /**\n   * The loading state of the document at the time when the even corresponding\n   * to INP occurred (see `LoadState` for details). If the interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long delays.\n   */\n  loadState?: LoadState;\n}\n```\n\n#### LCP `attribution`:\n\n```ts\ninterface LCPAttribution {\n  /**\n   * The element corresponding to the largest contentful paint for the page.\n   */\n  element?: string;\n  /**\n   * The URL (if applicable) of the LCP image resource. If the LCP element\n   * is a text node, this value will not be set.\n   */\n  url?: string;\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB). See\n   * [Optimize LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and when the browser starts loading the LCP\n   * resource (if there is one, otherwise 0). See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  resourceLoadDelay: number;\n  /**\n   * The total time it takes to load the LCP resource itself (if there is one,\n   * otherwise 0). See [Optimize LCP](https://web.dev/optimize-lcp/) for\n   * details.\n   */\n  resourceLoadTime: number;\n  /**\n   * The delta between when the LCP resource finishes loading until the LCP\n   * element is fully rendered. See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  elementRenderDelay: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n  /**\n   * The `resource` entry for the LCP resource (if applicable), which is useful\n   * for diagnosing resource load issues.\n   */\n  lcpResourceEntry?: PerformanceResourceTiming;\n  /**\n   * The `LargestContentfulPaint` entry corresponding to LCP.\n   */\n  lcpEntry?: LargestContentfulPaint;\n}\n```\n\n#### TTFB `attribution`:\n\n```ts\ninterface TTFBAttribution {\n  /**\n   * The total time from when the user initiates loading the page to when the\n   * DNS lookup begins. This includes redirects, service worker startup, and\n   * HTTP cache lookup times.\n   */\n  waitingTime: number;\n  /**\n   * The total time to resolve the DNS for the current request.\n   */\n  dnsTime: number;\n  /**\n   * The total time to create the connection to the requested domain.\n   */\n  connectionTime: number;\n  /**\n   * The time time from when the request was sent until the first byte of the\n   * response was received. This includes network time as well as server\n   * processing time.\n   */\n  requestTime: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium\n- `onFCP()`: Chromium, Firefox, Safari 14.1+\n- `onFID()`: Chromium, Firefox _(with [polyfill](#how-to-use-the-polyfill): Safari, Internet Explorer)_\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari 15+ _(with [polyfill](#how-to-use-the-polyfill): Safari 8+, Internet Explorer)_\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that measure the Web Vitals metrics, which means the limitations of those APIs will mostly apply to this library as well. More details on these limitations is available in [this blog post](https://web.dev/crux-and-rum-differences/).\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/vitals-ga4/).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `callback` functions and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"3b955723f40f7cd36f64ee5089d4583ba622574d","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.3.1-types-2","_nodeVersion":"18.16.0","_npmVersion":"9.5.1","dist":{"integrity":"sha512-msJ5DTGMuDwBhqdT+atXnRnTN9ZXGc3+tRtLIOsgs/wjgWoWti2V6EcUTpvYenpz4oIKrhdTRx2K8XQL+aqUFQ==","shasum":"6cf794c7fe7b4661f9c43407a45d6dfd59a0e8be","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.3.1-types-2.tgz","fileCount":143,"unpackedSize":383363,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQC9aFJVcXnNGTQy9HmiCerF3FDD1YiwWGXhGT753pudmgIhAJkBX0G+DYhl6jkLyBa7tnZRSQwGprbo14xg+n4Cmetu"}]},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.3.1-types-2_1685096823981_0.13151616683858425"},"_hasShrinkwrap":false},"3.3.2":{"name":"web-vitals","version":"3.3.2","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build test:unit -p -r test:e2e test:server","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","test:unit":"node --test test/unit/*test.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.21.0","@babel/preset-env":"^7.20.2","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.54.1","@typescript-eslint/parser":"^5.54.1","@wdio/cli":"^7.30.2","@wdio/local-runner":"^7.30.2","@wdio/mocha-framework":"^7.30.2","@wdio/selenium-standalone-service":"^7.30.2","@wdio/spec-reporter":"^7.30.2","body-parser":"^1.20.2","chromedriver":"^107.0.3","eslint":"^8.35.0","express":"^4.18.2","fs-extra":"^10.1.0","husky":"^8.0.3","lint-staged":"^13.1.2","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","prettier":"^2.8.4","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","selenium-standalone":"^8.3.0","typescript":"^4.9.5","wdio-chromedriver-service":"^8.1.1"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"gitHead":"32919e42db4c4580f474c413c5bbbc1c863766d7","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.3.2","_nodeVersion":"18.16.0","_npmVersion":"9.5.1","dist":{"integrity":"sha512-qRkpmSeKfEWAzNhtX541xA8gCJ+pqCqBmUlDVkVDSCSYUvfvNqF+k9g8I+uyreRcDBdfiJrd0/aLbTy5ydo49Q==","shasum":"83e8dbd0f8fba43c5fe2e601573e804afc771790","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.3.2.tgz","fileCount":143,"unpackedSize":383355,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCd7lxgX/IaEvPSjwQVfe9XGkceA25NpiEmzqnZIDbvcgIhAPcJGQ2gZHUCFtkSrJYYoQJjU5aKMe5dvzcwX09S4h4l"}]},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.3.2_1685369534881_0.23305365183958715"},"_hasShrinkwrap":false},"3.3.2-soft-navs-8":{"name":"web-vitals","version":"3.3.2-soft-navs-8","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build test:unit -p -r test:e2e test:server","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","test:unit":"node --test test/unit/*test.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.21.0","@babel/preset-env":"^7.20.2","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.54.1","@typescript-eslint/parser":"^5.54.1","@wdio/cli":"^7.30.2","@wdio/local-runner":"^7.30.2","@wdio/mocha-framework":"^7.30.2","@wdio/selenium-standalone-service":"^7.30.2","@wdio/spec-reporter":"^7.30.2","body-parser":"^1.20.2","chromedriver":"^107.0.3","eslint":"^8.35.0","express":"^4.18.2","fs-extra":"^10.1.0","husky":"^8.0.3","lint-staged":"^13.1.2","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","prettier":"^2.8.4","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","selenium-standalone":"^8.3.0","typescript":"^4.9.5","wdio-chromedriver-service":"^8.1.1"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Send attribution data](#send-attribution-data)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Build options](#build-options)\n  - [Which build is right for you?](#which-build-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n  - [Rating Thresholds](#rating-thresholds)\n  - [Attribution](#attribution)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1.5K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/vitals/) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/vitals/#core-web-vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/user-centric-performance-metrics/) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/cls/)\n- [First Input Delay (FID)](https://web.dev/fid/)\n- [Largest Contentful Paint (LCP)](https://web.dev/lcp/)\n\n### Other metrics\n\n- [Interaction to next Paint (INP)](https://web.dev/inp/) _(experimental)_\n- [First Contentful Paint (FCP)](https://web.dev/fcp/)\n- [Time to First Byte (TTFB)](https://web.dev/ttfb/)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\nThe `web-vitals` library uses the `buffered` flag for [PerformanceObserver](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver/observe), allowing it to access performance entries that occurred before the library was loaded.\n\nThis means you do not need to load this library early in order to get accurate performance data. In general, this library should be deferred until after other user-impacting code has loaded.\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are a few different builds of the `web-vitals` library, and how you load the library depends on which build you want to use.\n\nFor details on the difference between the builds, see <a href=\"#which-build-is-right-for-you\">which build is right for you</a>.\n\n**1. The \"standard\" build**\n\nTo load the \"standard\" build, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onFID, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functions were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"attribution-build\"><a>\n\n**2. The \"attribution\" build**\n\nMeasuring the Web Vitals scores for your real users is a great first step toward optimizing the user experience. But if your scores aren't _good_, the next step is to understand why they're not good and work to improve them.\n\nThe \"attribution\" build helps you do that by including additional diagnostic information with each metric to help you identify the root cause of poor performance as well as prioritize the most important things to fix.\n\nThe \"attribution\" build is slightly larger than the \"standard\" build (by about 600 bytes, brotli'd), so while the code size is still small, it's only recommended if you're actually using these features.\n\nTo load the \"attribution\" build, change any `import` statements that reference `web-vitals` to `web-vitals/attribution`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/attribution';\n```\n\nUsage for each of the imported function is identical to the standard build, but when importing from the attribution build, the [`Metric`](#metric) object will contain an additional [`attribution`](#metricwithattribution) property.\n\nSee [Send attribution data](#send-attribution-data) for usage examples, and the [`attribution` reference](#attribution) for details on what values are added for each metric.\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**3. The \"base+polyfill\" build**\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nLoading the \"base+polyfill\" build is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nIt's important that the code is inlined directly into the HTML. _Do not link to an external script file, as that will negatively affect performance:_\n\n```html\n<!-- GOOD -->\n<script>\n  // Inline code from `dist/polyfill.js` here\n</script>\n\n<!-- BAD! DO NOT DO! -->\n<script src=\"/path/to/polyfill.js\"></script>\n```\n\nAlso note that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com):\n\n_**Important!** The [unpkg.com](https://unpkg.com) CDN is shown here for example purposes only. `unpkg.com` is not affiliated with Google, and there are no guarantees that the URLs shown in these examples will continue to work in the future._\n\n**Load the \"standard\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals@3?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src = 'https://unpkg.com/web-vitals@3/dist/web-vitals.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n**Load the \"attribution\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {\n    onCLS,\n    onFID,\n    onLCP,\n  } from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"attribution\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src =\n      'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes a `callback` function that will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" build, but they will work with the \"attribution\" build as well.)_\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developer.chrome.com/docs/devtools/console/reference/#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID is not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS should be reported any time the [page's `visibilityState` changes to hidden](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/bfcache/).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onFID()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want the `callback` function to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each layout shift as it happens) by setting `reportAllChanges` to `true` in the optional, [configuration object](#reportopts) (second parameter).\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended) for measuring these metrics in production.\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, {reportAllChanges: true});\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonFID(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `callback` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Report metrics for soft navigations (experimental)\n\n_**Note:** this is experimental and subject to change._\n\nCurrently Core Web Vitals are only tracked for full page navigations, which can affect how [Single Page Applications](https://web.dev/vitals-spa-faq/) that use so called \"soft navigations\" to update the browser URL and history outside of the normal browser's handling of this. The Chrome team are experimenting with being able to [measure these soft navigations](https://github.com/WICG/soft-navigations) separately and report on Core Web Vitals separately for them.\n\nThis experimental support allows sites to measure how their Core Web Vitals might be measured differently should this happen.\n\nAt present a \"soft navigation\" is defined as happening after the following three things happen:\n\n- A user interaction occurs\n- The URL changes\n- Content is added to the DOM\n- Something is painted to screen.\n\nFor some sites, these heuristics may lead to false positives (that users would not really consider a \"navigation\"), or false negatives (where the user does consider a navigation to have happened despite not missing the above criteria). We welcome feedback at https://github.com/WICG/soft-navigations/issues on the heuristics, at https://crbug.com for bugs in the Chrome implementation, and on [https://github.com/GoogleChrome/web-vitals/pull/308](this pull request) for implementation issues with web-vitals.js.\n\n_**Note:** At this time it is not known if this experiment will be something we want to move forward with. Until such time, this support will likely remain in a separate branch of this project, rather than be included in any production builds. If we decide not to move forward with this, the support of this will likely be removed from this project since this library is intended to mirror the Core Web Vitals as much as possible._\n\nSome important points to note:\n\n- TTFB is reported as 0, and not the time of the first network call (if any) after the soft navigation.\n- FCP and LCP are the first and largest contentful paints after the soft navigation. Prior reported paint times will not be counted for these metrics, even though these elements may remain between soft navigations, and may be the first or largest contentful item.\n- FID is reset to measure the first interaction after the soft navigation.\n- INP is reset to measure only interactions after the the soft navigation.\n- CLS is reset to measure again separate to the first page.\n\n_**Note:** It is not known at this time whether soft navigations will be weighted the same as full navigations. No weighting is included in this library at present and metrics are reported in the same way as full page load metrics._\n\nThe metrics can be reported for Soft Navigations using the `reportSoftNavs: true` reporting option:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(console.log, {reportSoftNavs: true});\nonFID(console.log, {reportSoftNavs: true});\nonLCP(console.log, {reportSoftNavs: true});\n```\n\nNote that this will change the way the first page loads are measured as the metrics for the inital URL will be finalized once the first soft nav occurs. To measure both you need to register two callbacks:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(doTraditionalProcessing);\nonFID(doTraditionalProcessing);\nonLCP(doTraditionalProcessing);\n\nonCLS(doSoftNavProcessing, {reportSoftNavs: true});\nonFID(doSoftNavProcessing, {reportSoftNavs: true});\nonLCP(doSoftNavProcessing, {reportSoftNavs: true});\n```\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n    fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonFID(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique dimension value (in this case, the metric `id`, as shown in the examples below) on every metric instance that you send to Google Analytics, you can create a report yourself using the [Google Analytics Reporting API](https://developers.google.com/analytics/devguides/reporting) and any data visualization library you choose.\n\nAs an example of this, the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) is a free and open-source tool you can use to create visualizations of the Web Vitals data that you've sent to Google Analytics.\n\n[![web-vitals-report](https://user-images.githubusercontent.com/326742/101584324-3f9a0900-3992-11eb-8f2d-182f302fb67b.png)](https://github.com/GoogleChromeLabs/web-vitals-report)\n\nIn order to use the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) (or build your own custom reports using the API) you need to send your data to Google Analytics following one of the examples outlined below:\n\n#### Using `analytics.js`\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `ga()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/analyticsjs\n  ga('send', 'event', {\n    eventCategory: 'Web Vitals',\n    eventAction: name,\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    eventLabel: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    nonInteraction: true,\n    // Use `sendBeacon()` if the browser supports it.\n    transport: 'beacon',\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Universal Analytics)\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/gtagjs\n  gtag('event', name, {\n    event_category: 'Web Vitals',\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    event_label: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    value: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    non_interaction: true,\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Google Analytics 4)\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // metric_rating: 'good' | 'needs-improvement' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n### Send attribution data\n\nWhen using the [attribution build](#attribution-build), you can send additional data to help you debug _why_ the metric values are they way they are.\n\nThis example sends an additional `debug_target` param to Google Analytics, corresponding to the element most associated with each metric.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals/attribution';\n\nfunction sendToGoogleAnalytics({name, delta, value, id, attribution}) {\n  const eventParams = {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n  };\n\n  switch (name) {\n    case 'CLS':\n      eventParams.debug_target = attribution.largestShiftTarget;\n      break;\n    case 'FID':\n      eventParams.debug_target = attribution.eventTarget;\n      break;\n    case 'LCP':\n      eventParams.debug_target = attribution.element;\n      break;\n  }\n\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, eventParams);\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n_**Note:** this example relies on custom [event parameters](https://support.google.com/analytics/answer/11396839) in Google Analytics 4. For Universal Analytics the attribution data should be set using a [custom dimension](https://support.google.com/analytics/answer/2709828) rather than `debug_target` as shown above._\n\nSee [Debug performance in the field](https://web.dev/debug-performance-in-the-field/) for more information and examples.\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonFID(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n<a name=\"bundle-versions\"><a>\n\n## Build options\n\nThe `web-vitals` package includes builds for the \"standard\", \"attribution\", and \"base+polyfill\" ([deprecated](https://github.com/GoogleChrome/web-vitals/issues/238)) builds, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the builds distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any attribution features.</p>\n      This is the \"standard\" build and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.cjs</code></td>\n    <td><code>pgk.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.attribution.js</code></td>\n    <td>--</td>\n    <td>\n      An ES module version of all metric functions that includes <a href=\"#attribution-build\">attribution</a> features.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.iife.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An IIFE version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code>, <code>web-vitals.base.umd.cjs</code>, or <code>web-vitals.base.iife.js</code> (it will not work with any script that doesn't have \"base\" in the filename).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n<a name=\"which-build-is-right-for-you\"><a>\n\n### Which build is right for you?\n\nMost developers will generally want to use \"standard\" build (via either the ES module or UMD version, depending on your bundler/build system), as it's the easiest to use out of the box and integrate into existing tools.\n\nHowever, if you'd lke to collect additional debug information to help you diagnose performance bottlenecks based on real-user issues, use the [\"attribution\" build](#attribution-build).\n\nFor guidance on how to collect and use real-user data to debug performance issues, see [Debug performance in the field](https://web.dev/debug-performance-in-the-field/).\n\n### How the polyfill works\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nThe `polyfill.js` script adds event listeners (to track FID cross-browser), and it records initial page visibility state as well as the timestamp of the first visibility change to hidden (to improve the accuracy of CLS, FCP, LCP, and FID). It also polyfills the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) in browsers that only support the original (now deprecated) [Navigation Timing API](https://www.w3.org/TR/navigation-timing/).\n\nIn order for the polyfill to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" build of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" build, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  /**\n   * The name of the metric (in acronym form).\n   */\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  /**\n   * The current value of the metric.\n   */\n  value: number;\n\n  /**\n   * The rating as to whether the metric value is within the \"good\",\n   * \"needs improvement\", or \"poor\" thresholds of the metric.\n   */\n  rating: 'good' | 'needs-improvement' | 'poor';\n\n  /**\n   * The delta between the current value and the last-reported value.\n   * On the first report, `delta` and `value` will always be the same.\n   */\n  delta: number;\n\n  /**\n   * A unique ID representing this particular metric instance. This ID can\n   * be used by an analytics tool to dedupe multiple values sent for the same\n   * metric instance, or to group multiple deltas together and calculate a\n   * total. It can also be used to differentiate multiple different metric\n   * instances sent from the same page, which can happen if the page is\n   * restored from the back/forward cache (in that case new metrics object\n   * get created).\n   */\n  id: string;\n\n  /**\n   * Any performance entries relevant to the metric value calculation.\n   * The array may also be empty if the metric value was not based on any\n   * entries (e.g. a CLS value of 0 given no layout shifts).\n   */\n  entries: (\n    | PerformanceEntry\n    | LayoutShift\n    | FirstInputPolyfillEntry\n    | NavigationTimingPolyfillEntry\n  )[];\n\n  /**\n   * The type of navigation.\n   *\n   * This will be the value returned by the Navigation Timing API (or\n   * `undefined` if the browser doesn't support that API), with the following\n   * exceptions:\n   * - 'back-forward-cache': for pages that are restored from the bfcache.\n   * - 'prerender': for pages that were prerendered.\n   * - 'restore': for pages that were discarded by the browser and then\n   * restored by the user.\n   */\n  navigationType:\n    | 'navigate'\n    | 'reload'\n    | 'back-forward'\n    | 'back-forward-cache'\n    | 'prerender'\n    | 'restore'\n    | 'soft-navigation';\n\n  /**\n   * The navigatonId the metric happened for. This is particularly relevent for soft navigations where\n   * the metric may be reported for a previous URL.\n   *\n   * The navigationId can be mapped to the URL with the following:\n   *   1 (or empty) - performance.getEntriesByType('navigation')[0]?.name\n   *   > 1 - performance.getEntriesByType('soft-navigation')[navigationId - 2]?.name\n   */\n  navigatonId: number;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetric`](/src/types/cls.ts#:~:text=interface%20CLSMetric)\n- [`FCPMetric`](/src/types/fcp.ts#:~:text=interface%20FCPMetric)\n- [`FIDMetric`](/src/types/fid.ts#:~:text=interface%20FIDMetric)\n- [`INPMetric`](/src/types/inp.ts#:~:text=interface%20INPMetric)\n- [`LCPMetric`](/src/types/lcp.ts#:~:text=interface%20LCPMetric)\n- [`TTFBMetric`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetric)\n\n#### `MetricWithAttribution`\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n```ts\ninterface MetricWithAttribution extends Metric {\n  /**\n   * An object containing potentially-helpful debugging information that\n   * can be sent along with the metric value for the current page visit in\n   * order to help identify issues happening to real-users in the field.\n   */\n  attribution: {[key: string]: unknown};\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetricWithAttribution`](/src/types/cls.ts#:~:text=interface%20CLSMetricWithAttribution)\n- [`FCPMetricWithAttribution`](/src/types/fcp.ts#:~:text=interface%20FCPMetricWithAttribution)\n- [`FIDMetricWithAttribution`](/src/types/fid.ts#:~:text=interface%20FIDMetricWithAttribution)\n- [`INPMetricWithAttribution`](/src/types/inp.ts#:~:text=interface%20INPMetricWithAttribution)\n- [`LCPMetricWithAttribution`](/src/types/lcp.ts#:~:text=interface%20LCPMetricWithAttribution)\n- [`TTFBMetricWithAttribution`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetricWithAttribution)\n\n#### `MetricRatingThresholds`\n\nThe thresholds of metric's \"good\", \"needs improvement\", and \"poor\" ratings.\n\n- Metric values up to and including [0] are rated \"good\"\n- Metric values up to and including [1] are rated \"needs improvement\"\n- Metric values above [1] are \"poor\"\n\n| Metric value    | Rating              |\n| --------------- | ------------------- |\n| ≦ [0]           | \"good\"              |\n| > [0] and ≦ [1] | \"needs improvement\" |\n| > [1]           | \"poor\"              |\n\n```ts\nexport type MetricRatingThresholds = [number, number];\n```\n\n_See also [Rating Thresholds](#rating-thresholds)._\n\n#### `ReportCallback`\n\n```ts\ninterface ReportCallback {\n  (metric: Metric): void;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSReportCallback`](/src/types/cls.ts#:~:text=interface%20CLSReportCallback)\n- [`FCPReportCallback`](/src/types/fcp.ts#:~:text=interface%20FCPReportCallback)\n- [`FIDReportCallback`](/src/types/fid.ts#:~:text=interface%20FIDReportCallback)\n- [`INPReportCallback`](/src/types/inp.ts#:~:text=interface%20INPReportCallback)\n- [`LCPReportCallback`](/src/types/lcp.ts#:~:text=interface%20LCPReportCallback)\n- [`TTFBReportCallback`](/src/types/ttfb.ts#:~:text=interface%20TTFBReportCallback)\n\n#### `ReportOpts`\n\n```ts\ninterface ReportOpts {\n  reportAllChanges?: boolean;\n  durationThreshold?: number;\n  reportSoftNavs?: boolean;\n}\n```\n\n#### `LoadState`\n\nThe `LoadState` type is used in several of the metric [attribution objects](#attribution).\n\n```ts\n/**\n * The loading state of the document. Note: this value is similar to\n * `document.readyState` but it subdivides the \"interactive\" state into the\n * time before and after the DOMContentLoaded event fires.\n *\n * State descriptions:\n * - `loading`: the initial document response has not yet been fully downloaded\n *   and parsed. This is equivalent to the corresponding `readyState` value.\n * - `dom-interactive`: the document has been fully loaded and parsed, but\n *   scripts may not have yet finished loading and executing.\n * - `dom-content-loaded`: the document is fully loaded and parsed, and all\n *   scripts (except `async` scripts) have loaded and finished executing.\n * - `complete`: the document and all of its sub-resources have finished\n *   loading. This is equivalent to the corresponding `readyState` value.\n */\ntype LoadState =\n  | 'loading'\n  | 'dom-interactive'\n  | 'dom-content-loaded'\n  | 'complete';\n```\n\n#### `FirstInputPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't natively support the Event Timing API), the `metric.entries` reported by `onFID()` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<\n  PerformanceEventTiming,\n  'processingEnd' | 'toJSON'\n>;\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface), the `metric.entries` reported by `onTTFB()` will contain an object that polyfills the `PerformanceNavigationTiming` entry using timings from the legacy `performance.timing` interface:\n\n```ts\ntype NavigationTimingPolyfillEntry = Omit<\n  PerformanceNavigationTiming,\n  | 'initiatorType'\n  | 'nextHopProtocol'\n  | 'redirectCount'\n  | 'transferSize'\n  | 'encodedBodySize'\n  | 'decodedBodySize'\n  | 'type'\n> & {\n  type: PerformanceNavigationTiming['type'];\n};\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n  firstHiddenTime: number;\n}\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (callback: CLSReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [CLS](https://web.dev/cls/) value for the current page and calls the `callback` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/cls/#layout-shift-score)).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (callback: FCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FCP](https://web.dev/fcp/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n```ts\ntype onFID = (callback: FIDReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FID](https://web.dev/fid/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (callback: INPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [INP](https://web.dev/inp/) value for the current page and calls the `callback` function once the value is ready, along with the `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nA custom `durationThreshold` [configuration option](#reportopts) can optionally be passed to control what `event-timing` entries are considered for INP reporting. The default threshold is `40`, which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended [good](https://web.dev/inp/#what-is-a-good-inp-score) threshold).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (callback: LCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [LCP](https://web.dev/lcp/) value for the current page and calls the `callback` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (callback: TTFBReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [TTFB](https://web.dev/time-to-first-byte/) value for the current page and calls the `callback` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `callback` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it includes time spent on DNS lookup, connection negotiation, network latency, and server processing time.\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n### Rating Thresholds:\n\nThe thresholds of each metric's \"good\", \"needs improvement\", and \"poor\" ratings are available as [`MetricRatingThresholds`](#metricratingthresholds).\n\nExample:\n\n```ts\nimport {CLSThresholds, FIDThresholds, LCPThresholds} from 'web-vitals';\n\nconsole.log(CLSThresholds); // [ 0.1, 0.25 ]\nconsole.log(FIDThresholds); // [ 100, 300 ]\nconsole.log(LCPThresholds); // [ 2500, 4000 ]\n```\n\n_**Note:** It's typically not necessary (or recommended) to manually calculate metric value ratings using these thresholds. Use the [`Metric['rating']`](#metric) supplied by the [`ReportCallback`](#reportcallback) functions instead._\n\n### Attribution:\n\nThe following objects contain potentially-helpful debugging information that can be sent along with the metric values for the current page visit in order to help identify issues happening to real-users in the field.\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n#### CLS `attribution`:\n\n```ts\ninterface CLSAttribution {\n  /**\n   * A selector identifying the first element (in document order) that\n   * shifted when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTarget?: string;\n  /**\n   * The time when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTime?: DOMHighResTimeStamp;\n  /**\n   * The layout shift score of the single largest layout shift contributing to\n   * the page's CLS score.\n   */\n  largestShiftValue?: number;\n  /**\n   * The `LayoutShiftEntry` representing the single largest layout shift\n   * contributing to the page's CLS score. (Useful when you need more than just\n   * `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftEntry?: LayoutShift;\n  /**\n   * The first element source (in document order) among the `sources` list\n   * of the `largestShiftEntry` object. (Also useful when you need more than\n   * just `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftSource?: LayoutShiftAttribution;\n  /**\n   * The loading state of the document at the time when the largest layout\n   * shift contribution to the page's CLS score occurred (see `LoadState`\n   * for details).\n   */\n  loadState?: LoadState;\n}\n```\n\n#### FCP `attribution`:\n\n```ts\ninterface FCPAttribution {\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB).\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and the first contentful paint (FCP).\n   */\n  firstByteToFCP: number;\n  /**\n   * The loading state of the document at the time when FCP `occurred (see\n   * `LoadState` for details). Ideally, documents can paint before they finish\n   * loading (e.g. the `loading` or `dom-interactive` phases).\n   */\n  loadState: LoadState;\n  /**\n   * The `PerformancePaintTiming` entry corresponding to FCP.\n   */\n  fcpEntry?: PerformancePaintTiming;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n#### FID `attribution`:\n\n```ts\ninterface FIDAttribution {\n  /**\n   * A selector identifying the element that the user interacted with. This\n   * element will be the `target` of the `event` dispatched.\n   */\n  eventTarget: string;\n  /**\n   * The time when the user interacted. This time will match the `timeStamp`\n   * value of the `event` dispatched.\n   */\n  eventTime: number;\n  /**\n   * The `type` of the `event` dispatched from the user interaction.\n   */\n  eventType: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to FID (or the\n   * polyfill entry in browsers that don't support Event Timing).\n   */\n  eventEntry: PerformanceEventTiming | FirstInputPolyfillEntry;\n  /**\n   * The loading state of the document at the time when the first interaction\n   * occurred (see `LoadState` for details). If the first interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long input delays.\n   */\n  loadState: LoadState;\n}\n```\n\n#### INP `attribution`:\n\n```ts\ninterface INPAttribution {\n  /**\n   * A selector identifying the element that the user interacted with for\n   * the event corresponding to INP. This element will be the `target` of the\n   * `event` dispatched.\n   */\n  eventTarget?: string;\n  /**\n   * The time when the user interacted for the event corresponding to INP.\n   * This time will match the `timeStamp` value of the `event` dispatched.\n   */\n  eventTime?: number;\n  /**\n   * The `type` of the `event` dispatched corresponding to INP.\n   */\n  eventType?: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to INP.\n   */\n  eventEntry?: PerformanceEventTiming;\n  /**\n   * The loading state of the document at the time when the even corresponding\n   * to INP occurred (see `LoadState` for details). If the interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long delays.\n   */\n  loadState?: LoadState;\n}\n```\n\n#### LCP `attribution`:\n\n```ts\ninterface LCPAttribution {\n  /**\n   * The element corresponding to the largest contentful paint for the page.\n   */\n  element?: string;\n  /**\n   * The URL (if applicable) of the LCP image resource. If the LCP element\n   * is a text node, this value will not be set.\n   */\n  url?: string;\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB). See\n   * [Optimize LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and when the browser starts loading the LCP\n   * resource (if there is one, otherwise 0). See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  resourceLoadDelay: number;\n  /**\n   * The total time it takes to load the LCP resource itself (if there is one,\n   * otherwise 0). See [Optimize LCP](https://web.dev/optimize-lcp/) for\n   * details.\n   */\n  resourceLoadTime: number;\n  /**\n   * The delta between when the LCP resource finishes loading until the LCP\n   * element is fully rendered. See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  elementRenderDelay: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n  /**\n   * The `resource` entry for the LCP resource (if applicable), which is useful\n   * for diagnosing resource load issues.\n   */\n  lcpResourceEntry?: PerformanceResourceTiming;\n  /**\n   * The `LargestContentfulPaint` entry corresponding to LCP.\n   */\n  lcpEntry?: LargestContentfulPaint;\n}\n```\n\n#### TTFB `attribution`:\n\n```ts\ninterface TTFBAttribution {\n  /**\n   * The total time from when the user initiates loading the page to when the\n   * DNS lookup begins. This includes redirects, service worker startup, and\n   * HTTP cache lookup times.\n   */\n  waitingTime: number;\n  /**\n   * The total time to resolve the DNS for the current request.\n   */\n  dnsTime: number;\n  /**\n   * The total time to create the connection to the requested domain.\n   */\n  connectionTime: number;\n  /**\n   * The time time from when the request was sent until the first byte of the\n   * response was received. This includes network time as well as server\n   * processing time.\n   */\n  requestTime: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium\n- `onFCP()`: Chromium, Firefox, Safari 14.1+\n- `onFID()`: Chromium, Firefox _(with [polyfill](#how-to-use-the-polyfill): Safari, Internet Explorer)_\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari 15+ _(with [polyfill](#how-to-use-the-polyfill): Safari 8+, Internet Explorer)_\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that measure the Web Vitals metrics, which means the limitations of those APIs will mostly apply to this library as well. More details on these limitations is available in [this blog post](https://web.dev/crux-and-rum-differences/).\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/vitals-ga4/).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `callback` functions and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"090e7b20c98258c5a38fe046c7b6719a3a1755d2","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.3.2-soft-navs-8","_nodeVersion":"18.16.0","_npmVersion":"9.5.1","dist":{"integrity":"sha512-yp3MfEIIZst3uyIdaAQrHuFX1A0nxaqnnkxRJWC1mRnC2A9fBPg31m6gV9WrCVdi1UhU8yoHVJtxn/FbywYsUA==","shasum":"cc86fde840a9b9ea70162d5972ee2c601330e1a2","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.3.2-soft-navs-8.tgz","fileCount":146,"unpackedSize":437246,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQD6KLbAJp/Z9jTVJEO2up6vhnJacas7b0nk4xY2l6YSUQIhAMScA8UzSVW4xMo7qY1cOL7EUr88s6aDtT6gLh9GX30Q"}]},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.3.2-soft-navs-8_1685369862621_0.297686406104696"},"_hasShrinkwrap":false},"3.4.0":{"name":"web-vitals","version":"3.4.0","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build test:unit -p -r test:e2e test:server","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","test:unit":"node --test test/unit/*test.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.21.0","@babel/preset-env":"^7.20.2","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.54.1","@typescript-eslint/parser":"^5.54.1","@wdio/cli":"^7.30.2","@wdio/local-runner":"^7.30.2","@wdio/mocha-framework":"^7.30.2","@wdio/selenium-standalone-service":"^7.30.2","@wdio/spec-reporter":"^7.30.2","body-parser":"^1.20.2","chromedriver":"^107.0.3","eslint":"^8.35.0","express":"^4.18.2","fs-extra":"^10.1.0","husky":"^8.0.3","lint-staged":"^13.1.2","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","prettier":"^2.8.4","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","selenium-standalone":"^8.3.0","typescript":"^4.9.5","wdio-chromedriver-service":"^8.1.1"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"gitHead":"073033f792ef51feac9208706341ba9c39dfbb80","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.4.0","_nodeVersion":"18.16.0","_npmVersion":"9.5.1","dist":{"integrity":"sha512-n9fZ5/bG1oeDkyxLWyep0eahrNcPDF6bFqoyispt7xkW0xhDzpUBTgyDKqWDi1twT0MgH4HvvqzpUyh0ZxZV4A==","shasum":"45ed33a3a2e029dc38d36547eb5d71d1c7e2552d","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.4.0.tgz","fileCount":143,"unpackedSize":384944,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQCVs4ypnPBWNNkc/7EF+VfY8h5yOD5fmwESYXtLG9+ZIQIgFS0kDNHTuPXwQyGD7nZcY4yX2DRdaha1qJdi6zUlksI="}]},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.4.0_1689013429501_0.6997460771140855"},"_hasShrinkwrap":false},"3.4.0-soft-navs-9":{"name":"web-vitals","version":"3.4.0-soft-navs-9","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build test:unit -p -r test:e2e test:server","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","test:unit":"node --test test/unit/*test.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.21.0","@babel/preset-env":"^7.20.2","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.54.1","@typescript-eslint/parser":"^5.54.1","@wdio/cli":"^7.30.2","@wdio/local-runner":"^7.30.2","@wdio/mocha-framework":"^7.30.2","@wdio/selenium-standalone-service":"^7.30.2","@wdio/spec-reporter":"^7.30.2","body-parser":"^1.20.2","chromedriver":"^107.0.3","eslint":"^8.35.0","express":"^4.18.2","fs-extra":"^10.1.0","husky":"^8.0.3","lint-staged":"^13.1.2","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","prettier":"^2.8.4","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","selenium-standalone":"^8.3.0","typescript":"^4.9.5","wdio-chromedriver-service":"^8.1.1"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Send attribution data](#send-attribution-data)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Build options](#build-options)\n  - [Which build is right for you?](#which-build-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n  - [Rating Thresholds](#rating-thresholds)\n  - [Attribution](#attribution)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1.5K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/vitals/) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/vitals/#core-web-vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/user-centric-performance-metrics/) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/cls/)\n- [First Input Delay (FID)](https://web.dev/fid/)\n- [Largest Contentful Paint (LCP)](https://web.dev/lcp/)\n\n### Other metrics\n\n- [Interaction to next Paint (INP)](https://web.dev/inp/)\n- [First Contentful Paint (FCP)](https://web.dev/fcp/)\n- [Time to First Byte (TTFB)](https://web.dev/ttfb/)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\nThe `web-vitals` library uses the `buffered` flag for [PerformanceObserver](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver/observe), allowing it to access performance entries that occurred before the library was loaded.\n\nThis means you do not need to load this library early in order to get accurate performance data. In general, this library should be deferred until after other user-impacting code has loaded.\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are a few different builds of the `web-vitals` library, and how you load the library depends on which build you want to use.\n\nFor details on the difference between the builds, see <a href=\"#which-build-is-right-for-you\">which build is right for you</a>.\n\n**1. The \"standard\" build**\n\nTo load the \"standard\" build, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onFID, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functions were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"attribution-build\"><a>\n\n**2. The \"attribution\" build**\n\nMeasuring the Web Vitals scores for your real users is a great first step toward optimizing the user experience. But if your scores aren't _good_, the next step is to understand why they're not good and work to improve them.\n\nThe \"attribution\" build helps you do that by including additional diagnostic information with each metric to help you identify the root cause of poor performance as well as prioritize the most important things to fix.\n\nThe \"attribution\" build is slightly larger than the \"standard\" build (by about 600 bytes, brotli'd), so while the code size is still small, it's only recommended if you're actually using these features.\n\nTo load the \"attribution\" build, change any `import` statements that reference `web-vitals` to `web-vitals/attribution`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/attribution';\n```\n\nUsage for each of the imported function is identical to the standard build, but when importing from the attribution build, the [`Metric`](#metric) object will contain an additional [`attribution`](#metricwithattribution) property.\n\nSee [Send attribution data](#send-attribution-data) for usage examples, and the [`attribution` reference](#attribution) for details on what values are added for each metric.\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**3. The \"base+polyfill\" build**\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nLoading the \"base+polyfill\" build is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nIt's important that the code is inlined directly into the HTML. _Do not link to an external script file, as that will negatively affect performance:_\n\n```html\n<!-- GOOD -->\n<script>\n  // Inline code from `dist/polyfill.js` here\n</script>\n\n<!-- BAD! DO NOT DO! -->\n<script src=\"/path/to/polyfill.js\"></script>\n```\n\nAlso note that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com):\n\n_**Important!** The [unpkg.com](https://unpkg.com) CDN is shown here for example purposes only. `unpkg.com` is not affiliated with Google, and there are no guarantees that the URLs shown in these examples will continue to work in the future._\n\n**Load the \"standard\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals@3?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src = 'https://unpkg.com/web-vitals@3/dist/web-vitals.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n**Load the \"attribution\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {\n    onCLS,\n    onFID,\n    onLCP,\n  } from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"attribution\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src =\n      'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes a `callback` function that will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" build, but they will work with the \"attribution\" build as well.)_\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developer.chrome.com/docs/devtools/console/reference/#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID is not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS should be reported any time the [page's `visibilityState` changes to hidden](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/bfcache/).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onFID()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want the `callback` function to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each layout shift as it happens) by setting `reportAllChanges` to `true` in the optional, [configuration object](#reportopts) (second parameter).\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended) for measuring these metrics in production.\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, {reportAllChanges: true});\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonFID(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `callback` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Report metrics for soft navigations (experimental)\n\n_**Note:** this is experimental and subject to change._\n\nCurrently Core Web Vitals are only tracked for full page navigations, which can affect how [Single Page Applications](https://web.dev/vitals-spa-faq/) that use so called \"soft navigations\" to update the browser URL and history outside of the normal browser's handling of this. The Chrome team are experimenting with being able to [measure these soft navigations](https://github.com/WICG/soft-navigations) separately and report on Core Web Vitals separately for them.\n\nThis experimental support allows sites to measure how their Core Web Vitals might be measured differently should this happen.\n\nAt present a \"soft navigation\" is defined as happening after the following three things happen:\n\n- A user interaction occurs\n- The URL changes\n- Content is added to the DOM\n- Something is painted to screen.\n\nFor some sites, these heuristics may lead to false positives (that users would not really consider a \"navigation\"), or false negatives (where the user does consider a navigation to have happened despite not missing the above criteria). We welcome feedback at https://github.com/WICG/soft-navigations/issues on the heuristics, at https://crbug.com for bugs in the Chrome implementation, and on [https://github.com/GoogleChrome/web-vitals/pull/308](this pull request) for implementation issues with web-vitals.js.\n\n_**Note:** At this time it is not known if this experiment will be something we want to move forward with. Until such time, this support will likely remain in a separate branch of this project, rather than be included in any production builds. If we decide not to move forward with this, the support of this will likely be removed from this project since this library is intended to mirror the Core Web Vitals as much as possible._\n\nSome important points to note:\n\n- TTFB is reported as 0, and not the time of the first network call (if any) after the soft navigation.\n- FCP and LCP are the first and largest contentful paints after the soft navigation. Prior reported paint times will not be counted for these metrics, even though these elements may remain between soft navigations, and may be the first or largest contentful item.\n- FID is reset to measure the first interaction after the soft navigation.\n- INP is reset to measure only interactions after the the soft navigation.\n- CLS is reset to measure again separate to the first page.\n\n_**Note:** It is not known at this time whether soft navigations will be weighted the same as full navigations. No weighting is included in this library at present and metrics are reported in the same way as full page load metrics._\n\nThe metrics can be reported for Soft Navigations using the `reportSoftNavs: true` reporting option:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(console.log, {reportSoftNavs: true});\nonFID(console.log, {reportSoftNavs: true});\nonLCP(console.log, {reportSoftNavs: true});\n```\n\nNote that this will change the way the first page loads are measured as the metrics for the inital URL will be finalized once the first soft nav occurs. To measure both you need to register two callbacks:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(doTraditionalProcessing);\nonFID(doTraditionalProcessing);\nonLCP(doTraditionalProcessing);\n\nonCLS(doSoftNavProcessing, {reportSoftNavs: true});\nonFID(doSoftNavProcessing, {reportSoftNavs: true});\nonLCP(doSoftNavProcessing, {reportSoftNavs: true});\n```\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n    fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonFID(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique dimension value (in this case, the metric `id`, as shown in the examples below) on every metric instance that you send to Google Analytics, you can create a report yourself using the [Google Analytics Reporting API](https://developers.google.com/analytics/devguides/reporting) and any data visualization library you choose.\n\nAs an example of this, the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) is a free and open-source tool you can use to create visualizations of the Web Vitals data that you've sent to Google Analytics.\n\n[![web-vitals-report](https://user-images.githubusercontent.com/326742/101584324-3f9a0900-3992-11eb-8f2d-182f302fb67b.png)](https://github.com/GoogleChromeLabs/web-vitals-report)\n\nIn order to use the [Web Vitals Report](https://github.com/GoogleChromeLabs/web-vitals-report) (or build your own custom reports using the API) you need to send your data to Google Analytics following one of the examples outlined below:\n\n#### Using `analytics.js`\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `ga()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/analyticsjs\n  ga('send', 'event', {\n    eventCategory: 'Web Vitals',\n    eventAction: name,\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    eventLabel: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    nonInteraction: true,\n    // Use `sendBeacon()` if the browser supports it.\n    transport: 'beacon',\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Universal Analytics)\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/gtagjs\n  gtag('event', name, {\n    event_category: 'Web Vitals',\n    // The `id` value will be unique to the current page load. When sending\n    // multiple values from the same page (e.g. for CLS), Google Analytics can\n    // compute a total by grouping on this ID (note: requires `eventLabel` to\n    // be a dimension in your report).\n    event_label: id,\n    // Google Analytics metrics must be integers, so the value is rounded.\n    // For CLS the value is first multiplied by 1000 for greater precision\n    // (note: increase the multiplier for greater precision if needed).\n    value: Math.round(name === 'CLS' ? delta * 1000 : delta),\n    // Use a non-interaction event to avoid affecting bounce rate.\n    non_interaction: true,\n\n    // OPTIONAL: any additional attribution params here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // dimension1: '...',\n    // dimension2: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n#### Using `gtag.js` (Google Analytics 4)\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // metric_rating: 'good' | 'needs-improvement' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n### Send attribution data\n\nWhen using the [attribution build](#attribution-build), you can send additional data to help you debug _why_ the metric values are they way they are.\n\nThis example sends an additional `debug_target` param to Google Analytics, corresponding to the element most associated with each metric.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals/attribution';\n\nfunction sendToGoogleAnalytics({name, delta, value, id, attribution}) {\n  const eventParams = {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n  };\n\n  switch (name) {\n    case 'CLS':\n      eventParams.debug_target = attribution.largestShiftTarget;\n      break;\n    case 'FID':\n      eventParams.debug_target = attribution.eventTarget;\n      break;\n    case 'LCP':\n      eventParams.debug_target = attribution.element;\n      break;\n  }\n\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, eventParams);\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n_**Note:** this example relies on custom [event parameters](https://support.google.com/analytics/answer/11396839) in Google Analytics 4. For Universal Analytics the attribution data should be set using a [custom dimension](https://support.google.com/analytics/answer/2709828) rather than `debug_target` as shown above._\n\nSee [Debug performance in the field](https://web.dev/debug-performance-in-the-field/) for more information and examples.\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonFID(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n<a name=\"bundle-versions\"><a>\n\n## Build options\n\nThe `web-vitals` package includes builds for the \"standard\", \"attribution\", and \"base+polyfill\" ([deprecated](https://github.com/GoogleChrome/web-vitals/issues/238)) builds, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the builds distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any attribution features.</p>\n      This is the \"standard\" build and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.cjs</code></td>\n    <td><code>pgk.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.attribution.js</code></td>\n    <td>--</td>\n    <td>\n      An ES module version of all metric functions that includes <a href=\"#attribution-build\">attribution</a> features.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.iife.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An IIFE version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code>, <code>web-vitals.base.umd.cjs</code>, or <code>web-vitals.base.iife.js</code> (it will not work with any script that doesn't have \"base\" in the filename).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n<a name=\"which-build-is-right-for-you\"><a>\n\n### Which build is right for you?\n\nMost developers will generally want to use \"standard\" build (via either the ES module or UMD version, depending on your bundler/build system), as it's the easiest to use out of the box and integrate into existing tools.\n\nHowever, if you'd lke to collect additional debug information to help you diagnose performance bottlenecks based on real-user issues, use the [\"attribution\" build](#attribution-build).\n\nFor guidance on how to collect and use real-user data to debug performance issues, see [Debug performance in the field](https://web.dev/debug-performance-in-the-field/).\n\n### How the polyfill works\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nThe `polyfill.js` script adds event listeners (to track FID cross-browser), and it records initial page visibility state as well as the timestamp of the first visibility change to hidden (to improve the accuracy of CLS, FCP, LCP, and FID). It also polyfills the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) in browsers that only support the original (now deprecated) [Navigation Timing API](https://www.w3.org/TR/navigation-timing/).\n\nIn order for the polyfill to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" build of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" build, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  /**\n   * The name of the metric (in acronym form).\n   */\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  /**\n   * The current value of the metric.\n   */\n  value: number;\n\n  /**\n   * The rating as to whether the metric value is within the \"good\",\n   * \"needs improvement\", or \"poor\" thresholds of the metric.\n   */\n  rating: 'good' | 'needs-improvement' | 'poor';\n\n  /**\n   * The delta between the current value and the last-reported value.\n   * On the first report, `delta` and `value` will always be the same.\n   */\n  delta: number;\n\n  /**\n   * A unique ID representing this particular metric instance. This ID can\n   * be used by an analytics tool to dedupe multiple values sent for the same\n   * metric instance, or to group multiple deltas together and calculate a\n   * total. It can also be used to differentiate multiple different metric\n   * instances sent from the same page, which can happen if the page is\n   * restored from the back/forward cache (in that case new metrics object\n   * get created).\n   */\n  id: string;\n\n  /**\n   * Any performance entries relevant to the metric value calculation.\n   * The array may also be empty if the metric value was not based on any\n   * entries (e.g. a CLS value of 0 given no layout shifts).\n   */\n  entries: (\n    | PerformanceEntry\n    | LayoutShift\n    | FirstInputPolyfillEntry\n    | NavigationTimingPolyfillEntry\n  )[];\n\n  /**\n   * The type of navigation.\n   *\n   * This will be the value returned by the Navigation Timing API (or\n   * `undefined` if the browser doesn't support that API), with the following\n   * exceptions:\n   * - 'back-forward-cache': for pages that are restored from the bfcache.\n   * - 'prerender': for pages that were prerendered.\n   * - 'restore': for pages that were discarded by the browser and then\n   * restored by the user.\n   */\n  navigationType:\n    | 'navigate'\n    | 'reload'\n    | 'back-forward'\n    | 'back-forward-cache'\n    | 'prerender'\n    | 'restore'\n    | 'soft-navigation';\n\n  /**\n   * The navigatonId the metric happened for. This is particularly relevent for soft navigations where\n   * the metric may be reported for a previous URL.\n   *\n   * The navigationId can be mapped to the URL with the following:\n   *   1 (or empty) - performance.getEntriesByType('navigation')[0]?.name\n   *   > 1 - performance.getEntriesByType('soft-navigation')[navigationId - 2]?.name\n   */\n  navigatonId: number;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetric`](/src/types/cls.ts#:~:text=interface%20CLSMetric)\n- [`FCPMetric`](/src/types/fcp.ts#:~:text=interface%20FCPMetric)\n- [`FIDMetric`](/src/types/fid.ts#:~:text=interface%20FIDMetric)\n- [`INPMetric`](/src/types/inp.ts#:~:text=interface%20INPMetric)\n- [`LCPMetric`](/src/types/lcp.ts#:~:text=interface%20LCPMetric)\n- [`TTFBMetric`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetric)\n\n#### `MetricWithAttribution`\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n```ts\ninterface MetricWithAttribution extends Metric {\n  /**\n   * An object containing potentially-helpful debugging information that\n   * can be sent along with the metric value for the current page visit in\n   * order to help identify issues happening to real-users in the field.\n   */\n  attribution: {[key: string]: unknown};\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetricWithAttribution`](/src/types/cls.ts#:~:text=interface%20CLSMetricWithAttribution)\n- [`FCPMetricWithAttribution`](/src/types/fcp.ts#:~:text=interface%20FCPMetricWithAttribution)\n- [`FIDMetricWithAttribution`](/src/types/fid.ts#:~:text=interface%20FIDMetricWithAttribution)\n- [`INPMetricWithAttribution`](/src/types/inp.ts#:~:text=interface%20INPMetricWithAttribution)\n- [`LCPMetricWithAttribution`](/src/types/lcp.ts#:~:text=interface%20LCPMetricWithAttribution)\n- [`TTFBMetricWithAttribution`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetricWithAttribution)\n\n#### `MetricRatingThresholds`\n\nThe thresholds of metric's \"good\", \"needs improvement\", and \"poor\" ratings.\n\n- Metric values up to and including [0] are rated \"good\"\n- Metric values up to and including [1] are rated \"needs improvement\"\n- Metric values above [1] are \"poor\"\n\n| Metric value    | Rating              |\n| --------------- | ------------------- |\n| ≦ [0]           | \"good\"              |\n| > [0] and ≦ [1] | \"needs improvement\" |\n| > [1]           | \"poor\"              |\n\n```ts\nexport type MetricRatingThresholds = [number, number];\n```\n\n_See also [Rating Thresholds](#rating-thresholds)._\n\n#### `ReportCallback`\n\n```ts\ninterface ReportCallback {\n  (metric: Metric): void;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSReportCallback`](/src/types/cls.ts#:~:text=interface%20CLSReportCallback)\n- [`FCPReportCallback`](/src/types/fcp.ts#:~:text=interface%20FCPReportCallback)\n- [`FIDReportCallback`](/src/types/fid.ts#:~:text=interface%20FIDReportCallback)\n- [`INPReportCallback`](/src/types/inp.ts#:~:text=interface%20INPReportCallback)\n- [`LCPReportCallback`](/src/types/lcp.ts#:~:text=interface%20LCPReportCallback)\n- [`TTFBReportCallback`](/src/types/ttfb.ts#:~:text=interface%20TTFBReportCallback)\n\n#### `ReportOpts`\n\n```ts\ninterface ReportOpts {\n  reportAllChanges?: boolean;\n  durationThreshold?: number;\n  reportSoftNavs?: boolean;\n}\n```\n\n#### `LoadState`\n\nThe `LoadState` type is used in several of the metric [attribution objects](#attribution).\n\n```ts\n/**\n * The loading state of the document. Note: this value is similar to\n * `document.readyState` but it subdivides the \"interactive\" state into the\n * time before and after the DOMContentLoaded event fires.\n *\n * State descriptions:\n * - `loading`: the initial document response has not yet been fully downloaded\n *   and parsed. This is equivalent to the corresponding `readyState` value.\n * - `dom-interactive`: the document has been fully loaded and parsed, but\n *   scripts may not have yet finished loading and executing.\n * - `dom-content-loaded`: the document is fully loaded and parsed, and all\n *   scripts (except `async` scripts) have loaded and finished executing.\n * - `complete`: the document and all of its sub-resources have finished\n *   loading. This is equivalent to the corresponding `readyState` value.\n */\ntype LoadState =\n  | 'loading'\n  | 'dom-interactive'\n  | 'dom-content-loaded'\n  | 'complete';\n```\n\n#### `FirstInputPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't natively support the Event Timing API), the `metric.entries` reported by `onFID()` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<\n  PerformanceEventTiming,\n  'processingEnd' | 'toJSON'\n>;\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface), the `metric.entries` reported by `onTTFB()` will contain an object that polyfills the `PerformanceNavigationTiming` entry using timings from the legacy `performance.timing` interface:\n\n```ts\ntype NavigationTimingPolyfillEntry = Omit<\n  PerformanceNavigationTiming,\n  | 'initiatorType'\n  | 'nextHopProtocol'\n  | 'redirectCount'\n  | 'transferSize'\n  | 'encodedBodySize'\n  | 'decodedBodySize'\n  | 'type'\n> & {\n  type: PerformanceNavigationTiming['type'];\n};\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n  firstHiddenTime: number;\n}\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (callback: CLSReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [CLS](https://web.dev/cls/) value for the current page and calls the `callback` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/cls/#layout-shift-score)).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (callback: FCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FCP](https://web.dev/fcp/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n```ts\ntype onFID = (callback: FIDReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FID](https://web.dev/fid/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (callback: INPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [INP](https://web.dev/inp/) value for the current page and calls the `callback` function once the value is ready, along with the `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nA custom `durationThreshold` [configuration option](#reportopts) can optionally be passed to control what `event-timing` entries are considered for INP reporting. The default threshold is `40`, which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended [good](https://web.dev/inp/#what-is-a-good-inp-score) threshold).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (callback: LCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [LCP](https://web.dev/lcp/) value for the current page and calls the `callback` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (callback: TTFBReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [TTFB](https://web.dev/time-to-first-byte/) value for the current page and calls the `callback` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `callback` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it includes time spent on DNS lookup, connection negotiation, network latency, and server processing time.\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n### Rating Thresholds:\n\nThe thresholds of each metric's \"good\", \"needs improvement\", and \"poor\" ratings are available as [`MetricRatingThresholds`](#metricratingthresholds).\n\nExample:\n\n```ts\nimport {CLSThresholds, FIDThresholds, LCPThresholds} from 'web-vitals';\n\nconsole.log(CLSThresholds); // [ 0.1, 0.25 ]\nconsole.log(FIDThresholds); // [ 100, 300 ]\nconsole.log(LCPThresholds); // [ 2500, 4000 ]\n```\n\n_**Note:** It's typically not necessary (or recommended) to manually calculate metric value ratings using these thresholds. Use the [`Metric['rating']`](#metric) supplied by the [`ReportCallback`](#reportcallback) functions instead._\n\n### Attribution:\n\nThe following objects contain potentially-helpful debugging information that can be sent along with the metric values for the current page visit in order to help identify issues happening to real-users in the field.\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n#### CLS `attribution`:\n\n```ts\ninterface CLSAttribution {\n  /**\n   * A selector identifying the first element (in document order) that\n   * shifted when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTarget?: string;\n  /**\n   * The time when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTime?: DOMHighResTimeStamp;\n  /**\n   * The layout shift score of the single largest layout shift contributing to\n   * the page's CLS score.\n   */\n  largestShiftValue?: number;\n  /**\n   * The `LayoutShiftEntry` representing the single largest layout shift\n   * contributing to the page's CLS score. (Useful when you need more than just\n   * `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftEntry?: LayoutShift;\n  /**\n   * The first element source (in document order) among the `sources` list\n   * of the `largestShiftEntry` object. (Also useful when you need more than\n   * just `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftSource?: LayoutShiftAttribution;\n  /**\n   * The loading state of the document at the time when the largest layout\n   * shift contribution to the page's CLS score occurred (see `LoadState`\n   * for details).\n   */\n  loadState?: LoadState;\n}\n```\n\n#### FCP `attribution`:\n\n```ts\ninterface FCPAttribution {\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB).\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and the first contentful paint (FCP).\n   */\n  firstByteToFCP: number;\n  /**\n   * The loading state of the document at the time when FCP `occurred (see\n   * `LoadState` for details). Ideally, documents can paint before they finish\n   * loading (e.g. the `loading` or `dom-interactive` phases).\n   */\n  loadState: LoadState;\n  /**\n   * The `PerformancePaintTiming` entry corresponding to FCP.\n   */\n  fcpEntry?: PerformancePaintTiming;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n#### FID `attribution`:\n\n```ts\ninterface FIDAttribution {\n  /**\n   * A selector identifying the element that the user interacted with. This\n   * element will be the `target` of the `event` dispatched.\n   */\n  eventTarget: string;\n  /**\n   * The time when the user interacted. This time will match the `timeStamp`\n   * value of the `event` dispatched.\n   */\n  eventTime: number;\n  /**\n   * The `type` of the `event` dispatched from the user interaction.\n   */\n  eventType: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to FID (or the\n   * polyfill entry in browsers that don't support Event Timing).\n   */\n  eventEntry: PerformanceEventTiming | FirstInputPolyfillEntry;\n  /**\n   * The loading state of the document at the time when the first interaction\n   * occurred (see `LoadState` for details). If the first interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long input delays.\n   */\n  loadState: LoadState;\n}\n```\n\n#### INP `attribution`:\n\n```ts\ninterface INPAttribution {\n  /**\n   * A selector identifying the element that the user interacted with for\n   * the event corresponding to INP. This element will be the `target` of the\n   * `event` dispatched.\n   */\n  eventTarget?: string;\n  /**\n   * The time when the user interacted for the event corresponding to INP.\n   * This time will match the `timeStamp` value of the `event` dispatched.\n   */\n  eventTime?: number;\n  /**\n   * The `type` of the `event` dispatched corresponding to INP.\n   */\n  eventType?: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to INP.\n   */\n  eventEntry?: PerformanceEventTiming;\n  /**\n   * The loading state of the document at the time when the even corresponding\n   * to INP occurred (see `LoadState` for details). If the interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long delays.\n   */\n  loadState?: LoadState;\n}\n```\n\n#### LCP `attribution`:\n\n```ts\ninterface LCPAttribution {\n  /**\n   * The element corresponding to the largest contentful paint for the page.\n   */\n  element?: string;\n  /**\n   * The URL (if applicable) of the LCP image resource. If the LCP element\n   * is a text node, this value will not be set.\n   */\n  url?: string;\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB). See\n   * [Optimize LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and when the browser starts loading the LCP\n   * resource (if there is one, otherwise 0). See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  resourceLoadDelay: number;\n  /**\n   * The total time it takes to load the LCP resource itself (if there is one,\n   * otherwise 0). See [Optimize LCP](https://web.dev/optimize-lcp/) for\n   * details.\n   */\n  resourceLoadTime: number;\n  /**\n   * The delta between when the LCP resource finishes loading until the LCP\n   * element is fully rendered. See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  elementRenderDelay: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n  /**\n   * The `resource` entry for the LCP resource (if applicable), which is useful\n   * for diagnosing resource load issues.\n   */\n  lcpResourceEntry?: PerformanceResourceTiming;\n  /**\n   * The `LargestContentfulPaint` entry corresponding to LCP.\n   */\n  lcpEntry?: LargestContentfulPaint;\n}\n```\n\n#### TTFB `attribution`:\n\n```ts\ninterface TTFBAttribution {\n  /**\n   * The total time from when the user initiates loading the page to when the\n   * DNS lookup begins. This includes redirects, service worker startup, and\n   * HTTP cache lookup times.\n   */\n  waitingTime: number;\n  /**\n   * The total time to resolve the DNS for the current request.\n   */\n  dnsTime: number;\n  /**\n   * The total time to create the connection to the requested domain.\n   */\n  connectionTime: number;\n  /**\n   * The time time from when the request was sent until the first byte of the\n   * response was received. This includes network time as well as server\n   * processing time.\n   */\n  requestTime: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium\n- `onFCP()`: Chromium, Firefox, Safari 14.1+\n- `onFID()`: Chromium, Firefox _(with [polyfill](#how-to-use-the-polyfill): Safari, Internet Explorer)_\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari 15+ _(with [polyfill](#how-to-use-the-polyfill): Safari 8+, Internet Explorer)_\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that measure the Web Vitals metrics, which means the limitations of those APIs will mostly apply to this library as well. More details on these limitations is available in [this blog post](https://web.dev/crux-and-rum-differences/).\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/vitals-ga4/).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `callback` functions and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"39a043ad3034edf76b3f6c36cae740c5aaf86ec6","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.4.0-soft-navs-9","_nodeVersion":"18.16.0","_npmVersion":"9.5.1","dist":{"integrity":"sha512-NvfUf4j+L6bYII9yWLeU7JzBO1g3QAt/pTVLGPaQrWGrrrxwBp76Sk+iFYkp3vBsw+l06es09BIe+uYDmMY5Gg==","shasum":"9223b80a128da93ddc09ef0b11925a90d2191d10","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.4.0-soft-navs-9.tgz","fileCount":146,"unpackedSize":438925,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDEiBa3XGw+XqfUsUyBrVr1VxPK0QSpwx3EYgxl8pSu4QIgDoalWwyaSAZkUvOd/EpHM0JuMxyjnw1AxEmFHyhgJrk="}]},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.4.0-soft-navs-9_1689015348558_0.25395654665627276"},"_hasShrinkwrap":false},"3.5.0":{"name":"web-vitals","version":"3.5.0","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build test:unit -p -r test:e2e test:server","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","test:unit":"node --test test/unit/*test.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.21.0","@babel/preset-env":"^7.20.2","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.54.1","@typescript-eslint/parser":"^5.54.1","@wdio/cli":"^7.30.2","@wdio/local-runner":"^7.30.2","@wdio/mocha-framework":"^7.30.2","@wdio/selenium-standalone-service":"^7.32.4","@wdio/spec-reporter":"^7.30.2","body-parser":"^1.20.2","chromedriver":"^117.0.3","eslint":"^8.35.0","express":"^4.18.2","fs-extra":"^10.1.0","husky":"^8.0.3","lint-staged":"^13.1.2","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","prettier":"^2.8.4","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","selenium-standalone":"^8.3.0","typescript":"^4.9.5","wdio-chromedriver-service":"^8.1.1"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"gitHead":"dfdf57d112a33ec3cd29e7bc293b253274e4e38d","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.5.0","_nodeVersion":"18.16.0","_npmVersion":"9.5.1","dist":{"integrity":"sha512-f5YnCHVG9Y6uLCePD4tY8bO/Ge15NPEQWtvm3tPzDKygloiqtb4SVqRHBcrIAqo2ztqX5XueqDn97zHF0LdT6w==","shasum":"3a5571f00743ecd059394b61e0adceec7fac2634","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.5.0.tgz","fileCount":143,"unpackedSize":383481,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDKDLHdYoSbSdJv/hPqKrbvdTZJdZBHsHQWMdKmbhs7RwIgHW/OVPsYzPunqrcNsOgP3ZjOVupsQCB2ny6wnTMcoSw="}]},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.5.0_1695900739332_0.2488339097759953"},"_hasShrinkwrap":false},"3.5.0-soft-navs-10":{"name":"web-vitals","version":"3.5.0-soft-navs-10","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build test:unit -p -r test:e2e test:server","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","test:unit":"node --test test/unit/*test.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.21.0","@babel/preset-env":"^7.20.2","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.54.1","@typescript-eslint/parser":"^5.54.1","@wdio/cli":"^7.30.2","@wdio/local-runner":"^7.30.2","@wdio/mocha-framework":"^7.30.2","@wdio/selenium-standalone-service":"^7.32.4","@wdio/spec-reporter":"^7.30.2","body-parser":"^1.20.2","chromedriver":"^117.0.3","eslint":"^8.35.0","express":"^4.18.2","fs-extra":"^10.1.0","husky":"^8.0.3","lint-staged":"^13.1.2","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","prettier":"^2.8.4","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","selenium-standalone":"^8.3.0","typescript":"^4.9.5","wdio-chromedriver-service":"^8.1.1"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Send attribution data](#send-attribution-data)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Build options](#build-options)\n  - [Which build is right for you?](#which-build-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n  - [Rating Thresholds](#rating-thresholds)\n  - [Attribution](#attribution)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1.5K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/vitals/) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/vitals/#core-web-vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/user-centric-performance-metrics/) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/cls/)\n- [First Input Delay (FID)](https://web.dev/fid/)\n- [Largest Contentful Paint (LCP)](https://web.dev/lcp/)\n\n### Other metrics\n\n- [Interaction to next Paint (INP)](https://web.dev/inp/)\n- [First Contentful Paint (FCP)](https://web.dev/fcp/)\n- [Time to First Byte (TTFB)](https://web.dev/ttfb/)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\nThe `web-vitals` library uses the `buffered` flag for [PerformanceObserver](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver/observe), allowing it to access performance entries that occurred before the library was loaded.\n\nThis means you do not need to load this library early in order to get accurate performance data. In general, this library should be deferred until after other user-impacting code has loaded.\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are a few different builds of the `web-vitals` library, and how you load the library depends on which build you want to use.\n\nFor details on the difference between the builds, see <a href=\"#which-build-is-right-for-you\">which build is right for you</a>.\n\n**1. The \"standard\" build**\n\nTo load the \"standard\" build, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onFID, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functions were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"attribution-build\"><a>\n\n**2. The \"attribution\" build**\n\nMeasuring the Web Vitals scores for your real users is a great first step toward optimizing the user experience. But if your scores aren't _good_, the next step is to understand why they're not good and work to improve them.\n\nThe \"attribution\" build helps you do that by including additional diagnostic information with each metric to help you identify the root cause of poor performance as well as prioritize the most important things to fix.\n\nThe \"attribution\" build is slightly larger than the \"standard\" build (by about 600 bytes, brotli'd), so while the code size is still small, it's only recommended if you're actually using these features.\n\nTo load the \"attribution\" build, change any `import` statements that reference `web-vitals` to `web-vitals/attribution`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/attribution';\n```\n\nUsage for each of the imported function is identical to the standard build, but when importing from the attribution build, the [`Metric`](#metric) object will contain an additional [`attribution`](#metricwithattribution) property.\n\nSee [Send attribution data](#send-attribution-data) for usage examples, and the [`attribution` reference](#attribution) for details on what values are added for each metric.\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**3. The \"base+polyfill\" build**\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nLoading the \"base+polyfill\" build is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nIt's important that the code is inlined directly into the HTML. _Do not link to an external script file, as that will negatively affect performance:_\n\n```html\n<!-- GOOD -->\n<script>\n  // Inline code from `dist/polyfill.js` here\n</script>\n\n<!-- BAD! DO NOT DO! -->\n<script src=\"/path/to/polyfill.js\"></script>\n```\n\nAlso note that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com):\n\n_**Important!** The [unpkg.com](https://unpkg.com) CDN is shown here for example purposes only. `unpkg.com` is not affiliated with Google, and there are no guarantees that the URLs shown in these examples will continue to work in the future._\n\n**Load the \"standard\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals@3?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src = 'https://unpkg.com/web-vitals@3/dist/web-vitals.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n**Load the \"attribution\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {\n    onCLS,\n    onFID,\n    onLCP,\n  } from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"attribution\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src =\n      'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes a `callback` function that will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" build, but they will work with the \"attribution\" build as well.)_\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developer.chrome.com/docs/devtools/console/reference/#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID and INP are not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS and INP should be reported any time the [page's `visibilityState` changes to hidden](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/bfcache/).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onFID()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want the `callback` function to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each layout shift as it happens) by setting `reportAllChanges` to `true` in the optional, [configuration object](#reportopts) (second parameter).\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended) for measuring these metrics in production.\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, {reportAllChanges: true});\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonFID(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `callback` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Report metrics for soft navigations (experimental)\n\n_**Note:** this is experimental and subject to change._\n\nCurrently Core Web Vitals are only tracked for full page navigations, which can affect how [Single Page Applications](https://web.dev/vitals-spa-faq/) that use so called \"soft navigations\" to update the browser URL and history outside of the normal browser's handling of this. The Chrome team are experimenting with being able to [measure these soft navigations](https://github.com/WICG/soft-navigations) separately and report on Core Web Vitals separately for them.\n\nThis experimental support allows sites to measure how their Core Web Vitals might be measured differently should this happen.\n\nAt present a \"soft navigation\" is defined as happening after the following three things happen:\n\n- A user interaction occurs\n- The URL changes\n- Content is added to the DOM\n- Something is painted to screen.\n\nFor some sites, these heuristics may lead to false positives (that users would not really consider a \"navigation\"), or false negatives (where the user does consider a navigation to have happened despite not missing the above criteria). We welcome feedback at https://github.com/WICG/soft-navigations/issues on the heuristics, at https://crbug.com for bugs in the Chrome implementation, and on [https://github.com/GoogleChrome/web-vitals/pull/308](this pull request) for implementation issues with web-vitals.js.\n\n_**Note:** At this time it is not known if this experiment will be something we want to move forward with. Until such time, this support will likely remain in a separate branch of this project, rather than be included in any production builds. If we decide not to move forward with this, the support of this will likely be removed from this project since this library is intended to mirror the Core Web Vitals as much as possible._\n\nSome important points to note:\n\n- TTFB is reported as 0, and not the time of the first network call (if any) after the soft navigation.\n- FCP and LCP are the first and largest contentful paints after the soft navigation. Prior reported paint times will not be counted for these metrics, even though these elements may remain between soft navigations, and may be the first or largest contentful item.\n- FID is reset to measure the first interaction after the soft navigation.\n- INP is reset to measure only interactions after the the soft navigation.\n- CLS is reset to measure again separate to the first page.\n\n_**Note:** It is not known at this time whether soft navigations will be weighted the same as full navigations. No weighting is included in this library at present and metrics are reported in the same way as full page load metrics._\n\nThe metrics can be reported for Soft Navigations using the `reportSoftNavs: true` reporting option:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(console.log, {reportSoftNavs: true});\nonFID(console.log, {reportSoftNavs: true});\nonLCP(console.log, {reportSoftNavs: true});\n```\n\nNote that this will change the way the first page loads are measured as the metrics for the inital URL will be finalized once the first soft nav occurs. To measure both you need to register two callbacks:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(doTraditionalProcessing);\nonFID(doTraditionalProcessing);\nonLCP(doTraditionalProcessing);\n\nonCLS(doSoftNavProcessing, {reportSoftNavs: true});\nonFID(doSoftNavProcessing, {reportSoftNavs: true});\nonLCP(doSoftNavProcessing, {reportSoftNavs: true});\n```\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n    fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonFID(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique event parameter value (in this case, the metric_id, as shown in the example below) on every metric instance that you send to Google Analytics, you can create a report yourself by first getting the data via the [Google Analytics Data API](https://developers.google.com/analytics/devguides/reporting/data/v1) or via [BigQuery export](https://support.google.com/analytics/answer/9358801) and then visualizing it any charting library you choose.\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // metric_rating: 'good' | 'needs-improvement' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\nFor details on how to query this data in [BigQuery](https://cloud.google.com/bigquery), or visualise it in [Looker Studio](https://lookerstudio.google.com/), see [Measure and debug performance with Google Analytics 4 and BigQuery](https://web.dev/vitals-ga4/).\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n### Send attribution data\n\nWhen using the [attribution build](#attribution-build), you can send additional data to help you debug _why_ the metric values are they way they are.\n\nThis example sends an additional `debug_target` param to Google Analytics, corresponding to the element most associated with each metric.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals/attribution';\n\nfunction sendToGoogleAnalytics({name, delta, value, id, attribution}) {\n  const eventParams = {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n  };\n\n  switch (name) {\n    case 'CLS':\n      eventParams.debug_target = attribution.largestShiftTarget;\n      break;\n    case 'FID':\n      eventParams.debug_target = attribution.eventTarget;\n      break;\n    case 'LCP':\n      eventParams.debug_target = attribution.element;\n      break;\n  }\n\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, eventParams);\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n_**Note:** this example relies on custom [event parameters](https://support.google.com/analytics/answer/11396839) in Google Analytics 4._\n\nSee [Debug performance in the field](https://web.dev/debug-performance-in-the-field/) for more information and examples.\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonFID(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n<a name=\"bundle-versions\"><a>\n\n## Build options\n\nThe `web-vitals` package includes builds for the \"standard\", \"attribution\", and \"base+polyfill\" ([deprecated](https://github.com/GoogleChrome/web-vitals/issues/238)) builds, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the builds distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any attribution features.</p>\n      This is the \"standard\" build and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.cjs</code></td>\n    <td><code>pgk.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.attribution.js</code></td>\n    <td>--</td>\n    <td>\n      An ES module version of all metric functions that includes <a href=\"#attribution-build\">attribution</a> features.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.iife.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An IIFE version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code>, <code>web-vitals.base.umd.cjs</code>, or <code>web-vitals.base.iife.js</code> (it will not work with any script that doesn't have \"base\" in the filename).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n<a name=\"which-build-is-right-for-you\"><a>\n\n### Which build is right for you?\n\nMost developers will generally want to use \"standard\" build (via either the ES module or UMD version, depending on your bundler/build system), as it's the easiest to use out of the box and integrate into existing tools.\n\nHowever, if you'd lke to collect additional debug information to help you diagnose performance bottlenecks based on real-user issues, use the [\"attribution\" build](#attribution-build).\n\nFor guidance on how to collect and use real-user data to debug performance issues, see [Debug performance in the field](https://web.dev/debug-performance-in-the-field/).\n\n### How the polyfill works\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nThe `polyfill.js` script adds event listeners (to track FID cross-browser), and it records initial page visibility state as well as the timestamp of the first visibility change to hidden (to improve the accuracy of CLS, FCP, LCP, and FID). It also polyfills the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) in browsers that only support the original (now deprecated) [Navigation Timing API](https://www.w3.org/TR/navigation-timing/).\n\nIn order for the polyfill to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" build of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" build, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  /**\n   * The name of the metric (in acronym form).\n   */\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  /**\n   * The current value of the metric.\n   */\n  value: number;\n\n  /**\n   * The rating as to whether the metric value is within the \"good\",\n   * \"needs improvement\", or \"poor\" thresholds of the metric.\n   */\n  rating: 'good' | 'needs-improvement' | 'poor';\n\n  /**\n   * The delta between the current value and the last-reported value.\n   * On the first report, `delta` and `value` will always be the same.\n   */\n  delta: number;\n\n  /**\n   * A unique ID representing this particular metric instance. This ID can\n   * be used by an analytics tool to dedupe multiple values sent for the same\n   * metric instance, or to group multiple deltas together and calculate a\n   * total. It can also be used to differentiate multiple different metric\n   * instances sent from the same page, which can happen if the page is\n   * restored from the back/forward cache (in that case new metrics object\n   * get created).\n   */\n  id: string;\n\n  /**\n   * Any performance entries relevant to the metric value calculation.\n   * The array may also be empty if the metric value was not based on any\n   * entries (e.g. a CLS value of 0 given no layout shifts).\n   */\n  entries: (\n    | PerformanceEntry\n    | LayoutShift\n    | FirstInputPolyfillEntry\n    | NavigationTimingPolyfillEntry\n  )[];\n\n  /**\n   * The type of navigation.\n   *\n   * This will be the value returned by the Navigation Timing API (or\n   * `undefined` if the browser doesn't support that API), with the following\n   * exceptions:\n   * - 'back-forward-cache': for pages that are restored from the bfcache.\n   * - 'prerender': for pages that were prerendered.\n   * - 'restore': for pages that were discarded by the browser and then\n   * restored by the user.\n   */\n  navigationType:\n    | 'navigate'\n    | 'reload'\n    | 'back-forward'\n    | 'back-forward-cache'\n    | 'prerender'\n    | 'restore'\n    | 'soft-navigation';\n\n  /**\n   * The navigatonId the metric happened for. This is particularly relevent for soft navigations where\n   * the metric may be reported for a previous URL.\n   */\n  navigatonId: number;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetric`](/src/types/cls.ts#:~:text=interface%20CLSMetric)\n- [`FCPMetric`](/src/types/fcp.ts#:~:text=interface%20FCPMetric)\n- [`FIDMetric`](/src/types/fid.ts#:~:text=interface%20FIDMetric)\n- [`INPMetric`](/src/types/inp.ts#:~:text=interface%20INPMetric)\n- [`LCPMetric`](/src/types/lcp.ts#:~:text=interface%20LCPMetric)\n- [`TTFBMetric`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetric)\n\n#### `MetricWithAttribution`\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n```ts\ninterface MetricWithAttribution extends Metric {\n  /**\n   * An object containing potentially-helpful debugging information that\n   * can be sent along with the metric value for the current page visit in\n   * order to help identify issues happening to real-users in the field.\n   */\n  attribution: {[key: string]: unknown};\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetricWithAttribution`](/src/types/cls.ts#:~:text=interface%20CLSMetricWithAttribution)\n- [`FCPMetricWithAttribution`](/src/types/fcp.ts#:~:text=interface%20FCPMetricWithAttribution)\n- [`FIDMetricWithAttribution`](/src/types/fid.ts#:~:text=interface%20FIDMetricWithAttribution)\n- [`INPMetricWithAttribution`](/src/types/inp.ts#:~:text=interface%20INPMetricWithAttribution)\n- [`LCPMetricWithAttribution`](/src/types/lcp.ts#:~:text=interface%20LCPMetricWithAttribution)\n- [`TTFBMetricWithAttribution`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetricWithAttribution)\n\n#### `MetricRatingThresholds`\n\nThe thresholds of metric's \"good\", \"needs improvement\", and \"poor\" ratings.\n\n- Metric values up to and including [0] are rated \"good\"\n- Metric values up to and including [1] are rated \"needs improvement\"\n- Metric values above [1] are \"poor\"\n\n| Metric value    | Rating              |\n| --------------- | ------------------- |\n| ≦ [0]           | \"good\"              |\n| > [0] and ≦ [1] | \"needs improvement\" |\n| > [1]           | \"poor\"              |\n\n```ts\nexport type MetricRatingThresholds = [number, number];\n```\n\n_See also [Rating Thresholds](#rating-thresholds)._\n\n#### `ReportCallback`\n\n```ts\ninterface ReportCallback {\n  (metric: Metric): void;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSReportCallback`](/src/types/cls.ts#:~:text=interface%20CLSReportCallback)\n- [`FCPReportCallback`](/src/types/fcp.ts#:~:text=interface%20FCPReportCallback)\n- [`FIDReportCallback`](/src/types/fid.ts#:~:text=interface%20FIDReportCallback)\n- [`INPReportCallback`](/src/types/inp.ts#:~:text=interface%20INPReportCallback)\n- [`LCPReportCallback`](/src/types/lcp.ts#:~:text=interface%20LCPReportCallback)\n- [`TTFBReportCallback`](/src/types/ttfb.ts#:~:text=interface%20TTFBReportCallback)\n\n#### `ReportOpts`\n\n```ts\ninterface ReportOpts {\n  reportAllChanges?: boolean;\n  durationThreshold?: number;\n  reportSoftNavs?: boolean;\n}\n```\n\n#### `LoadState`\n\nThe `LoadState` type is used in several of the metric [attribution objects](#attribution).\n\n```ts\n/**\n * The loading state of the document. Note: this value is similar to\n * `document.readyState` but it subdivides the \"interactive\" state into the\n * time before and after the DOMContentLoaded event fires.\n *\n * State descriptions:\n * - `loading`: the initial document response has not yet been fully downloaded\n *   and parsed. This is equivalent to the corresponding `readyState` value.\n * - `dom-interactive`: the document has been fully loaded and parsed, but\n *   scripts may not have yet finished loading and executing.\n * - `dom-content-loaded`: the document is fully loaded and parsed, and all\n *   scripts (except `async` scripts) have loaded and finished executing.\n * - `complete`: the document and all of its sub-resources have finished\n *   loading. This is equivalent to the corresponding `readyState` value.\n */\ntype LoadState =\n  | 'loading'\n  | 'dom-interactive'\n  | 'dom-content-loaded'\n  | 'complete';\n```\n\n#### `FirstInputPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't natively support the Event Timing API), the `metric.entries` reported by `onFID()` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<\n  PerformanceEventTiming,\n  'processingEnd' | 'toJSON'\n>;\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface), the `metric.entries` reported by `onTTFB()` will contain an object that polyfills the `PerformanceNavigationTiming` entry using timings from the legacy `performance.timing` interface:\n\n```ts\ntype NavigationTimingPolyfillEntry = Omit<\n  PerformanceNavigationTiming,\n  | 'initiatorType'\n  | 'nextHopProtocol'\n  | 'redirectCount'\n  | 'transferSize'\n  | 'encodedBodySize'\n  | 'decodedBodySize'\n  | 'type'\n> & {\n  type: PerformanceNavigationTiming['type'];\n};\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n  firstHiddenTime: number;\n}\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (callback: CLSReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [CLS](https://web.dev/cls/) value for the current page and calls the `callback` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/cls/#layout-shift-score)).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (callback: FCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FCP](https://web.dev/fcp/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n```ts\ntype onFID = (callback: FIDReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FID](https://web.dev/fid/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (callback: INPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [INP](https://web.dev/inp/) value for the current page and calls the `callback` function once the value is ready, along with the `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nA custom `durationThreshold` [configuration option](#reportopts) can optionally be passed to control what `event-timing` entries are considered for INP reporting. The default threshold is `40`, which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended [good](https://web.dev/inp/#what-is-a-good-inp-score) threshold).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (callback: LCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [LCP](https://web.dev/lcp/) value for the current page and calls the `callback` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (callback: TTFBReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [TTFB](https://web.dev/time-to-first-byte/) value for the current page and calls the `callback` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `callback` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it includes time spent on DNS lookup, connection negotiation, network latency, and server processing time.\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n### Rating Thresholds:\n\nThe thresholds of each metric's \"good\", \"needs improvement\", and \"poor\" ratings are available as [`MetricRatingThresholds`](#metricratingthresholds).\n\nExample:\n\n```ts\nimport {CLSThresholds, FIDThresholds, LCPThresholds} from 'web-vitals';\n\nconsole.log(CLSThresholds); // [ 0.1, 0.25 ]\nconsole.log(FIDThresholds); // [ 100, 300 ]\nconsole.log(LCPThresholds); // [ 2500, 4000 ]\n```\n\n_**Note:** It's typically not necessary (or recommended) to manually calculate metric value ratings using these thresholds. Use the [`Metric['rating']`](#metric) supplied by the [`ReportCallback`](#reportcallback) functions instead._\n\n### Attribution:\n\nThe following objects contain potentially-helpful debugging information that can be sent along with the metric values for the current page visit in order to help identify issues happening to real-users in the field.\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n#### CLS `attribution`:\n\n```ts\ninterface CLSAttribution {\n  /**\n   * A selector identifying the first element (in document order) that\n   * shifted when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTarget?: string;\n  /**\n   * The time when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTime?: DOMHighResTimeStamp;\n  /**\n   * The layout shift score of the single largest layout shift contributing to\n   * the page's CLS score.\n   */\n  largestShiftValue?: number;\n  /**\n   * The `LayoutShiftEntry` representing the single largest layout shift\n   * contributing to the page's CLS score. (Useful when you need more than just\n   * `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftEntry?: LayoutShift;\n  /**\n   * The first element source (in document order) among the `sources` list\n   * of the `largestShiftEntry` object. (Also useful when you need more than\n   * just `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftSource?: LayoutShiftAttribution;\n  /**\n   * The loading state of the document at the time when the largest layout\n   * shift contribution to the page's CLS score occurred (see `LoadState`\n   * for details).\n   */\n  loadState?: LoadState;\n}\n```\n\n#### FCP `attribution`:\n\n```ts\ninterface FCPAttribution {\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB).\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and the first contentful paint (FCP).\n   */\n  firstByteToFCP: number;\n  /**\n   * The loading state of the document at the time when FCP `occurred (see\n   * `LoadState` for details). Ideally, documents can paint before they finish\n   * loading (e.g. the `loading` or `dom-interactive` phases).\n   */\n  loadState: LoadState;\n  /**\n   * The `PerformancePaintTiming` entry corresponding to FCP.\n   */\n  fcpEntry?: PerformancePaintTiming;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n#### FID `attribution`:\n\n```ts\ninterface FIDAttribution {\n  /**\n   * A selector identifying the element that the user interacted with. This\n   * element will be the `target` of the `event` dispatched.\n   */\n  eventTarget: string;\n  /**\n   * The time when the user interacted. This time will match the `timeStamp`\n   * value of the `event` dispatched.\n   */\n  eventTime: number;\n  /**\n   * The `type` of the `event` dispatched from the user interaction.\n   */\n  eventType: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to FID (or the\n   * polyfill entry in browsers that don't support Event Timing).\n   */\n  eventEntry: PerformanceEventTiming | FirstInputPolyfillEntry;\n  /**\n   * The loading state of the document at the time when the first interaction\n   * occurred (see `LoadState` for details). If the first interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long input delays.\n   */\n  loadState: LoadState;\n}\n```\n\n#### INP `attribution`:\n\n```ts\ninterface INPAttribution {\n  /**\n   * A selector identifying the element that the user interacted with for\n   * the event corresponding to INP. This element will be the `target` of the\n   * `event` dispatched.\n   */\n  eventTarget?: string;\n  /**\n   * The time when the user interacted for the event corresponding to INP.\n   * This time will match the `timeStamp` value of the `event` dispatched.\n   */\n  eventTime?: number;\n  /**\n   * The `type` of the `event` dispatched corresponding to INP.\n   */\n  eventType?: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to INP.\n   */\n  eventEntry?: PerformanceEventTiming;\n  /**\n   * The loading state of the document at the time when the even corresponding\n   * to INP occurred (see `LoadState` for details). If the interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long delays.\n   */\n  loadState?: LoadState;\n}\n```\n\n#### LCP `attribution`:\n\n```ts\ninterface LCPAttribution {\n  /**\n   * The element corresponding to the largest contentful paint for the page.\n   */\n  element?: string;\n  /**\n   * The URL (if applicable) of the LCP image resource. If the LCP element\n   * is a text node, this value will not be set.\n   */\n  url?: string;\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB). See\n   * [Optimize LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and when the browser starts loading the LCP\n   * resource (if there is one, otherwise 0). See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  resourceLoadDelay: number;\n  /**\n   * The total time it takes to load the LCP resource itself (if there is one,\n   * otherwise 0). See [Optimize LCP](https://web.dev/optimize-lcp/) for\n   * details.\n   */\n  resourceLoadTime: number;\n  /**\n   * The delta between when the LCP resource finishes loading until the LCP\n   * element is fully rendered. See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  elementRenderDelay: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n  /**\n   * The `resource` entry for the LCP resource (if applicable), which is useful\n   * for diagnosing resource load issues.\n   */\n  lcpResourceEntry?: PerformanceResourceTiming;\n  /**\n   * The `LargestContentfulPaint` entry corresponding to LCP.\n   */\n  lcpEntry?: LargestContentfulPaint;\n}\n```\n\n#### TTFB `attribution`:\n\n```ts\ninterface TTFBAttribution {\n  /**\n   * The total time from when the user initiates loading the page to when the\n   * DNS lookup begins. This includes redirects, service worker startup, and\n   * HTTP cache lookup times.\n   */\n  waitingTime: number;\n  /**\n   * The total time to resolve the DNS for the current request.\n   */\n  dnsTime: number;\n  /**\n   * The total time to create the connection to the requested domain.\n   */\n  connectionTime: number;\n  /**\n   * The time time from when the request was sent until the first byte of the\n   * response was received. This includes network time as well as server\n   * processing time.\n   */\n  requestTime: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium\n- `onFCP()`: Chromium, Firefox, Safari 14.1+\n- `onFID()`: Chromium, Firefox _(with [polyfill](#how-to-use-the-polyfill): Safari, Internet Explorer)_\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari 15+ _(with [polyfill](#how-to-use-the-polyfill): Safari 8+, Internet Explorer)_\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that measure the Web Vitals metrics, which means the limitations of those APIs will mostly apply to this library as well. More details on these limitations is available in [this blog post](https://web.dev/crux-and-rum-differences/).\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/vitals-ga4/).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `callback` functions and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"5de5e890cb201e2c19c7be67c9ad006ec743ad3f","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.5.0-soft-navs-10","_nodeVersion":"18.16.0","_npmVersion":"9.5.1","dist":{"integrity":"sha512-GAVEyZYlNMZ6Q0gIadM7ZEte5YhQyxraAxXAAfwav4WOekS9nlFtYE5duq01mg/2dcR76SDuRPkuGyc386C6dg==","shasum":"a5dbc0dd59aa987463a3a5c4803d8e638255bf10","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.5.0-soft-navs-10.tgz","fileCount":146,"unpackedSize":456198,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCaVY02DQ8KJO8ZMh/cR2o61IV9wjVmYKwhHW3xzEzGcgIhAMtyCHWmv/t8HJRLXmNSLFDHkG5joVC/5ETFc+5/foX4"}]},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.5.0-soft-navs-10_1695902301160_0.6137968126755236"},"_hasShrinkwrap":false},"3.5.0-soft-navs-11":{"name":"web-vitals","version":"3.5.0-soft-navs-11","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build test:unit -p -r test:e2e test:server","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","test:unit":"node --test test/unit/*test.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.21.0","@babel/preset-env":"^7.20.2","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.54.1","@typescript-eslint/parser":"^5.54.1","@wdio/cli":"^7.30.2","@wdio/local-runner":"^7.30.2","@wdio/mocha-framework":"^7.30.2","@wdio/selenium-standalone-service":"^7.32.4","@wdio/spec-reporter":"^7.30.2","body-parser":"^1.20.2","chromedriver":"^117.0.3","eslint":"^8.35.0","express":"^4.18.2","fs-extra":"^10.1.0","husky":"^8.0.3","lint-staged":"^13.1.2","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","prettier":"^2.8.4","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","selenium-standalone":"^8.3.0","typescript":"^4.9.5","wdio-chromedriver-service":"^8.1.1"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Send attribution data](#send-attribution-data)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Build options](#build-options)\n  - [Which build is right for you?](#which-build-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n  - [Rating Thresholds](#rating-thresholds)\n  - [Attribution](#attribution)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1.5K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/vitals/) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/vitals/#core-web-vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/user-centric-performance-metrics/) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/cls/)\n- [First Input Delay (FID)](https://web.dev/fid/)\n- [Largest Contentful Paint (LCP)](https://web.dev/lcp/)\n\n### Other metrics\n\n- [Interaction to next Paint (INP)](https://web.dev/inp/)\n- [First Contentful Paint (FCP)](https://web.dev/fcp/)\n- [Time to First Byte (TTFB)](https://web.dev/ttfb/)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\nThe `web-vitals` library uses the `buffered` flag for [PerformanceObserver](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver/observe), allowing it to access performance entries that occurred before the library was loaded.\n\nThis means you do not need to load this library early in order to get accurate performance data. In general, this library should be deferred until after other user-impacting code has loaded.\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are a few different builds of the `web-vitals` library, and how you load the library depends on which build you want to use.\n\nFor details on the difference between the builds, see <a href=\"#which-build-is-right-for-you\">which build is right for you</a>.\n\n**1. The \"standard\" build**\n\nTo load the \"standard\" build, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onFID, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functions were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"attribution-build\"><a>\n\n**2. The \"attribution\" build**\n\nMeasuring the Web Vitals scores for your real users is a great first step toward optimizing the user experience. But if your scores aren't _good_, the next step is to understand why they're not good and work to improve them.\n\nThe \"attribution\" build helps you do that by including additional diagnostic information with each metric to help you identify the root cause of poor performance as well as prioritize the most important things to fix.\n\nThe \"attribution\" build is slightly larger than the \"standard\" build (by about 600 bytes, brotli'd), so while the code size is still small, it's only recommended if you're actually using these features.\n\nTo load the \"attribution\" build, change any `import` statements that reference `web-vitals` to `web-vitals/attribution`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/attribution';\n```\n\nUsage for each of the imported function is identical to the standard build, but when importing from the attribution build, the [`Metric`](#metric) object will contain an additional [`attribution`](#metricwithattribution) property.\n\nSee [Send attribution data](#send-attribution-data) for usage examples, and the [`attribution` reference](#attribution) for details on what values are added for each metric.\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**3. The \"base+polyfill\" build**\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nLoading the \"base+polyfill\" build is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nIt's important that the code is inlined directly into the HTML. _Do not link to an external script file, as that will negatively affect performance:_\n\n```html\n<!-- GOOD -->\n<script>\n  // Inline code from `dist/polyfill.js` here\n</script>\n\n<!-- BAD! DO NOT DO! -->\n<script src=\"/path/to/polyfill.js\"></script>\n```\n\nAlso note that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com):\n\n_**Important!** The [unpkg.com](https://unpkg.com) CDN is shown here for example purposes only. `unpkg.com` is not affiliated with Google, and there are no guarantees that the URLs shown in these examples will continue to work in the future._\n\n**Load the \"standard\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals@3?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src = 'https://unpkg.com/web-vitals@3/dist/web-vitals.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n**Load the \"attribution\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {\n    onCLS,\n    onFID,\n    onLCP,\n  } from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"attribution\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src =\n      'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes a `callback` function that will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" build, but they will work with the \"attribution\" build as well.)_\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developer.chrome.com/docs/devtools/console/reference/#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID and INP are not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS and INP should be reported any time the [page's `visibilityState` changes to hidden](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/bfcache/).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onFID()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want the `callback` function to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each layout shift as it happens) by setting `reportAllChanges` to `true` in the optional, [configuration object](#reportopts) (second parameter).\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended) for measuring these metrics in production.\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, {reportAllChanges: true});\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonFID(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `callback` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Report metrics for soft navigations (experimental)\n\n_**Note:** this is experimental and subject to change._\n\nCurrently Core Web Vitals are only tracked for full page navigations, which can affect how [Single Page Applications](https://web.dev/vitals-spa-faq/) that use so called \"soft navigations\" to update the browser URL and history outside of the normal browser's handling of this. The Chrome team are experimenting with being able to [measure these soft navigations](https://github.com/WICG/soft-navigations) separately and report on Core Web Vitals separately for them.\n\nThis experimental support allows sites to measure how their Core Web Vitals might be measured differently should this happen.\n\nAt present a \"soft navigation\" is defined as happening after the following three things happen:\n\n- A user interaction occurs\n- The URL changes\n- Content is added to the DOM\n- Something is painted to screen.\n\nFor some sites, these heuristics may lead to false positives (that users would not really consider a \"navigation\"), or false negatives (where the user does consider a navigation to have happened despite not missing the above criteria). We welcome feedback at https://github.com/WICG/soft-navigations/issues on the heuristics, at https://crbug.com for bugs in the Chrome implementation, and on [https://github.com/GoogleChrome/web-vitals/pull/308](this pull request) for implementation issues with web-vitals.js.\n\n_**Note:** At this time it is not known if this experiment will be something we want to move forward with. Until such time, this support will likely remain in a separate branch of this project, rather than be included in any production builds. If we decide not to move forward with this, the support of this will likely be removed from this project since this library is intended to mirror the Core Web Vitals as much as possible._\n\nSome important points to note:\n\n- TTFB is reported as 0, and not the time of the first network call (if any) after the soft navigation.\n- FCP and LCP are the first and largest contentful paints after the soft navigation. Prior reported paint times will not be counted for these metrics, even though these elements may remain between soft navigations, and may be the first or largest contentful item.\n- FID is reset to measure the first interaction after the soft navigation.\n- INP is reset to measure only interactions after the the soft navigation.\n- CLS is reset to measure again separate to the first page.\n\n_**Note:** It is not known at this time whether soft navigations will be weighted the same as full navigations. No weighting is included in this library at present and metrics are reported in the same way as full page load metrics._\n\nThe metrics can be reported for Soft Navigations using the `reportSoftNavs: true` reporting option:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(console.log, {reportSoftNavs: true});\nonFID(console.log, {reportSoftNavs: true});\nonLCP(console.log, {reportSoftNavs: true});\n```\n\nNote that this will change the way the first page loads are measured as the metrics for the inital URL will be finalized once the first soft nav occurs. To measure both you need to register two callbacks:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(doTraditionalProcessing);\nonFID(doTraditionalProcessing);\nonLCP(doTraditionalProcessing);\n\nonCLS(doSoftNavProcessing, {reportSoftNavs: true});\nonFID(doSoftNavProcessing, {reportSoftNavs: true});\nonLCP(doSoftNavProcessing, {reportSoftNavs: true});\n```\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n    fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonFID(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique event parameter value (in this case, the metric_id, as shown in the example below) on every metric instance that you send to Google Analytics, you can create a report yourself by first getting the data via the [Google Analytics Data API](https://developers.google.com/analytics/devguides/reporting/data/v1) or via [BigQuery export](https://support.google.com/analytics/answer/9358801) and then visualizing it any charting library you choose.\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // metric_rating: 'good' | 'needs-improvement' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\nFor details on how to query this data in [BigQuery](https://cloud.google.com/bigquery), or visualise it in [Looker Studio](https://lookerstudio.google.com/), see [Measure and debug performance with Google Analytics 4 and BigQuery](https://web.dev/vitals-ga4/).\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n### Send attribution data\n\nWhen using the [attribution build](#attribution-build), you can send additional data to help you debug _why_ the metric values are they way they are.\n\nThis example sends an additional `debug_target` param to Google Analytics, corresponding to the element most associated with each metric.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals/attribution';\n\nfunction sendToGoogleAnalytics({name, delta, value, id, attribution}) {\n  const eventParams = {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n  };\n\n  switch (name) {\n    case 'CLS':\n      eventParams.debug_target = attribution.largestShiftTarget;\n      break;\n    case 'FID':\n      eventParams.debug_target = attribution.eventTarget;\n      break;\n    case 'LCP':\n      eventParams.debug_target = attribution.element;\n      break;\n  }\n\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, eventParams);\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n_**Note:** this example relies on custom [event parameters](https://support.google.com/analytics/answer/11396839) in Google Analytics 4._\n\nSee [Debug performance in the field](https://web.dev/debug-performance-in-the-field/) for more information and examples.\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonFID(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n<a name=\"bundle-versions\"><a>\n\n## Build options\n\nThe `web-vitals` package includes builds for the \"standard\", \"attribution\", and \"base+polyfill\" ([deprecated](https://github.com/GoogleChrome/web-vitals/issues/238)) builds, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the builds distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any attribution features.</p>\n      This is the \"standard\" build and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.cjs</code></td>\n    <td><code>pgk.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.attribution.js</code></td>\n    <td>--</td>\n    <td>\n      An ES module version of all metric functions that includes <a href=\"#attribution-build\">attribution</a> features.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.iife.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An IIFE version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code>, <code>web-vitals.base.umd.cjs</code>, or <code>web-vitals.base.iife.js</code> (it will not work with any script that doesn't have \"base\" in the filename).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n<a name=\"which-build-is-right-for-you\"><a>\n\n### Which build is right for you?\n\nMost developers will generally want to use \"standard\" build (via either the ES module or UMD version, depending on your bundler/build system), as it's the easiest to use out of the box and integrate into existing tools.\n\nHowever, if you'd lke to collect additional debug information to help you diagnose performance bottlenecks based on real-user issues, use the [\"attribution\" build](#attribution-build).\n\nFor guidance on how to collect and use real-user data to debug performance issues, see [Debug performance in the field](https://web.dev/debug-performance-in-the-field/).\n\n### How the polyfill works\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nThe `polyfill.js` script adds event listeners (to track FID cross-browser), and it records initial page visibility state as well as the timestamp of the first visibility change to hidden (to improve the accuracy of CLS, FCP, LCP, and FID). It also polyfills the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) in browsers that only support the original (now deprecated) [Navigation Timing API](https://www.w3.org/TR/navigation-timing/).\n\nIn order for the polyfill to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" build of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" build, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  /**\n   * The name of the metric (in acronym form).\n   */\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  /**\n   * The current value of the metric.\n   */\n  value: number;\n\n  /**\n   * The rating as to whether the metric value is within the \"good\",\n   * \"needs improvement\", or \"poor\" thresholds of the metric.\n   */\n  rating: 'good' | 'needs-improvement' | 'poor';\n\n  /**\n   * The delta between the current value and the last-reported value.\n   * On the first report, `delta` and `value` will always be the same.\n   */\n  delta: number;\n\n  /**\n   * A unique ID representing this particular metric instance. This ID can\n   * be used by an analytics tool to dedupe multiple values sent for the same\n   * metric instance, or to group multiple deltas together and calculate a\n   * total. It can also be used to differentiate multiple different metric\n   * instances sent from the same page, which can happen if the page is\n   * restored from the back/forward cache (in that case new metrics object\n   * get created).\n   */\n  id: string;\n\n  /**\n   * Any performance entries relevant to the metric value calculation.\n   * The array may also be empty if the metric value was not based on any\n   * entries (e.g. a CLS value of 0 given no layout shifts).\n   */\n  entries: (\n    | PerformanceEntry\n    | LayoutShift\n    | FirstInputPolyfillEntry\n    | NavigationTimingPolyfillEntry\n  )[];\n\n  /**\n   * The type of navigation.\n   *\n   * This will be the value returned by the Navigation Timing API (or\n   * `undefined` if the browser doesn't support that API), with the following\n   * exceptions:\n   * - 'back-forward-cache': for pages that are restored from the bfcache.\n   * - 'prerender': for pages that were prerendered.\n   * - 'restore': for pages that were discarded by the browser and then\n   * restored by the user.\n   */\n  navigationType:\n    | 'navigate'\n    | 'reload'\n    | 'back-forward'\n    | 'back-forward-cache'\n    | 'prerender'\n    | 'restore'\n    | 'soft-navigation';\n\n  /**\n   * The navigatonId the metric happened for. This is particularly relevent for soft navigations where\n   * the metric may be reported for a previous URL.\n   */\n  navigatonId: number;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetric`](/src/types/cls.ts#:~:text=interface%20CLSMetric)\n- [`FCPMetric`](/src/types/fcp.ts#:~:text=interface%20FCPMetric)\n- [`FIDMetric`](/src/types/fid.ts#:~:text=interface%20FIDMetric)\n- [`INPMetric`](/src/types/inp.ts#:~:text=interface%20INPMetric)\n- [`LCPMetric`](/src/types/lcp.ts#:~:text=interface%20LCPMetric)\n- [`TTFBMetric`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetric)\n\n#### `MetricWithAttribution`\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n```ts\ninterface MetricWithAttribution extends Metric {\n  /**\n   * An object containing potentially-helpful debugging information that\n   * can be sent along with the metric value for the current page visit in\n   * order to help identify issues happening to real-users in the field.\n   */\n  attribution: {[key: string]: unknown};\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetricWithAttribution`](/src/types/cls.ts#:~:text=interface%20CLSMetricWithAttribution)\n- [`FCPMetricWithAttribution`](/src/types/fcp.ts#:~:text=interface%20FCPMetricWithAttribution)\n- [`FIDMetricWithAttribution`](/src/types/fid.ts#:~:text=interface%20FIDMetricWithAttribution)\n- [`INPMetricWithAttribution`](/src/types/inp.ts#:~:text=interface%20INPMetricWithAttribution)\n- [`LCPMetricWithAttribution`](/src/types/lcp.ts#:~:text=interface%20LCPMetricWithAttribution)\n- [`TTFBMetricWithAttribution`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetricWithAttribution)\n\n#### `MetricRatingThresholds`\n\nThe thresholds of metric's \"good\", \"needs improvement\", and \"poor\" ratings.\n\n- Metric values up to and including [0] are rated \"good\"\n- Metric values up to and including [1] are rated \"needs improvement\"\n- Metric values above [1] are \"poor\"\n\n| Metric value    | Rating              |\n| --------------- | ------------------- |\n| ≦ [0]           | \"good\"              |\n| > [0] and ≦ [1] | \"needs improvement\" |\n| > [1]           | \"poor\"              |\n\n```ts\nexport type MetricRatingThresholds = [number, number];\n```\n\n_See also [Rating Thresholds](#rating-thresholds)._\n\n#### `ReportCallback`\n\n```ts\ninterface ReportCallback {\n  (metric: Metric): void;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSReportCallback`](/src/types/cls.ts#:~:text=interface%20CLSReportCallback)\n- [`FCPReportCallback`](/src/types/fcp.ts#:~:text=interface%20FCPReportCallback)\n- [`FIDReportCallback`](/src/types/fid.ts#:~:text=interface%20FIDReportCallback)\n- [`INPReportCallback`](/src/types/inp.ts#:~:text=interface%20INPReportCallback)\n- [`LCPReportCallback`](/src/types/lcp.ts#:~:text=interface%20LCPReportCallback)\n- [`TTFBReportCallback`](/src/types/ttfb.ts#:~:text=interface%20TTFBReportCallback)\n\n#### `ReportOpts`\n\n```ts\ninterface ReportOpts {\n  reportAllChanges?: boolean;\n  durationThreshold?: number;\n  reportSoftNavs?: boolean;\n}\n```\n\n#### `LoadState`\n\nThe `LoadState` type is used in several of the metric [attribution objects](#attribution).\n\n```ts\n/**\n * The loading state of the document. Note: this value is similar to\n * `document.readyState` but it subdivides the \"interactive\" state into the\n * time before and after the DOMContentLoaded event fires.\n *\n * State descriptions:\n * - `loading`: the initial document response has not yet been fully downloaded\n *   and parsed. This is equivalent to the corresponding `readyState` value.\n * - `dom-interactive`: the document has been fully loaded and parsed, but\n *   scripts may not have yet finished loading and executing.\n * - `dom-content-loaded`: the document is fully loaded and parsed, and all\n *   scripts (except `async` scripts) have loaded and finished executing.\n * - `complete`: the document and all of its sub-resources have finished\n *   loading. This is equivalent to the corresponding `readyState` value.\n */\ntype LoadState =\n  | 'loading'\n  | 'dom-interactive'\n  | 'dom-content-loaded'\n  | 'complete';\n```\n\n#### `FirstInputPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't natively support the Event Timing API), the `metric.entries` reported by `onFID()` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<\n  PerformanceEventTiming,\n  'processingEnd' | 'toJSON'\n>;\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface), the `metric.entries` reported by `onTTFB()` will contain an object that polyfills the `PerformanceNavigationTiming` entry using timings from the legacy `performance.timing` interface:\n\n```ts\ntype NavigationTimingPolyfillEntry = Omit<\n  PerformanceNavigationTiming,\n  | 'initiatorType'\n  | 'nextHopProtocol'\n  | 'redirectCount'\n  | 'transferSize'\n  | 'encodedBodySize'\n  | 'decodedBodySize'\n  | 'type'\n> & {\n  type: PerformanceNavigationTiming['type'];\n};\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n  firstHiddenTime: number;\n}\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (callback: CLSReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [CLS](https://web.dev/cls/) value for the current page and calls the `callback` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/cls/#layout-shift-score)).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (callback: FCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FCP](https://web.dev/fcp/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n```ts\ntype onFID = (callback: FIDReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FID](https://web.dev/fid/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (callback: INPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [INP](https://web.dev/inp/) value for the current page and calls the `callback` function once the value is ready, along with the `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nA custom `durationThreshold` [configuration option](#reportopts) can optionally be passed to control what `event-timing` entries are considered for INP reporting. The default threshold is `40`, which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended [good](https://web.dev/inp/#what-is-a-good-inp-score) threshold).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (callback: LCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [LCP](https://web.dev/lcp/) value for the current page and calls the `callback` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (callback: TTFBReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [TTFB](https://web.dev/time-to-first-byte/) value for the current page and calls the `callback` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `callback` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it includes time spent on DNS lookup, connection negotiation, network latency, and server processing time.\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n### Rating Thresholds:\n\nThe thresholds of each metric's \"good\", \"needs improvement\", and \"poor\" ratings are available as [`MetricRatingThresholds`](#metricratingthresholds).\n\nExample:\n\n```ts\nimport {CLSThresholds, FIDThresholds, LCPThresholds} from 'web-vitals';\n\nconsole.log(CLSThresholds); // [ 0.1, 0.25 ]\nconsole.log(FIDThresholds); // [ 100, 300 ]\nconsole.log(LCPThresholds); // [ 2500, 4000 ]\n```\n\n_**Note:** It's typically not necessary (or recommended) to manually calculate metric value ratings using these thresholds. Use the [`Metric['rating']`](#metric) supplied by the [`ReportCallback`](#reportcallback) functions instead._\n\n### Attribution:\n\nThe following objects contain potentially-helpful debugging information that can be sent along with the metric values for the current page visit in order to help identify issues happening to real-users in the field.\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n#### CLS `attribution`:\n\n```ts\ninterface CLSAttribution {\n  /**\n   * A selector identifying the first element (in document order) that\n   * shifted when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTarget?: string;\n  /**\n   * The time when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTime?: DOMHighResTimeStamp;\n  /**\n   * The layout shift score of the single largest layout shift contributing to\n   * the page's CLS score.\n   */\n  largestShiftValue?: number;\n  /**\n   * The `LayoutShiftEntry` representing the single largest layout shift\n   * contributing to the page's CLS score. (Useful when you need more than just\n   * `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftEntry?: LayoutShift;\n  /**\n   * The first element source (in document order) among the `sources` list\n   * of the `largestShiftEntry` object. (Also useful when you need more than\n   * just `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftSource?: LayoutShiftAttribution;\n  /**\n   * The loading state of the document at the time when the largest layout\n   * shift contribution to the page's CLS score occurred (see `LoadState`\n   * for details).\n   */\n  loadState?: LoadState;\n}\n```\n\n#### FCP `attribution`:\n\n```ts\ninterface FCPAttribution {\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB).\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and the first contentful paint (FCP).\n   */\n  firstByteToFCP: number;\n  /**\n   * The loading state of the document at the time when FCP `occurred (see\n   * `LoadState` for details). Ideally, documents can paint before they finish\n   * loading (e.g. the `loading` or `dom-interactive` phases).\n   */\n  loadState: LoadState;\n  /**\n   * The `PerformancePaintTiming` entry corresponding to FCP.\n   */\n  fcpEntry?: PerformancePaintTiming;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n#### FID `attribution`:\n\n```ts\ninterface FIDAttribution {\n  /**\n   * A selector identifying the element that the user interacted with. This\n   * element will be the `target` of the `event` dispatched.\n   */\n  eventTarget: string;\n  /**\n   * The time when the user interacted. This time will match the `timeStamp`\n   * value of the `event` dispatched.\n   */\n  eventTime: number;\n  /**\n   * The `type` of the `event` dispatched from the user interaction.\n   */\n  eventType: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to FID (or the\n   * polyfill entry in browsers that don't support Event Timing).\n   */\n  eventEntry: PerformanceEventTiming | FirstInputPolyfillEntry;\n  /**\n   * The loading state of the document at the time when the first interaction\n   * occurred (see `LoadState` for details). If the first interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long input delays.\n   */\n  loadState: LoadState;\n}\n```\n\n#### INP `attribution`:\n\n```ts\ninterface INPAttribution {\n  /**\n   * A selector identifying the element that the user interacted with for\n   * the event corresponding to INP. This element will be the `target` of the\n   * `event` dispatched.\n   */\n  eventTarget?: string;\n  /**\n   * The time when the user interacted for the event corresponding to INP.\n   * This time will match the `timeStamp` value of the `event` dispatched.\n   */\n  eventTime?: number;\n  /**\n   * The `type` of the `event` dispatched corresponding to INP.\n   */\n  eventType?: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to INP.\n   */\n  eventEntry?: PerformanceEventTiming;\n  /**\n   * The loading state of the document at the time when the even corresponding\n   * to INP occurred (see `LoadState` for details). If the interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long delays.\n   */\n  loadState?: LoadState;\n}\n```\n\n#### LCP `attribution`:\n\n```ts\ninterface LCPAttribution {\n  /**\n   * The element corresponding to the largest contentful paint for the page.\n   */\n  element?: string;\n  /**\n   * The URL (if applicable) of the LCP image resource. If the LCP element\n   * is a text node, this value will not be set.\n   */\n  url?: string;\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB). See\n   * [Optimize LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and when the browser starts loading the LCP\n   * resource (if there is one, otherwise 0). See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  resourceLoadDelay: number;\n  /**\n   * The total time it takes to load the LCP resource itself (if there is one,\n   * otherwise 0). See [Optimize LCP](https://web.dev/optimize-lcp/) for\n   * details.\n   */\n  resourceLoadTime: number;\n  /**\n   * The delta between when the LCP resource finishes loading until the LCP\n   * element is fully rendered. See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  elementRenderDelay: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n  /**\n   * The `resource` entry for the LCP resource (if applicable), which is useful\n   * for diagnosing resource load issues.\n   */\n  lcpResourceEntry?: PerformanceResourceTiming;\n  /**\n   * The `LargestContentfulPaint` entry corresponding to LCP.\n   */\n  lcpEntry?: LargestContentfulPaint;\n}\n```\n\n#### TTFB `attribution`:\n\n```ts\ninterface TTFBAttribution {\n  /**\n   * The total time from when the user initiates loading the page to when the\n   * DNS lookup begins. This includes redirects, service worker startup, and\n   * HTTP cache lookup times.\n   */\n  waitingTime: number;\n  /**\n   * The total time to resolve the DNS for the current request.\n   */\n  dnsTime: number;\n  /**\n   * The total time to create the connection to the requested domain.\n   */\n  connectionTime: number;\n  /**\n   * The time time from when the request was sent until the first byte of the\n   * response was received. This includes network time as well as server\n   * processing time.\n   */\n  requestTime: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium\n- `onFCP()`: Chromium, Firefox, Safari 14.1+\n- `onFID()`: Chromium, Firefox _(with [polyfill](#how-to-use-the-polyfill): Safari, Internet Explorer)_\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari 15+ _(with [polyfill](#how-to-use-the-polyfill): Safari 8+, Internet Explorer)_\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that measure the Web Vitals metrics, which means the limitations of those APIs will mostly apply to this library as well. More details on these limitations is available in [this blog post](https://web.dev/crux-and-rum-differences/).\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/vitals-ga4/).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `callback` functions and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"5de5e890cb201e2c19c7be67c9ad006ec743ad3f","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.5.0-soft-navs-11","_nodeVersion":"18.16.0","_npmVersion":"9.5.1","dist":{"integrity":"sha512-smvxHwYZBBxu4IGO1jr/4S7AiGE9rOjn+WuGCtal4GvLpNfVVqtYl62DXu8KlLeQPrwPVey8SbrTenVeepQ90g==","shasum":"63513ae571b9287e2fc7105954189eb8388282a4","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.5.0-soft-navs-11.tgz","fileCount":146,"unpackedSize":456982,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIAPfAAzQwizlun7WvtM5NBvoJhRyX+lroUmsM3h2jOn8AiEAu1k5ZX3zZjuKN0nnAHLhiVsXaOedLkJqEAtZ8dQrLFw="}]},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.5.0-soft-navs-11_1702501946256_0.009592630661957147"},"_hasShrinkwrap":false},"3.5.0-soft-navs-12":{"name":"web-vitals","version":"3.5.0-soft-navs-12","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build test:unit -p -r test:e2e test:server","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","test:unit":"node --test test/unit/*test.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.21.0","@babel/preset-env":"^7.20.2","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.54.1","@typescript-eslint/parser":"^5.54.1","@wdio/cli":"^7.30.2","@wdio/local-runner":"^7.30.2","@wdio/mocha-framework":"^7.30.2","@wdio/selenium-standalone-service":"^7.32.4","@wdio/spec-reporter":"^7.30.2","body-parser":"^1.20.2","chromedriver":"^117.0.3","eslint":"^8.35.0","express":"^4.18.2","fs-extra":"^10.1.0","husky":"^8.0.3","lint-staged":"^13.1.2","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","prettier":"^2.8.4","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","selenium-standalone":"^8.3.0","typescript":"^4.9.5","wdio-chromedriver-service":"^8.1.1"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Send attribution data](#send-attribution-data)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Build options](#build-options)\n  - [Which build is right for you?](#which-build-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n  - [Rating Thresholds](#rating-thresholds)\n  - [Attribution](#attribution)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1.5K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/vitals/) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/vitals/#core-web-vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/user-centric-performance-metrics/) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/cls/)\n- [First Input Delay (FID)](https://web.dev/fid/)\n- [Largest Contentful Paint (LCP)](https://web.dev/lcp/)\n\n### Other metrics\n\n- [Interaction to next Paint (INP)](https://web.dev/inp/)\n- [First Contentful Paint (FCP)](https://web.dev/fcp/)\n- [Time to First Byte (TTFB)](https://web.dev/ttfb/)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\nThe `web-vitals` library uses the `buffered` flag for [PerformanceObserver](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver/observe), allowing it to access performance entries that occurred before the library was loaded.\n\nThis means you do not need to load this library early in order to get accurate performance data. In general, this library should be deferred until after other user-impacting code has loaded.\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are a few different builds of the `web-vitals` library, and how you load the library depends on which build you want to use.\n\nFor details on the difference between the builds, see <a href=\"#which-build-is-right-for-you\">which build is right for you</a>.\n\n**1. The \"standard\" build**\n\nTo load the \"standard\" build, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onFID, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functions were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"attribution-build\"><a>\n\n**2. The \"attribution\" build**\n\nMeasuring the Web Vitals scores for your real users is a great first step toward optimizing the user experience. But if your scores aren't _good_, the next step is to understand why they're not good and work to improve them.\n\nThe \"attribution\" build helps you do that by including additional diagnostic information with each metric to help you identify the root cause of poor performance as well as prioritize the most important things to fix.\n\nThe \"attribution\" build is slightly larger than the \"standard\" build (by about 600 bytes, brotli'd), so while the code size is still small, it's only recommended if you're actually using these features.\n\nTo load the \"attribution\" build, change any `import` statements that reference `web-vitals` to `web-vitals/attribution`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/attribution';\n```\n\nUsage for each of the imported function is identical to the standard build, but when importing from the attribution build, the [`Metric`](#metric) object will contain an additional [`attribution`](#metricwithattribution) property.\n\nSee [Send attribution data](#send-attribution-data) for usage examples, and the [`attribution` reference](#attribution) for details on what values are added for each metric.\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**3. The \"base+polyfill\" build**\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nLoading the \"base+polyfill\" build is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nIt's important that the code is inlined directly into the HTML. _Do not link to an external script file, as that will negatively affect performance:_\n\n```html\n<!-- GOOD -->\n<script>\n  // Inline code from `dist/polyfill.js` here\n</script>\n\n<!-- BAD! DO NOT DO! -->\n<script src=\"/path/to/polyfill.js\"></script>\n```\n\nAlso note that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com):\n\n_**Important!** The [unpkg.com](https://unpkg.com) CDN is shown here for example purposes only. `unpkg.com` is not affiliated with Google, and there are no guarantees that the URLs shown in these examples will continue to work in the future._\n\n**Load the \"standard\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals@3?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src = 'https://unpkg.com/web-vitals@3/dist/web-vitals.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n**Load the \"attribution\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {\n    onCLS,\n    onFID,\n    onLCP,\n  } from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"attribution\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src =\n      'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes a `callback` function that will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" build, but they will work with the \"attribution\" build as well.)_\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developer.chrome.com/docs/devtools/console/reference/#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID and INP are not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS and INP should be reported any time the [page's `visibilityState` changes to hidden](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/bfcache/).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onFID()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want the `callback` function to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each layout shift as it happens) by setting `reportAllChanges` to `true` in the optional, [configuration object](#reportopts) (second parameter).\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended) for measuring these metrics in production.\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, {reportAllChanges: true});\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonFID(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `callback` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Report metrics for soft navigations (experimental)\n\n_**Note:** this is experimental and subject to change._\n\nCurrently Core Web Vitals are only tracked for full page navigations, which can affect how [Single Page Applications](https://web.dev/vitals-spa-faq/) that use so called \"soft navigations\" to update the browser URL and history outside of the normal browser's handling of this. The Chrome team are experimenting with being able to [measure these soft navigations](https://github.com/WICG/soft-navigations) separately and report on Core Web Vitals separately for them.\n\nThis experimental support allows sites to measure how their Core Web Vitals might be measured differently should this happen.\n\nAt present a \"soft navigation\" is defined as happening after the following three things happen:\n\n- A user interaction occurs\n- The URL changes\n- Content is added to the DOM\n- Something is painted to screen.\n\nFor some sites, these heuristics may lead to false positives (that users would not really consider a \"navigation\"), or false negatives (where the user does consider a navigation to have happened despite not missing the above criteria). We welcome feedback at https://github.com/WICG/soft-navigations/issues on the heuristics, at https://crbug.com for bugs in the Chrome implementation, and on [https://github.com/GoogleChrome/web-vitals/pull/308](this pull request) for implementation issues with web-vitals.js.\n\n_**Note:** At this time it is not known if this experiment will be something we want to move forward with. Until such time, this support will likely remain in a separate branch of this project, rather than be included in any production builds. If we decide not to move forward with this, the support of this will likely be removed from this project since this library is intended to mirror the Core Web Vitals as much as possible._\n\nSome important points to note:\n\n- TTFB is reported as 0, and not the time of the first network call (if any) after the soft navigation.\n- FCP and LCP are the first and largest contentful paints after the soft navigation. Prior reported paint times will not be counted for these metrics, even though these elements may remain between soft navigations, and may be the first or largest contentful item.\n- FID is reset to measure the first interaction after the soft navigation.\n- INP is reset to measure only interactions after the the soft navigation.\n- CLS is reset to measure again separate to the first page.\n\n_**Note:** It is not known at this time whether soft navigations will be weighted the same as full navigations. No weighting is included in this library at present and metrics are reported in the same way as full page load metrics._\n\nThe metrics can be reported for Soft Navigations using the `reportSoftNavs: true` reporting option:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(console.log, {reportSoftNavs: true});\nonFID(console.log, {reportSoftNavs: true});\nonLCP(console.log, {reportSoftNavs: true});\n```\n\nNote that this will change the way the first page loads are measured as the metrics for the inital URL will be finalized once the first soft nav occurs. To measure both you need to register two callbacks:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(doTraditionalProcessing);\nonFID(doTraditionalProcessing);\nonLCP(doTraditionalProcessing);\n\nonCLS(doSoftNavProcessing, {reportSoftNavs: true});\nonFID(doSoftNavProcessing, {reportSoftNavs: true});\nonLCP(doSoftNavProcessing, {reportSoftNavs: true});\n```\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n    fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonFID(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique event parameter value (in this case, the metric_id, as shown in the example below) on every metric instance that you send to Google Analytics, you can create a report yourself by first getting the data via the [Google Analytics Data API](https://developers.google.com/analytics/devguides/reporting/data/v1) or via [BigQuery export](https://support.google.com/analytics/answer/9358801) and then visualizing it any charting library you choose.\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // metric_rating: 'good' | 'needs-improvement' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\nFor details on how to query this data in [BigQuery](https://cloud.google.com/bigquery), or visualise it in [Looker Studio](https://lookerstudio.google.com/), see [Measure and debug performance with Google Analytics 4 and BigQuery](https://web.dev/vitals-ga4/).\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n### Send attribution data\n\nWhen using the [attribution build](#attribution-build), you can send additional data to help you debug _why_ the metric values are they way they are.\n\nThis example sends an additional `debug_target` param to Google Analytics, corresponding to the element most associated with each metric.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals/attribution';\n\nfunction sendToGoogleAnalytics({name, delta, value, id, attribution}) {\n  const eventParams = {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n  };\n\n  switch (name) {\n    case 'CLS':\n      eventParams.debug_target = attribution.largestShiftTarget;\n      break;\n    case 'FID':\n      eventParams.debug_target = attribution.eventTarget;\n      break;\n    case 'LCP':\n      eventParams.debug_target = attribution.element;\n      break;\n  }\n\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, eventParams);\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n_**Note:** this example relies on custom [event parameters](https://support.google.com/analytics/answer/11396839) in Google Analytics 4._\n\nSee [Debug performance in the field](https://web.dev/debug-performance-in-the-field/) for more information and examples.\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonFID(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n<a name=\"bundle-versions\"><a>\n\n## Build options\n\nThe `web-vitals` package includes builds for the \"standard\", \"attribution\", and \"base+polyfill\" ([deprecated](https://github.com/GoogleChrome/web-vitals/issues/238)) builds, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the builds distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any attribution features.</p>\n      This is the \"standard\" build and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.cjs</code></td>\n    <td><code>pgk.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.attribution.js</code></td>\n    <td>--</td>\n    <td>\n      An ES module version of all metric functions that includes <a href=\"#attribution-build\">attribution</a> features.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.iife.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An IIFE version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code>, <code>web-vitals.base.umd.cjs</code>, or <code>web-vitals.base.iife.js</code> (it will not work with any script that doesn't have \"base\" in the filename).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n<a name=\"which-build-is-right-for-you\"><a>\n\n### Which build is right for you?\n\nMost developers will generally want to use \"standard\" build (via either the ES module or UMD version, depending on your bundler/build system), as it's the easiest to use out of the box and integrate into existing tools.\n\nHowever, if you'd lke to collect additional debug information to help you diagnose performance bottlenecks based on real-user issues, use the [\"attribution\" build](#attribution-build).\n\nFor guidance on how to collect and use real-user data to debug performance issues, see [Debug performance in the field](https://web.dev/debug-performance-in-the-field/).\n\n### How the polyfill works\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nThe `polyfill.js` script adds event listeners (to track FID cross-browser), and it records initial page visibility state as well as the timestamp of the first visibility change to hidden (to improve the accuracy of CLS, FCP, LCP, and FID). It also polyfills the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) in browsers that only support the original (now deprecated) [Navigation Timing API](https://www.w3.org/TR/navigation-timing/).\n\nIn order for the polyfill to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" build of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" build, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  /**\n   * The name of the metric (in acronym form).\n   */\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  /**\n   * The current value of the metric.\n   */\n  value: number;\n\n  /**\n   * The rating as to whether the metric value is within the \"good\",\n   * \"needs improvement\", or \"poor\" thresholds of the metric.\n   */\n  rating: 'good' | 'needs-improvement' | 'poor';\n\n  /**\n   * The delta between the current value and the last-reported value.\n   * On the first report, `delta` and `value` will always be the same.\n   */\n  delta: number;\n\n  /**\n   * A unique ID representing this particular metric instance. This ID can\n   * be used by an analytics tool to dedupe multiple values sent for the same\n   * metric instance, or to group multiple deltas together and calculate a\n   * total. It can also be used to differentiate multiple different metric\n   * instances sent from the same page, which can happen if the page is\n   * restored from the back/forward cache (in that case new metrics object\n   * get created).\n   */\n  id: string;\n\n  /**\n   * Any performance entries relevant to the metric value calculation.\n   * The array may also be empty if the metric value was not based on any\n   * entries (e.g. a CLS value of 0 given no layout shifts).\n   */\n  entries: (\n    | PerformanceEntry\n    | LayoutShift\n    | FirstInputPolyfillEntry\n    | NavigationTimingPolyfillEntry\n  )[];\n\n  /**\n   * The type of navigation.\n   *\n   * This will be the value returned by the Navigation Timing API (or\n   * `undefined` if the browser doesn't support that API), with the following\n   * exceptions:\n   * - 'back-forward-cache': for pages that are restored from the bfcache.\n   * - 'prerender': for pages that were prerendered.\n   * - 'restore': for pages that were discarded by the browser and then\n   * restored by the user.\n   */\n  navigationType:\n    | 'navigate'\n    | 'reload'\n    | 'back-forward'\n    | 'back-forward-cache'\n    | 'prerender'\n    | 'restore'\n    | 'soft-navigation';\n\n  /**\n   * The navigatonId the metric happened for. This is particularly relevent for soft navigations where\n   * the metric may be reported for a previous URL.\n   */\n  navigatonId: number;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetric`](/src/types/cls.ts#:~:text=interface%20CLSMetric)\n- [`FCPMetric`](/src/types/fcp.ts#:~:text=interface%20FCPMetric)\n- [`FIDMetric`](/src/types/fid.ts#:~:text=interface%20FIDMetric)\n- [`INPMetric`](/src/types/inp.ts#:~:text=interface%20INPMetric)\n- [`LCPMetric`](/src/types/lcp.ts#:~:text=interface%20LCPMetric)\n- [`TTFBMetric`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetric)\n\n#### `MetricWithAttribution`\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n```ts\ninterface MetricWithAttribution extends Metric {\n  /**\n   * An object containing potentially-helpful debugging information that\n   * can be sent along with the metric value for the current page visit in\n   * order to help identify issues happening to real-users in the field.\n   */\n  attribution: {[key: string]: unknown};\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetricWithAttribution`](/src/types/cls.ts#:~:text=interface%20CLSMetricWithAttribution)\n- [`FCPMetricWithAttribution`](/src/types/fcp.ts#:~:text=interface%20FCPMetricWithAttribution)\n- [`FIDMetricWithAttribution`](/src/types/fid.ts#:~:text=interface%20FIDMetricWithAttribution)\n- [`INPMetricWithAttribution`](/src/types/inp.ts#:~:text=interface%20INPMetricWithAttribution)\n- [`LCPMetricWithAttribution`](/src/types/lcp.ts#:~:text=interface%20LCPMetricWithAttribution)\n- [`TTFBMetricWithAttribution`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetricWithAttribution)\n\n#### `MetricRatingThresholds`\n\nThe thresholds of metric's \"good\", \"needs improvement\", and \"poor\" ratings.\n\n- Metric values up to and including [0] are rated \"good\"\n- Metric values up to and including [1] are rated \"needs improvement\"\n- Metric values above [1] are \"poor\"\n\n| Metric value    | Rating              |\n| --------------- | ------------------- |\n| ≦ [0]           | \"good\"              |\n| > [0] and ≦ [1] | \"needs improvement\" |\n| > [1]           | \"poor\"              |\n\n```ts\nexport type MetricRatingThresholds = [number, number];\n```\n\n_See also [Rating Thresholds](#rating-thresholds)._\n\n#### `ReportCallback`\n\n```ts\ninterface ReportCallback {\n  (metric: Metric): void;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSReportCallback`](/src/types/cls.ts#:~:text=interface%20CLSReportCallback)\n- [`FCPReportCallback`](/src/types/fcp.ts#:~:text=interface%20FCPReportCallback)\n- [`FIDReportCallback`](/src/types/fid.ts#:~:text=interface%20FIDReportCallback)\n- [`INPReportCallback`](/src/types/inp.ts#:~:text=interface%20INPReportCallback)\n- [`LCPReportCallback`](/src/types/lcp.ts#:~:text=interface%20LCPReportCallback)\n- [`TTFBReportCallback`](/src/types/ttfb.ts#:~:text=interface%20TTFBReportCallback)\n\n#### `ReportOpts`\n\n```ts\ninterface ReportOpts {\n  reportAllChanges?: boolean;\n  durationThreshold?: number;\n  reportSoftNavs?: boolean;\n}\n```\n\n#### `LoadState`\n\nThe `LoadState` type is used in several of the metric [attribution objects](#attribution).\n\n```ts\n/**\n * The loading state of the document. Note: this value is similar to\n * `document.readyState` but it subdivides the \"interactive\" state into the\n * time before and after the DOMContentLoaded event fires.\n *\n * State descriptions:\n * - `loading`: the initial document response has not yet been fully downloaded\n *   and parsed. This is equivalent to the corresponding `readyState` value.\n * - `dom-interactive`: the document has been fully loaded and parsed, but\n *   scripts may not have yet finished loading and executing.\n * - `dom-content-loaded`: the document is fully loaded and parsed, and all\n *   scripts (except `async` scripts) have loaded and finished executing.\n * - `complete`: the document and all of its sub-resources have finished\n *   loading. This is equivalent to the corresponding `readyState` value.\n */\ntype LoadState =\n  | 'loading'\n  | 'dom-interactive'\n  | 'dom-content-loaded'\n  | 'complete';\n```\n\n#### `FirstInputPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't natively support the Event Timing API), the `metric.entries` reported by `onFID()` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<\n  PerformanceEventTiming,\n  'processingEnd' | 'toJSON'\n>;\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface), the `metric.entries` reported by `onTTFB()` will contain an object that polyfills the `PerformanceNavigationTiming` entry using timings from the legacy `performance.timing` interface:\n\n```ts\ntype NavigationTimingPolyfillEntry = Omit<\n  PerformanceNavigationTiming,\n  | 'initiatorType'\n  | 'nextHopProtocol'\n  | 'redirectCount'\n  | 'transferSize'\n  | 'encodedBodySize'\n  | 'decodedBodySize'\n  | 'type'\n> & {\n  type: PerformanceNavigationTiming['type'];\n};\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n  firstHiddenTime: number;\n}\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (callback: CLSReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [CLS](https://web.dev/cls/) value for the current page and calls the `callback` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/cls/#layout-shift-score)).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (callback: FCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FCP](https://web.dev/fcp/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n```ts\ntype onFID = (callback: FIDReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FID](https://web.dev/fid/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (callback: INPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [INP](https://web.dev/inp/) value for the current page and calls the `callback` function once the value is ready, along with the `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nA custom `durationThreshold` [configuration option](#reportopts) can optionally be passed to control what `event-timing` entries are considered for INP reporting. The default threshold is `40`, which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended [good](https://web.dev/inp/#what-is-a-good-inp-score) threshold).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (callback: LCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [LCP](https://web.dev/lcp/) value for the current page and calls the `callback` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (callback: TTFBReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [TTFB](https://web.dev/time-to-first-byte/) value for the current page and calls the `callback` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `callback` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it includes time spent on DNS lookup, connection negotiation, network latency, and server processing time.\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n### Rating Thresholds:\n\nThe thresholds of each metric's \"good\", \"needs improvement\", and \"poor\" ratings are available as [`MetricRatingThresholds`](#metricratingthresholds).\n\nExample:\n\n```ts\nimport {CLSThresholds, FIDThresholds, LCPThresholds} from 'web-vitals';\n\nconsole.log(CLSThresholds); // [ 0.1, 0.25 ]\nconsole.log(FIDThresholds); // [ 100, 300 ]\nconsole.log(LCPThresholds); // [ 2500, 4000 ]\n```\n\n_**Note:** It's typically not necessary (or recommended) to manually calculate metric value ratings using these thresholds. Use the [`Metric['rating']`](#metric) supplied by the [`ReportCallback`](#reportcallback) functions instead._\n\n### Attribution:\n\nThe following objects contain potentially-helpful debugging information that can be sent along with the metric values for the current page visit in order to help identify issues happening to real-users in the field.\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n#### CLS `attribution`:\n\n```ts\ninterface CLSAttribution {\n  /**\n   * A selector identifying the first element (in document order) that\n   * shifted when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTarget?: string;\n  /**\n   * The time when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTime?: DOMHighResTimeStamp;\n  /**\n   * The layout shift score of the single largest layout shift contributing to\n   * the page's CLS score.\n   */\n  largestShiftValue?: number;\n  /**\n   * The `LayoutShiftEntry` representing the single largest layout shift\n   * contributing to the page's CLS score. (Useful when you need more than just\n   * `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftEntry?: LayoutShift;\n  /**\n   * The first element source (in document order) among the `sources` list\n   * of the `largestShiftEntry` object. (Also useful when you need more than\n   * just `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftSource?: LayoutShiftAttribution;\n  /**\n   * The loading state of the document at the time when the largest layout\n   * shift contribution to the page's CLS score occurred (see `LoadState`\n   * for details).\n   */\n  loadState?: LoadState;\n}\n```\n\n#### FCP `attribution`:\n\n```ts\ninterface FCPAttribution {\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB).\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and the first contentful paint (FCP).\n   */\n  firstByteToFCP: number;\n  /**\n   * The loading state of the document at the time when FCP `occurred (see\n   * `LoadState` for details). Ideally, documents can paint before they finish\n   * loading (e.g. the `loading` or `dom-interactive` phases).\n   */\n  loadState: LoadState;\n  /**\n   * The `PerformancePaintTiming` entry corresponding to FCP.\n   */\n  fcpEntry?: PerformancePaintTiming;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n#### FID `attribution`:\n\n```ts\ninterface FIDAttribution {\n  /**\n   * A selector identifying the element that the user interacted with. This\n   * element will be the `target` of the `event` dispatched.\n   */\n  eventTarget: string;\n  /**\n   * The time when the user interacted. This time will match the `timeStamp`\n   * value of the `event` dispatched.\n   */\n  eventTime: number;\n  /**\n   * The `type` of the `event` dispatched from the user interaction.\n   */\n  eventType: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to FID (or the\n   * polyfill entry in browsers that don't support Event Timing).\n   */\n  eventEntry: PerformanceEventTiming | FirstInputPolyfillEntry;\n  /**\n   * The loading state of the document at the time when the first interaction\n   * occurred (see `LoadState` for details). If the first interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long input delays.\n   */\n  loadState: LoadState;\n}\n```\n\n#### INP `attribution`:\n\n```ts\ninterface INPAttribution {\n  /**\n   * A selector identifying the element that the user interacted with for\n   * the event corresponding to INP. This element will be the `target` of the\n   * `event` dispatched.\n   */\n  eventTarget?: string;\n  /**\n   * The time when the user interacted for the event corresponding to INP.\n   * This time will match the `timeStamp` value of the `event` dispatched.\n   */\n  eventTime?: number;\n  /**\n   * The `type` of the `event` dispatched corresponding to INP.\n   */\n  eventType?: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to INP.\n   */\n  eventEntry?: PerformanceEventTiming;\n  /**\n   * The loading state of the document at the time when the even corresponding\n   * to INP occurred (see `LoadState` for details). If the interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long delays.\n   */\n  loadState?: LoadState;\n}\n```\n\n#### LCP `attribution`:\n\n```ts\ninterface LCPAttribution {\n  /**\n   * The element corresponding to the largest contentful paint for the page.\n   */\n  element?: string;\n  /**\n   * The URL (if applicable) of the LCP image resource. If the LCP element\n   * is a text node, this value will not be set.\n   */\n  url?: string;\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB). See\n   * [Optimize LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and when the browser starts loading the LCP\n   * resource (if there is one, otherwise 0). See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  resourceLoadDelay: number;\n  /**\n   * The total time it takes to load the LCP resource itself (if there is one,\n   * otherwise 0). See [Optimize LCP](https://web.dev/optimize-lcp/) for\n   * details.\n   */\n  resourceLoadTime: number;\n  /**\n   * The delta between when the LCP resource finishes loading until the LCP\n   * element is fully rendered. See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  elementRenderDelay: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n  /**\n   * The `resource` entry for the LCP resource (if applicable), which is useful\n   * for diagnosing resource load issues.\n   */\n  lcpResourceEntry?: PerformanceResourceTiming;\n  /**\n   * The `LargestContentfulPaint` entry corresponding to LCP.\n   */\n  lcpEntry?: LargestContentfulPaint;\n}\n```\n\n#### TTFB `attribution`:\n\n```ts\ninterface TTFBAttribution {\n  /**\n   * The total time from when the user initiates loading the page to when the\n   * DNS lookup begins. This includes redirects, service worker startup, and\n   * HTTP cache lookup times.\n   */\n  waitingTime: number;\n  /**\n   * The total time to resolve the DNS for the current request.\n   */\n  dnsTime: number;\n  /**\n   * The total time to create the connection to the requested domain.\n   */\n  connectionTime: number;\n  /**\n   * The time time from when the request was sent until the first byte of the\n   * response was received. This includes network time as well as server\n   * processing time.\n   */\n  requestTime: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium\n- `onFCP()`: Chromium, Firefox, Safari 14.1+\n- `onFID()`: Chromium, Firefox _(with [polyfill](#how-to-use-the-polyfill): Safari, Internet Explorer)_\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari 15+ _(with [polyfill](#how-to-use-the-polyfill): Safari 8+, Internet Explorer)_\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that measure the Web Vitals metrics, which means the limitations of those APIs will mostly apply to this library as well. More details on these limitations is available in [this blog post](https://web.dev/crux-and-rum-differences/).\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/vitals-ga4/).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `callback` functions and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"2dea9a2c720db3230b312c06d7211d715b782aaf","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.5.0-soft-navs-12","_nodeVersion":"18.16.0","_npmVersion":"9.5.1","dist":{"integrity":"sha512-R5XK8SJW8zaD4G45QVCReSHpIZT4LY3G8/An178Cufuj0RIyZNuSLW/z5i4uB1YmdD1ttP3mhiva65WGfVvb0A==","shasum":"55276b7ba892f0be688cf15258fa76bab0f432b2","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.5.0-soft-navs-12.tgz","fileCount":146,"unpackedSize":457616,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQDcMjiOoG+Viw3L+E1TzmIHfPi685LPU6DuEdY+Wm9ZeAIhAPM+/fNn7i04d6DT/JyDfindLAy7rGRT2+AWDC5eL9DN"}]},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.5.0-soft-navs-12_1702505863208_0.6944845725354043"},"_hasShrinkwrap":false},"3.5.0-soft-navs-13":{"name":"web-vitals","version":"3.5.0-soft-navs-13","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build test:unit -p -r test:e2e test:server","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","test:unit":"node --test test/unit/*test.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.21.0","@babel/preset-env":"^7.20.2","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.54.1","@typescript-eslint/parser":"^5.54.1","@wdio/cli":"^7.30.2","@wdio/local-runner":"^7.30.2","@wdio/mocha-framework":"^7.30.2","@wdio/selenium-standalone-service":"^7.32.4","@wdio/spec-reporter":"^7.30.2","body-parser":"^1.20.2","chromedriver":"^117.0.3","eslint":"^8.35.0","express":"^4.18.2","fs-extra":"^10.1.0","husky":"^8.0.3","lint-staged":"^13.1.2","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","prettier":"^2.8.4","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","selenium-standalone":"^8.3.0","typescript":"^4.9.5","wdio-chromedriver-service":"^8.1.1"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Send attribution data](#send-attribution-data)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Build options](#build-options)\n  - [Which build is right for you?](#which-build-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n  - [Rating Thresholds](#rating-thresholds)\n  - [Attribution](#attribution)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1.5K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/vitals/) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/vitals/#core-web-vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/user-centric-performance-metrics/) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/cls/)\n- [First Input Delay (FID)](https://web.dev/fid/)\n- [Largest Contentful Paint (LCP)](https://web.dev/lcp/)\n\n### Other metrics\n\n- [Interaction to next Paint (INP)](https://web.dev/inp/)\n- [First Contentful Paint (FCP)](https://web.dev/fcp/)\n- [Time to First Byte (TTFB)](https://web.dev/ttfb/)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\nThe `web-vitals` library uses the `buffered` flag for [PerformanceObserver](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver/observe), allowing it to access performance entries that occurred before the library was loaded.\n\nThis means you do not need to load this library early in order to get accurate performance data. In general, this library should be deferred until after other user-impacting code has loaded.\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are a few different builds of the `web-vitals` library, and how you load the library depends on which build you want to use.\n\nFor details on the difference between the builds, see <a href=\"#which-build-is-right-for-you\">which build is right for you</a>.\n\n**1. The \"standard\" build**\n\nTo load the \"standard\" build, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onFID, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functions were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"attribution-build\"><a>\n\n**2. The \"attribution\" build**\n\nMeasuring the Web Vitals scores for your real users is a great first step toward optimizing the user experience. But if your scores aren't _good_, the next step is to understand why they're not good and work to improve them.\n\nThe \"attribution\" build helps you do that by including additional diagnostic information with each metric to help you identify the root cause of poor performance as well as prioritize the most important things to fix.\n\nThe \"attribution\" build is slightly larger than the \"standard\" build (by about 600 bytes, brotli'd), so while the code size is still small, it's only recommended if you're actually using these features.\n\nTo load the \"attribution\" build, change any `import` statements that reference `web-vitals` to `web-vitals/attribution`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/attribution';\n```\n\nUsage for each of the imported function is identical to the standard build, but when importing from the attribution build, the [`Metric`](#metric) object will contain an additional [`attribution`](#metricwithattribution) property.\n\nSee [Send attribution data](#send-attribution-data) for usage examples, and the [`attribution` reference](#attribution) for details on what values are added for each metric.\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**3. The \"base+polyfill\" build**\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nLoading the \"base+polyfill\" build is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nIt's important that the code is inlined directly into the HTML. _Do not link to an external script file, as that will negatively affect performance:_\n\n```html\n<!-- GOOD -->\n<script>\n  // Inline code from `dist/polyfill.js` here\n</script>\n\n<!-- BAD! DO NOT DO! -->\n<script src=\"/path/to/polyfill.js\"></script>\n```\n\nAlso note that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com):\n\n_**Important!** The [unpkg.com](https://unpkg.com) CDN is shown here for example purposes only. `unpkg.com` is not affiliated with Google, and there are no guarantees that the URLs shown in these examples will continue to work in the future._\n\n**Load the \"standard\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals@3?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src = 'https://unpkg.com/web-vitals@3/dist/web-vitals.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n**Load the \"attribution\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {\n    onCLS,\n    onFID,\n    onLCP,\n  } from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"attribution\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src =\n      'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes a `callback` function that will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" build, but they will work with the \"attribution\" build as well.)_\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developer.chrome.com/docs/devtools/console/reference/#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID and INP are not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS and INP should be reported any time the [page's `visibilityState` changes to hidden](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/bfcache/).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onFID()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want the `callback` function to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each layout shift as it happens) by setting `reportAllChanges` to `true` in the optional, [configuration object](#reportopts) (second parameter).\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended) for measuring these metrics in production.\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, {reportAllChanges: true});\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonFID(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `callback` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Report metrics for soft navigations (experimental)\n\n_**Note:** this is experimental and subject to change._\n\nCurrently Core Web Vitals are only tracked for full page navigations, which can affect how [Single Page Applications](https://web.dev/vitals-spa-faq/) that use so called \"soft navigations\" to update the browser URL and history outside of the normal browser's handling of this. The Chrome team are experimenting with being able to [measure these soft navigations](https://github.com/WICG/soft-navigations) separately and report on Core Web Vitals separately for them.\n\nThis experimental support allows sites to measure how their Core Web Vitals might be measured differently should this happen.\n\nAt present a \"soft navigation\" is defined as happening after the following three things happen:\n\n- A user interaction occurs\n- The URL changes\n- Content is added to the DOM\n- Something is painted to screen.\n\nFor some sites, these heuristics may lead to false positives (that users would not really consider a \"navigation\"), or false negatives (where the user does consider a navigation to have happened despite not missing the above criteria). We welcome feedback at https://github.com/WICG/soft-navigations/issues on the heuristics, at https://crbug.com for bugs in the Chrome implementation, and on [https://github.com/GoogleChrome/web-vitals/pull/308](this pull request) for implementation issues with web-vitals.js.\n\n_**Note:** At this time it is not known if this experiment will be something we want to move forward with. Until such time, this support will likely remain in a separate branch of this project, rather than be included in any production builds. If we decide not to move forward with this, the support of this will likely be removed from this project since this library is intended to mirror the Core Web Vitals as much as possible._\n\nSome important points to note:\n\n- TTFB is reported as 0, and not the time of the first network call (if any) after the soft navigation.\n- FCP and LCP are the first and largest contentful paints after the soft navigation. Prior reported paint times will not be counted for these metrics, even though these elements may remain between soft navigations, and may be the first or largest contentful item.\n- FID is reset to measure the first interaction after the soft navigation.\n- INP is reset to measure only interactions after the the soft navigation.\n- CLS is reset to measure again separate to the first page.\n\n_**Note:** It is not known at this time whether soft navigations will be weighted the same as full navigations. No weighting is included in this library at present and metrics are reported in the same way as full page load metrics._\n\nThe metrics can be reported for Soft Navigations using the `reportSoftNavs: true` reporting option:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(console.log, {reportSoftNavs: true});\nonFID(console.log, {reportSoftNavs: true});\nonLCP(console.log, {reportSoftNavs: true});\n```\n\nNote that this will change the way the first page loads are measured as the metrics for the inital URL will be finalized once the first soft nav occurs. To measure both you need to register two callbacks:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(doTraditionalProcessing);\nonFID(doTraditionalProcessing);\nonLCP(doTraditionalProcessing);\n\nonCLS(doSoftNavProcessing, {reportSoftNavs: true});\nonFID(doSoftNavProcessing, {reportSoftNavs: true});\nonLCP(doSoftNavProcessing, {reportSoftNavs: true});\n```\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n    fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonFID(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique event parameter value (in this case, the metric_id, as shown in the example below) on every metric instance that you send to Google Analytics, you can create a report yourself by first getting the data via the [Google Analytics Data API](https://developers.google.com/analytics/devguides/reporting/data/v1) or via [BigQuery export](https://support.google.com/analytics/answer/9358801) and then visualizing it any charting library you choose.\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // metric_rating: 'good' | 'needs-improvement' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\nFor details on how to query this data in [BigQuery](https://cloud.google.com/bigquery), or visualise it in [Looker Studio](https://lookerstudio.google.com/), see [Measure and debug performance with Google Analytics 4 and BigQuery](https://web.dev/vitals-ga4/).\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n### Send attribution data\n\nWhen using the [attribution build](#attribution-build), you can send additional data to help you debug _why_ the metric values are they way they are.\n\nThis example sends an additional `debug_target` param to Google Analytics, corresponding to the element most associated with each metric.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals/attribution';\n\nfunction sendToGoogleAnalytics({name, delta, value, id, attribution}) {\n  const eventParams = {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n  };\n\n  switch (name) {\n    case 'CLS':\n      eventParams.debug_target = attribution.largestShiftTarget;\n      break;\n    case 'FID':\n      eventParams.debug_target = attribution.eventTarget;\n      break;\n    case 'LCP':\n      eventParams.debug_target = attribution.element;\n      break;\n  }\n\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, eventParams);\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n_**Note:** this example relies on custom [event parameters](https://support.google.com/analytics/answer/11396839) in Google Analytics 4._\n\nSee [Debug performance in the field](https://web.dev/debug-performance-in-the-field/) for more information and examples.\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonFID(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n<a name=\"bundle-versions\"><a>\n\n## Build options\n\nThe `web-vitals` package includes builds for the \"standard\", \"attribution\", and \"base+polyfill\" ([deprecated](https://github.com/GoogleChrome/web-vitals/issues/238)) builds, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the builds distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any attribution features.</p>\n      This is the \"standard\" build and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.cjs</code></td>\n    <td><code>pgk.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.attribution.js</code></td>\n    <td>--</td>\n    <td>\n      An ES module version of all metric functions that includes <a href=\"#attribution-build\">attribution</a> features.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.iife.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An IIFE version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code>, <code>web-vitals.base.umd.cjs</code>, or <code>web-vitals.base.iife.js</code> (it will not work with any script that doesn't have \"base\" in the filename).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n<a name=\"which-build-is-right-for-you\"><a>\n\n### Which build is right for you?\n\nMost developers will generally want to use \"standard\" build (via either the ES module or UMD version, depending on your bundler/build system), as it's the easiest to use out of the box and integrate into existing tools.\n\nHowever, if you'd lke to collect additional debug information to help you diagnose performance bottlenecks based on real-user issues, use the [\"attribution\" build](#attribution-build).\n\nFor guidance on how to collect and use real-user data to debug performance issues, see [Debug performance in the field](https://web.dev/debug-performance-in-the-field/).\n\n### How the polyfill works\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nThe `polyfill.js` script adds event listeners (to track FID cross-browser), and it records initial page visibility state as well as the timestamp of the first visibility change to hidden (to improve the accuracy of CLS, FCP, LCP, and FID). It also polyfills the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) in browsers that only support the original (now deprecated) [Navigation Timing API](https://www.w3.org/TR/navigation-timing/).\n\nIn order for the polyfill to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" build of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" build, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  /**\n   * The name of the metric (in acronym form).\n   */\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  /**\n   * The current value of the metric.\n   */\n  value: number;\n\n  /**\n   * The rating as to whether the metric value is within the \"good\",\n   * \"needs improvement\", or \"poor\" thresholds of the metric.\n   */\n  rating: 'good' | 'needs-improvement' | 'poor';\n\n  /**\n   * The delta between the current value and the last-reported value.\n   * On the first report, `delta` and `value` will always be the same.\n   */\n  delta: number;\n\n  /**\n   * A unique ID representing this particular metric instance. This ID can\n   * be used by an analytics tool to dedupe multiple values sent for the same\n   * metric instance, or to group multiple deltas together and calculate a\n   * total. It can also be used to differentiate multiple different metric\n   * instances sent from the same page, which can happen if the page is\n   * restored from the back/forward cache (in that case new metrics object\n   * get created).\n   */\n  id: string;\n\n  /**\n   * Any performance entries relevant to the metric value calculation.\n   * The array may also be empty if the metric value was not based on any\n   * entries (e.g. a CLS value of 0 given no layout shifts).\n   */\n  entries: (\n    | PerformanceEntry\n    | LayoutShift\n    | FirstInputPolyfillEntry\n    | NavigationTimingPolyfillEntry\n  )[];\n\n  /**\n   * The type of navigation.\n   *\n   * This will be the value returned by the Navigation Timing API (or\n   * `undefined` if the browser doesn't support that API), with the following\n   * exceptions:\n   * - 'back-forward-cache': for pages that are restored from the bfcache.\n   * - 'prerender': for pages that were prerendered.\n   * - 'restore': for pages that were discarded by the browser and then\n   * restored by the user.\n   */\n  navigationType:\n    | 'navigate'\n    | 'reload'\n    | 'back-forward'\n    | 'back-forward-cache'\n    | 'prerender'\n    | 'restore'\n    | 'soft-navigation';\n\n  /**\n   * The navigatonId the metric happened for. This is particularly relevent for soft navigations where\n   * the metric may be reported for a previous URL.\n   */\n  navigatonId: number;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetric`](/src/types/cls.ts#:~:text=interface%20CLSMetric)\n- [`FCPMetric`](/src/types/fcp.ts#:~:text=interface%20FCPMetric)\n- [`FIDMetric`](/src/types/fid.ts#:~:text=interface%20FIDMetric)\n- [`INPMetric`](/src/types/inp.ts#:~:text=interface%20INPMetric)\n- [`LCPMetric`](/src/types/lcp.ts#:~:text=interface%20LCPMetric)\n- [`TTFBMetric`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetric)\n\n#### `MetricWithAttribution`\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n```ts\ninterface MetricWithAttribution extends Metric {\n  /**\n   * An object containing potentially-helpful debugging information that\n   * can be sent along with the metric value for the current page visit in\n   * order to help identify issues happening to real-users in the field.\n   */\n  attribution: {[key: string]: unknown};\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetricWithAttribution`](/src/types/cls.ts#:~:text=interface%20CLSMetricWithAttribution)\n- [`FCPMetricWithAttribution`](/src/types/fcp.ts#:~:text=interface%20FCPMetricWithAttribution)\n- [`FIDMetricWithAttribution`](/src/types/fid.ts#:~:text=interface%20FIDMetricWithAttribution)\n- [`INPMetricWithAttribution`](/src/types/inp.ts#:~:text=interface%20INPMetricWithAttribution)\n- [`LCPMetricWithAttribution`](/src/types/lcp.ts#:~:text=interface%20LCPMetricWithAttribution)\n- [`TTFBMetricWithAttribution`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetricWithAttribution)\n\n#### `MetricRatingThresholds`\n\nThe thresholds of metric's \"good\", \"needs improvement\", and \"poor\" ratings.\n\n- Metric values up to and including [0] are rated \"good\"\n- Metric values up to and including [1] are rated \"needs improvement\"\n- Metric values above [1] are \"poor\"\n\n| Metric value    | Rating              |\n| --------------- | ------------------- |\n| ≦ [0]           | \"good\"              |\n| > [0] and ≦ [1] | \"needs improvement\" |\n| > [1]           | \"poor\"              |\n\n```ts\nexport type MetricRatingThresholds = [number, number];\n```\n\n_See also [Rating Thresholds](#rating-thresholds)._\n\n#### `ReportCallback`\n\n```ts\ninterface ReportCallback {\n  (metric: Metric): void;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSReportCallback`](/src/types/cls.ts#:~:text=interface%20CLSReportCallback)\n- [`FCPReportCallback`](/src/types/fcp.ts#:~:text=interface%20FCPReportCallback)\n- [`FIDReportCallback`](/src/types/fid.ts#:~:text=interface%20FIDReportCallback)\n- [`INPReportCallback`](/src/types/inp.ts#:~:text=interface%20INPReportCallback)\n- [`LCPReportCallback`](/src/types/lcp.ts#:~:text=interface%20LCPReportCallback)\n- [`TTFBReportCallback`](/src/types/ttfb.ts#:~:text=interface%20TTFBReportCallback)\n\n#### `ReportOpts`\n\n```ts\ninterface ReportOpts {\n  reportAllChanges?: boolean;\n  durationThreshold?: number;\n  reportSoftNavs?: boolean;\n}\n```\n\n#### `LoadState`\n\nThe `LoadState` type is used in several of the metric [attribution objects](#attribution).\n\n```ts\n/**\n * The loading state of the document. Note: this value is similar to\n * `document.readyState` but it subdivides the \"interactive\" state into the\n * time before and after the DOMContentLoaded event fires.\n *\n * State descriptions:\n * - `loading`: the initial document response has not yet been fully downloaded\n *   and parsed. This is equivalent to the corresponding `readyState` value.\n * - `dom-interactive`: the document has been fully loaded and parsed, but\n *   scripts may not have yet finished loading and executing.\n * - `dom-content-loaded`: the document is fully loaded and parsed, and all\n *   scripts (except `async` scripts) have loaded and finished executing.\n * - `complete`: the document and all of its sub-resources have finished\n *   loading. This is equivalent to the corresponding `readyState` value.\n */\ntype LoadState =\n  | 'loading'\n  | 'dom-interactive'\n  | 'dom-content-loaded'\n  | 'complete';\n```\n\n#### `FirstInputPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't natively support the Event Timing API), the `metric.entries` reported by `onFID()` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<\n  PerformanceEventTiming,\n  'processingEnd' | 'toJSON'\n>;\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface), the `metric.entries` reported by `onTTFB()` will contain an object that polyfills the `PerformanceNavigationTiming` entry using timings from the legacy `performance.timing` interface:\n\n```ts\ntype NavigationTimingPolyfillEntry = Omit<\n  PerformanceNavigationTiming,\n  | 'initiatorType'\n  | 'nextHopProtocol'\n  | 'redirectCount'\n  | 'transferSize'\n  | 'encodedBodySize'\n  | 'decodedBodySize'\n  | 'type'\n> & {\n  type: PerformanceNavigationTiming['type'];\n};\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n  firstHiddenTime: number;\n}\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (callback: CLSReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [CLS](https://web.dev/cls/) value for the current page and calls the `callback` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/cls/#layout-shift-score)).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (callback: FCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FCP](https://web.dev/fcp/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n```ts\ntype onFID = (callback: FIDReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FID](https://web.dev/fid/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (callback: INPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [INP](https://web.dev/inp/) value for the current page and calls the `callback` function once the value is ready, along with the `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nA custom `durationThreshold` [configuration option](#reportopts) can optionally be passed to control what `event-timing` entries are considered for INP reporting. The default threshold is `40`, which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended [good](https://web.dev/inp/#what-is-a-good-inp-score) threshold).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (callback: LCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [LCP](https://web.dev/lcp/) value for the current page and calls the `callback` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (callback: TTFBReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [TTFB](https://web.dev/time-to-first-byte/) value for the current page and calls the `callback` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `callback` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it includes time spent on DNS lookup, connection negotiation, network latency, and server processing time.\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n### Rating Thresholds:\n\nThe thresholds of each metric's \"good\", \"needs improvement\", and \"poor\" ratings are available as [`MetricRatingThresholds`](#metricratingthresholds).\n\nExample:\n\n```ts\nimport {CLSThresholds, FIDThresholds, LCPThresholds} from 'web-vitals';\n\nconsole.log(CLSThresholds); // [ 0.1, 0.25 ]\nconsole.log(FIDThresholds); // [ 100, 300 ]\nconsole.log(LCPThresholds); // [ 2500, 4000 ]\n```\n\n_**Note:** It's typically not necessary (or recommended) to manually calculate metric value ratings using these thresholds. Use the [`Metric['rating']`](#metric) supplied by the [`ReportCallback`](#reportcallback) functions instead._\n\n### Attribution:\n\nThe following objects contain potentially-helpful debugging information that can be sent along with the metric values for the current page visit in order to help identify issues happening to real-users in the field.\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n#### CLS `attribution`:\n\n```ts\ninterface CLSAttribution {\n  /**\n   * A selector identifying the first element (in document order) that\n   * shifted when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTarget?: string;\n  /**\n   * The time when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTime?: DOMHighResTimeStamp;\n  /**\n   * The layout shift score of the single largest layout shift contributing to\n   * the page's CLS score.\n   */\n  largestShiftValue?: number;\n  /**\n   * The `LayoutShiftEntry` representing the single largest layout shift\n   * contributing to the page's CLS score. (Useful when you need more than just\n   * `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftEntry?: LayoutShift;\n  /**\n   * The first element source (in document order) among the `sources` list\n   * of the `largestShiftEntry` object. (Also useful when you need more than\n   * just `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftSource?: LayoutShiftAttribution;\n  /**\n   * The loading state of the document at the time when the largest layout\n   * shift contribution to the page's CLS score occurred (see `LoadState`\n   * for details).\n   */\n  loadState?: LoadState;\n}\n```\n\n#### FCP `attribution`:\n\n```ts\ninterface FCPAttribution {\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB).\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and the first contentful paint (FCP).\n   */\n  firstByteToFCP: number;\n  /**\n   * The loading state of the document at the time when FCP `occurred (see\n   * `LoadState` for details). Ideally, documents can paint before they finish\n   * loading (e.g. the `loading` or `dom-interactive` phases).\n   */\n  loadState: LoadState;\n  /**\n   * The `PerformancePaintTiming` entry corresponding to FCP.\n   */\n  fcpEntry?: PerformancePaintTiming;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n#### FID `attribution`:\n\n```ts\ninterface FIDAttribution {\n  /**\n   * A selector identifying the element that the user interacted with. This\n   * element will be the `target` of the `event` dispatched.\n   */\n  eventTarget: string;\n  /**\n   * The time when the user interacted. This time will match the `timeStamp`\n   * value of the `event` dispatched.\n   */\n  eventTime: number;\n  /**\n   * The `type` of the `event` dispatched from the user interaction.\n   */\n  eventType: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to FID (or the\n   * polyfill entry in browsers that don't support Event Timing).\n   */\n  eventEntry: PerformanceEventTiming | FirstInputPolyfillEntry;\n  /**\n   * The loading state of the document at the time when the first interaction\n   * occurred (see `LoadState` for details). If the first interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long input delays.\n   */\n  loadState: LoadState;\n}\n```\n\n#### INP `attribution`:\n\n```ts\ninterface INPAttribution {\n  /**\n   * A selector identifying the element that the user interacted with for\n   * the event corresponding to INP. This element will be the `target` of the\n   * `event` dispatched.\n   */\n  eventTarget?: string;\n  /**\n   * The time when the user interacted for the event corresponding to INP.\n   * This time will match the `timeStamp` value of the `event` dispatched.\n   */\n  eventTime?: number;\n  /**\n   * The `type` of the `event` dispatched corresponding to INP.\n   */\n  eventType?: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to INP.\n   */\n  eventEntry?: PerformanceEventTiming;\n  /**\n   * The loading state of the document at the time when the even corresponding\n   * to INP occurred (see `LoadState` for details). If the interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long delays.\n   */\n  loadState?: LoadState;\n}\n```\n\n#### LCP `attribution`:\n\n```ts\ninterface LCPAttribution {\n  /**\n   * The element corresponding to the largest contentful paint for the page.\n   */\n  element?: string;\n  /**\n   * The URL (if applicable) of the LCP image resource. If the LCP element\n   * is a text node, this value will not be set.\n   */\n  url?: string;\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB). See\n   * [Optimize LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and when the browser starts loading the LCP\n   * resource (if there is one, otherwise 0). See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  resourceLoadDelay: number;\n  /**\n   * The total time it takes to load the LCP resource itself (if there is one,\n   * otherwise 0). See [Optimize LCP](https://web.dev/optimize-lcp/) for\n   * details.\n   */\n  resourceLoadTime: number;\n  /**\n   * The delta between when the LCP resource finishes loading until the LCP\n   * element is fully rendered. See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  elementRenderDelay: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n  /**\n   * The `resource` entry for the LCP resource (if applicable), which is useful\n   * for diagnosing resource load issues.\n   */\n  lcpResourceEntry?: PerformanceResourceTiming;\n  /**\n   * The `LargestContentfulPaint` entry corresponding to LCP.\n   */\n  lcpEntry?: LargestContentfulPaint;\n}\n```\n\n#### TTFB `attribution`:\n\n```ts\ninterface TTFBAttribution {\n  /**\n   * The total time from when the user initiates loading the page to when the\n   * DNS lookup begins. This includes redirects, service worker startup, and\n   * HTTP cache lookup times.\n   */\n  waitingTime: number;\n  /**\n   * The total time to resolve the DNS for the current request.\n   */\n  dnsTime: number;\n  /**\n   * The total time to create the connection to the requested domain.\n   */\n  connectionTime: number;\n  /**\n   * The time time from when the request was sent until the first byte of the\n   * response was received. This includes network time as well as server\n   * processing time.\n   */\n  requestTime: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium\n- `onFCP()`: Chromium, Firefox, Safari 14.1+\n- `onFID()`: Chromium, Firefox _(with [polyfill](#how-to-use-the-polyfill): Safari, Internet Explorer)_\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari 15+ _(with [polyfill](#how-to-use-the-polyfill): Safari 8+, Internet Explorer)_\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that measure the Web Vitals metrics, which means the limitations of those APIs will mostly apply to this library as well. More details on these limitations is available in [this blog post](https://web.dev/crux-and-rum-differences/).\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/vitals-ga4/).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `callback` functions and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"1e72319d97cd45e2620b6d19fa4b3fa752de9647","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.5.0-soft-navs-13","_nodeVersion":"18.16.0","_npmVersion":"9.5.1","dist":{"integrity":"sha512-3EnAtOywHxyL8KN+lFBV2hQkmxgkKklV0IEBQ8fpFsnpSzSXnkC9AyoHyX4Gvcg7T1Zt72EC4MgQ+aM8wfOW+A==","shasum":"45dd9b966657a34ee2b813f5d8b5252e82cc7dd0","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.5.0-soft-navs-13.tgz","fileCount":146,"unpackedSize":457656,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCR8DH5q3cMKh+1nguXmCuwMMG80DhLtYDErz5f90KyEwIhALM+vIvk/rW4Tmflt659jdhsKFqoCi2CEOgeifwMSCnP"}]},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.5.0-soft-navs-13_1702507242255_0.6009803452484652"},"_hasShrinkwrap":false},"3.5.0-soft-navs-14":{"name":"web-vitals","version":"3.5.0-soft-navs-14","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build test:unit -p -r test:e2e test:server","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","test:unit":"node --test test/unit/*test.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.21.0","@babel/preset-env":"^7.20.2","@rollup/plugin-replace":"^4.0.0","@typescript-eslint/eslint-plugin":"^5.54.1","@typescript-eslint/parser":"^5.54.1","@wdio/cli":"^7.30.2","@wdio/local-runner":"^7.30.2","@wdio/mocha-framework":"^7.30.2","@wdio/selenium-standalone-service":"^7.32.4","@wdio/spec-reporter":"^7.30.2","body-parser":"^1.20.2","chromedriver":"^117.0.3","eslint":"^8.35.0","express":"^4.18.2","fs-extra":"^10.1.0","husky":"^8.0.3","lint-staged":"^13.1.2","npm-run-all":"^4.1.5","nunjucks":"^3.2.3","prettier":"^2.8.4","rollup":"^2.79.1","rollup-plugin-babel":"^4.4.0","rollup-plugin-terser":"^7.0.2","selenium-standalone":"^8.3.0","typescript":"^4.9.5","wdio-chromedriver-service":"^8.1.1"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Send attribution data](#send-attribution-data)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Build options](#build-options)\n  - [Which build is right for you?](#which-build-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n  - [Rating Thresholds](#rating-thresholds)\n  - [Attribution](#attribution)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1.5K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/vitals/) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/vitals/#core-web-vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/user-centric-performance-metrics/) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/cls/)\n- [First Input Delay (FID)](https://web.dev/fid/)\n- [Largest Contentful Paint (LCP)](https://web.dev/lcp/)\n\n### Other metrics\n\n- [Interaction to next Paint (INP)](https://web.dev/inp/)\n- [First Contentful Paint (FCP)](https://web.dev/fcp/)\n- [Time to First Byte (TTFB)](https://web.dev/ttfb/)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\nThe `web-vitals` library uses the `buffered` flag for [PerformanceObserver](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver/observe), allowing it to access performance entries that occurred before the library was loaded.\n\nThis means you do not need to load this library early in order to get accurate performance data. In general, this library should be deferred until after other user-impacting code has loaded.\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are a few different builds of the `web-vitals` library, and how you load the library depends on which build you want to use.\n\nFor details on the difference between the builds, see <a href=\"#which-build-is-right-for-you\">which build is right for you</a>.\n\n**1. The \"standard\" build**\n\nTo load the \"standard\" build, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onFID, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functions were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"attribution-build\"><a>\n\n**2. The \"attribution\" build**\n\nMeasuring the Web Vitals scores for your real users is a great first step toward optimizing the user experience. But if your scores aren't _good_, the next step is to understand why they're not good and work to improve them.\n\nThe \"attribution\" build helps you do that by including additional diagnostic information with each metric to help you identify the root cause of poor performance as well as prioritize the most important things to fix.\n\nThe \"attribution\" build is slightly larger than the \"standard\" build (by about 600 bytes, brotli'd), so while the code size is still small, it's only recommended if you're actually using these features.\n\nTo load the \"attribution\" build, change any `import` statements that reference `web-vitals` to `web-vitals/attribution`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/attribution';\n```\n\nUsage for each of the imported function is identical to the standard build, but when importing from the attribution build, the [`Metric`](#metric) object will contain an additional [`attribution`](#metricwithattribution) property.\n\nSee [Send attribution data](#send-attribution-data) for usage examples, and the [`attribution` reference](#attribution) for details on what values are added for each metric.\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**3. The \"base+polyfill\" build**\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nLoading the \"base+polyfill\" build is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!DOCTYPE html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nIt's important that the code is inlined directly into the HTML. _Do not link to an external script file, as that will negatively affect performance:_\n\n```html\n<!-- GOOD -->\n<script>\n  // Inline code from `dist/polyfill.js` here\n</script>\n\n<!-- BAD! DO NOT DO! -->\n<script src=\"/path/to/polyfill.js\"></script>\n```\n\nAlso note that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com):\n\n_**Important!** The [unpkg.com](https://unpkg.com) CDN is shown here for example purposes only. `unpkg.com` is not affiliated with Google, and there are no guarantees that the URLs shown in these examples will continue to work in the future._\n\n**Load the \"standard\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals@3?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src = 'https://unpkg.com/web-vitals@3/dist/web-vitals.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n**Load the \"attribution\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {\n    onCLS,\n    onFID,\n    onLCP,\n  } from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"attribution\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src =\n      'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes a `callback` function that will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" build, but they will work with the \"attribution\" build as well.)_\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developer.chrome.com/docs/devtools/console/reference/#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID and INP are not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS and INP should be reported any time the [page's `visibilityState` changes to hidden](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/bfcache/).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onFID()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want the `callback` function to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each layout shift as it happens) by setting `reportAllChanges` to `true` in the optional, [configuration object](#reportopts) (second parameter).\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended) for measuring these metrics in production.\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, {reportAllChanges: true});\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonFID(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `callback` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Report metrics for soft navigations (experimental)\n\n_**Note:** this is experimental and subject to change._\n\nCurrently Core Web Vitals are only tracked for full page navigations, which can affect how [Single Page Applications](https://web.dev/vitals-spa-faq/) that use so called \"soft navigations\" to update the browser URL and history outside of the normal browser's handling of this. The Chrome team are experimenting with being able to [measure these soft navigations](https://github.com/WICG/soft-navigations) separately and report on Core Web Vitals separately for them.\n\nThis experimental support allows sites to measure how their Core Web Vitals might be measured differently should this happen.\n\nAt present a \"soft navigation\" is defined as happening after the following three things happen:\n\n- A user interaction occurs\n- The URL changes\n- Content is added to the DOM\n- Something is painted to screen.\n\nFor some sites, these heuristics may lead to false positives (that users would not really consider a \"navigation\"), or false negatives (where the user does consider a navigation to have happened despite not missing the above criteria). We welcome feedback at https://github.com/WICG/soft-navigations/issues on the heuristics, at https://crbug.com for bugs in the Chrome implementation, and on [https://github.com/GoogleChrome/web-vitals/pull/308](this pull request) for implementation issues with web-vitals.js.\n\n_**Note:** At this time it is not known if this experiment will be something we want to move forward with. Until such time, this support will likely remain in a separate branch of this project, rather than be included in any production builds. If we decide not to move forward with this, the support of this will likely be removed from this project since this library is intended to mirror the Core Web Vitals as much as possible._\n\nSome important points to note:\n\n- TTFB is reported as 0, and not the time of the first network call (if any) after the soft navigation.\n- FCP and LCP are the first and largest contentful paints after the soft navigation. Prior reported paint times will not be counted for these metrics, even though these elements may remain between soft navigations, and may be the first or largest contentful item.\n- FID is reset to measure the first interaction after the soft navigation.\n- INP is reset to measure only interactions after the the soft navigation.\n- CLS is reset to measure again separate to the first page.\n\n_**Note:** It is not known at this time whether soft navigations will be weighted the same as full navigations. No weighting is included in this library at present and metrics are reported in the same way as full page load metrics._\n\nThe metrics can be reported for Soft Navigations using the `reportSoftNavs: true` reporting option:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(console.log, {reportSoftNavs: true});\nonFID(console.log, {reportSoftNavs: true});\nonLCP(console.log, {reportSoftNavs: true});\n```\n\nNote that this will change the way the first page loads are measured as the metrics for the inital URL will be finalized once the first soft nav occurs. To measure both you need to register two callbacks:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(doTraditionalProcessing);\nonFID(doTraditionalProcessing);\nonLCP(doTraditionalProcessing);\n\nonCLS(doSoftNavProcessing, {reportSoftNavs: true});\nonFID(doSoftNavProcessing, {reportSoftNavs: true});\nonLCP(doSoftNavProcessing, {reportSoftNavs: true});\n```\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n    fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonFID(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique event parameter value (in this case, the metric_id, as shown in the example below) on every metric instance that you send to Google Analytics, you can create a report yourself by first getting the data via the [Google Analytics Data API](https://developers.google.com/analytics/devguides/reporting/data/v1) or via [BigQuery export](https://support.google.com/analytics/answer/9358801) and then visualizing it any charting library you choose.\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/debug-performance-in-the-field/\n    // metric_rating: 'good' | 'needs-improvement' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\nFor details on how to query this data in [BigQuery](https://cloud.google.com/bigquery), or visualise it in [Looker Studio](https://lookerstudio.google.com/), see [Measure and debug performance with Google Analytics 4 and BigQuery](https://web.dev/vitals-ga4/).\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n### Send attribution data\n\nWhen using the [attribution build](#attribution-build), you can send additional data to help you debug _why_ the metric values are they way they are.\n\nThis example sends an additional `debug_target` param to Google Analytics, corresponding to the element most associated with each metric.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals/attribution';\n\nfunction sendToGoogleAnalytics({name, delta, value, id, attribution}) {\n  const eventParams = {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n  };\n\n  switch (name) {\n    case 'CLS':\n      eventParams.debug_target = attribution.largestShiftTarget;\n      break;\n    case 'FID':\n      eventParams.debug_target = attribution.eventTarget;\n      break;\n    case 'LCP':\n      eventParams.debug_target = attribution.element;\n      break;\n  }\n\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, eventParams);\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n_**Note:** this example relies on custom [event parameters](https://support.google.com/analytics/answer/11396839) in Google Analytics 4._\n\nSee [Debug performance in the field](https://web.dev/debug-performance-in-the-field/) for more information and examples.\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonFID(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n<a name=\"bundle-versions\"><a>\n\n## Build options\n\nThe `web-vitals` package includes builds for the \"standard\", \"attribution\", and \"base+polyfill\" ([deprecated](https://github.com/GoogleChrome/web-vitals/issues/238)) builds, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the builds distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any attribution features.</p>\n      This is the \"standard\" build and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.cjs</code></td>\n    <td><code>pgk.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.attribution.js</code></td>\n    <td>--</td>\n    <td>\n      An ES module version of all metric functions that includes <a href=\"#attribution-build\">attribution</a> features.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.iife.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An IIFE version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code>, <code>web-vitals.base.umd.cjs</code>, or <code>web-vitals.base.iife.js</code> (it will not work with any script that doesn't have \"base\" in the filename).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n<a name=\"which-build-is-right-for-you\"><a>\n\n### Which build is right for you?\n\nMost developers will generally want to use \"standard\" build (via either the ES module or UMD version, depending on your bundler/build system), as it's the easiest to use out of the box and integrate into existing tools.\n\nHowever, if you'd lke to collect additional debug information to help you diagnose performance bottlenecks based on real-user issues, use the [\"attribution\" build](#attribution-build).\n\nFor guidance on how to collect and use real-user data to debug performance issues, see [Debug performance in the field](https://web.dev/debug-performance-in-the-field/).\n\n### How the polyfill works\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nThe `polyfill.js` script adds event listeners (to track FID cross-browser), and it records initial page visibility state as well as the timestamp of the first visibility change to hidden (to improve the accuracy of CLS, FCP, LCP, and FID). It also polyfills the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) in browsers that only support the original (now deprecated) [Navigation Timing API](https://www.w3.org/TR/navigation-timing/).\n\nIn order for the polyfill to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" build of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" build, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  /**\n   * The name of the metric (in acronym form).\n   */\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  /**\n   * The current value of the metric.\n   */\n  value: number;\n\n  /**\n   * The rating as to whether the metric value is within the \"good\",\n   * \"needs improvement\", or \"poor\" thresholds of the metric.\n   */\n  rating: 'good' | 'needs-improvement' | 'poor';\n\n  /**\n   * The delta between the current value and the last-reported value.\n   * On the first report, `delta` and `value` will always be the same.\n   */\n  delta: number;\n\n  /**\n   * A unique ID representing this particular metric instance. This ID can\n   * be used by an analytics tool to dedupe multiple values sent for the same\n   * metric instance, or to group multiple deltas together and calculate a\n   * total. It can also be used to differentiate multiple different metric\n   * instances sent from the same page, which can happen if the page is\n   * restored from the back/forward cache (in that case new metrics object\n   * get created).\n   */\n  id: string;\n\n  /**\n   * Any performance entries relevant to the metric value calculation.\n   * The array may also be empty if the metric value was not based on any\n   * entries (e.g. a CLS value of 0 given no layout shifts).\n   */\n  entries: (\n    | PerformanceEntry\n    | LayoutShift\n    | FirstInputPolyfillEntry\n    | NavigationTimingPolyfillEntry\n  )[];\n\n  /**\n   * The type of navigation.\n   *\n   * This will be the value returned by the Navigation Timing API (or\n   * `undefined` if the browser doesn't support that API), with the following\n   * exceptions:\n   * - 'back-forward-cache': for pages that are restored from the bfcache.\n   * - 'prerender': for pages that were prerendered.\n   * - 'restore': for pages that were discarded by the browser and then\n   * restored by the user.\n   */\n  navigationType:\n    | 'navigate'\n    | 'reload'\n    | 'back-forward'\n    | 'back-forward-cache'\n    | 'prerender'\n    | 'restore'\n    | 'soft-navigation';\n\n  /**\n   * The navigatonId the metric happened for. This is particularly relevent for soft navigations where\n   * the metric may be reported for a previous URL.\n   */\n  navigatonId: number;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetric`](/src/types/cls.ts#:~:text=interface%20CLSMetric)\n- [`FCPMetric`](/src/types/fcp.ts#:~:text=interface%20FCPMetric)\n- [`FIDMetric`](/src/types/fid.ts#:~:text=interface%20FIDMetric)\n- [`INPMetric`](/src/types/inp.ts#:~:text=interface%20INPMetric)\n- [`LCPMetric`](/src/types/lcp.ts#:~:text=interface%20LCPMetric)\n- [`TTFBMetric`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetric)\n\n#### `MetricWithAttribution`\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n```ts\ninterface MetricWithAttribution extends Metric {\n  /**\n   * An object containing potentially-helpful debugging information that\n   * can be sent along with the metric value for the current page visit in\n   * order to help identify issues happening to real-users in the field.\n   */\n  attribution: {[key: string]: unknown};\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetricWithAttribution`](/src/types/cls.ts#:~:text=interface%20CLSMetricWithAttribution)\n- [`FCPMetricWithAttribution`](/src/types/fcp.ts#:~:text=interface%20FCPMetricWithAttribution)\n- [`FIDMetricWithAttribution`](/src/types/fid.ts#:~:text=interface%20FIDMetricWithAttribution)\n- [`INPMetricWithAttribution`](/src/types/inp.ts#:~:text=interface%20INPMetricWithAttribution)\n- [`LCPMetricWithAttribution`](/src/types/lcp.ts#:~:text=interface%20LCPMetricWithAttribution)\n- [`TTFBMetricWithAttribution`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetricWithAttribution)\n\n#### `MetricRatingThresholds`\n\nThe thresholds of metric's \"good\", \"needs improvement\", and \"poor\" ratings.\n\n- Metric values up to and including [0] are rated \"good\"\n- Metric values up to and including [1] are rated \"needs improvement\"\n- Metric values above [1] are \"poor\"\n\n| Metric value    | Rating              |\n| --------------- | ------------------- |\n| ≦ [0]           | \"good\"              |\n| > [0] and ≦ [1] | \"needs improvement\" |\n| > [1]           | \"poor\"              |\n\n```ts\nexport type MetricRatingThresholds = [number, number];\n```\n\n_See also [Rating Thresholds](#rating-thresholds)._\n\n#### `ReportCallback`\n\n```ts\ninterface ReportCallback {\n  (metric: Metric): void;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSReportCallback`](/src/types/cls.ts#:~:text=interface%20CLSReportCallback)\n- [`FCPReportCallback`](/src/types/fcp.ts#:~:text=interface%20FCPReportCallback)\n- [`FIDReportCallback`](/src/types/fid.ts#:~:text=interface%20FIDReportCallback)\n- [`INPReportCallback`](/src/types/inp.ts#:~:text=interface%20INPReportCallback)\n- [`LCPReportCallback`](/src/types/lcp.ts#:~:text=interface%20LCPReportCallback)\n- [`TTFBReportCallback`](/src/types/ttfb.ts#:~:text=interface%20TTFBReportCallback)\n\n#### `ReportOpts`\n\n```ts\ninterface ReportOpts {\n  reportAllChanges?: boolean;\n  durationThreshold?: number;\n  reportSoftNavs?: boolean;\n}\n```\n\n#### `LoadState`\n\nThe `LoadState` type is used in several of the metric [attribution objects](#attribution).\n\n```ts\n/**\n * The loading state of the document. Note: this value is similar to\n * `document.readyState` but it subdivides the \"interactive\" state into the\n * time before and after the DOMContentLoaded event fires.\n *\n * State descriptions:\n * - `loading`: the initial document response has not yet been fully downloaded\n *   and parsed. This is equivalent to the corresponding `readyState` value.\n * - `dom-interactive`: the document has been fully loaded and parsed, but\n *   scripts may not have yet finished loading and executing.\n * - `dom-content-loaded`: the document is fully loaded and parsed, and all\n *   scripts (except `async` scripts) have loaded and finished executing.\n * - `complete`: the document and all of its sub-resources have finished\n *   loading. This is equivalent to the corresponding `readyState` value.\n */\ntype LoadState =\n  | 'loading'\n  | 'dom-interactive'\n  | 'dom-content-loaded'\n  | 'complete';\n```\n\n#### `FirstInputPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't natively support the Event Timing API), the `metric.entries` reported by `onFID()` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<\n  PerformanceEventTiming,\n  'processingEnd' | 'toJSON'\n>;\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface), the `metric.entries` reported by `onTTFB()` will contain an object that polyfills the `PerformanceNavigationTiming` entry using timings from the legacy `performance.timing` interface:\n\n```ts\ntype NavigationTimingPolyfillEntry = Omit<\n  PerformanceNavigationTiming,\n  | 'initiatorType'\n  | 'nextHopProtocol'\n  | 'redirectCount'\n  | 'transferSize'\n  | 'encodedBodySize'\n  | 'decodedBodySize'\n  | 'type'\n> & {\n  type: PerformanceNavigationTiming['type'];\n};\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n  firstHiddenTime: number;\n}\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (callback: CLSReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [CLS](https://web.dev/cls/) value for the current page and calls the `callback` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/cls/#layout-shift-score)).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (callback: FCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FCP](https://web.dev/fcp/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n```ts\ntype onFID = (callback: FIDReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FID](https://web.dev/fid/) value for the current page and calls the `callback` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (callback: INPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [INP](https://web.dev/inp/) value for the current page and calls the `callback` function once the value is ready, along with the `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nA custom `durationThreshold` [configuration option](#reportopts) can optionally be passed to control what `event-timing` entries are considered for INP reporting. The default threshold is `40`, which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended [good](https://web.dev/inp/#what-is-a-good-inp-score) threshold).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (callback: LCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [LCP](https://web.dev/lcp/) value for the current page and calls the `callback` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (callback: TTFBReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [TTFB](https://web.dev/time-to-first-byte/) value for the current page and calls the `callback` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `callback` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it includes time spent on DNS lookup, connection negotiation, network latency, and server processing time.\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n### Rating Thresholds:\n\nThe thresholds of each metric's \"good\", \"needs improvement\", and \"poor\" ratings are available as [`MetricRatingThresholds`](#metricratingthresholds).\n\nExample:\n\n```ts\nimport {CLSThresholds, FIDThresholds, LCPThresholds} from 'web-vitals';\n\nconsole.log(CLSThresholds); // [ 0.1, 0.25 ]\nconsole.log(FIDThresholds); // [ 100, 300 ]\nconsole.log(LCPThresholds); // [ 2500, 4000 ]\n```\n\n_**Note:** It's typically not necessary (or recommended) to manually calculate metric value ratings using these thresholds. Use the [`Metric['rating']`](#metric) supplied by the [`ReportCallback`](#reportcallback) functions instead._\n\n### Attribution:\n\nThe following objects contain potentially-helpful debugging information that can be sent along with the metric values for the current page visit in order to help identify issues happening to real-users in the field.\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n#### CLS `attribution`:\n\n```ts\ninterface CLSAttribution {\n  /**\n   * A selector identifying the first element (in document order) that\n   * shifted when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTarget?: string;\n  /**\n   * The time when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTime?: DOMHighResTimeStamp;\n  /**\n   * The layout shift score of the single largest layout shift contributing to\n   * the page's CLS score.\n   */\n  largestShiftValue?: number;\n  /**\n   * The `LayoutShiftEntry` representing the single largest layout shift\n   * contributing to the page's CLS score. (Useful when you need more than just\n   * `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftEntry?: LayoutShift;\n  /**\n   * The first element source (in document order) among the `sources` list\n   * of the `largestShiftEntry` object. (Also useful when you need more than\n   * just `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftSource?: LayoutShiftAttribution;\n  /**\n   * The loading state of the document at the time when the largest layout\n   * shift contribution to the page's CLS score occurred (see `LoadState`\n   * for details).\n   */\n  loadState?: LoadState;\n}\n```\n\n#### FCP `attribution`:\n\n```ts\ninterface FCPAttribution {\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB).\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and the first contentful paint (FCP).\n   */\n  firstByteToFCP: number;\n  /**\n   * The loading state of the document at the time when FCP `occurred (see\n   * `LoadState` for details). Ideally, documents can paint before they finish\n   * loading (e.g. the `loading` or `dom-interactive` phases).\n   */\n  loadState: LoadState;\n  /**\n   * The `PerformancePaintTiming` entry corresponding to FCP.\n   */\n  fcpEntry?: PerformancePaintTiming;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n#### FID `attribution`:\n\n```ts\ninterface FIDAttribution {\n  /**\n   * A selector identifying the element that the user interacted with. This\n   * element will be the `target` of the `event` dispatched.\n   */\n  eventTarget: string;\n  /**\n   * The time when the user interacted. This time will match the `timeStamp`\n   * value of the `event` dispatched.\n   */\n  eventTime: number;\n  /**\n   * The `type` of the `event` dispatched from the user interaction.\n   */\n  eventType: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to FID (or the\n   * polyfill entry in browsers that don't support Event Timing).\n   */\n  eventEntry: PerformanceEventTiming | FirstInputPolyfillEntry;\n  /**\n   * The loading state of the document at the time when the first interaction\n   * occurred (see `LoadState` for details). If the first interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long input delays.\n   */\n  loadState: LoadState;\n}\n```\n\n#### INP `attribution`:\n\n```ts\ninterface INPAttribution {\n  /**\n   * A selector identifying the element that the user interacted with for\n   * the event corresponding to INP. This element will be the `target` of the\n   * `event` dispatched.\n   */\n  eventTarget?: string;\n  /**\n   * The time when the user interacted for the event corresponding to INP.\n   * This time will match the `timeStamp` value of the `event` dispatched.\n   */\n  eventTime?: number;\n  /**\n   * The `type` of the `event` dispatched corresponding to INP.\n   */\n  eventType?: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to INP.\n   */\n  eventEntry?: PerformanceEventTiming;\n  /**\n   * The loading state of the document at the time when the even corresponding\n   * to INP occurred (see `LoadState` for details). If the interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long delays.\n   */\n  loadState?: LoadState;\n}\n```\n\n#### LCP `attribution`:\n\n```ts\ninterface LCPAttribution {\n  /**\n   * The element corresponding to the largest contentful paint for the page.\n   */\n  element?: string;\n  /**\n   * The URL (if applicable) of the LCP image resource. If the LCP element\n   * is a text node, this value will not be set.\n   */\n  url?: string;\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB). See\n   * [Optimize LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and when the browser starts loading the LCP\n   * resource (if there is one, otherwise 0). See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  resourceLoadDelay: number;\n  /**\n   * The total time it takes to load the LCP resource itself (if there is one,\n   * otherwise 0). See [Optimize LCP](https://web.dev/optimize-lcp/) for\n   * details.\n   */\n  resourceLoadTime: number;\n  /**\n   * The delta between when the LCP resource finishes loading until the LCP\n   * element is fully rendered. See [Optimize\n   * LCP](https://web.dev/optimize-lcp/) for details.\n   */\n  elementRenderDelay: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n  /**\n   * The `resource` entry for the LCP resource (if applicable), which is useful\n   * for diagnosing resource load issues.\n   */\n  lcpResourceEntry?: PerformanceResourceTiming;\n  /**\n   * The `LargestContentfulPaint` entry corresponding to LCP.\n   */\n  lcpEntry?: LargestContentfulPaint;\n}\n```\n\n#### TTFB `attribution`:\n\n```ts\ninterface TTFBAttribution {\n  /**\n   * The total time from when the user initiates loading the page to when the\n   * DNS lookup begins. This includes redirects, service worker startup, and\n   * HTTP cache lookup times.\n   */\n  waitingTime: number;\n  /**\n   * The total time to resolve the DNS for the current request.\n   */\n  dnsTime: number;\n  /**\n   * The total time to create the connection to the requested domain.\n   */\n  connectionTime: number;\n  /**\n   * The time time from when the request was sent until the first byte of the\n   * response was received. This includes network time as well as server\n   * processing time.\n   */\n  requestTime: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium\n- `onFCP()`: Chromium, Firefox, Safari 14.1+\n- `onFID()`: Chromium, Firefox _(with [polyfill](#how-to-use-the-polyfill): Safari, Internet Explorer)_\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari 15+ _(with [polyfill](#how-to-use-the-polyfill): Safari 8+, Internet Explorer)_\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that measure the Web Vitals metrics, which means the limitations of those APIs will mostly apply to this library as well. More details on these limitations is available in [this blog post](https://web.dev/crux-and-rum-differences/).\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/vitals-ga4/).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `callback` functions and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"5b5c81c1303006ff7164d759d0da03f6e4d730b4","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.5.0-soft-navs-14","_nodeVersion":"18.16.0","_npmVersion":"9.5.1","dist":{"integrity":"sha512-XMleK5IbwUvKGH5lzMQwtW4gDzTR0rUtQQia0Hn6J7Tyc06P8cLbTwhyUUgP9RZer+oIO8Vay8bjM/wEYFWQmw==","shasum":"796a2a61790dc26e65c79ae6b37a3ca511a6051d","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.5.0-soft-navs-14.tgz","fileCount":146,"unpackedSize":459280,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDcK7oMh5cMeQsSQ20MAVKAO6OWtxO2eGrilvy2hlaMCQIgPwelSYHRQZVV0D1F+pK0FkDXT8S/xBATApMYbFGce5A="}]},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.5.0-soft-navs-14_1702636965101_0.7309362390298477"},"_hasShrinkwrap":false},"3.5.1":{"name":"web-vitals","version":"3.5.1","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build test:unit -p -r test:e2e test:server","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","test:unit":"node --test test/unit/*test.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.23.6","@babel/preset-env":"^7.23.6","@rollup/plugin-babel":"^6.0.4","@rollup/plugin-replace":"^5.0.5","@rollup/plugin-terser":"^0.4.4","@typescript-eslint/eslint-plugin":"^6.16.0","@typescript-eslint/parser":"^6.16.0","@wdio/cli":"^8.27.0","@wdio/local-runner":"^8.27.0","@wdio/mocha-framework":"^8.27.0","@wdio/spec-reporter":"^8.27.0","body-parser":"^1.20.2","chromedriver":"^120.0.1","eslint":"^8.56.0","express":"^4.18.2","fs-extra":"^11.2.0","husky":"^8.0.3","lint-staged":"^15.2.0","npm-run-all":"^4.1.5","nunjucks":"^3.2.4","prettier":"^3.1.1","rollup":"^4.9.1","selenium-standalone":"^9.3.1","typescript":"^5.3.3","wdio-chromedriver-service":"^8.1.1"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"gitHead":"a9a90150512582923dfc85f20ddc6898fba5db03","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.5.1","_nodeVersion":"18.12.1","_npmVersion":"9.7.1","dist":{"integrity":"sha512-xQ9lvIpfLxUj0eSmT79ZjRoU5wIRfIr7pNukL7ZE4EcWZSmfZQqOlhuAGfkVa3EFmzPHZhWhXfm2i5ys+THVPg==","shasum":"af7a9dc60708b81007922ab55a23d963676ba30a","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.5.1.tgz","fileCount":143,"unpackedSize":384254,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIG32G2vNw+nTmiQ5/Ldzr+T6KTuB43IQq7j2m9xwtgAZAiATkJFhPy4Zieq+JhG9vpQA7KVfB1irZnTBJTWKZ+M6rQ=="}]},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.5.1_1703708710360_0.4827348993902627"},"_hasShrinkwrap":false},"3.5.1-soft-navs-15":{"name":"web-vitals","version":"3.5.1-soft-navs-15","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build test:unit -p -r test:e2e test:server","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","test:unit":"node --test test/unit/*test.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.23.6","@babel/preset-env":"^7.23.6","@rollup/plugin-babel":"^6.0.4","@rollup/plugin-replace":"^5.0.5","@rollup/plugin-terser":"^0.4.4","@typescript-eslint/eslint-plugin":"^6.16.0","@typescript-eslint/parser":"^6.16.0","@wdio/cli":"^8.27.0","@wdio/local-runner":"^8.27.0","@wdio/mocha-framework":"^8.27.0","@wdio/spec-reporter":"^8.27.0","body-parser":"^1.20.2","chromedriver":"^120.0.1","eslint":"^8.56.0","express":"^4.18.2","fs-extra":"^11.2.0","husky":"^8.0.3","lint-staged":"^15.2.0","npm-run-all":"^4.1.5","nunjucks":"^3.2.4","prettier":"^3.1.1","rollup":"^4.9.1","selenium-standalone":"^9.3.1","typescript":"^5.3.3","wdio-chromedriver-service":"^8.1.1"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Send attribution data](#send-attribution-data)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Build options](#build-options)\n  - [Which build is right for you?](#which-build-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n  - [Rating Thresholds](#rating-thresholds)\n  - [Attribution](#attribution)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1.5K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/articles/vitals) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/articles/vitals#core_web_vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/articles/user-centric-performance-metrics) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/articles/cls)\n- [First Input Delay (FID)](https://web.dev/articles/fid)\n- [Largest Contentful Paint (LCP)](https://web.dev/articles/lcp)\n\n### Other metrics\n\n- [Interaction to next Paint (INP)](https://web.dev/articles/inp)\n- [First Contentful Paint (FCP)](https://web.dev/articles/fcp)\n- [Time to First Byte (TTFB)](https://web.dev/articles/ttfb)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\nThe `web-vitals` library uses the `buffered` flag for [PerformanceObserver](https://developer.mozilla.org/docs/Web/API/PerformanceObserver/observe), allowing it to access performance entries that occurred before the library was loaded.\n\nThis means you do not need to load this library early in order to get accurate performance data. In general, this library should be deferred until after other user-impacting code has loaded.\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are a few different builds of the `web-vitals` library, and how you load the library depends on which build you want to use.\n\nFor details on the difference between the builds, see <a href=\"#which-build-is-right-for-you\">which build is right for you</a>.\n\n**1. The \"standard\" build**\n\nTo load the \"standard\" build, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onFID, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functions were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"attribution-build\"><a>\n\n**2. The \"attribution\" build**\n\nMeasuring the Web Vitals scores for your real users is a great first step toward optimizing the user experience. But if your scores aren't _good_, the next step is to understand why they're not good and work to improve them.\n\nThe \"attribution\" build helps you do that by including additional diagnostic information with each metric to help you identify the root cause of poor performance as well as prioritize the most important things to fix.\n\nThe \"attribution\" build is slightly larger than the \"standard\" build (by about 600 bytes, brotli'd), so while the code size is still small, it's only recommended if you're actually using these features.\n\nTo load the \"attribution\" build, change any `import` statements that reference `web-vitals` to `web-vitals/attribution`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/attribution';\n```\n\nUsage for each of the imported function is identical to the standard build, but when importing from the attribution build, the [`Metric`](#metric) object will contain an additional [`attribution`](#metricwithattribution) property.\n\nSee [Send attribution data](#send-attribution-data) for usage examples, and the [`attribution` reference](#attribution) for details on what values are added for each metric.\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**3. The \"base+polyfill\" build**\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nLoading the \"base+polyfill\" build is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!doctype html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nIt's important that the code is inlined directly into the HTML. _Do not link to an external script file, as that will negatively affect performance:_\n\n```html\n<!-- GOOD -->\n<script>\n  // Inline code from `dist/polyfill.js` here\n</script>\n\n<!-- BAD! DO NOT DO! -->\n<script src=\"/path/to/polyfill.js\"></script>\n```\n\nAlso note that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com):\n\n_**Important!** The [unpkg.com](https://unpkg.com) CDN is shown here for example purposes only. `unpkg.com` is not affiliated with Google, and there are no guarantees that the URLs shown in these examples will continue to work in the future._\n\n**Load the \"standard\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals@3?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src = 'https://unpkg.com/web-vitals@3/dist/web-vitals.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n**Load the \"attribution\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {\n    onCLS,\n    onFID,\n    onLCP,\n  } from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"attribution\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src =\n      'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes a `callback` function that will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" build, but they will work with the \"attribution\" build as well.)_\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developer.chrome.com/docs/devtools/console/reference/#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID and INP are not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS and INP should be reported any time the [page's `visibilityState` changes to hidden](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/articles/bfcache).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onFID()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want the `callback` function to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each layout shift as it happens) by setting `reportAllChanges` to `true` in the optional, [configuration object](#reportopts) (second parameter).\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended) for measuring these metrics in production.\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, {reportAllChanges: true});\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonFID(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `callback` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Report metrics for soft navigations (experimental)\n\n_**Note:** this is experimental and subject to change._\n\nCurrently Core Web Vitals are only tracked for full page navigations, which can affect how [Single Page Applications](https://web.dev/vitals-spa-faq/) that use so called \"soft navigations\" to update the browser URL and history outside of the normal browser's handling of this. The Chrome team are experimenting with being able to [measure these soft navigations](https://github.com/WICG/soft-navigations) separately and report on Core Web Vitals separately for them.\n\nThis experimental support allows sites to measure how their Core Web Vitals might be measured differently should this happen.\n\nAt present a \"soft navigation\" is defined as happening after the following three things happen:\n\n- A user interaction occurs\n- The URL changes\n- Content is added to the DOM\n- Something is painted to screen.\n\nFor some sites, these heuristics may lead to false positives (that users would not really consider a \"navigation\"), or false negatives (where the user does consider a navigation to have happened despite not missing the above criteria). We welcome feedback at https://github.com/WICG/soft-navigations/issues on the heuristics, at https://crbug.com for bugs in the Chrome implementation, and on [https://github.com/GoogleChrome/web-vitals/pull/308](this pull request) for implementation issues with web-vitals.js.\n\n_**Note:** At this time it is not known if this experiment will be something we want to move forward with. Until such time, this support will likely remain in a separate branch of this project, rather than be included in any production builds. If we decide not to move forward with this, the support of this will likely be removed from this project since this library is intended to mirror the Core Web Vitals as much as possible._\n\nSome important points to note:\n\n- TTFB is reported as 0, and not the time of the first network call (if any) after the soft navigation.\n- FCP and LCP are the first and largest contentful paints after the soft navigation. Prior reported paint times will not be counted for these metrics, even though these elements may remain between soft navigations, and may be the first or largest contentful item.\n- FID is reset to measure the first interaction after the soft navigation.\n- INP is reset to measure only interactions after the the soft navigation.\n- CLS is reset to measure again separate to the first page.\n\n_**Note:** It is not known at this time whether soft navigations will be weighted the same as full navigations. No weighting is included in this library at present and metrics are reported in the same way as full page load metrics._\n\nThe metrics can be reported for Soft Navigations using the `reportSoftNavs: true` reporting option:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(console.log, {reportSoftNavs: true});\nonFID(console.log, {reportSoftNavs: true});\nonLCP(console.log, {reportSoftNavs: true});\n```\n\nNote that this will change the way the first page loads are measured as the metrics for the inital URL will be finalized once the first soft nav occurs. To measure both you need to register two callbacks:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(doTraditionalProcessing);\nonFID(doTraditionalProcessing);\nonLCP(doTraditionalProcessing);\n\nonCLS(doSoftNavProcessing, {reportSoftNavs: true});\nonFID(doSoftNavProcessing, {reportSoftNavs: true});\nonLCP(doSoftNavProcessing, {reportSoftNavs: true});\n```\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n    fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonFID(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique event parameter value (in this case, the metric_id, as shown in the example below) on every metric instance that you send to Google Analytics, you can create a report yourself by first getting the data via the [Google Analytics Data API](https://developers.google.com/analytics/devguides/reporting/data/v1) or via [BigQuery export](https://support.google.com/analytics/answer/9358801) and then visualizing it any charting library you choose.\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/articles/debug-performance-in-the-field\n    // metric_rating: 'good' | 'needs-improvement' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\nFor details on how to query this data in [BigQuery](https://cloud.google.com/bigquery), or visualise it in [Looker Studio](https://lookerstudio.google.com/), see [Measure and debug performance with Google Analytics 4 and BigQuery](https://web.dev/articles/vitals-ga4).\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n### Send attribution data\n\nWhen using the [attribution build](#attribution-build), you can send additional data to help you debug _why_ the metric values are they way they are.\n\nThis example sends an additional `debug_target` param to Google Analytics, corresponding to the element most associated with each metric.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals/attribution';\n\nfunction sendToGoogleAnalytics({name, delta, value, id, attribution}) {\n  const eventParams = {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n  };\n\n  switch (name) {\n    case 'CLS':\n      eventParams.debug_target = attribution.largestShiftTarget;\n      break;\n    case 'FID':\n      eventParams.debug_target = attribution.eventTarget;\n      break;\n    case 'LCP':\n      eventParams.debug_target = attribution.element;\n      break;\n  }\n\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, eventParams);\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n_**Note:** this example relies on custom [event parameters](https://support.google.com/analytics/answer/11396839) in Google Analytics 4._\n\nSee [Debug performance in the field](https://web.dev/articles/debug-performance-in-the-field) for more information and examples.\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonFID(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n<a name=\"bundle-versions\"><a>\n\n## Build options\n\nThe `web-vitals` package includes builds for the \"standard\", \"attribution\", and \"base+polyfill\" ([deprecated](https://github.com/GoogleChrome/web-vitals/issues/238)) builds, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the builds distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any attribution features.</p>\n      This is the \"standard\" build and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.cjs</code></td>\n    <td><code>pkg.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.attribution.js</code></td>\n    <td>--</td>\n    <td>\n      An ES module version of all metric functions that includes <a href=\"#attribution-build\">attribution</a> features.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.iife.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An IIFE version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code>, <code>web-vitals.base.umd.cjs</code>, or <code>web-vitals.base.iife.js</code> (it will not work with any script that doesn't have \"base\" in the filename).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n<a name=\"which-build-is-right-for-you\"><a>\n\n### Which build is right for you?\n\nMost developers will generally want to use \"standard\" build (via either the ES module or UMD version, depending on your bundler/build system), as it's the easiest to use out of the box and integrate into existing tools.\n\nHowever, if you'd lke to collect additional debug information to help you diagnose performance bottlenecks based on real-user issues, use the [\"attribution\" build](#attribution-build).\n\nFor guidance on how to collect and use real-user data to debug performance issues, see [Debug performance in the field](https://web.dev/debug-performance-in-the-field/).\n\n### How the polyfill works\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nThe `polyfill.js` script adds event listeners (to track FID cross-browser), and it records initial page visibility state as well as the timestamp of the first visibility change to hidden (to improve the accuracy of CLS, FCP, LCP, and FID). It also polyfills the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) in browsers that only support the original (now deprecated) [Navigation Timing API](https://www.w3.org/TR/navigation-timing/).\n\nIn order for the polyfill to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" build of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" build, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  /**\n   * The name of the metric (in acronym form).\n   */\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  /**\n   * The current value of the metric.\n   */\n  value: number;\n\n  /**\n   * The rating as to whether the metric value is within the \"good\",\n   * \"needs improvement\", or \"poor\" thresholds of the metric.\n   */\n  rating: 'good' | 'needs-improvement' | 'poor';\n\n  /**\n   * The delta between the current value and the last-reported value.\n   * On the first report, `delta` and `value` will always be the same.\n   */\n  delta: number;\n\n  /**\n   * A unique ID representing this particular metric instance. This ID can\n   * be used by an analytics tool to dedupe multiple values sent for the same\n   * metric instance, or to group multiple deltas together and calculate a\n   * total. It can also be used to differentiate multiple different metric\n   * instances sent from the same page, which can happen if the page is\n   * restored from the back/forward cache (in that case new metrics object\n   * get created).\n   */\n  id: string;\n\n  /**\n   * Any performance entries relevant to the metric value calculation.\n   * The array may also be empty if the metric value was not based on any\n   * entries (e.g. a CLS value of 0 given no layout shifts).\n   */\n  entries: (\n    | PerformanceEntry\n    | LayoutShift\n    | FirstInputPolyfillEntry\n    | NavigationTimingPolyfillEntry\n  )[];\n\n  /**\n   * The type of navigation.\n   *\n   * This will be the value returned by the Navigation Timing API (or\n   * `undefined` if the browser doesn't support that API), with the following\n   * exceptions:\n   * - 'back-forward-cache': for pages that are restored from the bfcache.\n   * - 'prerender': for pages that were prerendered.\n   * - 'restore': for pages that were discarded by the browser and then\n   * restored by the user.\n   */\n  navigationType:\n    | 'navigate'\n    | 'reload'\n    | 'back-forward'\n    | 'back-forward-cache'\n    | 'prerender'\n    | 'restore'\n    | 'soft-navigation';\n\n  /**\n   * The navigatonId the metric happened for. This is particularly relevent for soft navigations where\n   * the metric may be reported for a previous URL.\n   */\n  navigatonId: number;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetric`](/src/types/cls.ts#:~:text=interface%20CLSMetric)\n- [`FCPMetric`](/src/types/fcp.ts#:~:text=interface%20FCPMetric)\n- [`FIDMetric`](/src/types/fid.ts#:~:text=interface%20FIDMetric)\n- [`INPMetric`](/src/types/inp.ts#:~:text=interface%20INPMetric)\n- [`LCPMetric`](/src/types/lcp.ts#:~:text=interface%20LCPMetric)\n- [`TTFBMetric`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetric)\n\n#### `MetricWithAttribution`\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n```ts\ninterface MetricWithAttribution extends Metric {\n  /**\n   * An object containing potentially-helpful debugging information that\n   * can be sent along with the metric value for the current page visit in\n   * order to help identify issues happening to real-users in the field.\n   */\n  attribution: {[key: string]: unknown};\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetricWithAttribution`](/src/types/cls.ts#:~:text=interface%20CLSMetricWithAttribution)\n- [`FCPMetricWithAttribution`](/src/types/fcp.ts#:~:text=interface%20FCPMetricWithAttribution)\n- [`FIDMetricWithAttribution`](/src/types/fid.ts#:~:text=interface%20FIDMetricWithAttribution)\n- [`INPMetricWithAttribution`](/src/types/inp.ts#:~:text=interface%20INPMetricWithAttribution)\n- [`LCPMetricWithAttribution`](/src/types/lcp.ts#:~:text=interface%20LCPMetricWithAttribution)\n- [`TTFBMetricWithAttribution`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetricWithAttribution)\n\n#### `MetricRatingThresholds`\n\nThe thresholds of metric's \"good\", \"needs improvement\", and \"poor\" ratings.\n\n- Metric values up to and including [0] are rated \"good\"\n- Metric values up to and including [1] are rated \"needs improvement\"\n- Metric values above [1] are \"poor\"\n\n| Metric value    | Rating              |\n| --------------- | ------------------- |\n| ≦ [0]           | \"good\"              |\n| > [0] and ≦ [1] | \"needs improvement\" |\n| > [1]           | \"poor\"              |\n\n```ts\nexport type MetricRatingThresholds = [number, number];\n```\n\n_See also [Rating Thresholds](#rating-thresholds)._\n\n#### `ReportCallback`\n\n```ts\ninterface ReportCallback {\n  (metric: Metric): void;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSReportCallback`](/src/types/cls.ts#:~:text=interface%20CLSReportCallback)\n- [`FCPReportCallback`](/src/types/fcp.ts#:~:text=interface%20FCPReportCallback)\n- [`FIDReportCallback`](/src/types/fid.ts#:~:text=interface%20FIDReportCallback)\n- [`INPReportCallback`](/src/types/inp.ts#:~:text=interface%20INPReportCallback)\n- [`LCPReportCallback`](/src/types/lcp.ts#:~:text=interface%20LCPReportCallback)\n- [`TTFBReportCallback`](/src/types/ttfb.ts#:~:text=interface%20TTFBReportCallback)\n\n#### `ReportOpts`\n\n```ts\ninterface ReportOpts {\n  reportAllChanges?: boolean;\n  durationThreshold?: number;\n  reportSoftNavs?: boolean;\n}\n```\n\n#### `LoadState`\n\nThe `LoadState` type is used in several of the metric [attribution objects](#attribution).\n\n```ts\n/**\n * The loading state of the document. Note: this value is similar to\n * `document.readyState` but it subdivides the \"interactive\" state into the\n * time before and after the DOMContentLoaded event fires.\n *\n * State descriptions:\n * - `loading`: the initial document response has not yet been fully downloaded\n *   and parsed. This is equivalent to the corresponding `readyState` value.\n * - `dom-interactive`: the document has been fully loaded and parsed, but\n *   scripts may not have yet finished loading and executing.\n * - `dom-content-loaded`: the document is fully loaded and parsed, and all\n *   scripts (except `async` scripts) have loaded and finished executing.\n * - `complete`: the document and all of its sub-resources have finished\n *   loading. This is equivalent to the corresponding `readyState` value.\n */\ntype LoadState =\n  | 'loading'\n  | 'dom-interactive'\n  | 'dom-content-loaded'\n  | 'complete';\n```\n\n#### `FirstInputPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't natively support the Event Timing API), the `metric.entries` reported by `onFID()` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<\n  PerformanceEventTiming,\n  'processingEnd' | 'toJSON'\n>;\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface), the `metric.entries` reported by `onTTFB()` will contain an object that polyfills the `PerformanceNavigationTiming` entry using timings from the legacy `performance.timing` interface:\n\n```ts\ntype NavigationTimingPolyfillEntry = Omit<\n  PerformanceNavigationTiming,\n  | 'initiatorType'\n  | 'nextHopProtocol'\n  | 'redirectCount'\n  | 'transferSize'\n  | 'encodedBodySize'\n  | 'decodedBodySize'\n  | 'type'\n> & {\n  type: PerformanceNavigationTiming['type'];\n};\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n  firstHiddenTime: number;\n}\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (callback: CLSReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [CLS](https://web.dev/articles/cls) value for the current page and calls the `callback` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/articles/cls#layout_shift_score)).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (callback: FCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FCP](https://web.dev/articles/fcp) value for the current page and calls the `callback` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n```ts\ntype onFID = (callback: FIDReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FID](https://web.dev/articles/fid) value for the current page and calls the `callback` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (callback: INPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [INP](https://web.dev/articles/inp) value for the current page and calls the `callback` function once the value is ready, along with the `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp).\n\nA custom `durationThreshold` [configuration option](#reportopts) can optionally be passed to control what `event-timing` entries are considered for INP reporting. The default threshold is `40`, which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended [good](https://web.dev/articles/inp#what_is_a_good_inp_score) threshold).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan.\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (callback: LCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [LCP](https://web.dev/articles/lcp) value for the current page and calls the `callback` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (callback: TTFBReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [TTFB](https://web.dev/articles/ttfb) value for the current page and calls the `callback` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `callback` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it includes time spent on DNS lookup, connection negotiation, network latency, and server processing time.\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n### Rating Thresholds:\n\nThe thresholds of each metric's \"good\", \"needs improvement\", and \"poor\" ratings are available as [`MetricRatingThresholds`](#metricratingthresholds).\n\nExample:\n\n```ts\nimport {CLSThresholds, FIDThresholds, LCPThresholds} from 'web-vitals';\n\nconsole.log(CLSThresholds); // [ 0.1, 0.25 ]\nconsole.log(FIDThresholds); // [ 100, 300 ]\nconsole.log(LCPThresholds); // [ 2500, 4000 ]\n```\n\n_**Note:** It's typically not necessary (or recommended) to manually calculate metric value ratings using these thresholds. Use the [`Metric['rating']`](#metric) supplied by the [`ReportCallback`](#reportcallback) functions instead._\n\n### Attribution:\n\nThe following objects contain potentially-helpful debugging information that can be sent along with the metric values for the current page visit in order to help identify issues happening to real-users in the field.\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n#### CLS `attribution`:\n\n```ts\ninterface CLSAttribution {\n  /**\n   * A selector identifying the first element (in document order) that\n   * shifted when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTarget?: string;\n  /**\n   * The time when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTime?: DOMHighResTimeStamp;\n  /**\n   * The layout shift score of the single largest layout shift contributing to\n   * the page's CLS score.\n   */\n  largestShiftValue?: number;\n  /**\n   * The `LayoutShiftEntry` representing the single largest layout shift\n   * contributing to the page's CLS score. (Useful when you need more than just\n   * `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftEntry?: LayoutShift;\n  /**\n   * The first element source (in document order) among the `sources` list\n   * of the `largestShiftEntry` object. (Also useful when you need more than\n   * just `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftSource?: LayoutShiftAttribution;\n  /**\n   * The loading state of the document at the time when the largest layout\n   * shift contribution to the page's CLS score occurred (see `LoadState`\n   * for details).\n   */\n  loadState?: LoadState;\n}\n```\n\n#### FCP `attribution`:\n\n```ts\ninterface FCPAttribution {\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB).\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and the first contentful paint (FCP).\n   */\n  firstByteToFCP: number;\n  /**\n   * The loading state of the document at the time when FCP `occurred (see\n   * `LoadState` for details). Ideally, documents can paint before they finish\n   * loading (e.g. the `loading` or `dom-interactive` phases).\n   */\n  loadState: LoadState;\n  /**\n   * The `PerformancePaintTiming` entry corresponding to FCP.\n   */\n  fcpEntry?: PerformancePaintTiming;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n#### FID `attribution`:\n\n```ts\ninterface FIDAttribution {\n  /**\n   * A selector identifying the element that the user interacted with. This\n   * element will be the `target` of the `event` dispatched.\n   */\n  eventTarget: string;\n  /**\n   * The time when the user interacted. This time will match the `timeStamp`\n   * value of the `event` dispatched.\n   */\n  eventTime: number;\n  /**\n   * The `type` of the `event` dispatched from the user interaction.\n   */\n  eventType: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to FID (or the\n   * polyfill entry in browsers that don't support Event Timing).\n   */\n  eventEntry: PerformanceEventTiming | FirstInputPolyfillEntry;\n  /**\n   * The loading state of the document at the time when the first interaction\n   * occurred (see `LoadState` for details). If the first interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long input delays.\n   */\n  loadState: LoadState;\n}\n```\n\n#### INP `attribution`:\n\n```ts\ninterface INPAttribution {\n  /**\n   * A selector identifying the element that the user interacted with for\n   * the event corresponding to INP. This element will be the `target` of the\n   * `event` dispatched.\n   */\n  eventTarget?: string;\n  /**\n   * The time when the user interacted for the event corresponding to INP.\n   * This time will match the `timeStamp` value of the `event` dispatched.\n   */\n  eventTime?: number;\n  /**\n   * The `type` of the `event` dispatched corresponding to INP.\n   */\n  eventType?: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to INP.\n   */\n  eventEntry?: PerformanceEventTiming;\n  /**\n   * The loading state of the document at the time when the even corresponding\n   * to INP occurred (see `LoadState` for details). If the interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long delays.\n   */\n  loadState?: LoadState;\n}\n```\n\n#### LCP `attribution`:\n\n```ts\ninterface LCPAttribution {\n  /**\n   * The element corresponding to the largest contentful paint for the page.\n   */\n  element?: string;\n  /**\n   * The URL (if applicable) of the LCP image resource. If the LCP element\n   * is a text node, this value will not be set.\n   */\n  url?: string;\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB). See\n   * [Optimize LCP](https://web.dev/articles/optimize-lcp) for details.\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and when the browser starts loading the LCP\n   * resource (if there is one, otherwise 0). See [Optimize\n   * LCP](https://web.dev/articles/optimize-lcp) for details.\n   */\n  resourceLoadDelay: number;\n  /**\n   * The total time it takes to load the LCP resource itself (if there is one,\n   * otherwise 0). See [Optimize LCP](https://web.dev/articles/optimize-lcp) for\n   * details.\n   */\n  resourceLoadTime: number;\n  /**\n   * The delta between when the LCP resource finishes loading until the LCP\n   * element is fully rendered. See [Optimize\n   * LCP](https://web.dev/articles/optimize-lcp) for details.\n   */\n  elementRenderDelay: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n  /**\n   * The `resource` entry for the LCP resource (if applicable), which is useful\n   * for diagnosing resource load issues.\n   */\n  lcpResourceEntry?: PerformanceResourceTiming;\n  /**\n   * The `LargestContentfulPaint` entry corresponding to LCP.\n   */\n  lcpEntry?: LargestContentfulPaint;\n}\n```\n\n#### TTFB `attribution`:\n\n```ts\ninterface TTFBAttribution {\n  /**\n   * The total time from when the user initiates loading the page to when the\n   * DNS lookup begins. This includes redirects, service worker startup, and\n   * HTTP cache lookup times.\n   */\n  waitingTime: number;\n  /**\n   * The total time to resolve the DNS for the current request.\n   */\n  dnsTime: number;\n  /**\n   * The total time to create the connection to the requested domain.\n   */\n  connectionTime: number;\n  /**\n   * The time time from when the request was sent until the first byte of the\n   * response was received. This includes network time as well as server\n   * processing time.\n   */\n  requestTime: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium\n- `onFCP()`: Chromium, Firefox, Safari 14.1+\n- `onFID()`: Chromium, Firefox _(with [polyfill](#how-to-use-the-polyfill): Safari, Internet Explorer)_\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari 15+ _(with [polyfill](#how-to-use-the-polyfill): Safari 8+, Internet Explorer)_\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that measure the Web Vitals metrics, which means the limitations of those APIs will mostly apply to this library as well. More details on these limitations is available in [this blog post](https://web.dev/articles/crux-and-rum-differences).\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/articles/vitals-ga4).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `callback` functions and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"3ebf57fc55c3eaf7046396086464aa2c54b8abb4","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.5.1-soft-navs-15","_nodeVersion":"18.16.0","_npmVersion":"9.5.1","dist":{"integrity":"sha512-722LSXYqI9GKJUyQOumRiRLBEyHZHH/EoVF6yDkJUsNzO4sTDiNbUANwUkDZBDoiaGjPXuIteHHxxAHvbZhPhg==","shasum":"d58df675662499122a7b6019b49d8968dffc72c1","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.5.1-soft-navs-15.tgz","fileCount":146,"unpackedSize":460117,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQD9OFvJnCIBaZRpSSWCiiJILqVUxBZqCEVOkGpW7bR7ZgIgHPk+L1j6+sRea8ly0qcm48tR1rmFGFoA4RrCo28ZKaM="}]},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.5.1-soft-navs-15_1703788058914_0.6397026170527262"},"_hasShrinkwrap":false},"3.5.2":{"name":"web-vitals","version":"3.5.2","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build test:unit -p -r test:e2e test:server","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","test:unit":"node --test test/unit/*test.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.23.6","@babel/preset-env":"^7.23.6","@rollup/plugin-babel":"^6.0.4","@rollup/plugin-replace":"^5.0.5","@rollup/plugin-terser":"^0.4.4","@typescript-eslint/eslint-plugin":"^6.16.0","@typescript-eslint/parser":"^6.16.0","@wdio/cli":"^8.27.0","@wdio/local-runner":"^8.27.0","@wdio/mocha-framework":"^8.27.0","@wdio/spec-reporter":"^8.27.0","body-parser":"^1.20.2","chromedriver":"^120.0.1","eslint":"^8.56.0","express":"^4.18.2","fs-extra":"^11.2.0","husky":"^8.0.3","lint-staged":"^15.2.0","npm-run-all":"^4.1.5","nunjucks":"^3.2.4","prettier":"^3.1.1","rollup":"^4.9.1","selenium-standalone":"^9.3.1","typescript":"^5.3.3","wdio-chromedriver-service":"^8.1.1"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"gitHead":"6cd88fa88fef0cce445ca25af4f81d2129459352","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.5.2","_nodeVersion":"18.16.0","_npmVersion":"9.5.1","dist":{"integrity":"sha512-c0rhqNcHXRkY/ogGDJQxZ9Im9D19hDihbzSQJrsioex+KnFgmMzBiy57Z1EjkhX/+OjyBpclDCzz2ITtjokFmg==","shasum":"5bb58461bbc173c3f00c2ddff8bfe6e680999ca9","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.5.2.tgz","fileCount":143,"unpackedSize":386020,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDXnzcIi8kqxEc8fBzvFG0UlFO/LOoCi1jwskZxSluYGwIgT/KGNmMeKLX4pvnGXBfgohq87scecBXAHJpSwmtRFH0="}]},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.5.2_1706215321643_0.5724853289623617"},"_hasShrinkwrap":false},"3.5.2-soft-navs-16":{"name":"web-vitals","version":"3.5.2-soft-navs-16","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./base":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./base.js":{"types":"./base.d.ts","require":"./dist/web-vitals.base.umd.cjs","default":"./dist/web-vitals.base.js"},"./attribution":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build test:unit -p -r test:e2e test:server","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","test:unit":"node --test test/unit/*test.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.23.6","@babel/preset-env":"^7.23.6","@rollup/plugin-babel":"^6.0.4","@rollup/plugin-replace":"^5.0.5","@rollup/plugin-terser":"^0.4.4","@typescript-eslint/eslint-plugin":"^6.16.0","@typescript-eslint/parser":"^6.16.0","@wdio/cli":"^8.27.0","@wdio/local-runner":"^8.27.0","@wdio/mocha-framework":"^8.27.0","@wdio/spec-reporter":"^8.27.0","body-parser":"^1.20.2","chromedriver":"^120.0.1","eslint":"^8.56.0","express":"^4.18.2","fs-extra":"^11.2.0","husky":"^8.0.3","lint-staged":"^15.2.0","npm-run-all":"^4.1.5","nunjucks":"^3.2.4","prettier":"^3.1.1","rollup":"^4.9.1","selenium-standalone":"^9.3.1","typescript":"^5.3.3","wdio-chromedriver-service":"^8.1.1"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Send attribution data](#send-attribution-data)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Build options](#build-options)\n  - [Which build is right for you?](#which-build-is-right-for-you)\n  - [How the polyfill works](#how-the-polyfill-works)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n  - [Rating Thresholds](#rating-thresholds)\n  - [Attribution](#attribution)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~1.5K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/articles/vitals) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/articles/vitals#core_web_vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/articles/user-centric-performance-metrics) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/articles/cls)\n- [First Input Delay (FID)](https://web.dev/articles/fid)\n- [Largest Contentful Paint (LCP)](https://web.dev/articles/lcp)\n\n### Other metrics\n\n- [Interaction to next Paint (INP)](https://web.dev/articles/inp)\n- [First Contentful Paint (FCP)](https://web.dev/articles/fcp)\n- [Time to First Byte (TTFB)](https://web.dev/articles/ttfb)\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\nThe `web-vitals` library uses the `buffered` flag for [PerformanceObserver](https://developer.mozilla.org/docs/Web/API/PerformanceObserver/observe), allowing it to access performance entries that occurred before the library was loaded.\n\nThis means you do not need to load this library early in order to get accurate performance data. In general, this library should be deferred until after other user-impacting code has loaded.\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are a few different builds of the `web-vitals` library, and how you load the library depends on which build you want to use.\n\nFor details on the difference between the builds, see <a href=\"#which-build-is-right-for-you\">which build is right for you</a>.\n\n**1. The \"standard\" build**\n\nTo load the \"standard\" build, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onFID, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functions were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"attribution-build\"><a>\n\n**2. The \"attribution\" build**\n\nMeasuring the Web Vitals scores for your real users is a great first step toward optimizing the user experience. But if your scores aren't _good_, the next step is to understand why they're not good and work to improve them.\n\nThe \"attribution\" build helps you do that by including additional diagnostic information with each metric to help you identify the root cause of poor performance as well as prioritize the most important things to fix.\n\nThe \"attribution\" build is slightly larger than the \"standard\" build (by about 600 bytes, brotli'd), so while the code size is still small, it's only recommended if you're actually using these features.\n\nTo load the \"attribution\" build, change any `import` statements that reference `web-vitals` to `web-vitals/attribution`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/attribution';\n```\n\nUsage for each of the imported function is identical to the standard build, but when importing from the attribution build, the [`Metric`](#metric) object will contain an additional [`attribution`](#metricwithattribution) property.\n\nSee [Send attribution data](#send-attribution-data) for usage examples, and the [`attribution` reference](#attribution) for details on what values are added for each metric.\n\n<a name=\"how-to-use-the-polyfill\"><a>\n\n**3. The \"base+polyfill\" build**\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nLoading the \"base+polyfill\" build is a two-step process:\n\nFirst, in your application code, import the \"base\" build rather than the \"standard\" build. To do this, change any `import` statements that reference `web-vitals` to `web-vitals/base`:\n\n```diff\n- import {onLCP, onFID, onCLS} from 'web-vitals';\n+ import {onLCP, onFID, onCLS} from 'web-vitals/base';\n```\n\nThen, inline the code from `dist/polyfill.js` into the `<head>` of your pages. This step is important since the \"base\" build will error if the polyfill code has not been added.\n\n```html\n<!doctype html>\n<html>\n  <head>\n    <script>\n      // Inline code from `dist/polyfill.js` here\n    </script>\n  </head>\n  <body>\n    ...\n  </body>\n</html>\n```\n\nIt's important that the code is inlined directly into the HTML. _Do not link to an external script file, as that will negatively affect performance:_\n\n```html\n<!-- GOOD -->\n<script>\n  // Inline code from `dist/polyfill.js` here\n</script>\n\n<!-- BAD! DO NOT DO! -->\n<script src=\"/path/to/polyfill.js\"></script>\n```\n\nAlso note that the code _must_ go in the `<head>` of your pages in order to work. See [how the polyfill works](#how-the-polyfill-works) for more details.\n\n_**Tip:** while it's certainly possible to inline the code in `dist/polyfill.js` by copy and pasting it directly into your templates, it's better to automate this process in a build step—otherwise you risk the \"base\" and the \"polyfill\" scripts getting out of sync when new versions are released._\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com):\n\n_**Important!** The [unpkg.com](https://unpkg.com) CDN is shown here for example purposes only. `unpkg.com` is not affiliated with Google, and there are no guarantees that the URLs shown in these examples will continue to work in the future._\n\n**Load the \"standard\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onFID, onLCP} from 'https://unpkg.com/web-vitals@3?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src = 'https://unpkg.com/web-vitals@3/dist/web-vitals.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n**Load the \"attribution\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {\n    onCLS,\n    onFID,\n    onLCP,\n  } from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js?module';\n\n  onCLS(console.log);\n  onFID(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"attribution\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src =\n      'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onFID(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes a `callback` function that will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" build, but they will work with the \"attribution\" build as well.)_\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonFID(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developer.chrome.com/docs/devtools/console/reference/#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID and INP are not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS and INP should be reported any time the [page's `visibilityState` changes to hidden](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/articles/bfcache).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onFID()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want the `callback` function to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each larger layout shift as it happens) by setting `reportAllChanges` to `true` in the optional, [configuration object](#reportopts) (second parameter).\n\n_**Important:** `reportAllChanges` only reports when the **metric changes**, not for each **input to the metric**. For example, a new layout shift that does not increase the CLS metric will not be reported even with `reportAllChanges` set to `true` because the CLS metric has not changed. Similarly, for INP, each interaction is not reported even with `reportAllChanges` set to `true`—just when an interaction causes an increase to INP._\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended) for measuring these metrics in production.\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, {reportAllChanges: true});\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonFID(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `callback` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Report metrics for soft navigations (experimental)\n\n_**Note:** this is experimental and subject to change._\n\nCurrently Core Web Vitals are only tracked for full page navigations, which can affect how [Single Page Applications](https://web.dev/vitals-spa-faq/) that use so called \"soft navigations\" to update the browser URL and history outside of the normal browser's handling of this. The Chrome team are experimenting with being able to [measure these soft navigations](https://github.com/WICG/soft-navigations) separately and report on Core Web Vitals separately for them.\n\nThis experimental support allows sites to measure how their Core Web Vitals might be measured differently should this happen.\n\nAt present a \"soft navigation\" is defined as happening after the following three things happen:\n\n- A user interaction occurs\n- The URL changes\n- Content is added to the DOM\n- Something is painted to screen.\n\nFor some sites, these heuristics may lead to false positives (that users would not really consider a \"navigation\"), or false negatives (where the user does consider a navigation to have happened despite not missing the above criteria). We welcome feedback at https://github.com/WICG/soft-navigations/issues on the heuristics, at https://crbug.com for bugs in the Chrome implementation, and on [https://github.com/GoogleChrome/web-vitals/pull/308](this pull request) for implementation issues with web-vitals.js.\n\n_**Note:** At this time it is not known if this experiment will be something we want to move forward with. Until such time, this support will likely remain in a separate branch of this project, rather than be included in any production builds. If we decide not to move forward with this, the support of this will likely be removed from this project since this library is intended to mirror the Core Web Vitals as much as possible._\n\nSome important points to note:\n\n- TTFB is reported as 0, and not the time of the first network call (if any) after the soft navigation.\n- FCP and LCP are the first and largest contentful paints after the soft navigation. Prior reported paint times will not be counted for these metrics, even though these elements may remain between soft navigations, and may be the first or largest contentful item.\n- FID is reset to measure the first interaction after the soft navigation.\n- INP is reset to measure only interactions after the the soft navigation.\n- CLS is reset to measure again separate to the first page.\n\n_**Note:** It is not known at this time whether soft navigations will be weighted the same as full navigations. No weighting is included in this library at present and metrics are reported in the same way as full page load metrics._\n\nThe metrics can be reported for Soft Navigations using the `reportSoftNavs: true` reporting option:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(console.log, {reportSoftNavs: true});\nonFID(console.log, {reportSoftNavs: true});\nonLCP(console.log, {reportSoftNavs: true});\n```\n\nNote that this will change the way the first page loads are measured as the metrics for the inital URL will be finalized once the first soft nav occurs. To measure both you need to register two callbacks:\n\n```js\nimport {\n  onCLS,\n  onFID,\n  onLCP,\n} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';\n\nonCLS(doTraditionalProcessing);\nonFID(doTraditionalProcessing);\nonLCP(doTraditionalProcessing);\n\nonCLS(doSoftNavProcessing, {reportSoftNavs: true});\nonFID(doSoftNavProcessing, {reportSoftNavs: true});\nonLCP(doSoftNavProcessing, {reportSoftNavs: true});\n```\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n    fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonFID(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique event parameter value (in this case, the metric_id, as shown in the example below) on every metric instance that you send to Google Analytics, you can create a report yourself by first getting the data via the [Google Analytics Data API](https://developers.google.com/analytics/devguides/reporting/data/v1) or via [BigQuery export](https://support.google.com/analytics/answer/9358801) and then visualizing it any charting library you choose.\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/articles/debug-performance-in-the-field\n    // metric_rating: 'good' | 'needs-improvement' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\nFor details on how to query this data in [BigQuery](https://cloud.google.com/bigquery), or visualise it in [Looker Studio](https://lookerstudio.google.com/), see [Measure and debug performance with Google Analytics 4 and BigQuery](https://web.dev/articles/vitals-ga4).\n\n### Send the results to Google Tag Manager\n\nThe recommended way to measure Web Vitals metrics with Google Tag Manager is using the [Core Web Vitals](https://www.simoahava.com/custom-templates/core-web-vitals/) custom template tag created and maintained by [Simo Ahava](https://www.simoahava.com/).\n\nFor full installation and usage instructions, see Simo's post: [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/).\n\n### Send attribution data\n\nWhen using the [attribution build](#attribution-build), you can send additional data to help you debug _why_ the metric values are they way they are.\n\nThis example sends an additional `debug_target` param to Google Analytics, corresponding to the element most associated with each metric.\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals/attribution';\n\nfunction sendToGoogleAnalytics({name, delta, value, id, attribution}) {\n  const eventParams = {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n  };\n\n  switch (name) {\n    case 'CLS':\n      eventParams.debug_target = attribution.largestShiftTarget;\n      break;\n    case 'FID':\n      eventParams.debug_target = attribution.eventTarget;\n      break;\n    case 'LCP':\n      eventParams.debug_target = attribution.element;\n      break;\n  }\n\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, eventParams);\n}\n\nonCLS(sendToGoogleAnalytics);\nonFID(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n_**Note:** this example relies on custom [event parameters](https://support.google.com/analytics/answer/11396839) in Google Analytics 4._\n\nSee [Debug performance in the field](https://web.dev/articles/debug-performance-in-the-field) for more information and examples.\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onFID, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonFID(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n<a name=\"bundle-versions\"><a>\n\n## Build options\n\nThe `web-vitals` package includes builds for the \"standard\", \"attribution\", and \"base+polyfill\" ([deprecated](https://github.com/GoogleChrome/web-vitals/issues/238)) builds, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the builds distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any attribution features.</p>\n      This is the \"standard\" build and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.cjs</code></td>\n    <td><code>pkg.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.attribution.js</code></td>\n    <td>--</td>\n    <td>\n      An ES module version of all metric functions that includes <a href=\"#attribution-build\">attribution</a> features.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>window.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.base.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An ES module bundle containing just the \"base\" part of the \"base+polyfill\" version.</p>\n      Use this bundle if (and only if) you've also added the <code>polyfill.js</code> script to the <code>&lt;head&gt;</code> of your pages. See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>A UMD version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.base.iife.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>An IIFE version of the <code>web-vitals.base.js</code> bundle (exposed on the <code>window.webVitals.*</code> namespace).</p>\n    </td>\n  </tr>\n  <tr>\n    <td><code>polyfill.js</code></td>\n    <td>--</td>\n    <td>\n      <p><strong>This build has been <a href=\"https://github.com/GoogleChrome/web-vitals/issues/238\">deprecated</a>.</strong></p>\n      <p>The \"polyfill\" part of the \"base+polyfill\" version. This script should be used with either <code>web-vitals.base.js</code>, <code>web-vitals.base.umd.cjs</code>, or <code>web-vitals.base.iife.js</code> (it will not work with any script that doesn't have \"base\" in the filename).</p>\n      See <a href=\"#how-to-use-the-polyfill\">how to use the polyfill</a> for more details.\n    </td>\n  </tr>\n</table>\n\n<a name=\"which-build-is-right-for-you\"><a>\n\n### Which build is right for you?\n\nMost developers will generally want to use \"standard\" build (via either the ES module or UMD version, depending on your bundler/build system), as it's the easiest to use out of the box and integrate into existing tools.\n\nHowever, if you'd lke to collect additional debug information to help you diagnose performance bottlenecks based on real-user issues, use the [\"attribution\" build](#attribution-build).\n\nFor guidance on how to collect and use real-user data to debug performance issues, see [Debug performance in the field](https://web.dev/debug-performance-in-the-field/).\n\n### How the polyfill works\n\n_**⚠️ Warning ⚠️** the \"base+polyfill\" build is deprecated. See [#238](https://github.com/GoogleChrome/web-vitals/issues/238) for details._\n\nThe `polyfill.js` script adds event listeners (to track FID cross-browser), and it records initial page visibility state as well as the timestamp of the first visibility change to hidden (to improve the accuracy of CLS, FCP, LCP, and FID). It also polyfills the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) in browsers that only support the original (now deprecated) [Navigation Timing API](https://www.w3.org/TR/navigation-timing/).\n\nIn order for the polyfill to work properly, the script must be the first script added to the page, and it must run before the browser renders any content to the screen. This is why it needs to be added to the `<head>` of the document.\n\nThe \"standard\" build of the `web-vitals` library includes some of the same logic found in `polyfill.js`. To avoid duplicating that code when using the \"base+polyfill\" build, the `web-vitals.base.js` bundle does not include any polyfill logic, instead it coordinates with the code in `polyfill.js`, which is why the two scripts must be used together.\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  /**\n   * The name of the metric (in acronym form).\n   */\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  /**\n   * The current value of the metric.\n   */\n  value: number;\n\n  /**\n   * The rating as to whether the metric value is within the \"good\",\n   * \"needs improvement\", or \"poor\" thresholds of the metric.\n   */\n  rating: 'good' | 'needs-improvement' | 'poor';\n\n  /**\n   * The delta between the current value and the last-reported value.\n   * On the first report, `delta` and `value` will always be the same.\n   */\n  delta: number;\n\n  /**\n   * A unique ID representing this particular metric instance. This ID can\n   * be used by an analytics tool to dedupe multiple values sent for the same\n   * metric instance, or to group multiple deltas together and calculate a\n   * total. It can also be used to differentiate multiple different metric\n   * instances sent from the same page, which can happen if the page is\n   * restored from the back/forward cache (in that case new metrics object\n   * get created).\n   */\n  id: string;\n\n  /**\n   * Any performance entries relevant to the metric value calculation.\n   * The array may also be empty if the metric value was not based on any\n   * entries (e.g. a CLS value of 0 given no layout shifts).\n   */\n  entries: (\n    | PerformanceEntry\n    | LayoutShift\n    | FirstInputPolyfillEntry\n    | NavigationTimingPolyfillEntry\n  )[];\n\n  /**\n   * The type of navigation.\n   *\n   * This will be the value returned by the Navigation Timing API (or\n   * `undefined` if the browser doesn't support that API), with the following\n   * exceptions:\n   * - 'back-forward-cache': for pages that are restored from the bfcache.\n   * - 'prerender': for pages that were prerendered.\n   * - 'restore': for pages that were discarded by the browser and then\n   * restored by the user.\n   */\n  navigationType:\n    | 'navigate'\n    | 'reload'\n    | 'back-forward'\n    | 'back-forward-cache'\n    | 'prerender'\n    | 'restore'\n    | 'soft-navigation';\n\n  /**\n   * The navigatonId the metric happened for. This is particularly relevent for soft navigations where\n   * the metric may be reported for a previous URL.\n   */\n  navigatonId: number;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetric`](/src/types/cls.ts#:~:text=interface%20CLSMetric)\n- [`FCPMetric`](/src/types/fcp.ts#:~:text=interface%20FCPMetric)\n- [`FIDMetric`](/src/types/fid.ts#:~:text=interface%20FIDMetric)\n- [`INPMetric`](/src/types/inp.ts#:~:text=interface%20INPMetric)\n- [`LCPMetric`](/src/types/lcp.ts#:~:text=interface%20LCPMetric)\n- [`TTFBMetric`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetric)\n\n#### `MetricWithAttribution`\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n```ts\ninterface MetricWithAttribution extends Metric {\n  /**\n   * An object containing potentially-helpful debugging information that\n   * can be sent along with the metric value for the current page visit in\n   * order to help identify issues happening to real-users in the field.\n   */\n  attribution: {[key: string]: unknown};\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetricWithAttribution`](/src/types/cls.ts#:~:text=interface%20CLSMetricWithAttribution)\n- [`FCPMetricWithAttribution`](/src/types/fcp.ts#:~:text=interface%20FCPMetricWithAttribution)\n- [`FIDMetricWithAttribution`](/src/types/fid.ts#:~:text=interface%20FIDMetricWithAttribution)\n- [`INPMetricWithAttribution`](/src/types/inp.ts#:~:text=interface%20INPMetricWithAttribution)\n- [`LCPMetricWithAttribution`](/src/types/lcp.ts#:~:text=interface%20LCPMetricWithAttribution)\n- [`TTFBMetricWithAttribution`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetricWithAttribution)\n\n#### `MetricRatingThresholds`\n\nThe thresholds of metric's \"good\", \"needs improvement\", and \"poor\" ratings.\n\n- Metric values up to and including [0] are rated \"good\"\n- Metric values up to and including [1] are rated \"needs improvement\"\n- Metric values above [1] are \"poor\"\n\n| Metric value    | Rating              |\n| --------------- | ------------------- |\n| ≦ [0]           | \"good\"              |\n| > [0] and ≦ [1] | \"needs improvement\" |\n| > [1]           | \"poor\"              |\n\n```ts\nexport type MetricRatingThresholds = [number, number];\n```\n\n_See also [Rating Thresholds](#rating-thresholds)._\n\n#### `ReportCallback`\n\n```ts\ninterface ReportCallback {\n  (metric: Metric): void;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSReportCallback`](/src/types/cls.ts#:~:text=interface%20CLSReportCallback)\n- [`FCPReportCallback`](/src/types/fcp.ts#:~:text=interface%20FCPReportCallback)\n- [`FIDReportCallback`](/src/types/fid.ts#:~:text=interface%20FIDReportCallback)\n- [`INPReportCallback`](/src/types/inp.ts#:~:text=interface%20INPReportCallback)\n- [`LCPReportCallback`](/src/types/lcp.ts#:~:text=interface%20LCPReportCallback)\n- [`TTFBReportCallback`](/src/types/ttfb.ts#:~:text=interface%20TTFBReportCallback)\n\n#### `ReportOpts`\n\n```ts\ninterface ReportOpts {\n  reportAllChanges?: boolean;\n  durationThreshold?: number;\n  reportSoftNavs?: boolean;\n}\n```\n\n#### `LoadState`\n\nThe `LoadState` type is used in several of the metric [attribution objects](#attribution).\n\n```ts\n/**\n * The loading state of the document. Note: this value is similar to\n * `document.readyState` but it subdivides the \"interactive\" state into the\n * time before and after the DOMContentLoaded event fires.\n *\n * State descriptions:\n * - `loading`: the initial document response has not yet been fully downloaded\n *   and parsed. This is equivalent to the corresponding `readyState` value.\n * - `dom-interactive`: the document has been fully loaded and parsed, but\n *   scripts may not have yet finished loading and executing.\n * - `dom-content-loaded`: the document is fully loaded and parsed, and all\n *   scripts (except `async` scripts) have loaded and finished executing.\n * - `complete`: the document and all of its sub-resources have finished\n *   loading. This is equivalent to the corresponding `readyState` value.\n */\ntype LoadState =\n  | 'loading'\n  | 'dom-interactive'\n  | 'dom-content-loaded'\n  | 'complete';\n```\n\n#### `FirstInputPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't natively support the Event Timing API), the `metric.entries` reported by `onFID()` will contain an object that polyfills the `PerformanceEventTiming` entry:\n\n```ts\ntype FirstInputPolyfillEntry = Omit<\n  PerformanceEventTiming,\n  'processingEnd' | 'toJSON'\n>;\n```\n\n#### `FirstInputPolyfillCallback`\n\n```ts\ninterface FirstInputPolyfillCallback {\n  (entry: FirstInputPolyfillEntry): void;\n}\n```\n\n#### `NavigationTimingPolyfillEntry`\n\nIf using the \"base+polyfill\" build (and if the browser doesn't support the [Navigation Timing API Level 2](https://www.w3.org/TR/navigation-timing-2/) interface), the `metric.entries` reported by `onTTFB()` will contain an object that polyfills the `PerformanceNavigationTiming` entry using timings from the legacy `performance.timing` interface:\n\n```ts\ntype NavigationTimingPolyfillEntry = Omit<\n  PerformanceNavigationTiming,\n  | 'initiatorType'\n  | 'nextHopProtocol'\n  | 'redirectCount'\n  | 'transferSize'\n  | 'encodedBodySize'\n  | 'decodedBodySize'\n  | 'type'\n> & {\n  type: PerformanceNavigationTiming['type'];\n};\n```\n\n#### `WebVitalsGlobal`\n\nIf using the \"base+polyfill\" build, the `polyfill.js` script creates the global `webVitals` namespace matching the following interface:\n\n```ts\ninterface WebVitalsGlobal {\n  firstInputPolyfill: (onFirstInput: FirstInputPolyfillCallback) => void;\n  resetFirstInputPolyfill: () => void;\n  firstHiddenTime: number;\n}\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (callback: CLSReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [CLS](https://web.dev/articles/cls) value for the current page and calls the `callback` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/articles/cls#layout_shift_score)).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan (Note [not necessarily for every layout shift](#report-the-value-on-every-change)).\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (callback: FCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FCP](https://web.dev/articles/fcp) value for the current page and calls the `callback` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n```ts\ntype onFID = (callback: FIDReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FID](https://web.dev/articles/fid) value for the current page and calls the `callback` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (callback: INPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [INP](https://web.dev/articles/inp) value for the current page and calls the `callback` function once the value is ready, along with the `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp).\n\nA custom `durationThreshold` [configuration option](#reportopts) can optionally be passed to control what `event-timing` entries are considered for INP reporting. The default threshold is `40`, which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended [good](https://web.dev/articles/inp#what_is_a_good_inp_score) threshold).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan (Note [not necessarily for every interaction](#report-the-value-on-every-change)).\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (callback: LCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [LCP](https://web.dev/articles/lcp) value for the current page and calls the `callback` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (callback: TTFBReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [TTFB](https://web.dev/articles/ttfb) value for the current page and calls the `callback` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `callback` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it includes time spent on DNS lookup, connection negotiation, network latency, and server processing time.\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n### Rating Thresholds:\n\nThe thresholds of each metric's \"good\", \"needs improvement\", and \"poor\" ratings are available as [`MetricRatingThresholds`](#metricratingthresholds).\n\nExample:\n\n```ts\nimport {CLSThresholds, FIDThresholds, LCPThresholds} from 'web-vitals';\n\nconsole.log(CLSThresholds); // [ 0.1, 0.25 ]\nconsole.log(FIDThresholds); // [ 100, 300 ]\nconsole.log(LCPThresholds); // [ 2500, 4000 ]\n```\n\n_**Note:** It's typically not necessary (or recommended) to manually calculate metric value ratings using these thresholds. Use the [`Metric['rating']`](#metric) supplied by the [`ReportCallback`](#reportcallback) functions instead._\n\n### Attribution:\n\nThe following objects contain potentially-helpful debugging information that can be sent along with the metric values for the current page visit in order to help identify issues happening to real-users in the field.\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n#### CLS `attribution`:\n\n```ts\ninterface CLSAttribution {\n  /**\n   * A selector identifying the first element (in document order) that\n   * shifted when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTarget?: string;\n  /**\n   * The time when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTime?: DOMHighResTimeStamp;\n  /**\n   * The layout shift score of the single largest layout shift contributing to\n   * the page's CLS score.\n   */\n  largestShiftValue?: number;\n  /**\n   * The `LayoutShiftEntry` representing the single largest layout shift\n   * contributing to the page's CLS score. (Useful when you need more than just\n   * `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftEntry?: LayoutShift;\n  /**\n   * The first element source (in document order) among the `sources` list\n   * of the `largestShiftEntry` object. (Also useful when you need more than\n   * just `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftSource?: LayoutShiftAttribution;\n  /**\n   * The loading state of the document at the time when the largest layout\n   * shift contribution to the page's CLS score occurred (see `LoadState`\n   * for details).\n   */\n  loadState?: LoadState;\n}\n```\n\n#### FCP `attribution`:\n\n```ts\ninterface FCPAttribution {\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB).\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and the first contentful paint (FCP).\n   */\n  firstByteToFCP: number;\n  /**\n   * The loading state of the document at the time when FCP `occurred (see\n   * `LoadState` for details). Ideally, documents can paint before they finish\n   * loading (e.g. the `loading` or `dom-interactive` phases).\n   */\n  loadState: LoadState;\n  /**\n   * The `PerformancePaintTiming` entry corresponding to FCP.\n   */\n  fcpEntry?: PerformancePaintTiming;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n#### FID `attribution`:\n\n```ts\ninterface FIDAttribution {\n  /**\n   * A selector identifying the element that the user interacted with. This\n   * element will be the `target` of the `event` dispatched.\n   */\n  eventTarget: string;\n  /**\n   * The time when the user interacted. This time will match the `timeStamp`\n   * value of the `event` dispatched.\n   */\n  eventTime: number;\n  /**\n   * The `type` of the `event` dispatched from the user interaction.\n   */\n  eventType: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to FID (or the\n   * polyfill entry in browsers that don't support Event Timing).\n   */\n  eventEntry: PerformanceEventTiming | FirstInputPolyfillEntry;\n  /**\n   * The loading state of the document at the time when the first interaction\n   * occurred (see `LoadState` for details). If the first interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long input delays.\n   */\n  loadState: LoadState;\n}\n```\n\n#### INP `attribution`:\n\n```ts\ninterface INPAttribution {\n  /**\n   * A selector identifying the element that the user interacted with for\n   * the event corresponding to INP. This element will be the `target` of the\n   * `event` dispatched.\n   */\n  eventTarget?: string;\n  /**\n   * The time when the user interacted for the event corresponding to INP.\n   * This time will match the `timeStamp` value of the `event` dispatched.\n   */\n  eventTime?: number;\n  /**\n   * The `type` of the `event` dispatched corresponding to INP.\n   */\n  eventType?: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to INP.\n   */\n  eventEntry?: PerformanceEventTiming;\n  /**\n   * The loading state of the document at the time when the even corresponding\n   * to INP occurred (see `LoadState` for details). If the interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long delays.\n   */\n  loadState?: LoadState;\n}\n```\n\n#### LCP `attribution`:\n\n```ts\ninterface LCPAttribution {\n  /**\n   * The element corresponding to the largest contentful paint for the page.\n   */\n  element?: string;\n  /**\n   * The URL (if applicable) of the LCP image resource. If the LCP element\n   * is a text node, this value will not be set.\n   */\n  url?: string;\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB). See\n   * [Optimize LCP](https://web.dev/articles/optimize-lcp) for details.\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and when the browser starts loading the LCP\n   * resource (if there is one, otherwise 0). See [Optimize\n   * LCP](https://web.dev/articles/optimize-lcp) for details.\n   */\n  resourceLoadDelay: number;\n  /**\n   * The total time it takes to load the LCP resource itself (if there is one,\n   * otherwise 0). See [Optimize LCP](https://web.dev/articles/optimize-lcp) for\n   * details.\n   */\n  resourceLoadTime: number;\n  /**\n   * The delta between when the LCP resource finishes loading until the LCP\n   * element is fully rendered. See [Optimize\n   * LCP](https://web.dev/articles/optimize-lcp) for details.\n   */\n  elementRenderDelay: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n  /**\n   * The `resource` entry for the LCP resource (if applicable), which is useful\n   * for diagnosing resource load issues.\n   */\n  lcpResourceEntry?: PerformanceResourceTiming;\n  /**\n   * The `LargestContentfulPaint` entry corresponding to LCP.\n   */\n  lcpEntry?: LargestContentfulPaint;\n}\n```\n\n#### TTFB `attribution`:\n\n```ts\ninterface TTFBAttribution {\n  /**\n   * The total time from when the user initiates loading the page to when the\n   * DNS lookup begins. This includes redirects, service worker startup, and\n   * HTTP cache lookup times.\n   */\n  waitingTime: number;\n  /**\n   * The total time to resolve the DNS for the current request.\n   */\n  dnsTime: number;\n  /**\n   * The total time to create the connection to the requested domain.\n   */\n  connectionTime: number;\n  /**\n   * The time time from when the request was sent until the first byte of the\n   * response was received. This includes network time as well as server\n   * processing time.\n   */\n  requestTime: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming | NavigationTimingPolyfillEntry;\n}\n```\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium\n- `onFCP()`: Chromium, Firefox, Safari 14.1+\n- `onFID()`: Chromium, Firefox _(with [polyfill](#how-to-use-the-polyfill): Safari, Internet Explorer)_\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari 15+ _(with [polyfill](#how-to-use-the-polyfill): Safari 8+, Internet Explorer)_\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that measure the Web Vitals metrics, which means the limitations of those APIs will mostly apply to this library as well. More details on these limitations is available in [this blog post](https://web.dev/articles/crux-and-rum-differences).\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/articles/vitals-ga4).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `callback` functions and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"5ab847d42cff7d0299c46c4465d0c79ff3705033","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_id":"web-vitals@3.5.2-soft-navs-16","_nodeVersion":"18.16.0","_npmVersion":"9.5.1","dist":{"integrity":"sha512-qFT99bUih8ZDcA+AD4HpfGNrwdpXfWRgjn7OTFSkjHyeL8i2m4p9WMpstVHZ+Vt5Rwbd2w1yjpCtSUkof0T5dA==","shasum":"4d38dd1a57735a61ad171d21606a6fc4c7e546c9","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-3.5.2-soft-navs-16.tgz","fileCount":146,"unpackedSize":461832,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQCdhHoADoriALpVDH30mVSMv5bP2z+4Jjo230k8dG9PjgIhAJ/xdxyLusQ4HrEiKDNJ6fsl1sX7fsKUpZxyAHl8z6qP"}]},"_npmUser":{"name":"tunetheweb","email":"barrypollard@google.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_3.5.2-soft-navs-16_1706265690148_0.8868998158965977"},"_hasShrinkwrap":false},"4.0.0-beta.0":{"name":"web-vitals","version":"4.0.0-beta.0","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./attribution":{"types":"./dist/modules/attribution/index.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution/index.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build test:unit -p -r test:e2e test:server","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","test:unit":"node --test test/unit/*test.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.23.6","@babel/preset-env":"^7.23.6","@rollup/plugin-babel":"^6.0.4","@rollup/plugin-replace":"^5.0.5","@rollup/plugin-terser":"^0.4.4","@typescript-eslint/eslint-plugin":"^6.16.0","@typescript-eslint/parser":"^6.16.0","@wdio/cli":"^8.32.3","@wdio/local-runner":"^8.32.3","@wdio/mocha-framework":"^8.32.3","@wdio/spec-reporter":"^8.32.2","body-parser":"^1.20.2","chromedriver":"^122.0.4","eslint":"^8.56.0","express":"^4.18.2","fs-extra":"^11.2.0","husky":"^8.0.3","lint-staged":"^15.2.0","npm-run-all":"^4.1.5","nunjucks":"^3.2.4","prettier":"^3.1.1","rollup":"^4.9.1","selenium-standalone":"^9.3.1","typescript":"^5.3.3","wdio-chromedriver-service":"^8.1.1"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"_id":"web-vitals@4.0.0-beta.0","gitHead":"e526abf45a64088cc96498b7d0a10682f3d9eceb","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_nodeVersion":"20.11.0","_npmVersion":"10.3.0","dist":{"integrity":"sha512-FzCWV5aF/sAsTxNx0HsnDCOhaHeFReDga3n8CUDbglUggXwGUjIAabuvBkmnT/JJXid7VG65vPWBJXKCxCn9kA==","shasum":"5530c162e17d6e1f20ccd22aa74f2d956ffa3dd2","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-4.0.0-beta.0.tgz","fileCount":146,"unpackedSize":383626,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEUCIQDkK27gD4PLCRfSM7clJGOQbxHGaXmAAHRjm3RFsxQGPgIgXeuNaQUuc5upwIbCF1IfIi6ft3PHtn2LqxNDhpgk77k="}]},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_4.0.0-beta.0_1711739710127_0.4790615514115528"},"_hasShrinkwrap":false},"4.0.0-beta.1":{"name":"web-vitals","version":"4.0.0-beta.1","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./attribution":{"types":"./dist/modules/attribution/index.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution/index.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build test:unit -p -r test:e2e test:server","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","test:unit":"node --test test/unit/*test.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.23.6","@babel/preset-env":"^7.23.6","@rollup/plugin-babel":"^6.0.4","@rollup/plugin-replace":"^5.0.5","@rollup/plugin-terser":"^0.4.4","@typescript-eslint/eslint-plugin":"^6.16.0","@typescript-eslint/parser":"^6.16.0","@wdio/cli":"^8.32.3","@wdio/local-runner":"^8.32.3","@wdio/mocha-framework":"^8.32.3","@wdio/spec-reporter":"^8.32.2","body-parser":"^1.20.2","chromedriver":"^122.0.4","eslint":"^8.56.0","express":"^4.18.2","fs-extra":"^11.2.0","husky":"^8.0.3","lint-staged":"^15.2.0","npm-run-all":"^4.1.5","nunjucks":"^3.2.4","prettier":"^3.1.1","rollup":"^4.9.1","selenium-standalone":"^9.3.1","typescript":"^5.3.3","wdio-chromedriver-service":"^8.1.1"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"_id":"web-vitals@4.0.0-beta.1","readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Send attribution data](#send-attribution-data)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Build options](#build-options)\n  - [Which build is right for you?](#which-build-is-right-for-you)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n  - [Rating Thresholds](#rating-thresholds)\n  - [Attribution](#attribution)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~2K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/articles/vitals) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/articles/vitals#core_web_vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/articles/user-centric-performance-metrics) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/articles/cls)\n- [Interaction to Next Paint (INP)](https://web.dev/articles/inp)\n- [Largest Contentful Paint (LCP)](https://web.dev/articles/lcp)\n\n### Other metrics\n\n- [First Contentful Paint (FCP)](https://web.dev/articles/fcp)\n- [Time to First Byte (TTFB)](https://web.dev/articles/ttfb)\n- [First Input Delay (FID)](https://web.dev/articles/fid) _Deprecated and will be removed in next major release_\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\nThe `web-vitals` library uses the `buffered` flag for [PerformanceObserver](https://developer.mozilla.org/docs/Web/API/PerformanceObserver/observe), allowing it to access performance entries that occurred before the library was loaded.\n\nThis means you do not need to load this library early in order to get accurate performance data. In general, this library should be deferred until after other user-impacting code has loaded.\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are a few different builds of the `web-vitals` library, and how you load the library depends on which build you want to use.\n\nFor details on the difference between the builds, see <a href=\"#which-build-is-right-for-you\">which build is right for you</a>.\n\n**1. The \"standard\" build**\n\nTo load the \"standard\" build, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onINP, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonINP(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functions were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"attribution-build\"><a>\n\n**2. The \"attribution\" build**\n\nMeasuring the Web Vitals scores for your real users is a great first step toward optimizing the user experience. But if your scores aren't _good_, the next step is to understand why they're not good and work to improve them.\n\nThe \"attribution\" build helps you do that by including additional diagnostic information with each metric to help you identify the root cause of poor performance as well as prioritize the most important things to fix.\n\nThe \"attribution\" build is slightly larger than the \"standard\" build (by about 600 bytes, brotli'd), so while the code size is still small, it's only recommended if you're actually using these features.\n\nTo load the \"attribution\" build, change any `import` statements that reference `web-vitals` to `web-vitals/attribution`:\n\n```diff\n- import {onLCP, onINP, onCLS} from 'web-vitals';\n+ import {onLCP, onINP, onCLS} from 'web-vitals/attribution';\n```\n\nUsage for each of the imported function is identical to the standard build, but when importing from the attribution build, the [`Metric`](#metric) object will contain an additional [`attribution`](#metricwithattribution) property.\n\nSee [Send attribution data](#send-attribution-data) for usage examples, and the [`attribution` reference](#attribution) for details on what values are added for each metric.\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com):\n\n_**Important!** The [unpkg.com](https://unpkg.com) CDN is shown here for example purposes only. `unpkg.com` is not affiliated with Google, and there are no guarantees that the URLs shown in these examples will continue to work in the future._\n\n**Load the \"standard\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onINP, onLCP} from 'https://unpkg.com/web-vitals@4?module';\n\n  onCLS(console.log);\n  onINP(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src = 'https://unpkg.com/web-vitals@4/dist/web-vitals.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onINP(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n**Load the \"attribution\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {\n    onCLS,\n    onINP,\n    onLCP,\n  } from 'https://unpkg.com/web-vitals@4/dist/web-vitals.attribution.js?module';\n\n  onCLS(console.log);\n  onINP(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"attribution\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src =\n      'https://unpkg.com/web-vitals@4/dist/web-vitals.attribution.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onINP(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes a `callback` function that will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" build, but they will work with the \"attribution\" build as well.)_\n\n```js\nimport {onCLS, onINP, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonINP(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developer.chrome.com/docs/devtools/console/reference/#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID and INP are not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS and INP should be reported any time the [page's `visibilityState` changes to hidden](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/articles/bfcache).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onINP()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want the `callback` function to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each larger layout shift as it happens) by setting `reportAllChanges` to `true` in the optional, [configuration object](#reportopts) (second parameter).\n\n_**Important:** `reportAllChanges` only reports when the **metric changes**, not for each **input to the metric**. For example, a new layout shift that does not increase the CLS metric will not be reported even with `reportAllChanges` set to `true` because the CLS metric has not changed. Similarly, for INP, each interaction is not reported even with `reportAllChanges` set to `true`—just when an interaction causes an increase to INP._\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended) for measuring these metrics in production.\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, {reportAllChanges: true});\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onINP, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonINP(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `callback` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onINP, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n    fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonINP(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique event parameter value (in this case, the metric_id, as shown in the example below) on every metric instance that you send to Google Analytics, you can create a report yourself by first getting the data via the [Google Analytics Data API](https://developers.google.com/analytics/devguides/reporting/data/v1) or via [BigQuery export](https://support.google.com/analytics/answer/9358801) and then visualizing it any charting library you choose.\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onINP, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/articles/debug-performance-in-the-field\n    // metric_rating: 'good' | 'needs-improvement' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonINP(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\nFor details on how to query this data in [BigQuery](https://cloud.google.com/bigquery), or visualise it in [Looker Studio](https://lookerstudio.google.com/), see [Measure and debug performance with Google Analytics 4 and BigQuery](https://web.dev/articles/vitals-ga4).\n\n### Send the results to Google Tag Manager\n\nWhile `web-vitals` can be called directly from Google Tag Manager, using a pre-defined custom template makes this considerably easier. Some recommended templates include:\n\n- [Core Web Vitals](https://tagmanager.google.com/gallery/#/owners/gtm-templates-simo-ahava/templates/core-web-vitals) by [Simo Ahava](https://www.simoahava.com/). See [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for usage and installation instructions.\n- [Web Vitals Template for Google Tag Manager](https://github.com/google-marketing-solutions/web-vitals-gtm-template) by The Google Marketing Solutions team. See the [README](https://github.com/google-marketing-solutions/web-vitals-gtm-template?tab=readme-ov-file#web-vitals-template-for-google-tag-manager) for usage and installation instructions.\n\n### Send attribution data\n\nWhen using the [attribution build](#attribution-build), you can send additional data to help you debug _why_ the metric values are they way they are.\n\nThis example sends an additional `debug_target` param to Google Analytics, corresponding to the element most associated with each metric.\n\n```js\nimport {onCLS, onINP, onLCP} from 'web-vitals/attribution';\n\nfunction sendToGoogleAnalytics({name, delta, value, id, attribution}) {\n  const eventParams = {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n  };\n\n  switch (name) {\n    case 'CLS':\n      eventParams.debug_target = attribution.largestShiftTarget;\n      break;\n    case 'INP':\n      eventParams.debug_target = attribution.eventTarget;\n      break;\n    case 'LCP':\n      eventParams.debug_target = attribution.element;\n      break;\n  }\n\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, eventParams);\n}\n\nonCLS(sendToGoogleAnalytics);\nonINP(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n_**Note:** this example relies on custom [event parameters](https://support.google.com/analytics/answer/11396839) in Google Analytics 4._\n\nSee [Debug performance in the field](https://web.dev/articles/debug-performance-in-the-field) for more information and examples.\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onINP, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonINP(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n<a name=\"bundle-versions\"><a>\n\n## Build options\n\nThe `web-vitals` package includes both \"standard\" and \"attribution\" builds, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the builds distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any attribution features.</p>\n      This is the \"standard\" build and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.cjs</code></td>\n    <td><code>pkg.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>self.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>self.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.attribution.js</code></td>\n    <td>--</td>\n    <td>\n      An ES module version of all metric functions that includes <a href=\"#attribution-build\">attribution</a> features.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>self.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>self.webVitals.*</code> namespace).\n    </td>\n  </tr>\n</table>\n\n<a name=\"which-build-is-right-for-you\"><a>\n\n### Which build is right for you?\n\nMost developers will generally want to use \"standard\" build (via either the ES module or UMD version, depending on your bundler/build system), as it's the easiest to use out of the box and integrate into existing tools.\n\nHowever, if you'd lke to collect additional debug information to help you diagnose performance bottlenecks based on real-user issues, use the [\"attribution\" build](#attribution-build).\n\nFor guidance on how to collect and use real-user data to debug performance issues, see [Debug performance in the field](https://web.dev/debug-performance-in-the-field/).\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  /**\n   * The name of the metric (in acronym form).\n   */\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  /**\n   * The current value of the metric.\n   */\n  value: number;\n\n  /**\n   * The rating as to whether the metric value is within the \"good\",\n   * \"needs improvement\", or \"poor\" thresholds of the metric.\n   */\n  rating: 'good' | 'needs-improvement' | 'poor';\n\n  /**\n   * The delta between the current value and the last-reported value.\n   * On the first report, `delta` and `value` will always be the same.\n   */\n  delta: number;\n\n  /**\n   * A unique ID representing this particular metric instance. This ID can\n   * be used by an analytics tool to dedupe multiple values sent for the same\n   * metric instance, or to group multiple deltas together and calculate a\n   * total. It can also be used to differentiate multiple different metric\n   * instances sent from the same page, which can happen if the page is\n   * restored from the back/forward cache (in that case new metrics object\n   * get created).\n   */\n  id: string;\n\n  /**\n   * Any performance entries relevant to the metric value calculation.\n   * The array may also be empty if the metric value was not based on any\n   * entries (e.g. a CLS value of 0 given no layout shifts).\n   */\n  entries: (PerformanceEntry | LayoutShift)[];\n\n  /**\n   * The type of navigation.\n   *\n   * This will be the value returned by the Navigation Timing API (or\n   * `undefined` if the browser doesn't support that API), with the following\n   * exceptions:\n   * - 'back-forward-cache': for pages that are restored from the bfcache.\n   * - 'back_forward' is renamed to 'back-forward' for consistency.\n   * - 'prerender': for pages that were prerendered.\n   * - 'restore': for pages that were discarded by the browser and then\n   * restored by the user.\n   */\n  navigationType:\n    | 'navigate'\n    | 'reload'\n    | 'back-forward'\n    | 'back-forward-cache'\n    | 'prerender'\n    | 'restore';\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetric`](/src/types/cls.ts#:~:text=interface%20CLSMetric)\n- [`FCPMetric`](/src/types/fcp.ts#:~:text=interface%20FCPMetric)\n- [`FIDMetric`](/src/types/fid.ts#:~:text=interface%20FIDMetric)\n- [`INPMetric`](/src/types/inp.ts#:~:text=interface%20INPMetric)\n- [`LCPMetric`](/src/types/lcp.ts#:~:text=interface%20LCPMetric)\n- [`TTFBMetric`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetric)\n\n#### `MetricWithAttribution`\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n```ts\ninterface MetricWithAttribution extends Metric {\n  /**\n   * An object containing potentially-helpful debugging information that\n   * can be sent along with the metric value for the current page visit in\n   * order to help identify issues happening to real-users in the field.\n   */\n  attribution: {[key: string]: unknown};\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetricWithAttribution`](/src/types/cls.ts#:~:text=interface%20CLSMetricWithAttribution)\n- [`FCPMetricWithAttribution`](/src/types/fcp.ts#:~:text=interface%20FCPMetricWithAttribution)\n- [`FIDMetricWithAttribution`](/src/types/fid.ts#:~:text=interface%20FIDMetricWithAttribution)\n- [`INPMetricWithAttribution`](/src/types/inp.ts#:~:text=interface%20INPMetricWithAttribution)\n- [`LCPMetricWithAttribution`](/src/types/lcp.ts#:~:text=interface%20LCPMetricWithAttribution)\n- [`TTFBMetricWithAttribution`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetricWithAttribution)\n\n#### `MetricRatingThresholds`\n\nThe thresholds of metric's \"good\", \"needs improvement\", and \"poor\" ratings.\n\n- Metric values up to and including [0] are rated \"good\"\n- Metric values up to and including [1] are rated \"needs improvement\"\n- Metric values above [1] are \"poor\"\n\n| Metric value    | Rating              |\n| --------------- | ------------------- |\n| ≦ [0]           | \"good\"              |\n| > [0] and ≦ [1] | \"needs improvement\" |\n| > [1]           | \"poor\"              |\n\n```ts\nexport type MetricRatingThresholds = [number, number];\n```\n\n_See also [Rating Thresholds](#rating-thresholds)._\n\n#### `ReportCallback`\n\n```ts\ninterface ReportCallback {\n  (metric: Metric): void;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSReportCallback`](/src/types/cls.ts#:~:text=interface%20CLSReportCallback)\n- [`FCPReportCallback`](/src/types/fcp.ts#:~:text=interface%20FCPReportCallback)\n- [`FIDReportCallback`](/src/types/fid.ts#:~:text=interface%20FIDReportCallback)\n- [`INPReportCallback`](/src/types/inp.ts#:~:text=interface%20INPReportCallback)\n- [`LCPReportCallback`](/src/types/lcp.ts#:~:text=interface%20LCPReportCallback)\n- [`TTFBReportCallback`](/src/types/ttfb.ts#:~:text=interface%20TTFBReportCallback)\n\n#### `ReportOpts`\n\n```ts\ninterface ReportOpts {\n  reportAllChanges?: boolean;\n  durationThreshold?: number;\n}\n```\n\n#### `LoadState`\n\nThe `LoadState` type is used in several of the metric [attribution objects](#attribution).\n\n```ts\n/**\n * The loading state of the document. Note: this value is similar to\n * `document.readyState` but it subdivides the \"interactive\" state into the\n * time before and after the DOMContentLoaded event fires.\n *\n * State descriptions:\n * - `loading`: the initial document response has not yet been fully downloaded\n *   and parsed. This is equivalent to the corresponding `readyState` value.\n * - `dom-interactive`: the document has been fully loaded and parsed, but\n *   scripts may not have yet finished loading and executing.\n * - `dom-content-loaded`: the document is fully loaded and parsed, and all\n *   scripts (except `async` scripts) have loaded and finished executing.\n * - `complete`: the document and all of its sub-resources have finished\n *   loading. This is equivalent to the corresponding `readyState` value.\n */\ntype LoadState =\n  | 'loading'\n  | 'dom-interactive'\n  | 'dom-content-loaded'\n  | 'complete';\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (callback: CLSReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [CLS](https://web.dev/articles/cls) value for the current page and calls the `callback` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/articles/cls#layout_shift_score)).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan (Note [not necessarily for every layout shift](#report-the-value-on-every-change)).\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (callback: FCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FCP](https://web.dev/articles/fcp) value for the current page and calls the `callback` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n_Deprecated and will be removed in next major release_\n\n```ts\ntype onFID = (callback: FIDReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FID](https://web.dev/articles/fid) value for the current page and calls the `callback` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (callback: INPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [INP](https://web.dev/articles/inp) value for the current page and calls the `callback` function once the value is ready, along with the `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp).\n\nA custom `durationThreshold` [configuration option](#reportopts) can optionally be passed to control what `event-timing` entries are considered for INP reporting. The default threshold is `40`, which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended [good](https://web.dev/articles/inp#what_is_a_good_inp_score) threshold).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan (Note [not necessarily for every interaction](#report-the-value-on-every-change)).\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (callback: LCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [LCP](https://web.dev/articles/lcp) value for the current page and calls the `callback` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (callback: TTFBReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [TTFB](https://web.dev/articles/ttfb) value for the current page and calls the `callback` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `callback` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it includes time spent on DNS lookup, connection negotiation, network latency, and server processing time.\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n### Rating Thresholds:\n\nThe thresholds of each metric's \"good\", \"needs improvement\", and \"poor\" ratings are available as [`MetricRatingThresholds`](#metricratingthresholds).\n\nExample:\n\n```ts\nimport {CLSThresholds, INPThresholds, LCPThresholds} from 'web-vitals';\n\nconsole.log(CLSThresholds); // [ 0.1, 0.25 ]\nconsole.log(INPThresholds); // [ 200, 500 ]\nconsole.log(LCPThresholds); // [ 2500, 4000 ]\n```\n\n_**Note:** It's typically not necessary (or recommended) to manually calculate metric value ratings using these thresholds. Use the [`Metric['rating']`](#metric) supplied by the [`ReportCallback`](#reportcallback) functions instead._\n\n### Attribution:\n\nThe following objects contain potentially-helpful debugging information that can be sent along with the metric values for the current page visit in order to help identify issues happening to real-users in the field.\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n#### CLS `attribution`:\n\n```ts\ninterface CLSAttribution {\n  /**\n   * A selector identifying the first element (in document order) that\n   * shifted when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTarget?: string;\n  /**\n   * The time when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTime?: DOMHighResTimeStamp;\n  /**\n   * The layout shift score of the single largest layout shift contributing to\n   * the page's CLS score.\n   */\n  largestShiftValue?: number;\n  /**\n   * The `LayoutShiftEntry` representing the single largest layout shift\n   * contributing to the page's CLS score. (Useful when you need more than just\n   * `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftEntry?: LayoutShift;\n  /**\n   * The first element source (in document order) among the `sources` list\n   * of the `largestShiftEntry` object. (Also useful when you need more than\n   * just `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftSource?: LayoutShiftAttribution;\n  /**\n   * The loading state of the document at the time when the largest layout\n   * shift contribution to the page's CLS score occurred (see `LoadState`\n   * for details).\n   */\n  loadState?: LoadState;\n}\n```\n\n#### FCP `attribution`:\n\n```ts\ninterface FCPAttribution {\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB).\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and the first contentful paint (FCP).\n   */\n  firstByteToFCP: number;\n  /**\n   * The loading state of the document at the time when FCP `occurred (see\n   * `LoadState` for details). Ideally, documents can paint before they finish\n   * loading (e.g. the `loading` or `dom-interactive` phases).\n   */\n  loadState: LoadState;\n  /**\n   * The `PerformancePaintTiming` entry corresponding to FCP.\n   */\n  fcpEntry?: PerformancePaintTiming;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming;\n}\n```\n\n#### FID `attribution`:\n\n```ts\ninterface FIDAttribution {\n  /**\n   * A selector identifying the element that the user interacted with. This\n   * element will be the `target` of the `event` dispatched.\n   */\n  eventTarget: string;\n  /**\n   * The time when the user interacted. This time will match the `timeStamp`\n   * value of the `event` dispatched.\n   */\n  eventTime: number;\n  /**\n   * The `type` of the `event` dispatched from the user interaction.\n   */\n  eventType: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to FID.\n   */\n  eventEntry: PerformanceEventTiming;\n  /**\n   * The loading state of the document at the time when the first interaction\n   * occurred (see `LoadState` for details). If the first interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long input delays.\n   */\n  loadState: LoadState;\n}\n```\n\n#### INP `attribution`:\n\n```ts\ninterface INPAttribution {\n  /**\n   * A selector identifying the element that the user first interacted with\n   * as part of the frame where the INP candidate interaction occurred.\n   * If `interactionTarget` is an empty string, that generally means the\n   * element was removed from the DOM after the interaction.\n   */\n  interactionTarget: string;\n\n  /**\n   * The time when the user first interacted during the frame where the INP\n   * candidate interaction occurred (if more than one interaction occurred\n   * within the frame, only the first time is reported).\n   */\n  interactionTime: DOMHighResTimeStamp;\n\n  /**\n   * The best-guess timestamp of the next paint after the interaction.\n   * In general, this timestamp is the same as the `startTime + duration` of\n   * the event timing entry. However, since `duration` values are rounded to\n   * the nearest 8ms, it can sometimes appear that the paint occurred before\n   * processing ended (which cannot happen). This value clamps the paint time\n   * so it's always after `processingEnd` from the Event Timing API and\n   * `renderStart` from the Long Animation Frame API (where available).\n   * It also averages the duration values for all entries in the same\n   * animation frame, which should be closer to the \"real\" value.\n   */\n  nextPaintTime: DOMHighResTimeStamp;\n\n  /**\n   * The type of interaction, based on the event type of the `event` entry\n   * that corresponds to the interaction (i.e. the first `event` entry\n   * containing an `interactionId` dispatched in a given animation frame).\n   * For \"pointerdown\", \"pointerup\", or \"click\" events this will be \"pointer\",\n   * and for \"keydown\" or \"keyup\" events this will be \"keyboard\".\n   */\n  interactionType: 'pointer' | 'keyboard';\n\n  /**\n   * An array of Event Timing entries that were processed within the same\n   * animation frame as the INP candidate interaction.\n   */\n  processedEventEntries: PerformanceEventTiming[];\n\n  /**\n   * If the browser supports the Long Animation Frame API, this array will\n   * include any `long-animation-frame` entries that intersect with the INP\n   * candidate interaction's `startTime` and the `processingEnd` time of the\n   * last event processed within that animation frame. If the browser does not\n   * support the Long Animation Frame API or no `long-animation-frame` entries\n   * are detect, this array will be empty.\n   */\n  longAnimationFrameEntries: PerformanceLongAnimationFrameTiming[];\n\n  /**\n   * The time from when the user interacted with the page until when the\n   * browser was first able to start processing event listeners for that\n   * interaction. This time captures the delay before event processing can\n   * begin due to the main thread being busy with other work.\n   */\n  inputDelay: number;\n\n  /**\n   * The time from when the first event listener started running in response to\n   * the user interaction until when all event listener processing has finished.\n   */\n  processingDuration: number;\n\n  /**\n   * The time from when the browser finished processing all event listeners for\n   * the user interaction until the next frame is presented on the screen and\n   * visible to the user. This time includes work on the main thread (such as\n   * `requestAnimationFrame()` callbacks, `ResizeObserver` and\n   * `IntersectionObserver` callbacks, and style/layout calculation) as well\n   * as off-main-thread work (such as compositor, GPU, and raster work).\n   */\n  presentationDelay: number;\n\n  /**\n   * The loading state of the document at the time when the interaction\n   * corresponding to INP occurred (see `LoadState` for details). If the\n   * interaction occurred while the document was loading and executing script\n   * (e.g. usually in the `dom-interactive` phase) it can result in long delays.\n   */\n  loadState: LoadState;\n}\n```\n\n#### LCP `attribution`:\n\n```ts\ninterface LCPAttribution {\n  /**\n   * The element corresponding to the largest contentful paint for the page.\n   */\n  element?: string;\n  /**\n   * The URL (if applicable) of the LCP image resource. If the LCP element\n   * is a text node, this value will not be set.\n   */\n  url?: string;\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB). See\n   * [Optimize LCP](https://web.dev/articles/optimize-lcp) for details.\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and when the browser starts loading the LCP\n   * resource (if there is one, otherwise 0). See [Optimize\n   * LCP](https://web.dev/articles/optimize-lcp) for details.\n   */\n  resourceLoadDelay: number;\n  /**\n   * The total time it takes to load the LCP resource itself (if there is one,\n   * otherwise 0). See [Optimize LCP](https://web.dev/articles/optimize-lcp) for\n   * details.\n   */\n  resourceLoadDuration: number;\n  /**\n   * The delta between when the LCP resource finishes loading until the LCP\n   * element is fully rendered. See [Optimize\n   * LCP](https://web.dev/articles/optimize-lcp) for details.\n   */\n  elementRenderDelay: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming;\n  /**\n   * The `resource` entry for the LCP resource (if applicable), which is useful\n   * for diagnosing resource load issues.\n   */\n  lcpResourceEntry?: PerformanceResourceTiming;\n  /**\n   * The `LargestContentfulPaint` entry corresponding to LCP.\n   */\n  lcpEntry?: LargestContentfulPaint;\n}\n```\n\n#### TTFB `attribution`:\n\n```ts\ninterface TTFBAttribution {\n  /**\n   * The total time from when the user initiates loading the page to when the\n   * DNS lookup begins. This includes redirects, service worker startup, and\n   * HTTP cache lookup times.\n   */\n  waitingDuration: number;\n  /**\n   * The total time to resolve the DNS for the current request.\n   */\n  dnsDuration: number;\n  /**\n   * The total time to create the connection to the requested domain.\n   */\n  connectionDuration: number;\n  /**\n   * The total time from when the request was sent until the first byte of the\n   * response was received. This includes network time as well as server\n   * processing time.\n   */\n  requestDuration: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming;\n}\n```\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium\n- `onFCP()`: Chromium, Firefox, Safari 14.1+\n- `onFID()`: Chromium, Firefox _(Deprecated)_\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari 15+\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that measure the Web Vitals metrics, which means the limitations of those APIs will mostly apply to this library as well. More details on these limitations is available in [this blog post](https://web.dev/articles/crux-and-rum-differences).\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/articles/vitals-ga4).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `callback` functions and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"d5549a4f5d22bd6fae3cace12ac03350ea638e0e","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_nodeVersion":"20.11.0","_npmVersion":"10.3.0","dist":{"integrity":"sha512-+XVBLnzG6YnqHDui5d41S2Jk7l1BEgAhNZYUhb1d+m06tRQ+k7/sAqAYfhhGsi4xOJEZ8oHD8md87F8czLnaiA==","shasum":"4cd09797296a802660e5df006ffcdf3ccc513112","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-4.0.0-beta.1.tgz","fileCount":146,"unpackedSize":380842,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIGUG9Q0zRwdLC6OeCnVQHtaSY4YPl5FvVHhHgjx6XPCoAiBqoFnDMu3ZT3f57vHyP0R7mYU+hTjcl3uBaL0/F1zjYA=="}]},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_4.0.0-beta.1_1712008482761_0.7141310038772373"},"_hasShrinkwrap":false},"4.0.0-beta.2":{"name":"web-vitals","version":"4.0.0-beta.2","description":"Easily measure performance metrics in JavaScript","type":"module","typings":"dist/modules/index.d.ts","main":"dist/web-vitals.umd.cjs","module":"dist/web-vitals.js","unpkg":"dist/web-vitals.iife.js","exports":{".":{"types":"./dist/modules/index.d.ts","require":"./dist/web-vitals.umd.cjs","default":"./dist/web-vitals.js"},"./attribution":{"types":"./dist/modules/attribution/index.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./attribution.js":{"types":"./dist/modules/attribution/index.d.ts","require":"./dist/web-vitals.attribution.umd.cjs","default":"./dist/web-vitals.attribution.js"},"./onCLS.js":{"types":"./dist/modules/onCLS.d.ts","default":"./dist/modules/onCLS.js"},"./onFCP.js":{"types":"./dist/modules/onFCP.d.ts","default":"./dist/modules/onFCP.js"},"./onFID.js":{"types":"./dist/modules/onFID.d.ts","default":"./dist/modules/onFID.js"},"./onINP.js":{"types":"./dist/modules/onINP.d.ts","default":"./dist/modules/onINP.js"},"./onLCP.js":{"types":"./dist/modules/onLCP.d.ts","default":"./dist/modules/onLCP.js"},"./onTTFB.js":{"types":"./dist/modules/onTTFB.d.ts","default":"./dist/modules/onTTFB.js"},"./attribution/onCLS.js":{"types":"./dist/modules/attribution/onCLS.d.ts","default":"./dist/modules/attribution/onCLS.js"},"./attribution/onFCP.js":{"types":"./dist/modules/attribution/onFCP.d.ts","default":"./dist/modules/attribution/onFCP.js"},"./attribution/onFID.js":{"types":"./dist/modules/attribution/onFID.d.ts","default":"./dist/modules/attribution/onFID.js"},"./attribution/onINP.js":{"types":"./dist/modules/attribution/onINP.d.ts","default":"./dist/modules/attribution/onINP.js"},"./attribution/onLCP.js":{"types":"./dist/modules/attribution/onLCP.d.ts","default":"./dist/modules/attribution/onLCP.js"},"./attribution/onTTFB.js":{"types":"./dist/modules/attribution/onTTFB.d.ts","default":"./dist/modules/attribution/onTTFB.js"}},"scripts":{"build":"run-s clean build:ts build:js","build:ts":"tsc -b","build:js":"rollup -c","clean":"rm -rf dist tsconfig.tsbuildinfo","dev":"run-p watch test:server","format":"prettier \"**/*.{cjs,css,html,js,json,md,ts,yml,yaml}\" --write --ignore-path .gitignore","format:check":"prettier \"**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}\" --check --ignore-path .gitignore","lint":"eslint \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","lint:fix":"eslint --fix \"*.js\" \"src/**/*.ts\" \"test/**/*.js\"","postversion":"git push --follow-tags","release:major":"npm version major -m 'Release v%s' && npm publish","release:minor":"npm version minor -m 'Release v%s' && npm publish","release:patch":"npm version patch -m 'Release v%s' && npm publish","test":"npm-run-all build test:unit -p -r test:e2e test:server","test:e2e":"wdio wdio.conf.cjs","test:server":"node test/server.js","test:unit":"node --test test/unit/*test.js","start":"run-s build:ts test:server watch","watch":"run-p watch:*","watch:ts":"tsc -b -w","watch:js":"rollup -c -w","version":"run-s build","prepare":"husky install"},"keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"license":"Apache-2.0","repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"husky":{"hooks":{"pre-commit":"npm run lint"}},"prettier":{"arrowParens":"always","bracketSpacing":false,"quoteProps":"preserve","singleQuote":true},"devDependencies":{"@babel/core":"^7.23.6","@babel/preset-env":"^7.23.6","@rollup/plugin-babel":"^6.0.4","@rollup/plugin-replace":"^5.0.5","@rollup/plugin-terser":"^0.4.4","@typescript-eslint/eslint-plugin":"^6.16.0","@typescript-eslint/parser":"^6.16.0","@wdio/cli":"^8.32.3","@wdio/local-runner":"^8.32.3","@wdio/mocha-framework":"^8.32.3","@wdio/spec-reporter":"^8.32.2","body-parser":"^1.20.2","chromedriver":"^122.0.4","eslint":"^8.56.0","express":"^4.18.2","fs-extra":"^11.2.0","husky":"^8.0.3","lint-staged":"^15.2.0","npm-run-all":"^4.1.5","nunjucks":"^3.2.4","prettier":"^3.1.1","rollup":"^4.9.1","selenium-standalone":"^9.3.1","typescript":"^5.3.3","wdio-chromedriver-service":"^8.1.1"},"lint-staged":{"**/*.{js,ts}":"eslint --fix --ignore-path .gitignore","**/*.{cjs,css,html,js,json,html,md,ts,yml,yaml}":"prettier --write --ignore-path .gitignore"},"_id":"web-vitals@4.0.0-beta.2","readme":"# `web-vitals`\n\n- [Overview](#overview)\n- [Install and load the library](#installation)\n  - [From npm](#import-web-vitals-from-npm)\n  - [From a CDN](#load-web-vitals-from-a-cdn)\n- [Usage](#usage)\n  - [Basic usage](#basic-usage)\n  - [Report the value on every change](#report-the-value-on-every-change)\n  - [Report only the delta of changes](#report-only-the-delta-of-changes)\n  - [Send the results to an analytics endpoint](#send-the-results-to-an-analytics-endpoint)\n  - [Send the results to Google Analytics](#send-the-results-to-google-analytics)\n  - [Send the results to Google Tag Manager](#send-the-results-to-google-tag-manager)\n  - [Send attribution data](#send-attribution-data)\n  - [Batch multiple reports together](#batch-multiple-reports-together)\n- [Build options](#build-options)\n  - [Which build is right for you?](#which-build-is-right-for-you)\n- [API](#api)\n  - [Types](#types)\n  - [Functions](#functions)\n  - [Rating Thresholds](#rating-thresholds)\n  - [Attribution](#attribution)\n- [Browser Support](#browser-support)\n- [Limitations](#limitations)\n- [Development](#development)\n- [Integrations](#integrations)\n- [License](#license)\n\n## Overview\n\nThe `web-vitals` library is a tiny (~2K, brotli'd), modular library for measuring all the [Web Vitals](https://web.dev/articles/vitals) metrics on real users, in a way that accurately matches how they're measured by Chrome and reported to other Google tools (e.g. [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report), [Page Speed Insights](https://developers.google.com/speed/pagespeed/insights/), [Search Console's Speed Report](https://webmasters.googleblog.com/2019/11/search-console-speed-report.html)).\n\nThe library supports all of the [Core Web Vitals](https://web.dev/articles/vitals#core_web_vitals) as well as a number of other metrics that are useful in diagnosing [real-user](https://web.dev/articles/user-centric-performance-metrics) performance issues.\n\n### Core Web Vitals\n\n- [Cumulative Layout Shift (CLS)](https://web.dev/articles/cls)\n- [Interaction to Next Paint (INP)](https://web.dev/articles/inp)\n- [Largest Contentful Paint (LCP)](https://web.dev/articles/lcp)\n\n### Other metrics\n\n- [First Contentful Paint (FCP)](https://web.dev/articles/fcp)\n- [Time to First Byte (TTFB)](https://web.dev/articles/ttfb)\n- [First Input Delay (FID)](https://web.dev/articles/fid) _Deprecated and will be removed in next major release_\n\n<a name=\"installation\"><a>\n<a name=\"load-the-library\"><a>\n\n## Install and load the library\n\n<a name=\"import-web-vitals-from-npm\"><a>\n\nThe `web-vitals` library uses the `buffered` flag for [PerformanceObserver](https://developer.mozilla.org/docs/Web/API/PerformanceObserver/observe), allowing it to access performance entries that occurred before the library was loaded.\n\nThis means you do not need to load this library early in order to get accurate performance data. In general, this library should be deferred until after other user-impacting code has loaded.\n\n### From npm\n\nYou can install this library from npm by running:\n\n```sh\nnpm install web-vitals\n```\n\n_**Note:** If you're not using npm, you can still load `web-vitals` via `<script>` tags from a CDN like [unpkg.com](https://unpkg.com). See the [load `web-vitals` from a CDN](#load-web-vitals-from-a-cdn) usage example below for details._\n\nThere are a few different builds of the `web-vitals` library, and how you load the library depends on which build you want to use.\n\nFor details on the difference between the builds, see <a href=\"#which-build-is-right-for-you\">which build is right for you</a>.\n\n**1. The \"standard\" build**\n\nTo load the \"standard\" build, import modules from the `web-vitals` package in your application code (as you would with any npm package and node-based build tool):\n\n```js\nimport {onLCP, onINP, onCLS} from 'web-vitals';\n\nonCLS(console.log);\nonINP(console.log);\nonLCP(console.log);\n```\n\n_**Note:** in version 2, these functions were named `getXXX()` rather than `onXXX()`. They've [been renamed](https://github.com/GoogleChrome/web-vitals/pull/222) in version 3 to reduce confusion (see [#217](https://github.com/GoogleChrome/web-vitals/pull/217) for details) and will continue to be available using the `getXXX()` until at least version 4. Users are encouraged to switch to the new names, though, for future compatibility._\n\n<a name=\"attribution-build\"><a>\n\n**2. The \"attribution\" build**\n\nMeasuring the Web Vitals scores for your real users is a great first step toward optimizing the user experience. But if your scores aren't _good_, the next step is to understand why they're not good and work to improve them.\n\nThe \"attribution\" build helps you do that by including additional diagnostic information with each metric to help you identify the root cause of poor performance as well as prioritize the most important things to fix.\n\nThe \"attribution\" build is slightly larger than the \"standard\" build (by about 600 bytes, brotli'd), so while the code size is still small, it's only recommended if you're actually using these features.\n\nTo load the \"attribution\" build, change any `import` statements that reference `web-vitals` to `web-vitals/attribution`:\n\n```diff\n- import {onLCP, onINP, onCLS} from 'web-vitals';\n+ import {onLCP, onINP, onCLS} from 'web-vitals/attribution';\n```\n\nUsage for each of the imported function is identical to the standard build, but when importing from the attribution build, the [`Metric`](#metric) object will contain an additional [`attribution`](#metricwithattribution) property.\n\nSee [Send attribution data](#send-attribution-data) for usage examples, and the [`attribution` reference](#attribution) for details on what values are added for each metric.\n\n<a name=\"load-web-vitals-from-a-cdn\"><a>\n\n### From a CDN\n\nThe recommended way to use the `web-vitals` package is to install it from npm and integrate it into your build process. However, if you're not using npm, it's still possible to use `web-vitals` by requesting it from a CDN that serves npm package files.\n\nThe following examples show how to load `web-vitals` from [unpkg.com](https://unpkg.com):\n\n_**Important!** The [unpkg.com](https://unpkg.com) CDN is shown here for example purposes only. `unpkg.com` is not affiliated with Google, and there are no guarantees that the URLs shown in these examples will continue to work in the future._\n\n**Load the \"standard\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {onCLS, onINP, onLCP} from 'https://unpkg.com/web-vitals@4?module';\n\n  onCLS(console.log);\n  onINP(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"standard\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src = 'https://unpkg.com/web-vitals@4/dist/web-vitals.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onINP(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n**Load the \"attribution\" build** _(using a module script)_\n\n```html\n<!-- Append the `?module` param to load the module version of `web-vitals` -->\n<script type=\"module\">\n  import {\n    onCLS,\n    onINP,\n    onLCP,\n  } from 'https://unpkg.com/web-vitals@4/dist/web-vitals.attribution.js?module';\n\n  onCLS(console.log);\n  onINP(console.log);\n  onLCP(console.log);\n</script>\n```\n\n**Load the \"attribution\" build** _(using a classic script)_\n\n```html\n<script>\n  (function () {\n    var script = document.createElement('script');\n    script.src =\n      'https://unpkg.com/web-vitals@4/dist/web-vitals.attribution.iife.js';\n    script.onload = function () {\n      // When loading `web-vitals` using a classic script, all the public\n      // methods can be found on the `webVitals` global namespace.\n      webVitals.onCLS(console.log);\n      webVitals.onINP(console.log);\n      webVitals.onLCP(console.log);\n    };\n    document.head.appendChild(script);\n  })();\n</script>\n```\n\n## Usage\n\n### Basic usage\n\nEach of the Web Vitals metrics is exposed as a single function that takes a `callback` function that will be called any time the metric value is available and ready to be reported.\n\nThe following example measures each of the Core Web Vitals metrics and logs the result to the console once its value is ready to report.\n\n_(The examples below import the \"standard\" build, but they will work with the \"attribution\" build as well.)_\n\n```js\nimport {onCLS, onINP, onLCP} from 'web-vitals';\n\nonCLS(console.log);\nonINP(console.log);\nonLCP(console.log);\n```\n\nNote that some of these metrics will not report until the user has interacted with the page, switched tabs, or the page starts to unload. If you don't see the values logged to the console immediately, try reloading the page (with [preserve log](https://developer.chrome.com/docs/devtools/console/reference/#persist) enabled) or switching tabs and then switching back.\n\nAlso, in some cases a metric callback may never be called:\n\n- FID and INP are not reported if the user never interacts with the page.\n- CLS, FCP, FID, and LCP are not reported if the page was loaded in the background.\n\nIn other cases, a metric callback may be called more than once:\n\n- CLS and INP should be reported any time the [page's `visibilityState` changes to hidden](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden).\n- All metrics are reported again (with the above exceptions) after a page is restored from the [back/forward cache](https://web.dev/articles/bfcache).\n\n_**Warning:** do not call any of the Web Vitals functions (e.g. `onCLS()`, `onINP()`, `onLCP()`) more than once per page load. Each of these functions creates a `PerformanceObserver` instance and registers event listeners for the lifetime of the page. While the overhead of calling these functions once is negligible, calling them repeatedly on the same page may eventually result in a memory leak._\n\n### Report the value on every change\n\nIn most cases, you only want the `callback` function to be called when the metric is ready to be reported. However, it is possible to report every change (e.g. each larger layout shift as it happens) by setting `reportAllChanges` to `true` in the optional, [configuration object](#reportopts) (second parameter).\n\n_**Important:** `reportAllChanges` only reports when the **metric changes**, not for each **input to the metric**. For example, a new layout shift that does not increase the CLS metric will not be reported even with `reportAllChanges` set to `true` because the CLS metric has not changed. Similarly, for INP, each interaction is not reported even with `reportAllChanges` set to `true`—just when an interaction causes an increase to INP._\n\nThis can be useful when debugging, but in general using `reportAllChanges` is not needed (or recommended) for measuring these metrics in production.\n\n```js\nimport {onCLS} from 'web-vitals';\n\n// Logs CLS as the value changes.\nonCLS(console.log, {reportAllChanges: true});\n```\n\n### Report only the delta of changes\n\nSome analytics providers allow you to update the value of a metric, even after you've already sent it to their servers (overwriting the previously-sent value with the same `id`).\n\nOther analytics providers, however, do not allow this, so instead of reporting the new value, you need to report only the delta (the difference between the current value and the last-reported value). You can then compute the total value by summing all metric deltas sent with the same ID.\n\nThe following example shows how to use the `id` and `delta` properties:\n\n```js\nimport {onCLS, onINP, onLCP} from 'web-vitals';\n\nfunction logDelta({name, id, delta}) {\n  console.log(`${name} matching ID ${id} changed by ${delta}`);\n}\n\nonCLS(logDelta);\nonINP(logDelta);\nonLCP(logDelta);\n```\n\n_**Note:** the first time the `callback` function is called, its `value` and `delta` properties will be the same._\n\nIn addition to using the `id` field to group multiple deltas for the same metric, it can also be used to differentiate different metrics reported on the same page. For example, after a back/forward cache restore, a new metric object is created with a new `id` (since back/forward cache restores are considered separate page visits).\n\n### Send the results to an analytics endpoint\n\nThe following example measures each of the Core Web Vitals metrics and reports them to a hypothetical `/analytics` endpoint, as soon as each is ready to be sent.\n\nThe `sendToAnalytics()` function uses the [`navigator.sendBeacon()`](https://developer.mozilla.org/docs/Web/API/Navigator/sendBeacon) method (if available), but falls back to the [`fetch()`](https://developer.mozilla.org/docs/Web/API/Fetch_API) API when not.\n\n```js\nimport {onCLS, onINP, onLCP} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n  // Replace with whatever serialization method you prefer.\n  // Note: JSON.stringify will likely include more data than you need.\n  const body = JSON.stringify(metric);\n\n  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n    fetch('/analytics', {body, method: 'POST', keepalive: true});\n}\n\nonCLS(sendToAnalytics);\nonINP(sendToAnalytics);\nonLCP(sendToAnalytics);\n```\n\n### Send the results to Google Analytics\n\nGoogle Analytics does not support reporting metric distributions in any of its built-in reports; however, if you set a unique event parameter value (in this case, the metric_id, as shown in the example below) on every metric instance that you send to Google Analytics, you can create a report yourself by first getting the data via the [Google Analytics Data API](https://developers.google.com/analytics/devguides/reporting/data/v1) or via [BigQuery export](https://support.google.com/analytics/answer/9358801) and then visualizing it any charting library you choose.\n\n[Google Analytics 4](https://support.google.com/analytics/answer/10089681) introduces a new Event model allowing custom parameters instead of a fixed category, action, and label. It also supports non-integer values, making it easier to measure Web Vitals metrics compared to previous versions.\n\n```js\nimport {onCLS, onINP, onLCP} from 'web-vitals';\n\nfunction sendToGoogleAnalytics({name, delta, value, id}) {\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n\n    // OPTIONAL: any additional params or debug info here.\n    // See: https://web.dev/articles/debug-performance-in-the-field\n    // metric_rating: 'good' | 'needs-improvement' | 'poor',\n    // debug_info: '...',\n    // ...\n  });\n}\n\nonCLS(sendToGoogleAnalytics);\nonINP(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\nFor details on how to query this data in [BigQuery](https://cloud.google.com/bigquery), or visualise it in [Looker Studio](https://lookerstudio.google.com/), see [Measure and debug performance with Google Analytics 4 and BigQuery](https://web.dev/articles/vitals-ga4).\n\n### Send the results to Google Tag Manager\n\nWhile `web-vitals` can be called directly from Google Tag Manager, using a pre-defined custom template makes this considerably easier. Some recommended templates include:\n\n- [Core Web Vitals](https://tagmanager.google.com/gallery/#/owners/gtm-templates-simo-ahava/templates/core-web-vitals) by [Simo Ahava](https://www.simoahava.com/). See [Track Core Web Vitals in GA4 with Google Tag Manager](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for usage and installation instructions.\n- [Web Vitals Template for Google Tag Manager](https://github.com/google-marketing-solutions/web-vitals-gtm-template) by The Google Marketing Solutions team. See the [README](https://github.com/google-marketing-solutions/web-vitals-gtm-template?tab=readme-ov-file#web-vitals-template-for-google-tag-manager) for usage and installation instructions.\n\n### Send attribution data\n\nWhen using the [attribution build](#attribution-build), you can send additional data to help you debug _why_ the metric values are they way they are.\n\nThis example sends an additional `debug_target` param to Google Analytics, corresponding to the element most associated with each metric.\n\n```js\nimport {onCLS, onINP, onLCP} from 'web-vitals/attribution';\n\nfunction sendToGoogleAnalytics({name, delta, value, id, attribution}) {\n  const eventParams = {\n    // Built-in params:\n    value: delta, // Use `delta` so the value can be summed.\n    // Custom params:\n    metric_id: id, // Needed to aggregate events.\n    metric_value: value, // Optional.\n    metric_delta: delta, // Optional.\n  };\n\n  switch (name) {\n    case 'CLS':\n      eventParams.debug_target = attribution.largestShiftTarget;\n      break;\n    case 'INP':\n      eventParams.debug_target = attribution.eventTarget;\n      break;\n    case 'LCP':\n      eventParams.debug_target = attribution.element;\n      break;\n  }\n\n  // Assumes the global `gtag()` function exists, see:\n  // https://developers.google.com/analytics/devguides/collection/ga4\n  gtag('event', name, eventParams);\n}\n\nonCLS(sendToGoogleAnalytics);\nonINP(sendToGoogleAnalytics);\nonLCP(sendToGoogleAnalytics);\n```\n\n_**Note:** this example relies on custom [event parameters](https://support.google.com/analytics/answer/11396839) in Google Analytics 4._\n\nSee [Debug performance in the field](https://web.dev/articles/debug-performance-in-the-field) for more information and examples.\n\n### Batch multiple reports together\n\nRather than reporting each individual Web Vitals metric separately, you can minimize your network usage by batching multiple metric reports together in a single network request.\n\nHowever, since not all Web Vitals metrics become available at the same time, and since not all metrics are reported on every page, you cannot simply defer reporting until all metrics are available.\n\nInstead, you should keep a queue of all metrics that were reported and flush the queue whenever the page is backgrounded or unloaded:\n\n```js\nimport {onCLS, onINP, onLCP} from 'web-vitals';\n\nconst queue = new Set();\nfunction addToQueue(metric) {\n  queue.add(metric);\n}\n\nfunction flushQueue() {\n  if (queue.size > 0) {\n    // Replace with whatever serialization method you prefer.\n    // Note: JSON.stringify will likely include more data than you need.\n    const body = JSON.stringify([...queue]);\n\n    // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.\n    (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||\n      fetch('/analytics', {body, method: 'POST', keepalive: true});\n\n    queue.clear();\n  }\n}\n\nonCLS(addToQueue);\nonINP(addToQueue);\nonLCP(addToQueue);\n\n// Report all available metrics whenever the page is backgrounded or unloaded.\naddEventListener('visibilitychange', () => {\n  if (document.visibilityState === 'hidden') {\n    flushQueue();\n  }\n});\n\n// NOTE: Safari does not reliably fire the `visibilitychange` event when the\n// page is being unloaded. If Safari support is needed, you should also flush\n// the queue in the `pagehide` event.\naddEventListener('pagehide', flushQueue);\n```\n\n_**Note:** see [the Page Lifecycle guide](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#legacy-lifecycle-apis-to-avoid) for an explanation of why `visibilitychange` and `pagehide` are recommended over events like `beforeunload` and `unload`._\n\n<a name=\"bundle-versions\"><a>\n\n## Build options\n\nThe `web-vitals` package includes both \"standard\" and \"attribution\" builds, as well as different formats of each to allow developers to choose the format that best meets their needs or integrates with their architecture.\n\nThe following table lists all the builds distributed with the `web-vitals` package on npm.\n\n<table>\n  <tr>\n    <td width=\"35%\">\n      <strong>Filename</strong> <em>(all within <code>dist/*</code>)</em>\n    </td>\n    <td><strong>Export</strong></td>\n    <td><strong>Description</strong></td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.js</code></td>\n    <td><code>pkg.module</code></td>\n    <td>\n      <p>An ES module bundle of all metric functions, without any attribution features.</p>\n      This is the \"standard\" build and is the simplest way to consume this library out of the box.\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.umd.cjs</code></td>\n    <td><code>pkg.main</code></td>\n    <td>\n      A UMD version of the <code>web-vitals.js</code> bundle (exposed on the <code>self.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.js</code> bundle (exposed on the <code>self.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  <tr>\n    <td><code>web-vitals.attribution.js</code></td>\n    <td>--</td>\n    <td>\n      An ES module version of all metric functions that includes <a href=\"#attribution-build\">attribution</a> features.\n    </td>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.umd.cjs</code></td>\n    <td>--</td>\n    <td>\n      A UMD version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>self.webVitals.*</code> namespace).\n    </td>\n  </tr>\n  </tr>\n    <tr>\n    <td><code>web-vitals.attribution.iife.js</code></td>\n    <td>--</td>\n    <td>\n      An IIFE version of the <code>web-vitals.attribution.js</code> build (exposed on the <code>self.webVitals.*</code> namespace).\n    </td>\n  </tr>\n</table>\n\n<a name=\"which-build-is-right-for-you\"><a>\n\n### Which build is right for you?\n\nMost developers will generally want to use \"standard\" build (via either the ES module or UMD version, depending on your bundler/build system), as it's the easiest to use out of the box and integrate into existing tools.\n\nHowever, if you'd lke to collect additional debug information to help you diagnose performance bottlenecks based on real-user issues, use the [\"attribution\" build](#attribution-build).\n\nFor guidance on how to collect and use real-user data to debug performance issues, see [Debug performance in the field](https://web.dev/debug-performance-in-the-field/).\n\n## API\n\n### Types:\n\n#### `Metric`\n\n```ts\ninterface Metric {\n  /**\n   * The name of the metric (in acronym form).\n   */\n  name: 'CLS' | 'FCP' | 'FID' | 'INP' | 'LCP' | 'TTFB';\n\n  /**\n   * The current value of the metric.\n   */\n  value: number;\n\n  /**\n   * The rating as to whether the metric value is within the \"good\",\n   * \"needs improvement\", or \"poor\" thresholds of the metric.\n   */\n  rating: 'good' | 'needs-improvement' | 'poor';\n\n  /**\n   * The delta between the current value and the last-reported value.\n   * On the first report, `delta` and `value` will always be the same.\n   */\n  delta: number;\n\n  /**\n   * A unique ID representing this particular metric instance. This ID can\n   * be used by an analytics tool to dedupe multiple values sent for the same\n   * metric instance, or to group multiple deltas together and calculate a\n   * total. It can also be used to differentiate multiple different metric\n   * instances sent from the same page, which can happen if the page is\n   * restored from the back/forward cache (in that case new metrics object\n   * get created).\n   */\n  id: string;\n\n  /**\n   * Any performance entries relevant to the metric value calculation.\n   * The array may also be empty if the metric value was not based on any\n   * entries (e.g. a CLS value of 0 given no layout shifts).\n   */\n  entries: (PerformanceEntry | LayoutShift)[];\n\n  /**\n   * The type of navigation.\n   *\n   * This will be the value returned by the Navigation Timing API (or\n   * `undefined` if the browser doesn't support that API), with the following\n   * exceptions:\n   * - 'back-forward-cache': for pages that are restored from the bfcache.\n   * - 'back_forward' is renamed to 'back-forward' for consistency.\n   * - 'prerender': for pages that were prerendered.\n   * - 'restore': for pages that were discarded by the browser and then\n   * restored by the user.\n   */\n  navigationType:\n    | 'navigate'\n    | 'reload'\n    | 'back-forward'\n    | 'back-forward-cache'\n    | 'prerender'\n    | 'restore';\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetric`](/src/types/cls.ts#:~:text=interface%20CLSMetric)\n- [`FCPMetric`](/src/types/fcp.ts#:~:text=interface%20FCPMetric)\n- [`FIDMetric`](/src/types/fid.ts#:~:text=interface%20FIDMetric)\n- [`INPMetric`](/src/types/inp.ts#:~:text=interface%20INPMetric)\n- [`LCPMetric`](/src/types/lcp.ts#:~:text=interface%20LCPMetric)\n- [`TTFBMetric`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetric)\n\n#### `MetricWithAttribution`\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n```ts\ninterface MetricWithAttribution extends Metric {\n  /**\n   * An object containing potentially-helpful debugging information that\n   * can be sent along with the metric value for the current page visit in\n   * order to help identify issues happening to real-users in the field.\n   */\n  attribution: {[key: string]: unknown};\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSMetricWithAttribution`](/src/types/cls.ts#:~:text=interface%20CLSMetricWithAttribution)\n- [`FCPMetricWithAttribution`](/src/types/fcp.ts#:~:text=interface%20FCPMetricWithAttribution)\n- [`FIDMetricWithAttribution`](/src/types/fid.ts#:~:text=interface%20FIDMetricWithAttribution)\n- [`INPMetricWithAttribution`](/src/types/inp.ts#:~:text=interface%20INPMetricWithAttribution)\n- [`LCPMetricWithAttribution`](/src/types/lcp.ts#:~:text=interface%20LCPMetricWithAttribution)\n- [`TTFBMetricWithAttribution`](/src/types/ttfb.ts#:~:text=interface%20TTFBMetricWithAttribution)\n\n#### `MetricRatingThresholds`\n\nThe thresholds of metric's \"good\", \"needs improvement\", and \"poor\" ratings.\n\n- Metric values up to and including [0] are rated \"good\"\n- Metric values up to and including [1] are rated \"needs improvement\"\n- Metric values above [1] are \"poor\"\n\n| Metric value    | Rating              |\n| --------------- | ------------------- |\n| ≦ [0]           | \"good\"              |\n| > [0] and ≦ [1] | \"needs improvement\" |\n| > [1]           | \"poor\"              |\n\n```ts\nexport type MetricRatingThresholds = [number, number];\n```\n\n_See also [Rating Thresholds](#rating-thresholds)._\n\n#### `ReportCallback`\n\n```ts\ninterface ReportCallback {\n  (metric: Metric): void;\n}\n```\n\nMetric-specific subclasses:\n\n- [`CLSReportCallback`](/src/types/cls.ts#:~:text=interface%20CLSReportCallback)\n- [`FCPReportCallback`](/src/types/fcp.ts#:~:text=interface%20FCPReportCallback)\n- [`FIDReportCallback`](/src/types/fid.ts#:~:text=interface%20FIDReportCallback)\n- [`INPReportCallback`](/src/types/inp.ts#:~:text=interface%20INPReportCallback)\n- [`LCPReportCallback`](/src/types/lcp.ts#:~:text=interface%20LCPReportCallback)\n- [`TTFBReportCallback`](/src/types/ttfb.ts#:~:text=interface%20TTFBReportCallback)\n\n#### `ReportOpts`\n\n```ts\ninterface ReportOpts {\n  reportAllChanges?: boolean;\n  durationThreshold?: number;\n}\n```\n\n#### `LoadState`\n\nThe `LoadState` type is used in several of the metric [attribution objects](#attribution).\n\n```ts\n/**\n * The loading state of the document. Note: this value is similar to\n * `document.readyState` but it subdivides the \"interactive\" state into the\n * time before and after the DOMContentLoaded event fires.\n *\n * State descriptions:\n * - `loading`: the initial document response has not yet been fully downloaded\n *   and parsed. This is equivalent to the corresponding `readyState` value.\n * - `dom-interactive`: the document has been fully loaded and parsed, but\n *   scripts may not have yet finished loading and executing.\n * - `dom-content-loaded`: the document is fully loaded and parsed, and all\n *   scripts (except `async` scripts) have loaded and finished executing.\n * - `complete`: the document and all of its sub-resources have finished\n *   loading. This is equivalent to the corresponding `readyState` value.\n */\ntype LoadState =\n  | 'loading'\n  | 'dom-interactive'\n  | 'dom-content-loaded'\n  | 'complete';\n```\n\n### Functions:\n\n#### `onCLS()`\n\n```ts\ntype onCLS = (callback: CLSReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [CLS](https://web.dev/articles/cls) value for the current page and calls the `callback` function once the value is ready to be reported, along with all `layout-shift` performance entries that were used in the metric value calculation. The reported value is a [double](https://heycam.github.io/webidl/#idl-double) (corresponding to a [layout shift score](https://web.dev/articles/cls#layout_shift_score)).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan (Note [not necessarily for every layout shift](#report-the-value-on-every-change)).\n\n_**Important:** CLS should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onFCP()`\n\n```ts\ntype onFCP = (callback: FCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FCP](https://web.dev/articles/fcp) value for the current page and calls the `callback` function once the value is ready, along with the relevant `paint` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp).\n\n#### `onFID()`\n\n_Deprecated and will be removed in next major release_\n\n```ts\ntype onFID = (callback: FIDReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [FID](https://web.dev/articles/fid) value for the current page and calls the `callback` function once the value is ready, along with the relevant `first-input` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp).\n\n_**Important:** since FID is only reported after the user interacts with the page, it's possible that it will not be reported for some page loads._\n\n#### `onINP()`\n\n```ts\ntype onINP = (callback: INPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [INP](https://web.dev/articles/inp) value for the current page and calls the `callback` function once the value is ready, along with the `event` performance entries reported for that interaction. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp).\n\nA custom `durationThreshold` [configuration option](#reportopts) can optionally be passed to control what `event-timing` entries are considered for INP reporting. The default threshold is `40`, which means INP scores of less than 40 are reported as 0. Note that this will not affect your 75th percentile INP value unless that value is also less than 40 (well below the recommended [good](https://web.dev/articles/inp#what_is_a_good_inp_score) threshold).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called as soon as the value is initially determined as well as any time the value changes throughout the page lifespan (Note [not necessarily for every interaction](#report-the-value-on-every-change)).\n\n_**Important:** INP should be continually monitored for changes throughout the entire lifespan of a page—including if the user returns to the page after it's been hidden/backgrounded. However, since browsers often [will not fire additional callbacks once the user has backgrounded a page](https://developer.chrome.com/blog/page-lifecycle-api/#advice-hidden), `callback` is always called when the page's visibility state changes to hidden. As a result, the `callback` function might be called multiple times during the same page load (see [Reporting only the delta of changes](#report-only-the-delta-of-changes) for how to manage this)._\n\n#### `onLCP()`\n\n```ts\ntype onLCP = (callback: LCPReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [LCP](https://web.dev/articles/lcp) value for the current page and calls the `callback` function once the value is ready (along with the relevant `largest-contentful-paint` performance entry used to determine the value). The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp).\n\nIf the `reportAllChanges` [configuration option](#reportopts) is set to `true`, the `callback` function will be called any time a new `largest-contentful-paint` performance entry is dispatched, or once the final value of the metric has been determined.\n\n#### `onTTFB()`\n\n```ts\ntype onTTFB = (callback: TTFBReportCallback, opts?: ReportOpts) => void;\n```\n\nCalculates the [TTFB](https://web.dev/articles/ttfb) value for the current page and calls the `callback` function once the page has loaded, along with the relevant `navigation` performance entry used to determine the value. The reported value is a [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp).\n\nNote, this function waits until after the page is loaded to call `callback` in order to ensure all properties of the `navigation` entry are populated. This is useful if you want to report on other metrics exposed by the [Navigation Timing API](https://w3c.github.io/navigation-timing/).\n\nFor example, the TTFB metric starts from the page's [time origin](https://www.w3.org/TR/hr-time-2/#sec-time-origin), which means it includes time spent on DNS lookup, connection negotiation, network latency, and server processing time.\n\n```js\nimport {onTTFB} from 'web-vitals';\n\nonTTFB((metric) => {\n  // Calculate the request time by subtracting from TTFB\n  // everything that happened prior to the request starting.\n  const requestTime = metric.value - metric.entries[0].requestStart;\n  console.log('Request time:', requestTime);\n});\n```\n\n_**Note:** browsers that do not support `navigation` entries will fall back to\nusing `performance.timing` (with the timestamps converted from epoch time to [`DOMHighResTimeStamp`](https://developer.mozilla.org/docs/Web/API/DOMHighResTimeStamp)). This ensures code referencing these values (like in the example above) will work the same in all browsers._\n\n### Rating Thresholds:\n\nThe thresholds of each metric's \"good\", \"needs improvement\", and \"poor\" ratings are available as [`MetricRatingThresholds`](#metricratingthresholds).\n\nExample:\n\n```ts\nimport {CLSThresholds, INPThresholds, LCPThresholds} from 'web-vitals';\n\nconsole.log(CLSThresholds); // [ 0.1, 0.25 ]\nconsole.log(INPThresholds); // [ 200, 500 ]\nconsole.log(LCPThresholds); // [ 2500, 4000 ]\n```\n\n_**Note:** It's typically not necessary (or recommended) to manually calculate metric value ratings using these thresholds. Use the [`Metric['rating']`](#metric) supplied by the [`ReportCallback`](#reportcallback) functions instead._\n\n### Attribution:\n\nThe following objects contain potentially-helpful debugging information that can be sent along with the metric values for the current page visit in order to help identify issues happening to real-users in the field.\n\nSee the [attribution build](#attribution-build) section for details on how to use this feature.\n\n#### CLS `attribution`:\n\n```ts\ninterface CLSAttribution {\n  /**\n   * A selector identifying the first element (in document order) that\n   * shifted when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTarget?: string;\n  /**\n   * The time when the single largest layout shift contributing to the page's\n   * CLS score occurred.\n   */\n  largestShiftTime?: DOMHighResTimeStamp;\n  /**\n   * The layout shift score of the single largest layout shift contributing to\n   * the page's CLS score.\n   */\n  largestShiftValue?: number;\n  /**\n   * The `LayoutShiftEntry` representing the single largest layout shift\n   * contributing to the page's CLS score. (Useful when you need more than just\n   * `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftEntry?: LayoutShift;\n  /**\n   * The first element source (in document order) among the `sources` list\n   * of the `largestShiftEntry` object. (Also useful when you need more than\n   * just `largestShiftTarget`, `largestShiftTime`, and `largestShiftValue`).\n   */\n  largestShiftSource?: LayoutShiftAttribution;\n  /**\n   * The loading state of the document at the time when the largest layout\n   * shift contribution to the page's CLS score occurred (see `LoadState`\n   * for details).\n   */\n  loadState?: LoadState;\n}\n```\n\n#### FCP `attribution`:\n\n```ts\ninterface FCPAttribution {\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB).\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and the first contentful paint (FCP).\n   */\n  firstByteToFCP: number;\n  /**\n   * The loading state of the document at the time when FCP `occurred (see\n   * `LoadState` for details). Ideally, documents can paint before they finish\n   * loading (e.g. the `loading` or `dom-interactive` phases).\n   */\n  loadState: LoadState;\n  /**\n   * The `PerformancePaintTiming` entry corresponding to FCP.\n   */\n  fcpEntry?: PerformancePaintTiming;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming;\n}\n```\n\n#### FID `attribution`:\n\n```ts\ninterface FIDAttribution {\n  /**\n   * A selector identifying the element that the user interacted with. This\n   * element will be the `target` of the `event` dispatched.\n   */\n  eventTarget: string;\n  /**\n   * The time when the user interacted. This time will match the `timeStamp`\n   * value of the `event` dispatched.\n   */\n  eventTime: number;\n  /**\n   * The `type` of the `event` dispatched from the user interaction.\n   */\n  eventType: string;\n  /**\n   * The `PerformanceEventTiming` entry corresponding to FID.\n   */\n  eventEntry: PerformanceEventTiming;\n  /**\n   * The loading state of the document at the time when the first interaction\n   * occurred (see `LoadState` for details). If the first interaction occurred\n   * while the document was loading and executing script (e.g. usually in the\n   * `dom-interactive` phase) it can result in long input delays.\n   */\n  loadState: LoadState;\n}\n```\n\n#### INP `attribution`:\n\n```ts\ninterface INPAttribution {\n  /**\n   * A selector identifying the element that the user first interacted with\n   * as part of the frame where the INP candidate interaction occurred.\n   * If `interactionTarget` is an empty string, that generally means the\n   * element was removed from the DOM after the interaction.\n   */\n  interactionTarget: string;\n\n  /**\n   * The time when the user first interacted during the frame where the INP\n   * candidate interaction occurred (if more than one interaction occurred\n   * within the frame, only the first time is reported).\n   */\n  interactionTime: DOMHighResTimeStamp;\n\n  /**\n   * The best-guess timestamp of the next paint after the interaction.\n   * In general, this timestamp is the same as the `startTime + duration` of\n   * the event timing entry. However, since `duration` values are rounded to\n   * the nearest 8ms, it can sometimes appear that the paint occurred before\n   * processing ended (which cannot happen). This value clamps the paint time\n   * so it's always after `processingEnd` from the Event Timing API and\n   * `renderStart` from the Long Animation Frame API (where available).\n   * It also averages the duration values for all entries in the same\n   * animation frame, which should be closer to the \"real\" value.\n   */\n  nextPaintTime: DOMHighResTimeStamp;\n\n  /**\n   * The type of interaction, based on the event type of the `event` entry\n   * that corresponds to the interaction (i.e. the first `event` entry\n   * containing an `interactionId` dispatched in a given animation frame).\n   * For \"pointerdown\", \"pointerup\", or \"click\" events this will be \"pointer\",\n   * and for \"keydown\" or \"keyup\" events this will be \"keyboard\".\n   */\n  interactionType: 'pointer' | 'keyboard';\n\n  /**\n   * An array of Event Timing entries that were processed within the same\n   * animation frame as the INP candidate interaction.\n   */\n  processedEventEntries: PerformanceEventTiming[];\n\n  /**\n   * If the browser supports the Long Animation Frame API, this array will\n   * include any `long-animation-frame` entries that intersect with the INP\n   * candidate interaction's `startTime` and the `processingEnd` time of the\n   * last event processed within that animation frame. If the browser does not\n   * support the Long Animation Frame API or no `long-animation-frame` entries\n   * are detect, this array will be empty.\n   */\n  longAnimationFrameEntries: PerformanceLongAnimationFrameTiming[];\n\n  /**\n   * The time from when the user interacted with the page until when the\n   * browser was first able to start processing event listeners for that\n   * interaction. This time captures the delay before event processing can\n   * begin due to the main thread being busy with other work.\n   */\n  inputDelay: number;\n\n  /**\n   * The time from when the first event listener started running in response to\n   * the user interaction until when all event listener processing has finished.\n   */\n  processingDuration: number;\n\n  /**\n   * The time from when the browser finished processing all event listeners for\n   * the user interaction until the next frame is presented on the screen and\n   * visible to the user. This time includes work on the main thread (such as\n   * `requestAnimationFrame()` callbacks, `ResizeObserver` and\n   * `IntersectionObserver` callbacks, and style/layout calculation) as well\n   * as off-main-thread work (such as compositor, GPU, and raster work).\n   */\n  presentationDelay: number;\n\n  /**\n   * The loading state of the document at the time when the interaction\n   * corresponding to INP occurred (see `LoadState` for details). If the\n   * interaction occurred while the document was loading and executing script\n   * (e.g. usually in the `dom-interactive` phase) it can result in long delays.\n   */\n  loadState: LoadState;\n}\n```\n\n#### LCP `attribution`:\n\n```ts\ninterface LCPAttribution {\n  /**\n   * The element corresponding to the largest contentful paint for the page.\n   */\n  element?: string;\n  /**\n   * The URL (if applicable) of the LCP image resource. If the LCP element\n   * is a text node, this value will not be set.\n   */\n  url?: string;\n  /**\n   * The time from when the user initiates loading the page until when the\n   * browser receives the first byte of the response (a.k.a. TTFB). See\n   * [Optimize LCP](https://web.dev/articles/optimize-lcp) for details.\n   */\n  timeToFirstByte: number;\n  /**\n   * The delta between TTFB and when the browser starts loading the LCP\n   * resource (if there is one, otherwise 0). See [Optimize\n   * LCP](https://web.dev/articles/optimize-lcp) for details.\n   */\n  resourceLoadDelay: number;\n  /**\n   * The total time it takes to load the LCP resource itself (if there is one,\n   * otherwise 0). See [Optimize LCP](https://web.dev/articles/optimize-lcp) for\n   * details.\n   */\n  resourceLoadDuration: number;\n  /**\n   * The delta between when the LCP resource finishes loading until the LCP\n   * element is fully rendered. See [Optimize\n   * LCP](https://web.dev/articles/optimize-lcp) for details.\n   */\n  elementRenderDelay: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming;\n  /**\n   * The `resource` entry for the LCP resource (if applicable), which is useful\n   * for diagnosing resource load issues.\n   */\n  lcpResourceEntry?: PerformanceResourceTiming;\n  /**\n   * The `LargestContentfulPaint` entry corresponding to LCP.\n   */\n  lcpEntry?: LargestContentfulPaint;\n}\n```\n\n#### TTFB `attribution`:\n\n```ts\ninterface TTFBAttribution {\n  /**\n   * The total time from when the user initiates loading the page to when the\n   * DNS lookup begins. This includes redirects, service worker startup, and\n   * HTTP cache lookup times.\n   */\n  waitingDuration: number;\n  /**\n   * The total time to resolve the DNS for the current request.\n   */\n  dnsDuration: number;\n  /**\n   * The total time to create the connection to the requested domain.\n   */\n  connectionDuration: number;\n  /**\n   * The total time from when the request was sent until the first byte of the\n   * response was received. This includes network time as well as server\n   * processing time.\n   */\n  requestDuration: number;\n  /**\n   * The `navigation` entry of the current page, which is useful for diagnosing\n   * general page load issues. This can be used to access `serverTiming` for example:\n   * navigationEntry?.serverTiming\n   */\n  navigationEntry?: PerformanceNavigationTiming;\n}\n```\n\n## Browser Support\n\nThe `web-vitals` code has been tested and will run without error in all major browsers as well as Internet Explorer back to version 9. However, some of the APIs required to capture these metrics are currently only available in Chromium-based browsers (e.g. Chrome, Edge, Opera, Samsung Internet).\n\nBrowser support for each function is as follows:\n\n- `onCLS()`: Chromium\n- `onFCP()`: Chromium, Firefox, Safari 14.1+\n- `onFID()`: Chromium, Firefox _(Deprecated)_\n- `onINP()`: Chromium\n- `onLCP()`: Chromium\n- `onTTFB()`: Chromium, Firefox, Safari 15+\n\n## Limitations\n\nThe `web-vitals` library is primarily a wrapper around the Web APIs that measure the Web Vitals metrics, which means the limitations of those APIs will mostly apply to this library as well. More details on these limitations is available in [this blog post](https://web.dev/articles/crux-and-rum-differences).\n\nThe primary limitation of these APIs is they have no visibility into `<iframe>` content (not even same-origin iframes), which means pages that make use of iframes will likely see a difference between the data measured by this library and the data available in the Chrome User Experience Report (which does include iframe content).\n\nFor same-origin iframes, it's possible to use the `web-vitals` library to measure metrics, but it's tricky because it requires the developer to add the library to every frame and `postMessage()` the results to the parent frame for aggregation.\n\n_**Note:** given the lack of iframe support, the `onCLS()` function technically measures [DCLS](https://github.com/wicg/layout-instability#cumulative-scores) (Document Cumulative Layout Shift) rather than CLS, if the page includes iframes)._\n\n## Development\n\n### Building the code\n\nThe `web-vitals` source code is written in TypeScript. To transpile the code and build the production bundles, run the following command.\n\n```sh\nnpm run build\n```\n\nTo build the code and watch for changes, run:\n\n```sh\nnpm run watch\n```\n\n### Running the tests\n\nThe `web-vitals` code is tested in real browsers using [webdriver.io](https://webdriver.io/). Use the following command to run the tests:\n\n```sh\nnpm test\n```\n\nTo test any of the APIs manually, you can start the test server\n\n```sh\nnpm run test:server\n```\n\nThen navigate to `http://localhost:9090/test/<view>`, where `<view>` is the basename of one the templates under [/test/views/](/test/views/).\n\nYou'll likely want to combine this with `npm run watch` to ensure any changes you make are transpiled and rebuilt.\n\n## Integrations\n\n- [**Web Vitals Connector**](https://goo.gle/web-vitals-connector): Data Studio connector to create dashboards from [Web Vitals data captured in BiqQuery](https://web.dev/articles/vitals-ga4).\n- [**Core Web Vitals Custom Tag template**](https://www.simoahava.com/custom-templates/core-web-vitals/): Custom GTM template tag to [add measurement handlers](https://www.simoahava.com/analytics/track-core-web-vitals-in-ga4-with-google-tag-manager/) for all Core Web Vitals metrics.\n- [**`web-vitals-reporter`**](https://github.com/treosh/web-vitals-reporter): JavaScript library to batch `callback` functions and send data with a single request.\n\n## License\n\n[Apache 2.0](/LICENSE)\n","readmeFilename":"README.md","gitHead":"79d6f2888555f57ea76f9860b88ca7b1f162ac08","homepage":"https://github.com/GoogleChrome/web-vitals#readme","_nodeVersion":"20.11.0","_npmVersion":"10.3.0","dist":{"integrity":"sha512-opASHWRozKCgOVWLge5tqwerlfFysW0E6+s5uL+oSCQlU+A7SAIiFqBnKfAnVI0gmdi2741R5+zhvD47k8aMNg==","shasum":"175b2180b9d0eaabbfc00285d28e04befef14f89","tarball":"https://registry.npmjs.org/web-vitals/-/web-vitals-4.0.0-beta.2.tgz","fileCount":146,"unpackedSize":380849,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEYCIQC9DJKQN3Z2GYq8mwr5+VUHXobQiqBB8Od3msdmhGS8CQIhAP5Ev0AzrYKYo3/v5sr0uC20/4he0IMoEo2YbhnpjakF"}]},"_npmUser":{"name":"philipwalton","email":"philip@philipwalton.com"},"directories":{},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/web-vitals_4.0.0-beta.2_1712337780878_0.13758584559214393"},"_hasShrinkwrap":false}},"time":{"created":"2020-04-24T19:35:53.110Z","0.1.0":"2020-04-24T19:35:53.266Z","modified":"2024-04-05T17:23:01.270Z","0.2.0":"2020-05-04T04:54:48.431Z","0.2.1":"2020-05-07T06:53:43.370Z","0.2.2":"2020-05-12T23:39:13.623Z","0.2.3":"2020-06-26T19:59:48.145Z","0.2.4":"2020-07-24T01:46:34.692Z","1.0.0":"2020-11-17T02:00:02.070Z","1.0.1":"2020-11-17T04:17:17.882Z","1.1.0":"2021-01-14T02:42:44.373Z","1.1.1":"2021-03-13T21:03:43.087Z","1.1.2":"2021-05-06T02:24:32.820Z","2.0.0-beta.0":"2021-05-13T04:35:49.866Z","2.0.0-beta.1":"2021-05-13T04:38:59.288Z","2.0.0-beta.2":"2021-05-28T20:23:01.352Z","2.0.0":"2021-06-02T00:58:09.279Z","2.0.1":"2021-06-02T19:20:50.354Z","2.1.0":"2021-07-01T23:25:24.605Z","2.1.1":"2021-10-07T00:25:53.457Z","2.1.2":"2021-10-11T22:43:17.295Z","2.1.3":"2022-01-07T00:23:52.677Z","2.1.4":"2022-01-21T02:10:25.250Z","3.0.0-beta.0":"2022-04-25T23:46:36.389Z","3.0.0-beta.1":"2022-05-11T19:22:55.218Z","3.0.0-beta.2":"2022-05-12T00:09:47.037Z","3.0.0-rc.0":"2022-07-27T01:35:43.924Z","3.0.0":"2022-08-24T17:58:02.814Z","3.0.1":"2022-08-31T20:10:10.585Z","3.0.2":"2022-09-15T06:20:37.531Z","3.0.3":"2022-10-04T18:18:59.509Z","3.0.4":"2022-10-19T01:54:47.054Z","3.1.0":"2022-11-16T01:22:15.619Z","3.1.1":"2023-01-10T21:59:15.844Z","3.1.1-soft-navs":"2023-01-26T14:15:39.079Z","3.1.1-soft-navs-1":"2023-02-08T21:38:47.842Z","3.1.1-soft-navs-2":"2023-02-09T10:16:34.451Z","3.1.1-soft-navs-3":"2023-02-09T11:42:43.473Z","3.1.1-soft-navs-4":"2023-02-10T12:43:51.610Z","3.1.1-soft-navs-5":"2023-02-11T08:18:18.747Z","3.3.0":"2023-03-09T21:03:33.001Z","3.3.0-soft-navs-6":"2023-03-09T21:10:31.197Z","3.3.1":"2023-04-04T11:42:27.386Z","3.3.1-soft-navs-7":"2023-04-04T11:45:04.826Z","3.3.1-types":"2023-05-26T10:15:44.445Z","3.3.1-types-2":"2023-05-26T10:27:04.299Z","3.3.2":"2023-05-29T14:12:15.079Z","3.3.2-soft-navs-8":"2023-05-29T14:17:42.858Z","3.4.0":"2023-07-10T18:23:49.756Z","3.4.0-soft-navs-9":"2023-07-10T18:55:48.790Z","3.5.0":"2023-09-28T11:32:19.696Z","3.5.0-soft-navs-10":"2023-09-28T11:58:21.424Z","3.5.0-soft-navs-11":"2023-12-13T21:12:26.542Z","3.5.0-soft-navs-12":"2023-12-13T22:17:43.512Z","3.5.0-soft-navs-13":"2023-12-13T22:40:42.526Z","3.5.0-soft-navs-14":"2023-12-15T10:42:45.414Z","3.5.1":"2023-12-27T20:25:10.521Z","3.5.1-soft-navs-15":"2023-12-28T18:27:39.124Z","3.5.2":"2024-01-25T20:42:01.857Z","3.5.2-soft-navs-16":"2024-01-26T10:41:30.386Z","4.0.0-beta.0":"2024-03-29T19:15:10.318Z","4.0.0-beta.1":"2024-04-01T21:54:43.023Z","4.0.0-beta.2":"2024-04-05T17:23:01.081Z"},"maintainers":[{"name":"philipwalton","email":"philip@philipwalton.com"},{"name":"google-wombot","email":"node-team-npm+wombot@google.com"},{"name":"tunetheweb","email":"barrypollard@google.com"}],"description":"Easily measure performance metrics in JavaScript","homepage":"https://github.com/GoogleChrome/web-vitals#readme","keywords":["crux","performance","metrics","Core Web Vitals","CLS","FCP","FID","INP","LCP","TTFB"],"repository":{"type":"git","url":"git+https://github.com/GoogleChrome/web-vitals.git"},"author":{"name":"Philip Walton","email":"philip@philipwalton.com","url":"http://philipwalton.com"},"bugs":{"url":"https://github.com/GoogleChrome/web-vitals/issues"},"license":"Apache-2.0","readme":"","readmeFilename":""}