People have been talking a lot about CKEditor 3 on the web. We're having very good feedback for the nice stuff we've brought with our new editor. One of the most noticeable changes is its loading performance.
There are still several myths around web programming though, and we've faced one of them on the comments for the Ajaxian article about the recent CKEditor release: file sizes.
Since the very beginning, CKEditor has been coded with performance in mind. It's designed to be fast to load and fast to run. We bring details about it in this article.
Sample Page
Before starting, let's take a closer look on what's going on behind the scene when loading CKEditor in a page. For that, I'm using the original replacebyclass.html sample file distributed with the editor, directly from our nightly build. This page is quite simple, so it adds low overhead to our analysis.
My testing environment is a decent notebook with Firefox 3.5 and Firebug. I'm located in Warsaw, Poland, and our nightly server is in Chicago, USA. Compression is enabled on the server, but this should not be any news nowadays.
The following is the results you should find in the "Net" tab of Firebug.

The three grayed out files are not related to CKEditor effectively. Those are the main HTML page and the resource used by the page itself. The rest is the CKEditor stuff.
So, as you can see, the entire sample weight is 105KB, loaded and rendered in only 2.67s. Of course, different countries and connections will give different results, but considering that I'm way far from Chicago those are amazing results.
The Number of Server Requests
The key for amazing download performance is not related to the size of the stuff we're downloading, but instead the number of downloaded files. We kept a strong focus on this fact during the development of CKEditor and, as we can check above, the entire editor is loaded and is ready to use with only 7 files being downloaded. We can even reduce this number, but here we're talking about the default editor distribution, with no additional performance hacks. That's really amazing, compared to the 13 files we needed to download for each FCKeditor instance in the page (more details later in the article).
Just to give an example, still using the above Firebug results, note that the 81KB of the ckeditor.js file is loaded in only 1.2s, while the combined 24KB of the other 9 files is loaded in 1.5s.
For now, let's ignore the "?t=99D9" thing we can find in some of the editor URLs. Those are related to caching, which deserves a dedicated article. Let's instead check what's being downloaded:
- ckeditor.js: the heart of the editor. Here we have its core code, its API and all its plugins.
- config.js: the main configuration file of the editor. It's optional.
- en.js: the language file (English). It can be merged inside ckeditor.js.
- editor.css: the editor skin file.
- contents.css: the CSS used to style the editing area, so it reflects the end users web sites.
- sprites.png and icons.png: these are the images used to build the editor interface.
Minification
After taking care of the most critical issue related to loading performance, we come to the next important aspect: file sizes. Here again we looked for the best ways to reduce the size of our files. Some details:
- For JavaScript files like ckeditor.js and en.js, we've built a dedicated application called CKPackager (which deservers its own article also... SVN code available). We have amazing results with it, making our development much flexible and organized. For instance, the final (uncompressed) 265KB size of ckeditor.js is the results of the minification of 109 files, totalizing 875KB. The final result is 81KB being downloaded.
- CSS files, like editor.css are also processed and minified. The 25KB (uncompressed) size of editor.css is the result of the minification of 12 files, totalizing 50KB. This file is highly "compressable" (only 3KB).
Several Editors = Single Download
With FCKeditor 2, each editor instance in a page is an iframe loading all the 13 files needed to run the editor. It can be a disaster for pages containing several editors.
With CKEditor 3 instead, the editor code, language files, skin files, plugins and anything else, will be downloaded only once, no matter the number of editor instances in the page. Pages with several editors will load as fast as those with a single one. This is also good for Ajax like applications, where editor instances are created and destroyed by code, several times, without reloading pages.
You can check it now with the help of Firebug. Just compare the above Net screenshot with the one you'll have for the replacebycode.html sample, which contains two editor instances. Note that the same set of files is downloaded, only once.
Central Server/CDN Support
This is a unique feature you'll find with CKEditor: the ability to install and load the editor from a single central server or CDN anywhere on the web. That's it! Just place the editor files on your preferred CDN provider and go ahead reusing it on as many web sites as you want.
For example, suppose you CDN site is named "cdn.example.com", and you copied the CKEditor distribution files into the "ckeditor" folder on it. In your web site named "www.mysite.org", simply add a script tag pointing to "http://cdn.example.com/ckeditor/ckeditor.js" and you'll be ready to start using the editor on your pages.
Load on Demand
On pages where the editor is not required right away once loaded, like Ajax applications that create the editor by code when needed, instead of loading the ckeditor.js file, you can instead load the ckeditor_basic.js file, which is only 2KB. As soon as an editor instance is created, the full editor code is automatically downloaded.
It's even possible to configure it to load the full code after a number of seconds, so it will not impact on the initial page loading and rendering, but still leave the full editor code ready to be used with zero delays.
Optimization Tricks
There are a few optimizations that could be done to reduce the number of files being downloaded by CKEditor:
- If you need the editor interface to be localized in a single language only, you can set the language configuration option to that language code, and simply copy the contents of the language file (localized in the "lang" folder) at the very end of the ckeditor.js file. This will avoid this file being downloaded.
- It's recommendable to set the editor configurations in-page, instead of using the config.js file. Other than making it easier to upgrade the editor, you can even avoid downloading that file, by simply setting customConfig to an empty string ('').
- Standard configurations can be overridden by simply setting them into the CKEDITOR.config object directly, at the end of the ckeditor.js file, or even in-page, right after loading the editor file.
By doing the above optimizations, the editor download is reduced to only 5 files.
It's even possible to combine the ckeditor.js file contents with other scripts used in a page. For that, be sure to specify the editor installation path in your code.
New Things Coming
There are a few planned things that will enhance even more the download performance of CKEditor:
- The possibility of defining the CSS related settings (like the skin editor.css file and the contents.css file) directly into the configuration file. This feature will make it possible to potentially reduce the number of downloads for the editor to just 3 files: ckeditor.js and the two image files.
- CKEditor Builder: an online tool with which users can precisely select the plugins, skin and language files to be used, having an optimized and customized editor distribution. This will help having the size of the ckeditor.js file under control.
There are no dates for having these features ready, but they should definitely come sooner than later.
Conclusion
As a side note, just like I've said in my comments to the Ajaxian article... there is no magic here. In JavaScript, file sizes are strictly related to the features and the quality of the software that you have (considering all the above, of course). With CKEditor you're definitely full featured, with very high quality, and, as here described, we didn't overlook the download performance details. You may find a few editors that have smaller file sizes, but it's up to you to decide whether this not so evident benefit overcomes the huge quality difference.
I hope this article has been comprehensive on giving the details about the loading performance of CKEditor and its possible optimizations options. We're really looking for feedback and ideas in this sense.
Comments
Ckeditor loading event
i want to do some jquery work on page after Ckeditor loading completed. Can anyone help where to use jquery code......
Check the CKEditor for jQuery
Check the CKEditor for jQuery article and search for instanceReady (instanceReady.ckeditor).
CKEditor Builder
Hi, is there any updates on the CKEditor builder?
Men at work!
No ETA right now.
CKEditor Builder
any news on CKEditor Builder?
This sounds like a fantastic idea.
improvement to minifier
I would like to request that the minifier be able to take a parameter to output the BOM rather than hard-coding "true" for that. It could be set just like you set the "wrap" parameter for example.
Thanks!
Please open a ticket for it
That's not a bad idea.
Please open a ticket for it at our development site, eventually attaching a patch for it.
Packed CSS?
I've just downloaded CKEditor 3.0.1.
The only way to get ckeditor.js down to 81KB is to gzip -9.
You show contents.css at 453B. It is 674B from the tar.gz. Assuming the same server config with gzip -9, it becomes 466B (no minify). YUI Compressor makes it 222B (no gzip). YUI Compressed and then gzip -9 makes it 194B. Where does your 453B come from?
_samples/replacebyclass.html also results in 7 requests for skins/kama/sprites.png, for some reason.
CSS compression
I'm curious about the CSS compression you are doing here. You say you take 12 files totalling 50KB, and minify that down to 25KB, and then compress (gzip I assume) that down to 3KB?
I just had to do this for a client and I took one of their main CSS files and tried gzipping the original vs. minifying (I used the TextMate CSS bundle's "Format CSS Compressed" tool) and then compressing. Here's the results
original 72840 bytes Master2_1.css (100%)
original + gzip 12306 bytes Master2_1.css.gz (16.9%)
minified 67700 bytes Master2_1.minified.css (92.3%)
minified + gzip 11584 bytes Master2_1.minified.css.gz (15.9%)
I'll take the extra 1% saving, but its nothing like the reduction you are reporting (down to 6% original size). This CSS file is already pretty lean on the whitespace - the minification doesnt do that much to it which is probably a factor. Any other thoughts?
/Sam
Great Info!
I am a great fan of your editor! You do a great job.
I will keep this article to be prepared for my next integrations!
Case specific, probably
There are no special tricks here. We may have higher levels of compression simply because we have lots of repeated names in our CSS file, due to the fact that all skin selectors are prefixed with the main skin class name. We do that to isolate the editor styles from the rest of the page.
Look at one of the CSS files from the kama skin. You will note that the ".cke_skin_kama" class selector is repeated several times. This approach, while making the original file a bit bigger, have low impact once the file gets compressed.
Even faster loading
It's great to see so much focus on providing a fast user experience, and even greater that you took the time to share your performance tips. Here are a few changes that would make CKEditor load even faster.
Parallelization is a key to faster loading. In your sample page, config.js, en.js, editor.css, and contents.css should all download in parallel. That would reduce the load time by 400ms (15%). This happens automatically in Firefox 3.5 plus, and yet you're using Firefox 3.6 and it's not happening. This is because you've implemented your own scriptLoader class that forces the files to be loaded sequentially. In this case, it would be better to just let the browser do the loading. For other browsers (e.g., IE 6&7), a script loader would improve performance, but it shouldn't force sequential loading. The examples from my book for Chapters 4 and 5 have sample code that does this.
Don't use a querystring, "?t=99D9", to break caching. Many proxies, including the popular Squid proxy, won't cache resources with a querystring. See my blog post Revving Filenames: don’t use querystring for more details.
Thanks for sharing!
Thanks!
Hey Steve! It's a pleasure to see you here around, and it's definitely nice to have some high quality feedback. Let me add some more info here.
Parallelization: yes, we definitely considered this during the development. For example, if the editor has to load several external plugins, this will happen in parallel. This is handled by the resourceManager class, which loads a list of scripts in a single call.
The specific example you have pointed out has a precise explanation. The fact is that the editor language is a configuration option, which may be set in the config.js file. So, only after loading and executing that file we're able to understand which language file to load.
For the CSS files, you're definitely right. At least the editor.css file should be loaded in parallel, again right after the config.js loading (so we know which skin to use). I've opened a ticket to investigate it ;)
The contents.css file is a particular case, as it's loaded by the iframe that holds the editable area in the editor, which is part of the UI, which depends on the language file for its texts localization.
Now, regarding the querystring, we're targeting the general user case. We don't use this approach for our highly cacheable domain (a.cksource.com) for example, but the fact is that people are just used to install the editor in a specifically named directory (like "/ckeditor/"), and simply overwrite its contents when upgrading. Using the querystring approach we at least fix the browser cache issue. But of course, this could be a configurable option, so one can easily disable it, possible installing the editor into versioned directories instead (like "/ckeditor/3.0/"). So, another ticket :)
Thanks for the feedback!
Post new comment