Is AllAccessible Slowing Down My Site?
Overview
If you've run a speed test or looked at your browser's network tab and noticed the AllAccessible widget, you might be wondering whether it's affecting your page load. This is a fair question — every third-party script has some cost.
The short answer: the AllAccessible widget is built to load asynchronously, so it does not block your page from rendering. The initial script is small, and heavier features only load when a visitor actually opens the accessibility menu. A slow-looking request to the widget in a network log is not the same thing as a slow page.
This article explains how the widget loads, how to measure its real impact correctly, and what's normal versus what's worth investigating.
Who This Is For
Site owners who saw the widget in a PageSpeed, Lighthouse, or GTmetrix report
Developers reviewing the network waterfall on their site
Anyone who noticed a widget request taking (for example) around a second and wants to understand it
What You'll Learn
How the AllAccessible widget actually loads
Why an async script doesn't block your page
The difference between a slow request and a slow page
How to measure the widget's real impact with browser tools
Practical steps if you think something is wrong
How the Widget Loads
The AllAccessible widget is designed around a simple principle: stay out of the way of your page rendering.
1. It loads asynchronously.
The standard install snippet adds the script with the async attribute and injects it dynamically into the page. Both of these mean the browser downloads and runs the widget in parallel with your page — it does not pause HTML parsing or delay when your content appears. Here's the relevant part of the standard snippet:
<script>
(function(d) {
var s = d.createElement("script");
s.setAttribute("data-accessible-account-id", "YOUR_ACCOUNT_ID");
s.setAttribute("id", "allAccessibleWidget");
s.async = true; // ← loads without blocking your page
s.setAttribute("src", "https://api.allaccessible.org/widget/YOUR_ACCOUNT_ID.js");
d.head.appendChild(s);
})(document)
</script>
2. The initial script is small, and features load on demand.
The first thing that loads is a lightweight loader — just enough to place the accessibility button on your page. The bulk of the accessibility features are lazy-loaded: they're only fetched when a visitor actually opens the menu and uses them. Most visitors who never open the widget never download those extra pieces.
3. It's served from our global CDN.
The widget is delivered from https://api.allaccessible.org/widget/{your-account-id}.js through our content delivery network, which serves cached copies from locations close to your visitors. After the first visit, the file is typically served from the browser's cache on subsequent page loads.
"But I See a 1-Second Request in My Network Tab"
This is the most common source of confusion, so it's worth being precise.
A slow request (the time it takes to fetch a single file) is not the same as a slow page (the time it takes your content to become visible and usable). Because the widget loads asynchronously:
Your text, images, and layout render without waiting for the widget.
The widget request happens alongside your page, not in front of it.
A widget request that takes, say, ~1 second does not add ~1 second to when your visitors see your content.
Think of it like a guest arriving at a party that's already underway — the party (your page) doesn't stop and wait at the door for them.
There are also legitimate reasons a single request can look slow in a one-off measurement:
First (uncached) load is slower than repeat loads, where the file is served from cache.
Cold cache at the edge — the very first request from a region may take longer, then speeds up for later visitors.
Your own network conditions at the moment you ran the test.
Speed-test tools often measure a cold, single, throttled load — a worst case, not what most of your visitors experience.
How to Measure the Real Impact
Rather than reacting to a single number, measure what actually matters — whether the widget delays your content.
Option 1: Browser DevTools (Network tab)
Open your site in Chrome (or another browser) in a private/incognito window.
Press F12 to open Developer Tools and click the Network tab.
Reload the page and watch the request waterfall.
Find the request to
api.allaccessible.org/widget/....
What to look for:
Confirm the request runs in parallel with your other resources, not blocking them.
Note whether it's marked as a cached load on your second refresh (repeat visits should be faster).
Check that your page's main content appears before the widget finishes — it should.
📷 DevTools Network waterfall showing the widget request loading in parallel, not blocking page content
Option 2: Lighthouse / PageSpeed
Run a Lighthouse report (built into Chrome DevTools) or PageSpeed Insights.
Look at the real user-experience metrics rather than a raw file-timing number:
Largest Contentful Paint (LCP) — when your main content is visible
Cumulative Layout Shift (CLS) — visual stability
Total Blocking Time (TBT) — how much the main thread is blocked
Compare the same page with and without the widget snippet to see the true difference. An async, on-demand widget should have a modest effect on these metrics.
📷 Lighthouse report highlighting LCP, CLS, and Total Blocking Time
Option 3: The honest before/after test
The most reliable check is a direct comparison:
Measure your page's load metrics with the widget installed.
Temporarily remove the snippet and measure again.
Compare the rendering metrics (LCP, CLS), not just the size of the network waterfall.
This isolates the widget's real contribution to what your visitors experience.
What's Normal
The widget request appearing in your network log — normal. Every third-party tool shows up there.
A slightly slower first load, then faster cached loads afterward — normal.
The accessibility button appearing a moment after your main content — normal and by design. The widget deliberately loads after your content so it never delays it.
Additional small downloads only when a visitor opens the menu — normal. That's the on-demand design working as intended.
We won't claim the widget has "zero impact" — no honest third-party script can. What we can say is that it's designed to minimize that impact: load asynchronously, keep the initial download small, defer features until they're needed, and serve everything from a CDN with caching.
When Something Might Actually Be Wrong
Investigate further if you see:
Your page visibly waiting on the widget before content appears (this should not happen with the standard async snippet).
The snippet installed without
async, or placed in a way that blocks rendering — re-check against the standard installation snippet.The widget script failing to load (errors in the browser Console, F12).
A local plugin, tag manager, or performance/optimization tool changing how the script is injected.
If you run into any of these, gather the details below and contact support.
Frequently Asked Questions
Q: Does the widget block my page from loading?
A: No. It loads asynchronously, so your content renders without waiting for it.
Q: Why did a speed test flag the widget then?
A: Speed tests often list every third-party request and measure a cold, throttled, single load. That can make a request look slow in isolation even though it isn't delaying your visible content. Focus on rendering metrics like LCP and CLS.
Q: I saw the widget request take about a second. Is that adding a second to my load time?
A: No. Because it loads in parallel with your page, the request time is not added on top of when your content appears. Compare your LCP with and without the widget to see the real difference.
Q: Will every visitor download all the accessibility features?
A: No. The heavier features load on demand — only when a visitor actually opens the accessibility menu. Visitors who never open it don't download them.
Q: Does caching help?
A: Yes. The widget is served from our CDN, and after the first load the browser typically serves it from cache on later page views.
Q: How can I prove the impact to myself?
A: Run a before/after test — measure your page with the snippet, remove it, measure again, and compare the rendering metrics (not just the network waterfall).
Getting Help
If you believe the widget is genuinely slowing your site, please gather:
Your website URL
A screenshot of your Network tab (F12 → Network) showing the widget request
Your Lighthouse or PageSpeed Insights results (ideally with and without the widget)
Any errors from the browser Console (F12 → Console)
Details of any caching, optimization, or tag-manager tools on your site
Send these to [email protected] and we'll help you diagnose it.
Related Articles
Need Help?
For help diagnosing widget performance, contact [email protected] with the details listed above.
Last Updated: July 2026
Article Category: Troubleshooting
Related Systems: JavaScript Widget, CDN Delivery, Site Performance