{"id":17514,"date":"2023-02-17T13:25:13","date_gmt":"2023-02-17T13:25:13","guid":{"rendered":"https:\/\/www.searchenginejournal.com\/chrome-lighthouse-10-new-audits\/479813\/"},"modified":"2023-02-17T13:25:13","modified_gmt":"2023-02-17T13:25:13","slug":"google-chrome-lighthouse-10-contains-two-new-audits-via-sejournal-martinibuster","status":"publish","type":"post","link":"https:\/\/marketingnewsbox.com\/?p=17514","title":{"rendered":"Google Chrome Lighthouse 10 Contains Two New Audits via @sejournal, @martinibuster"},"content":{"rendered":"
<\/div>\n

The newly released Lighthouse 10, the technology underlying PageSpeed Insights and Chrome DevTools, introduces two new site audits. These audits should be useful as part of audit because they pertain to site security and user experience factors.<\/p>\n

Technically, one of the audits is an expansion of a previous audit, but it\u2019s essentially a new audit.<\/p>\n

Lighthouse contains several kinds of audits, including, Accessibility Audits, Best Practices Audits, Performance Audits, Progressive Web Apps Audits and an SEO Audit.<\/p>\n

These two new audits are from two different audits within Lighthouse. One is a part of the Best Practices audit<\/a> and the other is from the Performance audits<\/a> category.<\/p>\n

New Back\/forward Cache Audit<\/h2>\n

Something that isn\u2019t ordinarily thought of is that Back\/forward cache, also known as bfcache.<\/p>\n

bfcache is a cache that is enabled with optimization that allows webpages to instantly load when a user navigates back or forward within a website.<\/p>\n

Websites without bfcache enabled force site visitors to download webpages a second time when they navigate backwards and forwards within a website.<\/p>\n

But with bfcache enabled the same site visitors experience instant loading.<\/p>\n

Google\u2019s developer page about bfcache explains it like this:<\/strong><\/p>\n

\n

\u201cThe back\/forward cache (bfcache) stores a snapshot of the page in memory for when the page is restored from the navigation history.<\/p>\n

This significantly speeds up return navigations to the page, however some browser APIs (e.g. unload listeners) can cause the bfcache to fail and the page will be loaded normally.\u201d<\/p>\n<\/blockquote>\n

There are best-practices to ensure that pages are eligible to be stored in the bfcache.<\/p>\n

The first optimization is to never use the unload event.<\/p>\n

According to Web.dev:<\/strong><\/p>\n

\n

\u201cThe unload event is problematic for browsers because it predates bfcache and many pages on the internet operate under the (reasonable) assumption that a page will not continue to exist after the unload event has fired.<\/p>\n

This presents a challenge because many of those pages were also built with the assumption that the unload event would fire any time a user is navigating away, which is no longer true (and hasn\u2019t been true for a long time).\u201d<\/p>\n<\/blockquote>\n

The Mozilla developer webpage<\/a> for the unload event also advises against it:<\/p>\n

\n

\u201cWarning: Developers should avoid using this event.\u201d<\/p>\n<\/blockquote>\n

Lighthouse 10 now has an audit for bfcache.<\/p>\n

The way it works is that it navigates away from the webpage being tested and then returns to it.<\/p>\n

Any problems with the ability to use the bfcache are called attention to by the bfcache audit.<\/p>\n

There are three types of failures:<\/strong><\/p>\n

    \n
  1. Actionable
    Issues that can be fixed.<\/li>\n
  2. Pending Support
    Features that are not yet supported by Chrome prevent the browser from caching the webpage.<\/li>\n
  3. Not Actionable
    These are issues that are outside of the page itself that cannot be controlled or fixed.<\/li>\n<\/ol>\n

    Read for more information: Chrome developer page about the bfcache:<\/strong>
    Ensure the page can be restored from the back\/forward cache<\/a><\/p>\n

    Expansion of Paste Into Passwords Field Audit<\/h2>\n

    Allowing users to paste passwords into a password form field is a security improvement.<\/p>\n

    Disabling the ability to paste passwords prevents site visitors from using password managers that employ strong passwords.<\/p>\n

    Previous versions of Lighthouse that tested for this best practice related to pasting into form fields were limited to only testing the password field.<\/p>\n

    Lighthouse 10 improves this audit by expanding to test if pasting into any (non-readonly) input field works.<\/p>\n

    Google\u2019s announcement of this new audit explains why it\u2019s important:<\/p>\n

    \n

    \u201cFor most sites, preventing pasting is a net-negative user experience and prevents legitimate safety and accessibility workflows.\u201d<\/p>\n<\/blockquote>\n

    A \u201creadonly\u201d input field is a form field that contains a default entry pre-filled.<\/p>\n

    All other input fields should allow pasting because it is useful for accessibility, user experience and improving security.<\/p>\n

    Google\u2019s developer troubleshooting page for this audit type<\/a> offers this advice for fixing this problem:<\/p>\n

    \n

    \u201cHow to enable pasting into password fields<\/h3>\n

    #Find the code that\u2019s preventing pasting<\/strong>
    To quickly find and inspect the code that\u2019s preventing pasting:<\/p>\n<\/blockquote>\n