So I wanted to replace a site’s (*) main title which required some fancy font (Courgette!) to be downloaded, by an SVG image.
Here’s what I did;
- make a screenshot of the node in Firefox Developer Tools -> Inspector -> select node -> click “screenshot node” in context menu
- convert the png-file into svg at http://pngtosvg.com/ result being a 6.93KB file.
- optimize the svg at http://petercollingridge.appspot.com/svg-optimiser resulting in a 3.1KB file (see above image) which remains crispy at whatever size.
- added the SVG as background image (not inline though, might do that next) and set “visibility” of the logo->a->h3 (which has the title in it as text) to “hidden”
- ticked Autoptimize’s “remove Google Fonts”-option (which also removed a slew of other unwanted requests for fonts)
(*) The site is my wife’s boeken-jagers.be which is an offspring of her successful “De Boekenjagers” Facebook group where people hide books for others to find (hunt) and share info about that. 27 000 members and counting, proud of my Veerleken!
[Updated 23/06 to reflect newer versions 2.1.2 and 2.2.1]
Heads-up: Autoptimize 2.2 has just been released with a slew of new features (see changelog) and an important security-fix. Do upgrade as soon as possible.
If you prefer not to upgrade to 2.2 (because you prefer the stability of 2.1.0), you can instead download 2.1.2, which is identical to 2.1.0 except that the security fix has been backported.
I’ll follow up on the new features and on the security issue in more detail later today/ tomorrow.
I’ll roam the WordCamp EU 2017 campus next Saturday, contact me if you’d like to meet! :-)
Thanks for using Autoptimize guys & girls, looking forward to providing you with the new version next month!
So work on Autoptimize 2.2 is almost finished and I need your help testing this version before releasing (targeting May, but that depends on you!). The more people I have testing, the faster I might be able to push this thing out and there’s a lot to look forward to;
- New option: enable/ disable AO for logged in users for all you pagebuilders out there
- New option: enable/ disable AO for cart/ checkout pages of WooCommerce, Easy Digital Downloads & WP eCommerce
- New minification/ caching system, significantly speeding up your site for non-cached pages (previously part of a power-up)
- Switched to rel=preload + Filamentgroup’s loadCSS for CSS deferring
- Additional support for HTTP/2 setups (no GUI, you might need to have a look at the API to see/ use all possibilities)
- Important improvements to the logic of which JS/ CSS can be optimized (getPath function) increasing reliability of the aggregation process
- Updated to a newer version of the CSS Minification component (albeit not the 3.x one, which seems a tad too fresh and which would require me to drop support for PHP 5.2 which will come but just not yet)
- API: Lots of extra filters, making AO (even) more flexible.
- Lots of bugfixes and smaller improvements (see GitHub commit log)
So if you want to help:
- Download the zip-file from Github
- Overwrite the contents of
wp-content/plugins/autoptimize with the contents of
autoptimize-master from the zip
- Test and if any bug (regression) create an issue in GitHub (if it doesn’t exist already).
Very much looking forward to your feedback!
Historically Autoptimize used its own JS-implementation to defer the loading of the main CSS, hooking into the domContentLoaded event and this has worked fine. I knew about Filament Group’s loadCSS, but saw no urgent reason to implement it as I saw no big advantages vs. my homegrown solution. That changed when criticalcss.com’s Jonas contacted me, pointing out that the best way to load CSS is now using the
rel="preload" approach, which as of loadCSS 1.3 is also the way loadCSS works;
<link rel="preload" href="path/to/mystylesheet.css" as="style" onload="this.rel='stylesheet'">
rel="preload" currently is only supported by Chrome & Opera (both Blink-based), a JS polyfill is needed for other browsers which uses loadCSS to load the CSS. Hopefully other browsers catch up on
rel="preload" because it is a very elegant solution which allows the CSS to load sooner then with the old code while still being non-render blocking. What more could one which for (“Unicorns” my 10yo daughter might say, but what does she know)?
Anyways; I have integrated this new approach in a separate branch on GitHub, you can download the zip-file here to test this and all the other fixes and improvements since 2.1.0. Let me know what you think. Happy preloading!
Less blogposts here lately, mostly because I’m doing custom Autoptimize-development for a partner (more on that later) and because I get a lot of support-questions on the wordpress.org support forums (with approx. between 1500-2000 downloads/ weekday that is to be expected). One of the more interesting questions I got there was about Autoptimize being slow when JS optimization was active and what would be the cause of that. The reply is of interest for a larger audience and is equally valid for CSS optimization;
Typically the majority of time spent in Autoptimize is mainly in the actual minification of code that is not minified yet (purely based on filename; if the filename ends in .min.js or -min.js).
So generally speaking, the way to avoid this is;
1. have a page cache to avoid requests triggering autoptimize (as in that case the cached HTML will have links to cached CSS/JS in it)
2. for uncached pages; make sure AO can re-use previously cached CSS/ JS (from another page), in which case no minification needs to be done (for that you will almost always want to NOT aggregate inline JS, as this almost always busts the cache)
3. for uncached CSS/ JS; make sure any minified file is recognizable as such in the filename (e.g. .min.css -min.js), this can lighten the minification-load considerably (I’ll add a filter in the next version of AO so you can tell AO a file is minified even if it does not have that in the name).
So based on this, some tips;
* make sure you’re not aggregating inline JS
* for your own code (CSS/ JS); make sure it is minified and that the filename confirms this. if you can convince the theme’s developer to do so, all the better (esp. the already minified but big wp-content/themes/bridge/js/plugins.js is a waste of precious resources)
* you could try switching to the legacy minifiers (see FAQ) to see if this improves performance
* you can also check if excluding some un-minified files from minification helps performance (e.g. that bridge/js/plugins.js)