Skip to main content

In-depth Website Audit Using Google Chrome Inspect (Metrics Defined)


These are the 5 Audits of a web page using Inspect of Google Chrome:
  1. Performance
  2. Progressive Web App
  3. Accessibility
  4. Best Practices
  5. SEO

These are the Performance metrics:
  1. First Contentful Paint - Speed Index shows how quickly the contents of a page are visibly populated.
  2. First Meaningful Paint - First CPU Idle marks the first time at which the page's main thread is quiet enough to handle input.
  3. Speed Index - Interactive marks the time at which the page is fully interactive.
  4. Time to Interactive - Interactive marks the time at which the page is fully interactive.
  5. First CPU Idle -First CPU Idle marks the first time at which the page's main thread is quiet enough to handle input.
  6. Estimated Input Latency - The score above is an estimate of how long your app takes to respond to user input, in milliseconds, during the busiest 5s window of page load. If your latency is higher than 50 ms, users may perceive your app as laggy.

These are Opportunities to speed up your application:
  1. Eliminate render-blocking resources - Resources are blocking the first paint of your page. Consider delivering critical JS/CSS inline and deferring all non-critical JS/styles.
  2. Serve images in next-gen formats - Image formats like JPEG 2000, JPEG XR, and WebP often provide better compression than PNG or JPEG, which means faster downloads and less data consumption.
  3. Text is invisible while webfonts are loading - Leverage the font-display CSS feature to ensure text is user-visible while webfonts are loading.
  4. Has significant main thread work - Consider reducing the time spent parsing, compiling and executing JS. You may find delivering smaller JS payloads helps with this.
  5. JavaScript boot-up time - Consider reducing the time spent parsing, compiling, and executing JS. You may find delivering smaller JS payloads helps with this.
  6. Critical Request Chains - The Critical Request Chains below show you what resources are issued with a high priority. Consider reducing the length of chains, reducing the download size of resources, or deferring the download of unnecessary resources to improve page load.
  7. Properly size images - Serve images that are appropriately-sized to save cellular data and improve load time.
  8. Defer offscreen images - Consider lazy-loading offscreen and hidden images after all critical resources have finished loading to lower time to interactive.
  9. Minify CSS - Minifying CSS files can reduce network payload sizes.
  10. Minify JavaScript - Minifying JavaScript files can reduce payload sizes and script parse time.
  11. Defer unused CSS - Remove unused rules from stylesheets to reduce unnecessary bytes consumed by network activity.
  12. Efficiently encode images - Optimized images load faster and consume less cellular data.
  13. Enable text compression - Text-based responses should be served with compression (gzip, deflate or brotli) to minimize total network bytes.
  14. Avoid multiple, costly round trips to any origin - Consider adding preconnect or dns-prefetch resource hints to establish early connections to important third-party origins.
  15. Keep server response times low (TTFB) - Time To First Byte identifies the time at which your server sends a response.
  16. Avoid multiple page redirects - Redirects introduce additional delays before the page can be loaded.
  17. Preload key requests - Consider using <link rel=preload> to prioritize fetching late-discovered resources sooner.
  18. Use video formats for animated content - Large GIFs are inefficient for delivering animated content. Consider using MPEG4/WebM videos for animations and PNG/WebP for static images instead of GIF to save network bytes.
  19. Avoids enormous network payloads - Large network payloads cost users real money and are highly correlated with long load times.
  20. Uses efficient cache policy on static assets - A long cache lifetime can speed up repeat visits to your page.
  21. Avoids an excessive DOM size - 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.
  22. User Timing marks and measures - Consider instrumenting your app with the User Timing API to create custom, real-world measurements of key user experiences.

