[wp-trac] [WordPress Trac] #65080: wp_admin_bar_add_color_scheme_to_front_end()` uses `wp_remote_get()` to fetch a local CSS file, causing an unnecessary HTTP request on every front-end page load

WordPress Trac noreply at wordpress.org
Thu Apr 16 13:52:07 UTC 2026


#65080: wp_admin_bar_add_color_scheme_to_front_end()` uses `wp_remote_get()` to
fetch a local CSS file, causing an unnecessary HTTP request on every front-
end page load
--------------------------+--------------------------
 Reporter:  edumembe      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  Toolbar       |     Version:  trunk
 Severity:  normal        |  Resolution:  duplicate
 Keywords:                |     Focuses:  performance
--------------------------+--------------------------
Changes (by sabernhardt):

 * keywords:  needs-patch =>
 * component:  HTTP API => Toolbar


Old description:

> **Description:**
>
> The function introduced in 7.0.0 (`wp-includes/admin-bar.php`) fetches
> the admin color scheme stylesheet via `wp_remote_get( $url )`, where
> `$url` points to a local file such as `/wp-
> admin/css/colors/modern/colors.min.css`.
>
> This results in a full HTTP round-trip to the server itself on every
> front-end page load when the admin bar is visible. On our test
> environment, this request consistently takes ~30ms, accounting for the
> majority of the performance difference between WordPress 6.9 and 7.0.
>
> **Steps to reproduce:**
> 1. Install WordPress 7.0 with any classic theme.
> 2. Log in as an administrator and visit the front end.
> 3. Open Query Monitor → HTTP API Calls.
> 4. Observe a GET request to `/wp-admin/css/colors/modern/colors.min.css`
> taking 20–50ms.
>
> **Expected behavior:**
> The CSS content should be read directly from the filesystem using
> `file_get_contents()` or `WP_Filesystem`, avoiding the HTTP overhead
> entirely. The file path is already resolvable locally via `ABSPATH`.
>
> **Suggested fix:**
> Replace `wp_remote_get( $url )` with a direct filesystem read:
>
> ```php
> $css_file = ABSPATH . 'wp-admin/css/colors/' . $color_scheme .
> '/colors.min.css';
> if ( ! file_exists( $css_file ) ) {
>     return;
> }
> $css = file_get_contents( $css_file );
> ```
>
> This eliminates the HTTP request while producing identical output.
>
> **Environment:**
> - WordPress 7.0
> - Classic (non-block) theme
> - Admin bar enabled on front end
> - PHP 8.x, OPcache enabled
>
> **Impact:** Performance regression on every front-end page load for
> logged-in users. The HTTP request is blocking and adds 20–50ms of latency
> unconditionally.

New description:

 The function introduced in 7.0.0 (`wp-includes/admin-bar.php`) fetches the
 admin color scheme stylesheet via `wp_remote_get( $url )`, where `$url`
 points to a local file such as `/wp-
 admin/css/colors/modern/colors.min.css`.

 This results in a full HTTP round-trip to the server itself on every
 front-end page load when the admin bar is visible. On our test
 environment, this request consistently takes ~30ms, accounting for the
 majority of the performance difference between WordPress 6.9 and 7.0.

 **Steps to reproduce:**
 1. Install WordPress 7.0 with any classic theme.
 2. Log in as an administrator and visit the front end.
 3. Open Query Monitor → HTTP API Calls.
 4. Observe a GET request to `/wp-admin/css/colors/modern/colors.min.css`
 taking 20–50ms.

 **Expected behavior:**
 The CSS content should be read directly from the filesystem using
 `file_get_contents()` or `WP_Filesystem`, avoiding the HTTP overhead
 entirely. The file path is already resolvable locally via `ABSPATH`.

 **Suggested fix:**
 Replace `wp_remote_get( $url )` with a direct filesystem read:

 {{{#!php
 $css_file = ABSPATH . 'wp-admin/css/colors/' . $color_scheme .
 '/colors.min.css';
 if ( ! file_exists( $css_file ) ) {
     return;
 }
 $css = file_get_contents( $css_file );
 }}}

 This eliminates the HTTP request while producing identical output.

 **Environment:**
 - WordPress 7.0
 - Classic (non-block) theme
 - Admin bar enabled on front end
 - PHP 8.x, OPcache enabled

 **Impact:**
 Performance regression on every front-end page load for logged-in users.
 The HTTP request is blocking and adds 20–50ms of latency unconditionally.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65080#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list