I wouldnât be so sure about it. Most of it is just changing your behavior. I am lazy but 95% of that is not added work at all. Its just setting the server properly and doing smart decisions. I would say it is just good practice thatâs all.
Its not like people who manually rewrite svgs in code because they can make it more efficient than graphic programs.
Besides load times matter. Much more than people think. With all the badly optimized wordpress sites around it is easy to be so much faster that people notice.
Lot of times it breaks websites. Especialy when combined. (but this was few years ago when i tried last time)
When it worked it never was somehow worth it. Actually uncss was not useful. Mqpacker did most of the difference. I believe this was because we (at work) write very minimal css and all of it is custom for the site. Meaning there really isnât much that is not used. Uncss will make huge difference if you are using something like bootstrap.
About the JS:
Interesting. Does it really help? I mean most of our js are few js libs for things like lightboxes and slideshows plus very small file with initialisation of those libs and maybe few click event handlers for class switching.
If i understand it correctly this would pack all of the needed libs for certain template (+ their init code) into one special file. If i have the same lib in different template i will be downloading whole new file? It seems much more wasteful than my current approach which is not bundling at all :D. I wrote above that i have great success with http2 and we stopped bundling. But maybe is more about parse times? I know it takes quite bit of time for browsers to parse JS if it is big. Is the whole point of this to reduce js browser has to parse?
Iâve not had a problem with Uncss - it often strips 40 - 50k out of a CSS file. Itâs particularly useful if you have used something like FontAwesome but only used 3 icons in you project. Thats a lot of unnecessary code.
Actually, yes it does help. You end up with 1 javascripts per page, or sometimes 2 depending what the page needs. In each javascript you require your dependencies and then write your own code underneath:
The code above is the home.js file from a site i am working on. Every page in the site uses jQuery and Match Height. Browserify bundles these into a common.js file because they are common to every page.
On one page i have a select box that can be used as navigation. So i have a contact.js file containing this:
window.$ = window.jQuery = require('jquery');
$(function() {
// bind change event to select
$('.addon-button').click(function() {
var url = $('.addon-field').val(); // get selected value
if (url) { // require a URL
window.location = url; // redirect
}
return false;
});
});
Browserify links the dependency to jQuery to the common.js and strips it out of this file. All that ends up in contact.js is the unique function, so on this page you can use Kirbies to autoload the file after common.js.
This way you can incrementally load in just the bits of javascript that are needed for the page, rather then including all javascript on every page, wether it is needed or not.
@RushmerIO When I run Google Pagespeed the first time it felt like I had 100 speed related issues to fix. My site was slow in real life as well. Fixing one of the issues did not help much, but for each small fix my site did a little improvement. After fixing almost everything my site was really fast. Therefor I see every speed related fix as a kind of micro optimzation. If itâs worth it from a money perspective, I donât know. The lessons I learn, I keep in my head for the next project, so in the long run, I think Iâm richer, in one way or another.
@krisa Thanks, Iâll at least try to inline important css the next time to see how it goes.
@jimbobrjames About tools for removing unwanted css, I use another approach. If you would use plugins like [Patterns] (https://github.com/getkirby-plugins/patterns-plugin) or Bricks everything on the site would be modules. Removing a module will remove everything bound to it, including the javascript and the css. But I understand why itâs needed for things like fontawesome.
I just wanted to add my two cents to critical css.
All my projects are based on SCSS and I use a combination of ITCSS and BEM. For me it is pretty easy to fetch all needed scss files and include them in a critical css and inline that in the header. I choose the styles by hand because I usually know what styles are needed to display the first part of the page.
Some tools around are usefull. But most of the time doing it myself caused less headache.
This of course depends heavy on your css structure.
But thats what i am trying to say. Good code means clean but also performant. The problem ususaly is that devs dont care. Its not like minifiing code, images and http2 and https2 is more work for you. You learn/do it one time and then it will stay forever. Most of the advice is just way of structuring code.
Its not really about âworth the timeâ.
Btw 100ms is actualy a lot. If you think about medium sized ecommerce site with 5000 visitors a day you have saved them together more than hour a day (i think thats awesome, lets not waste other peoples times). There were few articles from amazon and google how 100ms equaled drop in sales 1%. Tell that to your customer next time you will need to get payed - that 1second you can shave off might be really worth it.
Ok, guys, letâs stop this here before it is getting personal and does not lead anywhere. I think we already have a lot of topics regarding performance, and we wonât be able to solve this one here. So letâs get back to creating beautiful, performant sites with Kirby, each and everyone in the way they think best and everybody will be happy.
Sorry, I know that licenses are always an annoying topic. I would really like to make this possible, but I could not guarantee the continuous development of the plugin. Kirby plugins are a very small market and development barely pays off considering the work invested for developing and maintaining them. If I would be able to sell thousands of copies, I would think about providing a different (cheaper) pricing model like Advanced Custom Fields (Unlimited, pay once) for WordPress or WPML (yearly subscription, urgh!).
