Josh

Hi,
Background:
All the banners I server are either images or HTML and there is 0% chance I serve flash.
While doing a performance review of my JS code I noted the standard Revive JS code (served via /asyncjs.php) contained a whole section of JS referencing ShockwaveFlash.ShockwaveFlash
Checking the asyncjs.php source I see it includes a reference to a required flash config file (fl.js in the /www/delivery folder)
require __DIR__.'/'.$GLOBALS['_MAX']['CONF']['file']['asyncjsjs']; require __DIR__.'/'.$GLOBALS['_MAX']['CONF']['file']['flash']; I currently commented out the inclusion of the fl.js so the JS is smaller. All seems to work fine.
Results
asyncjs.php goes from 3.6KB to 2.0Kb when transferring over the wire (GZIP). (not massive, but with Chrome never slow mode, you only have a certain budget of JS available. Saving 1.6Kb here can help to stay under the 500kb limit) 9883 bytes to 42993 bytes in unzipped format. (this is less JS code to parse/execute. Read The Cost Of JavaScript In 2018 for more details https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4)   
My 3 questions for the community are?
Do you know any side effects of removing the fl.js inclusion?  Are there better options than commenting it out? Are there other JS optimisations you are aware off? Thank you
Tim
 

It's useful to look at the zone probability report to see what Revive is calculating for current probability. As you do this and make changes remember that caching can have some impact, switch to admin user and recalc probability in maintenance.

I found the solution - and the option ?
Just disable the option "This banner can be safely displayed inside an iframe (e.g. is not expandable)" at the banner-settings. If this is disabled, the js-code is delivered without an iframe wrapped around.
It's that easy!

Assuming you can control your invocation code output for new visitors, you could use Delivery Options to target source=new-visitor. And like Andrew said, use override campaign to make sure they are highest priority.

This is due to bots. Bots most often won't execute js tags but will follow <img> (logging beacon) and <a> (click tracker). You can confirm this by looking at your web server logs.

Configure CDN Origin to be your revive /www/images
In Revive admin
Configuration > Banner Delivery Settings > update Image Store URLs to your CDN URL

Usage example for refreshing javascript async invocation tags.
Got it working like so
HTML
    <div class="ad-300x250" id="ad-300x250-1">
        <ins data-revive-zoneid="153" data-revive-id="b7c2bd3ff3b3bed3a9daa932a43cc2a8"></ins>
        <script async src="https://ra.example.com/www/delivery/asyncjs.php"></script>
    </div>
    <div class="ad-300x250" id="ad-300x250-2">
        <ins data-revive-zoneid="154" data-revive-id="b7c2bd3ff3b3bed3a9daa932a43cc2a8"></ins>
        <script async src="https://ra.example.com/www/delivery/asyncjs.php"></script>
    </div>
JS
    // placements to refresh
    var adSlots = ['#ad-300x250-1', '#ad-300x250-2'];
    // remove data-revive-loaded attribute
    for (var i = adSlots.length - 1; i >= 0; i--) {
        $(adSlots).find('ins').removeAttr('data-revive-loaded');
    }
    // refresh the ads (use your data-revive-id)
    reviveAsync.b7c2bd3ff3b3bed3a9daa932a43cc2a8.refresh();
    // if your data-revive-id starts with number, access like so
    //reviveAsync['7bc2bd3ff3b3bed3a9daa932a43cc2a8'].refresh();

Update: It worked fine. Thanks very much for the help on this. I appreciate it.