We frequently receive inquiries where people were told their site was slow, so they compressed all images and upgraded their server hosting plan, yet the perceived performance did not improve at all. Even on paper, while initial rendering became faster, the time until the page becomes interactive failed to shrink.
In this pattern, the root cause is often neither images nor servers. It is a state where tasks browsers can now perform natively are still being outsourced to JavaScript libraries. This applies particularly to sites built several years ago, where code that was necessary back then simply continues to be shipped even though it is no longer required.
When the true culprit behind slowness is neither images nor servers
When consulting on site speed, images and servers are usually the first things addressed. They are easy to understand and provide visible results. However, these two factors only impact the time "until the first frame appears," and do nothing to relieve subsequent sluggishness.
Breaking down what happens between opening a site and being able to interact with it looks like this:
- Receive (Network) — Where image compression and server upgrades take effect
- Read (Parse) — JavaScript file sizes translate directly into processing time
- Execute (Runtime) — Loaded code actually executes; where device performance differences matter most
Sites bogged down in the third stage manifest as that noticeable lag when tapped on an actual smartphone. What works here is not compression, but reducing the code you ship in the first place. What metrics to watch is summarized in How to read Core Web Vitals.
Criteria for identifying "dependencies you can now remove"
That said, deciding that "this library is no longer needed" is a daunting task for project owners. If removing it breaks the site in specific browsers, the consequences can be disastrous.
Baseline is the tool you can use to make that determination. Baseline consolidates whether a given feature works stably across all major browsers into a single badge, eliminating the need to cross-check compatibility tables yourself. The evaluation approach itself is covered in Designing corporate websites with Web Platform Baseline 2026, but its application here can be narrowed down to a single question.
Check each item one by one: "Is the problem this library solved now part of Baseline?" If it is, it's a candidate for removal; if not, leave it in place. That is all.
The removable payload can actually be quantified
In an audit workflow published by Smashing Magazine in August 2026, a mid-sized application can offload roughly 60KB to 90KB gzipped back to the platform. For example, a concrete case showed that removing just lodash.clonedeep and lodash.groupby saved approximately 8KB gzipped (Smashing Magazine).
Areas that frequently become candidates for replacement include the following:
- Dropdowns, tooltips, and modals — Libraries originally added for positioning and stacking order. CSS Anchor Positioning reached Baseline Newly Available in January 2026, making it possible to build these natively alongside the Popover API
- Page transition animations — With the View Transition API, switching between pages and states can be delegated to the browser
- Date, number, and currency formatting — Places where entire internationalization libraries were loaded
- Detecting when elements enter the viewport — Custom scroll-tracking implementations or dedicated libraries
The extent to which CSS can now handle these tasks is cataloged in What native features in modern CSS have replaced. Even prime examples that "traditionally required JavaScript," such as carousels, now have approaches built purely in CSS.
What breaks when removed, and what doesn't
Not everything can be removed. There is a clear line to draw to avoid misjudgments.
Things that rarely break are those whose appearance and behavior closely match the replacement. Operations with clear inputs and outputs, such as date formatting, array manipulations, and element visibility detection, have a predictable blast radius when replaced and fall well within testable boundaries.
Areas that require caution are those tied to accessibility. If a library previously handled keyboard navigation and screen reader announcements, switching to native features means you may need to recreate that functionality yourself. If you stop at "it looks the same," users navigating solely with a keyboard will be blocked.
What you should not remove is code carrying core business logic. High-stakes areas where failure causes significant loss—such as form validation or payment flows—are not targets to touch for minor performance gains. Breaking an inquiry form for the sake of saving a few dozen kilobytes is never worth the trade-off.
In other words, decide the removal order not by "magnitude of impact" but by "minimal risk if broken." Starting with the highest-impact items often leads to touching the most sensitive areas first.
You don't have to wait for a full site renewal
The advantage of reducing dependencies is that you can start without rebuilding the entire site. Removing a single library requires neither a design overhaul nor content migration. The effects are measurable in numbers, making it easy to decide whether to continue.
In terms of execution, start by requesting a list of "what is loaded and how much." Even when hiring a development agency, rather than asking for code modifications right away, ask for a list of current dependencies and the specific problems each one solves; candidates for removal will naturally emerge. Deciding how far to take the refactor after that visibility is achieved is more than enough.
Verifying results does not require specialized testing environments either. Open the same page on the same device under identical network conditions before and after changes, and compare real-world responsiveness alongside browser metrics. Having concrete numbers instead of "it feels faster" allows you to decide what to trim next. Whether this feedback loop can be established determines whether dependency reduction can be sustained over time.
Conversely, caution is warranted if this list cannot be provided. Modifying code without understanding what is running means side effects from removals will only be discovered post-launch. Whether such an inventory can be produced also serves as a reliable indicator of maintainability and ease of handover.
What to do next
Open your company's site on an actual smartphone and observe the response time upon tapping, rather than the initial page load. If this part feels sluggish, image compression and server upgrades will not resolve it.
Next, ask the agency that built your site to provide a list of currently loaded JavaScript and the purpose of each. If they cannot produce this list, or if there are items whose purpose cannot be explained, that is the first place you can start trimming.
If you are considering a complete site renewal purely due to loading speeds, a total rebuild may not be necessary. GleamHub accepts consultations for website creation and renewals, reviewing your current architecture starting with whether a rebuild is truly needed. Because optimal approaches depend on specific requirements, please consult with us individually via Contact Us.
