Let me show you something. Here is your own "CSS Trigger" demo page https://www.convertplug.com/plus/css-class-trigger-demo/ and here are results of running that page under Chrome profiler http://prntscr.com/hdv5bj. As you can see the "scripting" part took about 90% of the time comparing to the "painting" and "rendering". Almost all of that time spent in Convert Plug/Pro event handlers doing a job of reinitializing every single popup registered on the site on every UI event like "mouse scroll" or "mouse leave" no matter what triggers are actually configured and on what pages the popup is enabled. And this was just a page with a single popup.
On any normal page, the "scripting" should take only a fraction of the total time. Now imagine this site having several popups and some decent content to scroll. Can you imagine the lags it causes in rendering the page on mobile devices like iPhone 6? Check your own code - in "$( document ).scroll( ...)" you loop over every single popup and reload it (re-parse all cookies, etc) even if the event and the current page are not applicable to that popup. Here are you are multiplying UI events by the number of popups you have on the site in total and on every pair you perform an expensive initialization. Still does not sound like a major performance problem? From programming 101, you are never supposed to multiply operations in any well-designed code cause it leads to quadratic time complexity - something you always want to avoid by all means.
The fact that you "have not come across any major performance" explains why I gave up. I got sick of your support talking to me like this problem does not exist. The "fixes" declared as solutions were the most frustrating experience - after sending your team all the details - they didn't take time to actually understand it and obviously didn't test their "fixies". UI and feature-wide I think this plugin has a lot of potential though, but the current perf issues are unacceptable.