Making EasyEditor Even Faster

As a developer at dotMailer, I know that as a team we are lucky enough to develop on the latest technology: Quad-core i7s with loads of RAM and SSDs all-round.  This makes our lives easier, and speeds up day-to-day tasks.

However, it also has its down-sides.  When developing front-ends for applications – especially big projects like EasyEditor – everything is always faster for us!  Coupled with the fact that we develop in Google’s speedy Chrome browser, EasyEditor is, and has always been, fast and responsive.

Testing in older browsers is something we treat as very important, but sometimes features are tested to make sure they work, rather than to make sure the overall experience is as good as it can be.

So, with a 6-year-old laptop, running Microsoft’s ubiquitous Internet Explorer 8, we set about actually using EasyEditor, only to find the experience less than satisfactory.  Everything worked –  providing  one had a great deal of patience.

Rectifying this, however, was no easy feat. Testing and debugging in Internet Explorer 8 is painful – compared to more modern tools.  But with time, and patience, we managed to work through a host of different issues, speeding up many operations more than two-fold.

So, how did we do this?

Server-side vs Client generated mark-up

EasyEditor relies on our internal DDG JavaScript library.  This allows us to do many things quickly inside JavaScript itself, so that the EasyEditor application can be less reliant on the server pushing mark-up to the browser.

However, this may have meant that some development processes were faster, but at the expense of generating much of the mark-up in the browser.

Modern browsers do not struggle with this, but older browsers do.  We have now built the bulk of the application within the mark-up of the page, allowing the browser to process this upon page load, rather than injecting all the mark-up at run time.  This has led to a significant decrease in loading times.

Moving to CSS3 Animation

Everyone likes a little bit of animation – providing it doesn’t detract from the usability of a system.  But in older browsers, some of the animation was doing just that.  Moving to CSS3 animation makes animation run smoother in modern browsers, but not at all in older browsers!

The alternative is to use jQuery for the animation.  This is great – and works in all browsers – but JavaScript is single threaded: when jQuery animations are running, nothing else can!  We have many functions that run in the background in EasyEditor (calculating the text selection properties and auto-save, amongst others).

So, removing this animation gives the browser more time to get on with the important stuff.

Optimising CSS

It’s amazing how much certain CSS styles can slow older browsers down.  Opacity in Internet Explorer is achieved through the (now depreciated and proprietary to IE) filter tag.  Part of the code was using this to create a transparent element (opacity=0) so that events can be tied to the element, but the element cannot be seen.  This is done in certain drag operations, which were very slow in the older editor.

By simply replacing this opacity CSS with a transparent GIF background image (which essentially produces the same thing), we made a massive difference to the speed of the browser.  This is just one example where changing the CSS improved the speed of Internet Explorer.

Getting the timing right

In some places we have improved the speed without actually improving the speed at all!  This magic is just a question of doing certain operations a bit later, when we have time to do them – rather than trying to do everything instantly.

For example, scrolling up and down your document in EasyEditor does a lot of different things, trying to keep some parts of the interface visible at all times, whilst letting the email scroll.  The old version did all this work every single time you scrolled the document.

In comparison, the new version does the minimum required (mainly to keep the header on-screen), and waits for you to finish scrolling.  Once you stop scrolling, it will execute the rest of the code, redrawing the side bar, if required.

This technique has always been used in certain intensive parts of the editor, but we’ve now increased its use, and tweaked the timing for the best experience.

More to come?

Absolutely. My faithful old laptop will become an essential testing tool for the foreseeable future, and we’ll keep trying to improve performance on a continual basis.