To stop the Dashicons stylesheet loading for ordinary visitors, dequeue it on wp_enqueue_scripts, but only when the user is not logged in:
add_action( 'wp_enqueue_scripts', function () {
if ( ! is_user_logged_in() ) {
wp_dequeue_style( 'dashicons' );
wp_deregister_style( 'dashicons' );
}
}, 100 );That is the whole fix, and the is_user_logged_in() guard is the part that matters. Logged-in users need Dashicons for the admin toolbar at the top of the page, so you only want to drop it for the anonymous visitors who never see that toolbar. The late priority (100) makes sure your dequeue runs after whatever enqueued the style in the first place.
What Dashicons is and why it loads on the front end
Dashicons is the icon font that ships with WordPress core. It is what draws the little icons throughout wp-admin: the menu glyphs, the toolbar icons, the buttons. It lives at wp-includes/css/dashicons.min.css and is registered under the handle dashicons.
On the front end it has exactly one legitimate job: the admin bar. When a logged-in user views the site with the toolbar showing, the toolbar's icons come from Dashicons, so core enqueues it. That is correct and you should not touch it.
The problem is that Dashicons frequently loads for logged-out visitors too, who have no admin bar and no use for it. That happens when a theme or plugin lists dashicons as a stylesheet dependency, or enqueues it unconditionally, often for a few icons it could have drawn with inline SVG. The usual culprits are Contact Form 7, Wordfence, and many page builders, all of which enqueue dashicons on the front end whether or not the current page uses it. The result is a render-blocking stylesheet request on every public page load, serving an admin icon font to people who will never see a single admin icon.
How much does this actually save?
The dashicons.min.css file is around 60 KB uncompressed, roughly 30 KB over the wire with gzip, and dropping it removes one render-blocking request from every public page. So if DevTools shows it transferring at ~30 KB, that is the gzipped wire size, not the 60 KB the file weighs on disk; both numbers describe the same stylesheet.
That said, the win is real but modest, and entirely conditional on your site actually loading the file. It beats the emoji or shortlink cleanups, because this is a real network request rather than a few bytes of inline output, but it is still one request. It compresses well (it is mostly repetitive icon-class rules), but it is a request the browser has to make and block on. Dropping it removes:
- One render-blocking stylesheet request from the
<head>on every front-end page (the request itself, plus the round trip). - The icon-font download that the stylesheet would pull in if any Dashicon glyph were actually rendered.
The honest part: if your theme is well built and does not load Dashicons for logged-out visitors, this snippet saves nothing, because there is nothing to dequeue. The whole point is to check first (the next section) and only apply it where the request is genuinely there and genuinely unused. Where it is, removing a render-blocking CSS request is a more meaningful win than trimming a head tag.
Check whether you even have the problem
Before adding the snippet, confirm Dashicons is loading for logged-out visitors, because on many sites it is not. Open the site in a private/incognito window (so you are logged out) and look at the page source or the Network tab for dashicons:
$ curl -s https://example.com/ | grep -i dashicons
<link rel='stylesheet' id='dashicons-css' href='https://example.com/wp-includes/css/dashicons.min.css?ver=6.8' media='all' />If that line is there when you are logged out, you have something to remove. If it is absent, your theme already does the right thing and you can skip this entirely. Do not add a dequeue for a style that is not being enqueued; it just adds code that does nothing.
Put it in a plugin, not the theme
As with the other head and asset cleanups, keep it out of functions.php so it survives a theme switch. Drop it into wp-content/mu-plugins/te-disable-dashicons.php:
<?php
/**
* Plugin Name: TE Disable Dashicons (Front End)
* Plugin URI: https://techearl.com/disable-dashicons-wordpress
* Description: Dequeues the Dashicons stylesheet for logged-out visitors, keeping it for the admin bar.
* Version: 1.0.0
* Author: Ishan Karunaratne
* Author URI: https://techearl.com
* License: GPL-2.0-or-later
* Text Domain: te-disable-dashicons
*/
add_action( 'wp_enqueue_scripts', function () {
// Logged-in users need Dashicons for the admin toolbar; only drop it for the public.
if ( ! is_user_logged_in() ) {
wp_dequeue_style( 'dashicons' );
wp_deregister_style( 'dashicons' );
}
}, 100 );If you would rather not touch PHP, performance plugins such as Perfmatters and Perform expose a "Disable Dashicons" toggle that does exactly this (logged-out only). It is the same dequeue under the hood, so the same caveat applies: check that nothing front-facing depends on the font before flipping it on.
Why dequeue and deregister, and why the late priority
Two small implementation points that decide whether this works.
wp_dequeue_style( 'dashicons' ) stops the already-queued style from printing. wp_deregister_style( 'dashicons' ) removes the registration entirely, so anything that later tries to enqueue it by handle finds nothing to enqueue. Using both is belt and braces: dequeue handles the normal case, deregister covers a plugin that enqueues it later in the request. If a dependency chain still pulls it in after deregistering, that is a sign something genuinely depends on it (see the caveat below).
The priority 100 matters because hooks run in priority order. Themes and plugins typically enqueue their styles at the default priority 10 on wp_enqueue_scripts. If your dequeue ran at 10 as well, it might fire before the thing that adds Dashicons, and there would be nothing to remove yet. Running at 100 puts you after the enqueuers, so the style is in the queue by the time you take it out.
The caveat: make sure nothing front-facing uses it
Some themes legitimately use Dashicons for visible front-end elements: icons in menus, social links, buttons, a mobile nav toggle. If you dequeue it blind and those icons turn into empty boxes or missing glyphs, that theme was relying on it.
So after applying the snippet, click through the public site logged out and look for broken icons. If everything renders, you are clear. If something breaks, either leave Dashicons in place for that site, or (better) replace those few theme icons with inline SVG and then drop the whole font. Do not ship the dequeue without that visual check.
Verify it worked
Logged out, the stylesheet should be gone:
$ curl -s https://example.com/ | grep -i dashicons
(no output)And logged in, it should still be present (so your admin bar icons survive). Load the front end while logged in and confirm the dashicons-css line is back and the toolbar icons render. If the style is still there when logged out, the usual causes are a page cache serving old HTML (purge it), a priority that runs too early (raise it), or a plugin re-enqueueing it after your callback, in which case something depends on it and you should investigate before forcing it out.
See also
- Clean Up wp_head in WordPress: the wider sweep of default WordPress output, head tags and assets you can safely trim
- Disable WordPress Emojis to Speed Up Your Site: the head-script version of the same conditional-loading problem
- Remove the WordPress Shortlink: a head-tag and HTTP-header cleanup for the same must-use plugin
- How to Optimize WooCommerce: where to spend effort when a store is genuinely slow, beyond asset trimming
Sources
Authoritative references this article was fact-checked against.
- wp_dequeue_style(): WordPress Developer Referencedeveloper.wordpress.org
- wp_deregister_style(): WordPress Developer Referencedeveloper.wordpress.org
- wp_enqueue_scripts hook: WordPress Developer Referencedeveloper.wordpress.org