These checks validate the aspects of a Progressive Web App, as specified by the baseline PWA Checklist:
  1. Does not respond 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.
  2. User will not be prompted to Install the Web App (Site should register a service worker.) - Browsers can proactively prompt users to add your app to their homescreen, which can lead to higher engagement.
  3. Does not register 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.
  4. Is not configured for a custom splash screen - A themed splash screen ensures a high-quality experience when users launch your app from their homescreens.
  5. Address bar does not match brand colors (`<meta name="theme-color">` tag should be found.) - The browser address bar can be themed to match your site.
  6. Site works cross-browser - To reach the most number of users, sites should work across every major browser.
  7. 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.
  8. 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.
  9. Page load is fast enough on 3G - A fast page load over a 3G network ensures a good mobile user experience.
  10. 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.
  11. Redirects HTTP traffic to HTTPS - If you've already set up HTTPS, make sure that you redirect all HTTP traffic to HTTPS.
  12. Has a <meta name="viewport"> tag with width or initial-scale - Add a viewport meta tag to optimize your app for mobile screens.
  13. 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.
  14. 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.

These will improve the Accessibility of your web app:
  1. Color Contrast Is Satisfactory - These are opportunities to improve the legibility of your content.

    Background and foreground colors do not have a sufficient contrast ratio. - Low-contrast text is difficult or impossible for many users to read.
  2. Elements Are Well Structured - These are opportunities to make sure your HTML is appropriately structured.

    [id] attributes on the page are not unique - The value of an id attribute must be unique to prevent other instances from being overlooked by assistive technologies.
  3. Meta Tags Used Properly - These are opportunities to improve the user experience of your site.

    [user-scalable="no"] is used in the <meta name="viewport"> element or the [maximum-scale] attribute is 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.
  4. The page has a logical tab order - Tabbing through the page follows the visual layout. Users cannot focus elements that are offscreen.
  5. Interactive controls are keyboard focusable - Custom interactive controls are keyboard focusable and display a focus indicator.
  6. The user's focus is directed to new content added to the page - If new content, such as a dialog, is added to the page, the user's focus is directed to it.
  7. User focus is not accidentally trapped in a region - A user can tab into and out of any control or region without accidentally trapping their focus.
  8. Custom controls have associated labels - Custom interactive controls have associated labels, provided by aria-label or aria-labelledby
  9. Custom controls have ARIA roles - Custom interactive controls have appropriate ARIA roles.
  10. Visual order on the page follows DOM order - DOM order matches the visual order, improving navigation for assistive technology.
  11. Offscreen content is hidden from assistive technology - Offscreen content is hidden with display: none or aria-hidden=true.
  12. Headings don't skip levels - Headings are used to create an outline for the page and heading levels are not skipped.
  13. HTML5 landmark elements are used to improve navigation - Landmark elements (<main>, <nav>, etc.) are used to improve the keyboard navigation of the page for assistive technology.
  14. Elements Use Attributes Correctly - These are opportunities to improve the configuration of your HTML elements.

    Image elements have [alt] attributes - Informative elements should aim for short, descriptive alternate text. Decorative elements can be ignored with an empty alt attribute.
  15. ARIA Attributes Follow Best Practices - These are opportunities to improve the usage of ARIA in your application which may enhance the experience for users of assistive technology, like a screen reader.

    [role]s have all required [aria-*] attributes - Some ARIA roles have required attributes that describe the state of the element to screen readers.

    Elements with [role] that require specific children [role]s, are present - Some ARIA parent roles must contain specific child roles to perform their intended accessibility functions.

    [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.

    [role] values are valid - ARIA roles must have valid values in order to perform their intended accessibility functions.
  16. Elements Have Discernible Names - These are opportunities to improve the semantics of the controls in your application. This may enhance the experience for users of assistive technology, like a screen reader.

    Links do not have a discernible 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.

    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.
  17. Elements Describe Contents Well - These are opportunities to make your content easier to understand for a user of assistive technology, like a screen reader.

    Form elements do not have associated labels - Labels ensure that form controls are announced properly by assistive technologies, like screen readers.

    The page contains a heading, skip link, or landmark region - Adding ways to bypass repetitive content lets keyboard users navigate the page more efficiently.

    Document has a <title> element - The title gives screen reader users an overview of the page, and search engine users rely on it heavily to determine if a page is relevant to their search.
  18. Elements Are Well Structured - These are opportunities to make sure your HTML is appropriately structured.

    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.

    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.
  19. Page Specifies Valid Language - These are opportunities to improve the interpretation of your content by users in different locales.

    <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.

    <html> element has a valid value for its [lang] attribute - Specifying a valid BCP 47 language helps screen readers announce text properly.

Best Practices:
  1. Does not use passive listeners to improve scrolling performance - Consider marking your touch and wheel event listeners as `passive` to improve your page's scroll performance.
  2. Links to cross-origin destinations are unsafe - Add `rel="noopener"` or `rel="noreferrer"` to any external links to improve performance and prevent security vulnerabilities.
  3. Includes front-end JavaScript libraries with known security vulnerabilities - Some third-party scripts may contain known security vulnerabilities that are easily identified and exploited by attackers.
  4. Avoids Application Cache - Application Cache is deprecated.
  5. Avoids WebSQL DB - Web SQL is deprecated. Consider using IndexedDB instead.
  6. Uses HTTPS
  7. Uses HTTP/2 for its own resources - HTTP/2 offers many benefits over HTTP/1.1, including binary headers, multiplexing, and server push.
  8. Avoids document.write() - For users on slow connections, external scripts dynamically injected via `document.write()` can delay page load by tens of seconds.
  9. 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.
  10. Page has the HTML doctype - Specifying a doctype prevents the browser from switching to quirks-mode.
  11. 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.
  12. Avoids deprecated APIs - Deprecated APIs will eventually be removed from the browser.
  13. Allows users to paste into password fields - Preventing password pasting undermines good security policy.
  14. No browser errors logged to the console - Errors logged to the console indicate unresolved problems. They can come from network request failures and other browser concerns.
  15. Displays images with correct aspect ratio - Image display dimensions should match natural aspect ratio.
  16. Links to cross-origin destinations are safe - Add `rel="noopener"` or `rel="noreferrer"` to any external links to improve performance and prevent security vulnerabilities.

SEO - These checks ensure that your page is optimized for search engine results ranking:
  1. Page is mobile friendly - Take the Mobile-Friendly Test to check for audits not covered by Lighthouse, like sizing tap targets appropriately.
  2. Structured data is valid - Run the Structured Data Testing Tool and the Structured Data Linter to validate structured data.
  3. Mobile Friendly - Make sure your pages are mobile friendly so users don’t have to pinch or zoom in order to read the content pages.
  4. Content Best Practices - Format your HTML in a way that enables crawlers to better understand your app’s content.
  5. Crawling and Indexing - To appear in search results, crawlers need access to your app.

Mobile Friendly metrics - Make sure your pages are mobile friendly so users don’t have to pinch or zoom in order to read the content pages.:
  1. Has a <meta name="viewport"> tag with width or initial-scale - Add a viewport meta tag to optimize your app for mobile screens.
  2. Document uses legible font sizes - Font sizes less than 12px are too small to be legible and require mobile visitors to “pinch to zoom” in order to read. Strive to have >60% of page text ≥12px.

Content Best Practices:
  1. Document has a <title> element - The title gives screen reader users an overview of the page, and search engine users rely on it heavily to determine if a page is relevant to their search.
  2. Document has a meta description - Meta descriptions may be included in search results to concisely summarize page content.
  3. Links have descriptive text - Descriptive link text helps search engines understand your content.
  4. Document has a valid hreflang - hreflang links tell search engines what version of a page they should list in search results for a given language or region.
  5. Document has a valid rel=canonical - Canonical links suggest which URL to show in search results.
  6. Document avoids plugins - Search engines can't index plugin content, and many devices restrict plugins or don't support them.

Crawling and Indexing:
  1. Page has successful HTTP status code - Pages with unsuccessful HTTP status codes may not be indexed properly.
  2. Page isn’t blocked from indexing - Search engines are unable to include your pages in search results if they don't have permission to crawl them.
  3. robots.txt is valid - If your robots.txt file is malformed, crawlers may not be able to understand how you want your website to be crawled or indexed.

Read more from here:
https://developers.google.com/web/tools/lighthouse/

Comments