Boomla is about simplicity: just create a gallery and upload images into it, Boomla will take care of the rest. The rest, in this case, means resizing those images to present visitors with small thumbnails by default, otherwise too much data would greatly slow down page loads. To get Boomla into your hands as quickly as possible, I decided to only support resizing first, and later add a caching layer once it is a pressing issue. Caching means remembering the result, to save processing time. Here, it means saving a resized version of the image, instead of resizing it for each visitor.
To give you an idea, resizing a high-resolution image takes about 1sec. Your browser will only load 5 images at a time, so if you have 100 images on a page, it will take ~20sec to load. Ooops, that’s a lot. I can confirm I have experienced pageloads just over 10sec, and I did not enjoy it a bit.
Years ago, I have designed a universal caching architecture for Boomla. It could not have been implemented at the time, because it builds on other parts of the system that were not in place yet. Its immense benefit is that, well, it’s universal: it not only works for images, but any application in the system. In fact, the feasability of Boomla rested entirely on that component, as simplicity is quite resource hungry.
Finally, it is in place.
That may be an overstatement as so far only about 50% of it is implemented, but that 50% is the really complex part. It does not support caching every application yet, mostly just images, but the rest is only a question of time. Again, I’ll postpone that until speed is again becoming an issue.
Again, pages loads are usually well under 1sec, typically around 500ms, but that grealy dependents on the applications used and contents added. I absolutely intend to keep it under 1sec, hopefully even lower.