Way back when Imagify was brand new, I was doing some testing, and noticed how fast they optimized the images that were uploaded. The main reason they could do it faster was the use of background (asynchronous) optimization. When you uploaded an image, the plugin fired off a request to admin-ajax.php to optimize the image in a separate PHP process, so that the upload could complete, and you could go on doing what you do best.

I studied their implementation a while, and then I discovered that one of the developers for WP Offload S3 had released a library that allowed for background and async operations using similar methods. It took a while to implement, because I wanted to really maximize the performance impact, but when it was done, we not only had Background Optimization, we even had Parallel Optimization.

Background optimization would fire off a request for each image upload, and then that request would be responsible for optimizing the image plus all the resizes that were generated. Parallel optimization took that a step further, and broken each individual image resize into separate requests, and then ran those 5 at a time. Sounds great, right!

Wow, was that a mess! We ran into issues with security plugins thinking the plugin was doing nefarious things, and all sorts of fun. The worst though, was session locking. When the session_start() function is called, no other requests from your browser are allowed until the request finishes, or the session is closed. This made it seem that EWWW IO was locking up sites, browsers, the world! Ok, maybe not the world...

Now, I'm sure there is a time and place where using PHP sessions is appropriate. WordPress core does NOT use sessions, and it is generally advised that plugins and themes should not use sessions either. But if you are going to use sessions, when you are done with the session, UNLOCK IT! Don't assume that the PHP process will always execute so fast that session locking will never cause a problem. You see that? They're making two huge absolute assumptions, and you should never deal in absolutes :)

I didn't get to see most of the plugins responsible for my nightmare, but I got really good at typing "session_close()" anywhere and everywhere I thought EWWW IO might possibly stall the process. The one plugin where I actually found a session_start() call on a user's site was horrible though. They used session_start() and then... NEVER used the session!

Ok, so you probably don't care so much about all that. Suffice it to say that the background mode in EWWW IO has gotten a lot more sophisticated since it was first introduced. And while I'd like to think it would never cause a session locking problem anymore, I don't make such silly absolute assumptions. When you install EWWW IO, background mode is disabled by default, until it is able to successfully send a test async request. If that test succeeds, it is turned on and there is no option to turn it back off. Or is there?

Ok, of course there is, but it's a bit hidden. To completely disable all background/async operations, simply define EWWW_DISABLE_ASYNC in your wp-config.php file:

define( 'EWWW_DISABLE_ASYNC', true );

That's it, hope you like slow uploads! Ok, hopefully they aren't too slow, but when you do that you'll get to see first hand exactly why background mode exists. But sometimes, you have no other choice, so EWWW IO gives you one instead.

Still need help? Contact Us Contact Us