Option can_compress_scripts not autoload causing extra DB query on every request

[RavanH]

Asked about this two years ago ​https://wordpress.org/support/topic/option-can_compress_scripts-not-autoload/ but noticed this is still the case:

The option can_compress_scripts not being among the autoload options creates an extra DB query on every (front-end and admin) request:

SELECT option_value FROM wp_options WHERE option_name = 'can_compress_scripts' LIMIT 1

Install Debug Bar and you'll notice it everywhere.

WordPress can very easily prevent this extra query (for one option!) by making it an autoload option by putting it into the array of $defaults in populate_options() in wp-admin/includes/schema.php and removing it from the $unusedoptions array...

Next, an upgrade routine to make it autoload for current sites on upgrade... And maybe rethink the Network approach: currently stored as a network option, but is it really a network option? It gets updated on every odd sub-site admin (not super-admin!) request via compression_test() in admin-footer.php anyway so why not make it a normal blog option?

Note that it has been in the $unusedoptions array since WordPress 1.5 but re-introduced as an actively used DB option in 2.8 in script-loader.php and admin-footer.php.

The option can_compress_scripts not being among the autoload options creates an extra DB query on every (front-end and admin) request:

`
SELECT option_value FROM wp_options WHERE option_name = 'can_compress_scripts' LIMIT 1
`

Trac ticket: https://core.trac.wordpress.org/ticket/55270

[costdev]

Removing trunk from Version as this has existed before the 6.0 cycle.

[spacedmonkey]

#57836 was marked as a duplicate.

[azaozz]

Actually thinking this functionality (the option and the code that sets it) can now be removed. Detecting whether compression from PHP is supported was necessary many years ago and was used when outputting concatenated and compressed JS and CSS from load-scripts.php and load-styles.php. As PHP based compression was removed there, the code that detects it is unused.

Also looked if the option is used in themes/plugins. It is mentioned in about 40 plugins but seems only used as a "default core option", not to determine if compression from PHP is available. That's not surprising as over the years output compression has moved to the server software as it is more efficient.

In these terms thinking it would be better to (slightly) repurpose this ticket and remove the code that sets the option too. Seems for back-compat with the ~40 plugins the option can still be pre-populated with false.

Trac ticket: https://core.trac.wordpress.org/ticket/55270

[spacedmonkey]

@azaozz I think that is another for ticket that. This is a simple fix that can go out in the next release.

I have added an new PR at ​#4447.

[azaozz]

Replying to spacedmonkey:

@azaozz I think that is another for ticket that. This is a simple fix that can go out in the next release.

Sure, it makes sense to switch the option to not autoloading and close this ticket. I'll open another ticket for removing the rest of that code.

Not so sure about the rest of the changes though (the update_option() vs. update_site_option()). They look like an enhancement of a unused feature that is going to be removed soon?

[azaozz]

Related: #58302.

[spacedmonkey]

Replying to azaozz:

Not so sure about the rest of the changes though (the update_option() vs. update_site_option()). They look like an enhancement of a unused feature that is going to be removed soon?

But it is currently used right? It is used ​here. Until #58302 is committed which maybe in a future release ( if ever ), then we should fix what have.

[flixos90]

@azaozz I see your point, it seems pointless to autoload an option which will be removed soon. However, I also agree with @spacedmonkey that it is worth doing so to improve performance for the time being. If we get to a solution for #58302 that is committed in time for 6.3, then this change will naturally become pointless. But if the other ticket is more complicated than we think and ends up delayed, then it's reasonable to improve performance here.

In other words, I think this is worth moving forward regardless of #58302 - when the latter is implemented, it'll remove these parts of the code anyway.

That said, @spacedmonkey it would be great if you could share some performance benchmark to see what impact this has.

[spacedmonkey]

@flixos90
500 runs, on 2013 theme

	Trunk	PR
Response Time (median)	111.59	111.3
wp-load-alloptions-query (median)	0.63	0.64
wp-before-template (median)	24.2	23.9
wp-before-template-db-queries (median)	3.26	3.24
wp-template (median)	78.62	78.59
wp-total (median)	103.76	102.76
wp-template-db-queries (median)	16.75	16.78

Not a massive server response time improvement, but it is an improvement to database performance, as it removes a database query for EVERY page request, even REST API request.

[spacedmonkey]

In 55854:

Options, Meta APIs: Change the option can_compress_scripts to be autoloaded.

Ensure that the option can_compress_scripts is autoloaded on single sites, as this option is used in all requests. This change saves one database query per page request.

Props RavanH, spacedmonkey, costdev, azaozz, flixos90.
Fixes #55270.

Committed https://core.trac.wordpress.org/changeset/55854