#55270 closed defect (bug) (fixed)
Option can_compress_scripts not autoload causing extra DB query on every request
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 6.3 | Priority: | normal |
Severity: | minor | Version: | |
Component: | Options, Meta APIs | Keywords: | has-patch commit |
Focuses: | performance | Cc: |
Description
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.
Change History (17)
This ticket was mentioned in PR #2365 on WordPress/wordpress-develop by RavanH.
15 months ago
#1
- Keywords has-patch added
#2
@
13 months ago
- Version trunk deleted
Removing trunk
from Version as this has existed before the 6.0 cycle.
#5
@
5 weeks ago
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
.
This ticket was mentioned in PR #4447 on WordPress/wordpress-develop by @spacedmonkey.
2 weeks ago
#6
Trac ticket: https://core.trac.wordpress.org/ticket/55270
#7
@
2 weeks ago
- Milestone changed from Awaiting Review to 6.3
- Owner set to spacedmonkey
- Status changed from new to assigned
#8
follow-up:
↓ 9
@
2 weeks ago
@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.
#9
in reply to:
↑ 8
;
follow-up:
↓ 11
@
2 weeks ago
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?
#11
in reply to:
↑ 9
@
10 days ago
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.
#12
@
5 days ago
@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.
#13
@
5 days ago
@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.
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