A powerful bundle of lightweight tweaks that drastically improve the loading speed of WordPress by…
|Author:||LittleBizzy (profile at wordpress.org)|
|WordPress version required:||4.4|
|WordPress version tested:||5.0|
|Added to WordPress repository:||31-08-2018|
|Total downloads:||7 128|
|Active installs:||1 000+|
Click to start download
What makes this plugin different from others?
Speed Demon is a lightweight PHP-only plugin that bundles several of our popular performance micro-plugins into a single plugin. All functions can be controlled precisely using defined constants. The purpose of this plugin is to bundle several of our popular performance plugins into one single plugin for easier installation and management. In order to do this efficiently, however, Speed Demon maintains our popular “no settings page” approach to avoid database queries and instability/setup requirements. The most stable functions (sub-plugins) are enabled by default, while less predictable functions (sub-plugins) such as Inline Styles are disabled by default. In order to enable or disable any given function (sub-plugin) simply use the defined constants below inside your wp-config.php file or using our free Custom Functions plugin instead.
Do all your plugins support the defined constants?
Note: these defined constants are ONLY supported within Speed Demon. If you have one of these installed as a standalone plugin already, that function WILL REMAIN ENABLED until you disable the standalone version of the function. For example, if you disable Index Autoload in Speed Demon using a defined constant, but you still have our other Index Autoload plugin installed + enabled, then that function will continue to function until you disable or delete the standalone Index Autoload plugin. This allows for web hosts or other agencies to force-control their WordPress environment using our standalone plugins.
How can I change this plugin’s settings?
There is no settings page. To enable/disable a certain function (sub-plugin) use the defined constants only.
Why don’t you have a settings page?
Because that would mean database queries and more time/hassle/confusion for setup. No settings page means web developers, agencies, or web hosts can automate their WordPress setups (such as with Bash scripts, etc) much faster and easier, and clients have less chance of accidentally messing things up by snooping around a settings page.
Does it work alongside XYZ plugin?
Yes, it will work no matter what plugins/theme you have installed, there should be no conflicts. However we don’t recommend using other similar performance plugins at the same time as Speed Demon to avoid conflicts or redundancy.
My site looks horrible after installing this?
Turn off Inline Styles using the defined constant
define('INLINE_STYLES', 'false'); and consider ditching whatever bloated and horribly coded plugin is causing the problem, such as janky “slider” plugins, etc. Also ensure you are using PHP 7+
Why don’t you support defer, async, or concantenation of JS/CSS files?
No serious website uses these methods. Don’t believe us? Check the Alexa Top 100 sites and look at their source code. You will never see any high traffic or serious website using these methods because they are so risky. “But PageSpeed Insights told me to! I’m scared of Google!” … do what you wish, we know from experience it will not help your rankings (or speed, in the vast majority of cases… and no, “scores” are not the same as “speed”). Rather than altering or manipulating the loading order (or loading location) of JS/CSS it makes much more sense to only install plugins or themes from quality authors, who should be trusted to load JS/CSS resources how and where they want. The only method we currently support is inlining all CSS stylesheets, which should work fine on 90% of WordPress sites (bloated/unstable plugins like sliders may have an issue). Likewise, many JS scripts inherently support defer/async, such as Google’s Universal Analytics snippet. We don’t believe in “hacky” solutions, but rather in trusting code sources to handle these things (in other words, choose your software wisely). Lastly, if you really want to concatenate all your JS into one crap-pile, it would be better to let you CDN provider do this for you (such as CloudFlare’s free RocketLoader feature) rather than bundling your JS into some nasty temp file on your origin server.
What if I already have the corresponding micro-plugin installed?
Each module checks some constant(s) and class(es) from the original plugin release, and if some are detected then aborts the module execution. this is the sequence when a module ask if can continue the execution:
- First check the existence of the corresponding module constants (REMOVE_QUERY_STRINGS, DISABLE_XML_RPC) and stops the module execution if defined with a false value.
- Next step looks for a inherent constant of the original plugin to check if is running (RMQRST_FILE for Remove Query Strings, \LittleBizzy\DisableEmojis\FILE for Disable Emojis, etc.), aborting if detect the previous plugin.
- Sometimes the original plugin does not have a constant (code from other developers), so just in case checks the plugin class existence (\LB_Disable_XML_RPC etc.)
- But these checks do not do anything with the original plugin optional constants: REMOVE_QUERY_STRINGS_ARGS, DELETE_EXPIRED_TRANSIENTS_HOURS, etc.)
These checks of existing constants and classes are performed as late as possible, in order to give time to execute these constants/classes from different locations: wp-config.php, other plugins, functions.php from theme, etc.
Technically speaking, how does it check for micro-plugin code?
Some modules code have changes from the original due the common module/plugin adaptation mechanisms, but I tried to keep the original code fragments (Always will need small changes: namespaces, a separated main module folder, calls to check if the module is enabled, unified activation/deactivacion/uninstall hooks, etc.)
Regarding the modules:
Remove Query Strings
The cancellation check works right on the style and loader filters.
The last minute check occurs after the WP init hook. I have reorganized the plugin structure to fit the common module mechanism.
Checks constants/classes at the beginning and after the init hook. Tested the correct execution on activation/deactivation hooks.
Checks constants/classes at first and also after the init hook.
Checks constants/classes after the init hook. Tested the index removal and internal option deleted (used to save the timestamp) on plugin uninstall.
Delete Expired Transients
Checking on start and under cron event execution.
Disable Post Via Email
Just checks on start, it is not possible to check the module later due the early execution in wp-mail.php
Checks on start, and on the
The associated constant must be defined at the wp-config.php level because this module does not use any wp hook and runs at the same time of the plugin execution.
Disable Cart Fragments
There is a conflict with previous constant DISABLE_CART_FRAGMENTS, which if exists is expected to be an array from the old plugin. The new module supports the different data types (boolean or array), but if the constant remains boolean and the old plugin is activated, then the
truevalue is interpreted as page 1 (due the type casting).
The last check looking if the module is enabled works just before to remove the enqueued carts fragments scripts, so this module constant can be located anywhere.
Disable jQuery Migrate
Module is checked on the wp_default_scripts WP core hook, so the module constant can be defined in any place.
Plugin functionality is checked at WP init hook, so the module constant can be defined anywhere.
I have a suggestion, how can I let you know?
Please avoid leaving negative reviews in order to get a feature implemented. Join our Facebook group instead.
- tested with WP 5.0
- bundles Disable Gutenberg 1.0.0 (default = true)
- bundles Disable WooCommerce Status 1.0.4 (default = false)
- bundles Disable WooCommerce Styles 1.0.1 (default = false)
- updated Minify HTML 1.0.1
- (fixed bug in REMOVE_EXTRA_SPACING that was removing spaces before/after inline HTML tags)
- updated plugin meta
- bundles Minify HTML 1.0.0 (default = true)
- default status for Inline Styles is now = false
- default status for Disable Admin-AJAX is now = false
- optimized plugin code
- fixed error for PHP < 7.0 …you’re welcome, PHP 5 babies… now upgrade! 😉 e.g.
Parse error: syntax error, unexpected 'default' (T_DEFAULT), expecting identifier (T_STRING) in ../wp-content/plugins/speed-demon-littlebizzy/modules/remove-query-strings/core/filter.php on line 116
- bundles Disable Admin-AJAX 1.0.0 (default = true)
- bundles Disable Cart Fragments 1.1.3 (default = true)
- bundles Disable jQuery Migrate 1.0.0 (default = true)
- bundles Header Cleanup 1.1.1 (default = true)
- added recommended plugins notice
- added rating request notice
- initial release
- tested with PHP 7.0
- tested with PHP 7.1
- tested with PHP 7.2
- bundles Delete Expired Transients 1.0.3 (default = true)
- bundles Disable Embeds 1.1.1 (default = true)
- bundles Disable Emojis 1.1.2 (default = true)
- bundles Disable Post Via Email 1.0.0 (default = true)
- bundles Disable XML-RPC 1.0.8 (default = true)
- bundles Index Autoload 1.1.1 (default = true)
- bundles Inline Styles 1.1.0 (default = true)
- bundles Remove Query Strings 1.3.1 (default = true)
- added warning to Multisite installations
- plugin uses PHP namespaces
- object-oriented codebase