Thank you for the very good CMS Typesetter. And your effort for this speed test.
Yes, TS is fast, as you test also shows. BUT if one uses for TS many large images then TS is in view on trays and Smartphons not so fast that you should necessarily change in which one makes available the ball ends image sizes as with WordPress 4.5.
big Images =
Hi Felix and all,
5 50 500 cents about this topic ;)
Of course, large images will have a dramatic impact on page loading time.
If one is using - let's say - 5 large images in a slider with 200-300 kB each, they will likely increase page loading time by 500% and more.
Josh's comparison is about CMS performance and therefore not directly related to image sizes, because it's not the CMS serving the images nor is it PHP but it's the webserver (Apache, nginx, IIS, lighttpd, you name it). This would be different if images were generated or resized upon request, but this is not the case.
So, if we're going to use large images on our websites, the CMS in charge will certainly not be a noteworthy factor.
While downloading jQuery, Bootstrap and 1 MB of images and maybe even some web fonts will take at least 2-3 seconds, the CMS itself only needs some 20-30 milliseconds to generate the HTML output. This is what Josh's comparison is all about. On a shared host, serving some hundreds of websites, a fast CMS has advantages because it needs far less CPU and RAM. It will be noticable especially when the server load is high.
From my experience, on shared hosts the database server (e.g. MySQL) is often suffering most from heavy load, thus causing delays. Since Typesetter doesn't use a DB, we don't have to worry about that. In contrast to Wordpress or even more demanding CMS like Typo3 and others, I never encountered any noticeable server-side delay when using gpEasy/Typesetter CMS.
So, yes, Typesetter's speed plays a role, especially when you build websites that simply do not need a DB for the content they serve. Typesetter truly shines in this field and it's almost as fast as static HTML pages.
For image optimizations and the Wordpress Core Dev discussion you mention, Felix:
From my point of view, when we're going to use large images, image optimization plays a key role to reduce file size. Of course, image resolution (pixel size) and compression rate are main factors here. If we have to decide if to reduce resolution or increase compression to achieve a certain file size, higher compression is the way to go (good article here). But resolution vs. compression is only one aspect and there are many other things we can do with images to get their file sizes down, such as noise reduction, partial blurring or only selective sharpening on JPEGs, or color count reduction, dithering and removing content in transparent areas of PNGs. Most of the latter simply cannot or should not be done automatically by the CMS or the server's image processing libraries.
To come to a point: True optimization of large images is crucial and neither Typesetter nor any other CMS will do it for you.
I'd rather go a step further and say: With large, high quality images, DO NOT let the CMS process them and thereby decide about their compression and pixel dimensions.
In my opinion the only real solution to the whole issue will be using the HTML5 <picture> element which is only supported on major browsers right now (still considered experimental).
For future development this is the road we should be going down.
That was interesting to read. *thumb_up*
I test Typesetter CMS in more than 40000 pages/items in plugin, true catalog like, with own routing. Such amount in flat file cause to memory spash usage at start, and then rather fast. But think that many visitors crash such site. Database usage in such case increase perfomance, I try that too for fun.
Find out more about our Provider Spotlight