The nature of "common anti-patterns" is hopefully that with some time passing, the list of anti-patterns is not useful as they would not be common and no longer something anyone considers. However, it's still useful I think to maintain advice we often give on a central page for easy reference.
Both for outselves (so that we can elaborate and reference/re-use this advice), but also for others to consider during their self-review as part of the Performance Review process.
It's it TBD whether this would be a section of "Performance Review" or whether to fold it into relevant pars of Frontend perf guidelines and Backend perf guidelines instead. Perhaps both, that is, main text on the guidelines and maybe a short list linked from the "Perf review" process page.
TODO:
- Document common pitfalls and tips based on the type of review. Suggestions: Go through the ~20 perf reviews, and classify them into groups: extension, core, backend, frontend, etc. Look for patterns. example: "in 3 reviews for extension frontend review we notice that the team doesn't yet instrument X,Y,Z"
- Create grafana dashboards and link in our main pages to promote our main metrics and best practices.
- reword our perf review template to be more explicit, from “show us which perf measurements you have” to a link with all the possible metrics they can care about, and which ones are more suitable for their needs and how to measure them.
- Improve UX on Page drilldown on grafana
- Add more details about caching when test type is selected on page drilldown
- Record video comparing the 2 types of HAR: resource download (see steps in https://wikitech.wikimedia.org/wiki/Performance/Runbook/WebPageReplay/Alert) A good use case is sound logo
- Record video how to use dev tools log (trace log)
- Have a separate runbook for FE regression
https://wikitech.wikimedia.org/wiki/Performance/Runbook/WebPageReplay/Alert
https://wikitech.wikimedia.org/wiki/Performance/Runbook/RUM_Alert
- Have some sort of flow chart by type (extension, core, FE, BE)