Kirby Size Inventory

I'm always trying my very best to make us focus on keeping Kirby as simple and light-weight as possible. That's actually a very easy claim to make though. So after Kirby 2.2 and all the refactoring that went into it, I wanted to run a little inventory on the various components and assets and see how big Kirby really is.

Disclaimer: the numbers are taken from the latest build of Kirby 2.2.2

Components Overview


 668.00 KB Kirby Folder
1700.00 KB Panel Folder
2368.00 KB Kirby Components


 668.00 KB PHP in Kirby Folder
 591.00 KB PHP in Panel Folder
1259.00 KB PHP

The Panel

Panel Size Overview

  74.80 KB CSS 
 227.26 KB JS
 572.00 KB Fonts
   3.00 KB Images
 591.00 KB PHP
1700.00 KB 


  27.00 KB FontAwesome CSS
  47.80 KB Panel CSS
  74.80 KB CSS 

Here's still quite a lot of potential for optimization by cleaner CSS. 74 KB including the icon stuff is not too bad though.


   84.00 KB jQuery 
   61.00 KB jQuery UI (core.js, widget.js, mouse.js, draggable.js, droppable.js, sortable.js)
    1.00 KB jQuery UI Touch
    3.00 KB jQuery Autosize
    2.00 KB jQuery Hotkeys
   35.00 KB Moment JS
    4.00 KB NProgress 
   13.00 KB Pikaday
   24.26 KB Panel Components
  227.26 KB JS

Those 64 KB of jQuery UI and jQuery UI touch really annoy me. I'm planning to replace the sortable and drag & drop features with dragula in a future release to cut this down further.


 420.00 KB Source Sans Pro
 152.00 KB FontAwesome
 572.00 KB Fonts

Fortunately 572.00 KB is the size of all font files combined (WOFF & WOFF2). Browsers with WOFF2 support have to load 231.94 KB of font files on the first request. Still a lot. I'm looking for ways to move away from the icon font and replace the icons with proper SVG instead.


   3.00 KB Images

A few additional words…

This rundown is purely about the size of Kirby, not its performance. I think most of you already tested that part thouroughly for yourself :)

For me the golden rule has always been to go for as little code as possible. That means a healthy balance between size and maintainability.

I'm especially careful with adding external dependencies. I'm a friend of writing smaller custom solutions whenever possible instead of addig a third-party library that might have too many unneeded options and I can't be sure how well it will be maintained in the future. But again this has to be balanced.

In my opinion you should always look very closely at how much code you actually add with a dependency to your project. If a little tool that just handles "feature x" adds more code to your project than your entire project had before, it might be a good idea to double-check that.

I find the current trend of blindly playing plug and play developer troublesome. The coolest part about the web for me has always been the possibility to look behind the curtains. Make up your own mind and learn all the necessary parts to build your own tools. That's where the magic happens!

The longer Kirby exists, the more I enjoy the part of curating its source. Cutting down additional kilobytes of JavaScript or CSS and increasing Kirby's performance has become a very nerdy but beloved hobby :)

On to the next release!

— Bastian

This is a companion discussion topic for the original entry at

Interesting metrics from Kirby. I have to admit its one of my guilty pleasures to try to cut a couple of kilobytes here and there from my assets and try to optimize my site to the fullest.

For the Javascript, maybe look into a jQuery replacement. Depending on which parts of jQuery you use, you could use a lighter drop-in like Zepto, Sprint or Cash.

Alternatively you can build your own jQuery and take out the parts you don’t use.

1 Like

I was thinking about moving away from jQuery while working on 2.2, but it’s a solid, well-known basis for all plugin developers and that’s why I decided to keep it as it is.

You bring a great point. I hadn’t though about plugins using jQuery. Even if you’d build your own jQuery, a plugin developer might get surprised that function x is missing from kirby’s jQuery embed. Good call.

I though of something for CSS. You could add UnCSS to your Gulp process to strip any unused CSS (if any). If you’re using a framework of some sort, I’ll really help to thin the CSS down.

I am not a good coder, like you are - but I did make my own CMS in the '90s (1993 - 2003).

It was about less than 250kb in size (my marketing slogan was like “o my God, it fits on a floppy!”).

And what I did discover is that the size of the CMS is not the same as / equal to it’s performance;

My God… I was compressing every bit, I was cutting down every pixel… just to be sure the CMS was as small as possible… I even changed the CMS favicon to be 1kb smaller (using a horizontal pixel algorithm, in stead of the vertical ones it used to have).

You can cut down the size by compressing the code, packing it, removing / contaminate functions, embed Oops in Oops (embedding Object Orientating Programming, like an iFrame in an iFrame)…

…this will reduce the size of your CMS, but don’t get blind of the size; because sometimes the sizes goes down and the performance in milliseconds goes up.

I am not writing this because I think Kirby can learn from me - but for all those “new” developers out there;

