If there's the support of a major maintainer of a popular library, merging changes which incrementally incur larger performance penalties in Blink may be more effective.
If there's no support from a major maintainer, then simply writing contributions which are largely tested in firefox for performance but are tested in Blink for mere functionality should succeed over time in inducing the same.
In the end, the libraries are lock-in for larger SaaS providers far more than they might be aware, and if such changes start making it into e.g. React, there's not all that much that many product teams can do to work around it other than replying via support channels that Firefox seems to take less of a performance penalty.
That's the black hat in me talking. Resuming white hat status now.
That library will get forked by industry.
If its license does not permit forking, it's incredibly unlikely that it can get traction in the first place.
Good luck convincing your product owner of the necessity of that change. Most large enterprises won't do something like this.