Lighthouse Optimization

[orballo]

We have to cover five main categories in Lighthouse (here you can see how they are measured in v3, but I’m not sure if it’s 100% accurate, because the current version of Lighthouse is already 4.1).

Performance

There are 5 metrics that score in this category:

• Time To Interactive (5)
  Mesures three things: first contentful paint, event handlers are registered for most visible elements and user interactions get a response in less than 50ms.

• Speed Index (4)
  Mesures how quickly the content of a page is populated.

• First Contentful Paint (3)
  Measures the time from navigation to the time when the browser renders the first bit of content from the DOM.

• First CPU Idle (2)
  Is a more vague version of Time To Interactive.

• First Meaningful Paint (1)
  This audit identifies the time at which the user feels that the primary content of the page is visible.

What we can do for all of this metrics is basically the same: code splitting, tree shaking, compressing resources (maybe using brotli, with 85% support), caching resources, avoid unnecessary requests and avoid synchronous requests.

It shouldn’t be that difficult now that we’ll have full control on what is used and we’ll mesure only the framework without 3rd party libraries.

Progressive Web App

There are 11 checks, all of them with the same weight.

• Register A Service Worker

• Responds With a 200 When Offline

• Contains Some Content When JS Is Not Available
  This audit performs a simple check to ensure that your page isn’t blank when JS is disabled.
  In these cases we could serve the SSR with local links. It would offer sufficient navigation functionality.

• Uses HTTPS

• Redirects HTTP Traffic To HTTPS

• Page Load Is Fast Enough On Mobile
  If the time to interactive is less than 10s on a slow 4G, the audit passes.

• User Can Be Prompted To Install The Web App
  Different browsers have different criteria for the banner to prompt.

• Configured For A Custom Splash Screen
  This will be done in the manifest.json file.

• Has A Viewport Meta Tag With width Or initial-scale

• Content Sized Correctly for Viewport
  Checks that the width of the content on your page is equal to the width of the viewport.

• Address Bar Matches Brand Colors
  The audit passes if Lighthouse finds a theme-color meta tag in the page’s HTML and a theme_color property in manifest.json.

• The short_name won’t be truncated on the homescreen

Accessibility

There are too many cases to cover here, I think we should just go with eslint-plugin-jsx-a11y and then check Lighthouse to see what we are missing.

I also think most of these checks will be something that theme developers will need to take care of, and not something that we at the framework level will need to pay special attention.

Best Practices

There are 16 checks in this category, some of them as generic as Avoids front-end JavaScript libraries with known security vulnerabilities, so again I think there is no strategy here, we should just run Lighthouse and fix them one by one.

SEO

There are 10 checks in this category.

• Document Does Not Have A Meta Description

• Document Doesn’t Have A Title Element

• Document doesn’t have a valid hreflang
  If you serve different content based on a user’s language or region, use hreflang links to ensure that search engines serve the correct content for that language or region.

• Document doesn’t have a valid rel=canonical

• Document Doesn’t Use Legible Font Sizes
  Aim to have a font size of at least 12px on at least 60% of the text on your pages.

• Document uses plugins

• Links Do Not Have Descriptive Text

• Page has unsuccessful HTTP status code
  Ensure that your server returns a 2XX or 3XX HTTP status code.

• Page Is Blocked From Indexing

• robots.txt is not valid

Ways To Integrate Lighthouse in Frontity (or in Frontity’s workflow)

I don’t know what is the better way to achieve this, but we have at our disposal Lighthouse Node CLI.

I think this could be integrated with Github + Travis (video) or maybe it could also be included as a tool in our Frontity Admin board.

This way we could show a history of audits and the developer could easily check if what he is doing is working or not. This could be just a bunch of .json files saved in the repo, I guess, that we then render on the admin board.

There are some tools around the Node CLI that may come in handy like: webpack-lighthouse-plugin, lighthouse-gh-reporter…

There is also a video talking about the Lighthouse REST API but I think they are still in private beta, because I couldn’t find any docs about it.

[orballo]

@luisherranz @David let me know if there is something else you would like to see included here, or any thought about what I wrote.

[luisherranz]

I think we should just go with eslint-plugin-jsx-a11y and then check Lighthouse to see what we are missing.

Ok, we should add that in Eslint / Prettier - What presets should we use? then.

[luisherranz]

it could also be included as a tool in our Frontity Admin board

Wow, I love that. Could you add it to The Frontity Admin?

Edit: I mean that we should allow developers to check their Lighthouse score in the Admin.

[luisherranz]

There is also a video talking about the Lighthouse REST API but I think they are still in private beta, because I couldn’t find any docs about it.

I’ve used and it works great but you need a deploy url, it doesn’t work with localhost. It’s called pagespeed insights API or something like that, not lighthouse:
https://developers.google.com/speed/docs/insights/v5/get-started

There are some tools around the Node CLI that may come in handy like: webpack-lighthouse-plugin , lighthouse-gh-reporter…

Do those work with localhost somehow?

[luisherranz]

My takeaways from your post are that we should keep doing mostly the same but:

• Make tree shaking work
• Integrate with the WP PWA plugin for the service worker and manifest
• Use the service worker to make it work offline
• Reduce the Kbs we use at maximum
• Use esModules to reduce the Kbs even more
• Review all the Document stuff for SEO
• Add the eslint-jsx-a11y plugin
• Return a valid robots.txt

Things that don’t depend on us:

• Compressing resources
  I think we shouldn’t add compression as this is usually done by the server (Nginx, CDN…).
• Uses HTTPS & Redirects HTTP Traffic To HTTPS
  Same reason than compression

@orballo do I miss something?

[orballo]

Ok, we should add that in Eslint / Prettier - What presets should we use? then.

Done.

Could you add it to The Frontity Admin?

Done.

I’ve used and it works great but you need a deploy url, it doesn’t work with localhost.

Ok, thanks

Do those work with localhost somehow?

So… I think everything should work in localhost, as well as in Travis, as far as we use --headless Chrome and there is a Chrome installed. In this aspect Lighthouse and Puppeteer behave the same way: both are a layer over a Headless Chrome and the Chrome DevTools API.

[luisherranz]

I think everything should work in localhost

So we can make it work with the Admin, amazing!

[orballo]

do I miss something?

I think that’s pretty much it

[luisherranz]

I’ve found a library to test accessibility. Not JSX (like react-a11y) but the final HTML.

Test your React application with the axe-core accessibility testing library. Results will show in the Chrome DevTools console.

dequelabs/react-axe