Autoptimize comes with a “Add try-catch wrapping?”-option, which wraps every aggregated script in a try-catch-block, to avoid an error in one script to block the others. I considered enabling this option by default, as it would prevent JS optimization occasionally breaking sites badly. I discussed this with a number of smart people and searched the web, eventually stumbling on this blogpost which offers an alternative for try-catch because;
So given this damning evidence of severe performance degradation, “try/catch wrapping” will not be enabled by default and although Ryan’s alternative approach has its merits, I’m weary of the caveats so I won’t include that (for now anyway). If your site breaks when enabling JS optimization in Autoptimize, you can enable try/catch wrapping as a quick workaround, but finding the offending script and excluding it from being optimized is clearly the better solution.
At work we were stumped by a simple link that upon clicking didn’t have the browser request the target page. Our supplier investigated using VisualEvent, a bookmarklet-initiated javasript-tool that goes through a page and visualizes all events on DOM nodes. The developer released VisualEvent 2 a couple of days ago (also on GitHub), which I played around with for a bit and it really is great for debugging purposes!
(base) download complete: 0.324s for 4KB (which is marginally faster)
start render: 0.363s (again marginally faster)
full page download complete: 0.803s for 35KB (leaner, meaner and faster!)
The code that would have to be copy/pasted (multi-line for clarity):
And that, my dear fellow travellers, sucks big time. JSON without the P means we’re back to useless proxy-scripts on our servers. So until Google lets Jason pee (sorry folks, I just had to write this) in the V3 geocoding webservice, I’ll continue using the deprecated V2 with sweet -but undocumented- callback!
I know, this seems to have become an obsession of mine, but here I am again with a follow-up on my iframes-tips blogpost. You might remember I advised against disabling scrollbars on iframes, because;
Disabling them will render the iframe partially inaccessible for some of your users, because the size your iframe-content needs, depends on things outside your control such as operating system & versions (e.g. font & screen resolution), browser (e.g. css-implementation) and browser configuration (e.g. non-default font-size).
Optionally you can specify which iframes are to be treated this way (excluding the other ones) by doing