I'm considering whether to integrate performance testing into my deployment pipeline. I've discovered that PageSpeed provides an API that can be used to gauge performance, and it seems fairly straightforward to implement. My thought is not to make this a constant requirement but rather to include it in specific situations, like when pushing to the main branch, after a set number of pushes, or when creating a separate command for pushes that triggers the test based on a flag. I particularly like the idea of only running the test when I update a specific frontend branch. If performance metrics don't meet a certain score, I'd like the push to fail. Even though many developers might not prioritize performance and SEO after a certain point, I want to make sure I keep these factors in mind, especially since I'm newer to professional web development. Have others found this approach useful? Would it make sense to pursue?
4 Answers
Honestly, I wouldn't make the push fail outright. Instead, it'd be better to get notified, like via email, with the scores. Performance can be inconsistent sometimes, and you want to make sure you're not rejecting valid pushes over temporary issues.
Just a quick note—I'm thinking of rolling out the PageGym API soon. If you're interested, I'd be happy to provide early access before it's available publicly! It's designed to offer more accurate insights compared to PSI, along with more detailed reports.
I’m in too, please keep me updated!
I've never used PageSpeed's API, but I highly recommend checking out the web-vitals package. It's perfect for logging performance and you could even automate it with GitHub Actions. Running it for all PRs could be a great strategy. Maybe consider marking it with a label so it doesn't run repetitively on the same PR.
Absolutely! Focusing on performance for certain key branches is a smart move. You don’t need to test everything, but targeting main branches will help maintain quality.
That sounds awesome! I'd love to get access to the API when you're ready!