-
-
Notifications
You must be signed in to change notification settings - Fork 183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Lighthouse testing #1178
Comments
Could use the PageSpeed Insights API to get Lighthouse scores as well as real-user experience data from CrUX. |
That would be good for production monitoring @rviscomi but I'm more thinking of this Issue as a test in pull requests - to stop any regressions getting into production. |
@sudheendrachari I'm super keen on this so are you still planning on working on this? Hoping we didn't put you off with that drop down change! 😀 |
Haha. Yes, I'm still willing to work on this. Hopefully there should be some progress by next week |
Good stuff - looking forward to it! |
Any more progress here @sudheendrachari ? I had a play myself and came up with this: main...bazzadp:lighthouse-ci-action This fails on assertions or budgets not being met and also uploads reports for viewing. Seems to work quite well. Let me know if you came up with a different approach or have any comments on this approach. |
As mentioned in our Technical Accomplishments page we currently have very good Lighthouse Scores:
I'd like to keep it that way and prevent any regressions as we develop the platform.
Can we add Lighthouse testing, either as part of our
npm run test
command or as a separate continuous integration. Preference would be part ofnpm run test
so can be run offline while developing.Now when running it locally we do lose a few points:
This is because Flask, doesn't gzip responses, doesn't use HTTP/2 and the 127.0.0.1 domain causes some SEO points to be deducted - but that's fine. I think we should still set 90/100/100/85 as performance budgets and alert if anything goes below this, but open to suggestions.
What to test as well? Guessing too slow to test every page, so maybe should pick some key pages (Home Page, and a large chapter like CSS)? We should make it easy to add new pages to the test in case 2020 ends up being different from 2019 pages. Could we also have a "test all pages" option which we could run periodically if we wanted to?
The text was updated successfully, but these errors were encountered: