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
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!
So, removing this animation gives the browser more time to get on with the important stuff.
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.