Size doesn’t (always) matter, it’s also about speed / performance / flexibility, etc…

Lol - that’s old… my CMS from 1993 - 2003… it was even file-orientated, no database needed!

Whoops - back in 1993… the CMS was using plain text files and a folder structure to power the site…


Why are people using jQuery in their fields? Because they can. The field creators don’t even need to think about to include jQuery or not. It’s already there. The syntax is a bit shorter so that’s why they use it.

I left jQuery about 6 month ago for my own projects and never looked back. Modern javascript is very powerful. You don’t even need jQuery anymore.

The solution for already existing fields can be a simple option:

c::set('panel.jquery', true)

This only needs to be added if using a field that require jQuery. I bet many developers will use plain javascript when they realize that jQuery is optional.

What do you think?

There’s a big difference between keeping it small and light-weight in order to keep it clean and focused and micro-optimization :slight_smile: Especially compressing the PHP code doesn’t make any sense to be honest. The size of the source code isn’t a measure for the performance of the system. That’s what I meant with balanced. It has to be maintainable, tested and stable. But sometimes it’s easier to achieve that by cutting down the dependencies and the volume of your code base.

For assets it makes sense to go for every bit though.

jQuery still has a place in my opinion when it comes to fixing cross-browser issues. We are in the lucky position that all major browsers have become incredibly better in solving the day-to-day tasks in a rather standardized way, but there are still too many differences that need work-arounds and that’s why jQuery still is a good choice as a basis in my opinion. I’m looking forward to the near future in which we don’t need it anymore though, or maybe just a small part of it.


Here you can find an interesting article about jquery, zepto, size and performance.

@bastianallgeier take a look at Draggabilly (Dragula alternative)

I agree that Zepto is not a good choice. I’m using for a site, but now I prefer using plain javascript with own functions to make the code simpler.

I use something like this (like jquery):

var $ = function(selector) {
    return document.querySelector(selector);


When it comes to font icon font vs svg, the icon font is like a sprite. When using svg every svg file is a new http request. Svg might not be the best performance choice. Maybe a custom icon font would be better.

It looks like Source Sans Pro takes 4 times more space than FontAwesome.

1 Like

That’s only true if you embed every single icon from a separate svg file and use image tags, but that’s a bad idea anyway because it rids you of the ability to style them contextually. It’s absolutely possible to create svg sprite sheets, and if the number of icons is relatively low (as I suppose it is for the Kirby panel), Bastian could even go the simple route and just make the sprite sheet part of the initially loaded HTML document, causing no additional http requests at all.

Going for SVG icons over icon fonts is definitely the right decision, not just for maintainability, but also for accessibility. Here’s a nice recent article about the topic: Seriously, Don’t Use Icon Fonts – Cloud Four

1 Like

You have a point there about svg sprites.

However if the sprites are included inline it will be both messy html code and you can not cache the icons. Fonts are as far as I know cached by the browser, just like css and js files. Inline sprites are not.

Both have their benefits so it’s good to have as much information about them before taking a decision.

Me personally, I use an icon font when building tools and svg files when building websites.

Caching will indeed not work if you inline them, but for a single-page app like the panel (or any ajax-powered website) I wouldn’t consider it an issue as it only affects the first page load of each session. If you have lots of icons that absolutely need to be cached, consider using something like svg4everybody, which polyfills external svg spritesheet support for IE and other browsers that don’t support it.

“Messy HTML” is a moot point to me, if you include the svg snippet at the top of your document, I don’t see what’s messy about it (except that it’s inlined at all).

But the panel is not single-page? Just fast php. At least in 2.2+.

It is still a single-page app, just one that relies more on server-side rendering. The Panel still uses XHR to request the pages.

If the main objective here is to simply reduce the size of the bundle package, then why not simply load some of these components - like jQuery and FontAwesome - from CDN, rather than including them within the Kirby package? Wouldn’t it even be faster for the end user, in many instances, and reduce the maintenance overhead?

I vote this suggestion down. This is why:

  • It require that the CDN of jQuery is online in every single pageload of the panel
  • It reqiure that the CDN of FontAwesome is online in every single pageload of the panel
  • It require an internet connection, even when working on a site in a local environment
  • On slow or buggy internet connection it would probably be a pain to work in the panel

Even if everything work well in 99.9% of the cases, I think it’s not the most stable approach. I really prefer to not use the fancy CDN in this case.

One of the good choices WordPress made was to leave CDN and use self hosted files. Kirby also made that decision. Don’t change it!

@jenstornell I fully agree, the only thing I don’t like about your reasoning are those never-ending Wordpress comparisons :stuck_out_tongue_winking_eye:

Perhaps you are right. I know too much about WordPress for my own good. :wink:

1 Like

I don’t want to censor anything, it’s good and necessary to look beyond tellerrand, and see what good there is in other systems that might be useful for Kirby as well. And I understand from what background you are coming, so no offense meant :open_hands: