Lighthouse Optimization

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.

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.

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.

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

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

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.

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

Do those work with localhost somehow?

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?

Done.

Done.

Ok, thanks :+1:

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.

1 Like

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

I think that’s pretty much it :slight_smile:

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.