100
Progressive Web App
99
Performance
100
Accessibility
100
Best Practices
100
Progressive Web App
These audits validate the aspects of a Progressive Web App, as specified by the baseline PWA Checklist.
View 11 passed items
100
Registers a Service Worker
The service worker is the technology that enables your app to use many Progressive Web App features, such as offline, add to homescreen, and push notifications. Learn more.
100
Responds with a 200 when offline
If you're building a Progressive Web App, consider using a service worker so that your app can work offline. Learn more.
100
Contains some content when JavaScript is not available
Your app should display some content when JavaScript is disabled, even if it's just a warning to the user that JavaScript is required to use the app. Learn more.
100
Uses HTTPS
All sites should be protected with HTTPS, even ones that don't handle sensitive data. HTTPS prevents intruders from tampering with or passively listening in on the communications between your app and your users, and is a prerequisite for HTTP/2 and many new web platform APIs. Learn more.
100
Redirects HTTP traffic to HTTPS
If you've already set up HTTPS, make sure that you redirect all HTTP traffic to HTTPS. Learn more.
100
Page load is fast enough on 3G
Satisfied if First Interactive is less than 10 seconds, as defined by the PWA Baseline Checklist. Network throttling is required (specifically: RTT latencies >= 150 RTT are expected).
100
User can be prompted to Install the Web App
While users can manually add your site to their homescreen, the prompt (aka app install banner) will proactively prompt the user to install the app if the various requirements are met and the user has moderate engagement with your site.
100
Configured for a custom splash screen
A default splash screen will be constructed for your app, but satisfying these requirements guarantee a high-quality splash screen that transitions the user from tapping the home screen icon to your app's first paint
100
Address bar matches brand colors
The browser address bar can be themed to match your site. A `theme-color` meta tag will upgrade the address bar when a user browses the site, and the manifest theme-color will apply the same theme site-wide once it's been added to homescreen.
100
Has a <meta name="viewport"> tag with width or initial-scale
Add a viewport meta tag to optimize your app for mobile screens. Learn more.
100
Content is sized correctly for the viewport
If the width of your app's content doesn't match the width of the viewport, your app might not be optimized for mobile screens. Learn more.
Manual checks to verify
These audits are required by the baseline PWA Checklist but are not automatically checked by Lighthouse. They do not affect your score but it's important that you verify them manually.
0
Site works cross-browser
To reach the most number of users, sites should work across every major browser. Learn more.
0
Page transitions don't feel like they block on the network
Transitions should feel snappy as you tap around, even on a slow network, a key to perceived performance. Learn more.
0
Each page has a URL
Ensure individual pages are deep linkable via the URLs and that URLs are unique for the purpose of shareability on social media. Learn more.
99
Performance
These encapsulate your app's performance.
Metrics
These metrics encapsulate your app's performance across a number of dimensions.
194 ms
Screenshot at 194 ms
389 ms
Screenshot at 389 ms
583 ms
Screenshot at 583 ms
778 ms
Screenshot at 778 ms
972 ms
Screenshot at 972 ms
1.2 s
Screenshot at 1.2 s
1.4 s
Screenshot at 1.4 s
1.6 s
Screenshot at 1.6 s
1.8 s
Screenshot at 1.8 s
1.9 s
Screenshot at 1.9 s
First meaningful paint890 ms
First meaningful paint measures when the primary content of a page is visible. Learn more.
First Interactive (beta)1,940 ms
The first point at which necessary scripts of the page have loaded and the CPU is idle enough to handle most user input.
Consistently Interactive (beta)1,940 ms
The point at which most network resources have finished loading and the CPU is idle for a prolonged period.
97
Perceptual Speed Index: 1402 (target: < 1,250)
Speed Index shows how quickly the contents of a page are visibly populated. Learn more.
100
Estimated Input Latency: 16 ms (target: < 50 ms)
The score above is an estimate of how long your app takes to respond to user input, in milliseconds. There is a 90% probability that a user encounters this amount of latency, or less. 10% of the time a user can expect additional latency. If your score is higher than Lighthouse's target score, users may perceive your app as laggy. Learn more.
Diagnostics
More information about the performance of your application.
0
Critical Request Chains: 5
The Critical Request Chains below show you what resources are required for first render of this page. Improve page load by reducing the length of chains, reducing the download size of resources, or deferring the download of unnecessary resources. Learn more.
Longest chain: 1,822.3ms over 2 requests, totalling 89.21KB
View critical network waterfall:
Initial Navigation
/top (hackernews-ecvrcpossc.now.sh)
/_nuxt/manifest.01641f9….js (hackernews-ecvrcpossc.now.sh) - 580.6ms, 89.21KB
/_nuxt/vendor.bundle.8446899….js (hackernews-ecvrcpossc.now.sh) - 1,184ms, 89.21KB
/_nuxt/nuxt.bundle.32a9bf0….js (hackernews-ecvrcpossc.now.sh) - 730.1ms, 89.21KB
/_nuxt/6.nuxt.bundle.bb1d4c5….js (hackernews-ecvrcpossc.now.sh) - 634.9ms, 89.21KB
/_nuxt/0.nuxt.bundle.5f83ba5….js (hackernews-ecvrcpossc.now.sh) - 642.4ms, 89.21KB
View 10 passed items
100
Reduce render-blocking stylesheets
Link elements are blocking the first paint of your page. Consider inlining critical links and deferring non-critical ones. Learn more.
100
Reduce render-blocking scripts
Script elements are blocking the first paint of your page. Consider inlining critical scripts and deferring non-critical ones. Learn more.
100
Properly size images
Serve images that are appropriately-sized to save cellular data and improve load time. Learn more.
100
Offscreen images
Consider lazy-loading offscreen images to improve page load speed and time to interactive. Learn more.
100
Optimize images
Optimized images take less time to download and save cellular data. The identified images could have smaller file sizes when compressed as JPEG (q=85). Learn more about image optimization.
100
Serve images as WebP
WebP images take less time to download and save cellular data. Learn more about image optimization.
100
Enable text compression
Text-based responses should be served with compression (gzip, deflate or brotli) to minimize total network bytes. Learn more.
100
Avoids enormous network payloads: Total size was 133 KB (target: < 1,600 KB)
Network transfer size costs users real money and is highly correlated with long load times. Try to find ways to reduce the size of required files.
View Details
URL
Total Size
Transfer Time
/_nuxt/vendor.bundle.8446899….js
89 KB
460ms
/top
12 KB
60ms
/_nuxt/nuxt.bundle.32a9bf0….js
10 KB
50ms
/_nuxt/5.nuxt.bundle.bf702aa….js
3 KB
20ms
/_nuxt/0.nuxt.bundle.5f83ba5….js
3 KB
10ms
/_nuxt/4.nuxt.bundle.dcb8917….js
3 KB
10ms
/_nuxt/3.nuxt.bundle.0dc4144….js
3 KB
10ms
/_nuxt/2.nuxt.bundle.f3d2867….js
3 KB
10ms
/_nuxt/1.nuxt.bundle.569def4….js
3 KB
10ms
/_nuxt/6.nuxt.bundle.bb1d4c5….js
2 KB
10ms
100
Avoids an excessive DOM size: 303 nodes (target: < 1,500 nodes)
Browser engineers recommend pages contain fewer than ~1,500 DOM nodes. The sweet spot is a tree depth < 32 elements and fewer than 60 children/parent element. A large DOM can increase memory usage, cause longer style calculations, and produce costly layout reflows. Learn more.
View details
Total DOM Nodes
303
target: < 1,500 nodes
DOM Depth
11
target: < 32
Maximum Children
31
target: < 60 nodes
100
User Timing marks and measures: 0
Consider instrumenting your app with the User Timing API to create custom, real-world measurements of key user experiences. Learn more.
100
Accessibility
These checks highlight opportunities to improve the accessibility of your app.
View 8 passed items
Elements Use Attributes Correctly
Screen readers and other assistive technologies require annotations to understand otherwise ambiguous content.
100
[accesskey] values are unique.
Access keys let users quickly focus a part of the page. For proper navigation, each access key must be unique. Learn more.
100
<audio> elements contain a <track> element with [kind="captions"].
Captions make audio elements usable for deaf or hearing-impaired users, providing critical information such as who is talking, what they're saying, and other non-speech information. Learn more.
100
Image elements have [alt] attributes.
Informative elements should aim for short, descriptive alternate text. Decorative elements can be ignored with an empty alt attribute.Learn more.
100
<input type="image"> elements have [alt] text.
When an image is being used as an `<input>` button, providing alternative text can help screen reader users understand the purpose of the button. Learn more.
100
No element has a [tabindex] value greater than 0.
A value greater than 0 implies an explicit navigation ordering. Although technically valid, this often creates frustrating experiences for users who rely on assistive technologies. Learn more.
100
Cells in a <table> element that use the [headers] attribute only refer to other cells of that same table.
Screen readers have features to make navigating tables easier. Ensuring `<td>` cells using the `headers]` attribute only refer to other cells in the same table may improve the experience for screen reader users. [Learn more.
100
<th> elements and elements with [role="columnheader"/"rowheader"] have data cells they describe.
Screen readers have features to make navigating tables easier. Ensuring table headers always refer to some set of cells may improve the experience for screen reader users. Learn more.
ARIA Attributes Follow Best Practices
Screen readers and other assistive technologies require annotations to understand otherwise ambiguous content.
100
[aria-*] attributes match their roles.
Each ARIA `role` supports a specific subset of `aria-*` attributes. Mismatching these invalidates the `aria-*` attributes. Learn more.
100
[role]s have all required [aria-*] attributes.
Some ARIA roles have required attributes that describe the state of the element to screen readers. Learn more.
100
[role]s that require child [role]s contain them.
Some ARIA parent roles must contain specific child roles to perform their intended accessibility functions. Learn more.
100
[role]s are contained by their required parent element.
Some ARIA child roles must be contained by specific parent roles to properly perform their intended accessibility functions. Learn more.
100
[role] values are valid.
ARIA roles must have valid values in order to perform their intended accessibility functions. Learn more.
100
[aria-*] attributes have valid values.
Assistive technologies, like screen readers, can't interpret ARIA attributes with invalid values. Learn more.
100
[aria-*] attributes are valid and not misspelled.
Assistive technologies, like screen readers, can't interpret ARIA attributes with invalid names. Learn more.
Elements Have Discernable Names
Screen readers and other assistive technologies require annotations to understand otherwise ambiguous content.
100
Buttons have an accessible name.
When a button doesn't have an accessible name, screen readers announce it as "button", making it unusable for users who rely on screen readers. Learn more.
100
Links have a discernable name.
Link text (and alternate text for images, when used as links) that is discernible, unique, and focusable improves the navigation experience for screen reader users. Learn more.
Elements Describe Contents Well
Screen readers and other assistive technologies require annotations to understand otherwise ambiguous content.
100
The page contains a heading, skip link, or landmark region.
Adding ways to bypass repetitive content lets keyboard users navigate the page more efficiently. Learn more.
100
Document has a <title> element.
Screen reader users use page titles to get an overview of the contents of the page. Learn more.
100
<frame> or <iframe> elements have a title.
Screen reader users rely on frame titles to describe the contents of frames. Learn more.
100
Form elements have associated labels.
Labels ensure that form controls are announced properly by assistive technologies, like screen readers. Learn more.
100
Presentational <table> elements avoid using <th>, <caption> or the [summary] attribute.
A table being used for layout purposes should not include data elements, such as the th or caption elements or the summary attribute, because this can create a confusing experience for screen reader users. Learn more.
100
<object> elements have [alt] text.
Screen readers cannot translate non-text content. Adding alt text to `<object>` elements helps screen readers convey meaning to users. Learn more.
100
<video> elements contain a <track> element with [kind="captions"].
When a video provides a caption it is easier for deaf and hearing impaired users to access its information. Learn more.
100
<video> elements contain a <track> element with [kind="description"].
Audio descriptions provide relevant information for videos that dialogue cannot, such as facial expressions and scenes. Learn more.
Color Contrast Is Satisfactory
Screen readers and other assistive technologies require annotations to understand otherwise ambiguous content.
100
Background and foreground colors have a sufficient contrast ratio.
Low-contrast text is difficult or impossible for many users to read. Learn more.
Elements Are Well Structured
Screen readers and other assistive technologies require annotations to understand otherwise ambiguous content.
100
<dl>'s contain only properly-ordered <dt> and <dd> groups, <script> or <template> elements.
When definition lists are not properly marked up, screen readers may produce confusing or inaccurate output. Learn more.
100
Definition list items are wrapped in <dl> elements.
Definition list items (`<dt>` and `<dd>`) must be wrapped in a parent `<dl>` element to ensure that screen readers can properly announce them. Learn more.
100
[id] attributes on the page are unique.
The value of an id attribute must be unique to prevent other instances from being overlooked by assistive technologies. Learn more.
100
Lists contain only <li> elements and script supporting elements (<script> and <template>).
Screen readers have a specific way of announcing lists. Ensuring proper list structure aids screen reader output. Learn more.
100
List items (<li>) are contained within <ul> or <ol> parent elements.
Screen readers require list items (`<li>`) to be contained within a parent `<ul>` or `<ol>` to be announced properly. Learn more.
Page Specifies Valid Language
Screen readers and other assistive technologies require annotations to understand otherwise ambiguous content.
100
<html> element has a [lang] attribute.
If a page doesn't specify a lang attribute, a screen reader assumes that the page is in the default language that the user chose when setting up the screen reader. If the page isn't actually in the default language, then the screen reader might not announce the page's text correctly. Learn more.
100
<html> element has a valid value for its [lang] attribute.
Specifying a valid BCP 47 language helps screen readers announce text properly. Learn more.
100
[lang] attributes have a valid value.
Specifying a valid BCP 47 language on elements helps ensure that text is pronounced correctly by a screen reader. Learn more.
Meta Tags Used Properly
Screen readers and other assistive technologies require annotations to understand otherwise ambiguous content.
100
The document does not use <meta http-equiv="refresh">.
Users do not expect a page to refresh automatically, and doing so will move focus back to the top of the page. This may create a frustrating or confusing experience. Learn more.
100
[user-scalable="no"] is not used in the <meta name="viewport"> element and the [maximum-scale] attribute is not less than 5.
Disabling zooming is problematic for users with low vision who rely on screen magnification to properly see the contents of a web page. Learn more.
100
Best Practices
We've compiled some recommendations for modernizing your web app and avoiding performance pitfalls. These audits do not affect your score but are worth a look.
View 13 passed items
100
Avoids Application Cache
Application Cache has been deprecated by Service Workers. Consider implementing an offline solution using the Cache Storage API.
100
Avoids WebSQL DB
Web SQL is deprecated. Consider using IndexedDB instead. Learn more.
100
Uses HTTPS
All sites should be protected with HTTPS, even ones that don't handle sensitive data. HTTPS prevents intruders from tampering with or passively listening in on the communications between your app and your users, and is a prerequisite for HTTP/2 and many new web platform APIs. Learn more.
100
Uses HTTP/2 for its own resources
HTTP/2 offers many benefits over HTTP/1.1, including binary headers, multiplexing, and server push. Learn more.
100
Uses passive listeners to improve scrolling performance
Consider marking your touch and wheel event listeners as `passive` to improve your page's scroll performance. Learn more.
100
Avoids Mutation Events in its own scripts
Mutation Events are deprecated and harm performance. Consider using Mutation Observers instead. Learn more.
100
Avoids document.write()
For users on slow connections, external scripts dynamically injected via `document.write()` can delay page load by tens of seconds. Learn more.
100
Opens external anchors using rel="noopener"
Open new tabs using `rel="noopener"` to improve performance and prevent security vulnerabilities. Learn more.
100
Avoids requesting the geolocation permission on page load
Users are mistrustful of or confused by sites that request their location without context. Consider tying the request to user gestures instead. Learn more.
100
Avoids requesting the notification permission on page load
Users are mistrustful of or confused by sites that request to send notifications without context. Consider tying the request to user gestures instead. Learn more.
100
Avoids deprecated APIs
Deprecated APIs will eventually be removed from the browser. Learn more.
100
Manifest's short_name won't be truncated when displayed on homescreen
Make your app's `short_name` less than 12 characters to ensure that it's not truncated on homescreens. Learn more.
100
Allows to paste into password input fields