Today I launched a new WordPress plugin, called Lighthouse. It primarily gathers all performance tweaks I’ve been applying to client sites for the past years. All these steps come before caching, before GZipping and serving content. Caching less content is obviously more efficient than caching more content. GZipping less content and more consistent code is, again, more efficient than GZipping more content.
With most caching plugins, WordPress still needs to request queries or content from the database once in a while. The best solution is to unhook unused features, such as feeds,
rel links and
meta tags. Google is smart enough to (pre)fetch related posts and pages and certain SEO plugins would make the job even easier. As (still) a blog platform, WordPress automatically enqueues emojis and smilies on every page, just in case you added one inside your content or someone comments and adds a happy face. This functionality is not needed for 90% of the WordPress-powered sites out there.
I’m going to throw in the author references, automatic canonical redirections for non-existent pages (instead of showing a nice 404 page template), enqueuing script helpers (jQuery Migrate, Retina detectors, Modernizr and so on) and so on.
By micromanaging these tiny details (where the devil is) and by removing all unnecessary code, caching and GZipping will become more efficient.
A quick example is the removal of
type="text/css" from all script declarations. Modern browsers and HTML5 do not need these attributes any longer. There we have it, we just saved 10 bytes from the GZipped version. One might argue that there’s no noticeable difference, but on a website with thousands of visitors per day, this is definitely useful.
Another example is the version parameter appended to scripts and styles, which prevents certain browser configurations, certain server configurations and certain caching plugins from properly caching them. Google Search Console has a feature to remove query parameters, but wouldn’t it be better to remove everything before getting to Google?
A better example of script madness is when themes and plugins add lots of scripts and styles both inside the
head section and in the footer, and they all have version numbers appended, and they depend on each other and all depend on jQuery. And jQuery is customized and added either from the theme directory or from a CDN. The logical solution would be to add jQuery dependency for all scripts and let WordPress do its job: enqueue the core jQuery. This is something that always bothers me, so I’ve added it as an option to my plugin. Deregister all jQuery versions and cleanly enqueue the core version in the
head section for maximum compatibility.
While I was at it, I decided to add support for several other libraries, such as Modernizr, Masonry (core) and HTML5Shim/v. I have also added support for the most used style libraries/frameworks, such as FontAwesome, Entypo, Dashicons (core), PureCSS and Normalize. I haven’t added Bootstrap because it has too many dependencies and it was not in the scope of this plugin.
So here I am, with a nice plugin that removes lots of actions and filters.
While the plugin is still fresh, a new version is in the works with support for more action removals and some specialized cleanup.
Image by Igor Kasalovic.
Once a week or so we send an email with our best content. We never bug you, we just send you our latest piece of content.
If you found any value in this post, agree, disagree, or have anything to add - please do. I use comments as my #1 signal for what to write about. Read our comment policy before commenting! Comments such as "Thank you!", "Awesome!", "You're the man!" are either marked as spam or stripped from URL.