Optimization Detective currently only applies its optimizations by default when the user is not an admin. The logic is here:
|
$able = ! ( |
|
// Since there is no predictability in whether posts in the loop will have featured images assigned or not. If a |
|
// theme template for search results doesn't even show featured images, then this wouldn't be an issue. |
|
is_search() || |
|
// Since injection of inline-editing controls interfere with breadcrumbs, while also just not necessary in this context. |
|
is_customize_preview() || |
|
// Since the images detected in the response body of a POST request cannot, by definition, be cached. |
|
( isset( $_SERVER['REQUEST_METHOD'] ) && 'GET' !== $_SERVER['REQUEST_METHOD'] ) || |
|
// The aim is to optimize pages for the majority of site visitors, not those who administer the site. For admin |
|
// users, additional elements will be present like the script from wp_customize_support_script() which will |
|
// interfere with the XPath indices. Note that od_get_normalized_query_vars() is varied by is_user_logged_in() |
|
// so membership sites and e-commerce sites will still be able to be optimized for their normal visitors. |
|
current_user_can( 'customize' ) |
|
); |
|
|
|
/** |
|
* Filters whether the current response can be optimized. |
|
* |
|
* @since 0.1.0 |
|
* |
|
* @param bool $able Whether response can be optimized. |
|
*/ |
|
return (bool) apply_filters( 'od_can_optimize_response', $able ); |
This can be easily overridden via the following, which is super helpful during development (but see #1423):
add_filter( 'od_can_optimize_response', '__return_true' );
However, it can be confusing to be required to do this. The README includes this bit:
URL metrics are not collected for administrators because it is likely that additional elements will be present on the page which are not also shown to non-administrators, meaning the URL metrics could not reliably be reused between them.
Additional elements include Customizer scripts, edit post links, and so on.
If we included admins, then we'd need to modify od_get_normalized_query_vars() as follows to vary the URL Metrics by whether the user is an admin (due to the additional elements present for admins):
--- a/plugins/optimization-detective/storage/data.php
+++ b/plugins/optimization-detective/storage/data.php
@@ -82,6 +82,10 @@ function od_get_normalized_query_vars(): array {
$normalized_query_vars['user_logged_in'] = true;
}
+ if ( current_user_can( 'customize' ) ) {
+ $normalized_query_vars['admin'] = true;
+ }
+
return $normalized_query_vars;
}This means that for every URL, there would potentially be separate od_url_metrics posts for:
- Unauthenticated users.
- Logged-in users who aren't admins.
- Admin users.
Maybe this still isn't worthwhile to do and the existing logic is correct. But I wanted to open an issue to discuss further.
Optimization Detective currently only applies its optimizations by default when the user is not an admin. The logic is here:
performance/plugins/optimization-detective/optimization.php
Lines 82 to 104 in 08eba80
This can be easily overridden via the following, which is super helpful during development (but see #1423):
However, it can be confusing to be required to do this. The README includes this bit:
Additional elements include Customizer scripts, edit post links, and so on.
If we included admins, then we'd need to modify
od_get_normalized_query_vars()as follows to vary the URL Metrics by whether the user is an admin (due to the additional elements present for admins):This means that for every URL, there would potentially be separate
od_url_metricsposts for:Maybe this still isn't worthwhile to do and the existing logic is correct. But I wanted to open an issue to discuss further.