Share buttons and page speed

Where the weight comes from

A share link is a few hundred bytes of HTML. What makes some share buttons heavy is everything around the link: official widget scripts from each network, iframes for like buttons, icon fonts, a plugin's own stylesheet and JavaScript on every page, and requests to count APIs made from the reader's browser. The old benchmark post on this domain claimed speed as a selling point, and it was right to: speed is the part of share buttons that affects every visitor, not just those who share.

Share buttons page speed: measure before you change anything

1. 01

   Pick one post

   Use a typical article, logged out, with caching on.

2. 02

   Run a lab test

   Record total requests, transferred bytes and the largest contentful paint.

3. 03

   Turn the buttons off

   Run the same test again. The difference is the real cost of your share setup.

4. 04

   List the requests

   In the browser's network panel, filter by domain to see which calls the buttons make.

Worked example: one post, four setups

The numbers below are invented but proportioned like real lab runs on a mid-range phone profile with a typical theme. The post is 1,800 words with three images. Each row is the same page with a different share setup, tested three times and averaged.

Two kilobytes separate plain links from no buttons at all. The plugin with cached counts costs one stylesheet, one script and one icon file, which is acceptable if the settings screen earns it. The browser-side count version adds a request per network on every view and pushes interaction delay because the callbacks run while the reader is trying to scroll. The official widgets nearly double transferred bytes and add almost a second to the largest paint, which is the usual reason a share plugin gets blamed for a slow site.

Fixes, from biggest to smallest

• Replace official widgets with plain share links. This removes most third-party requests at once.
• Load plugin assets only on templates that show buttons, not on every page.
• Fetch share counts on the server on a schedule and cache them; never from the browser. See share counts not updating for cache settings.
• Use inline SVG icons instead of an icon font.
• Lazy-load anything below the fold that genuinely needs a script.

Profiling in WordPress

Server-side slowness shows up as a slow first byte rather than slow rendering. A query monitoring plugin lists database queries and remote requests per page. If a sharing plugin makes a remote call to a count API while building the page, that call delays every uncached visit. Older profiler plugins were known to misattribute time, so confirm what they report with a before-and-after test.

Two settings decide most of the server-side cost. The first is the count cache lifetime: in the worked example a 6 hour transient means at most four count fetches per post per day, made by a scheduled task rather than a visitor. The second is asset loading: a plugin that enqueues its stylesheet and script only on is_singular() templates removes them from the home page, archives and every static page, which on a 2,000 page site is most of the crawl.

What goes wrong

• Testing logged in. Admin bars and disabled caches distort every number. Test logged out in a private window.
• One run. Lab results vary by 10 to 20 percent between runs. Take three and average them before claiming a change.
• Deferring the wrong script. Deferring a plugin's script can leave buttons unclickable until the page finishes loading, which raises interaction delay instead of lowering it.
• Counts fetched on every uncached page build. A remote call inside the template with no transient means every cache miss waits on a network API. Move it to a scheduled task; see running WordPress cron from the system scheduler.
• Sitewide assets. The share stylesheet loads on the home page, archives and the contact form where no row exists. Enqueue only on single posts.
• Icon font for four icons. A 70 KB font file to draw four glyphs. Four inline SVGs are under 2 KB.

Check it worked

• Requests and transferred bytes with the buttons on are within a few percent of the no-buttons run.
• The network panel shows no request to a network domain until a share button is clicked.
• The share row is clickable before the page finishes loading.
• Archive and home pages no longer load the share stylesheet or script.
• If counts are shown, the page source contains the numbers and the browser makes no count API call.

Plain links are described with markup in adding share buttons without a plugin. The privacy side of the same decision is in share buttons and GDPR, since every request a widget makes before a click is both a speed cost and a data transfer. Related guides are gathered on the share buttons hub.

Sources

• web.dev: loading third-party JavaScript
• web.dev: Interaction to Next Paint (INP)
• web.dev: Largest Contentful Paint (LCP)

Questions

Related reading

1. 01How to add social share buttons to WordPressAdd social share buttons to WordPress with a plugin, a block, or plain links in your theme. Placement, networks, counts and the checks to run afterwards.6 min read
2. 02Share count not updating or not accurate: a fix listShare counts stuck at zero or wrong? Work through tokens, caches, cron, URL variants and rate limits in order, and why you should never add fake shares.6 min read
3. 03Share buttons and GDPR: what needs consentWhich share buttons need consent under GDPR and ePrivacy rules, why plain share links usually do not, the two-click pattern, and privacy policy wording.6 min read