"Our homepage slideshow stutters on mobile, and images occasionally overlap each other. It worked fine when it was first built. On top of that, the entire page feels slow to load." During a recent consultation regarding improvements to a corporate website, a client representative brought this issue to us. Looking at developer tools, a hefty JavaScript library was being loaded just for a single small slider on the homepage.
Homepage sliders (carousels) are a subtle yet frustrating pain point across many websites: heavy, prone to breaking, and slow. Making matters worse, rebuilding them is difficult because they are tightly coupled with existing libraries. In 2026, however, the landscape changed. With carousels now buildable using pure CSS, a viable alternative that does not rely on JavaScript libraries has become a reality. In this article, we break down why traditional sliders break so easily, what changes with native CSS, and whether to adopt it fully in client projects, taking real-world browser support into account.
Why traditional sliders are heavy and prone to breaking
First, let us examine the underlying causes. Traditional carousels have largely relied on JavaScript libraries, introducing three major weaknesses.
The first is bloat. Loading tens of kilobytes of libraries just to advance through slides is commonplace. Because sliders often occupy prominent positions on homepages, this delays initial rendering and degrades performance metrics like those discussed in our Core Web Vitals article.
The second is fragility. Libraries release updates and can conflict with other dependencies. The opening remark—"it worked when first built, but broke later"—almost always stems from such compatibility issues. Inherited websites often reach a point where no one understands the internals, making developers hesitant to touch them.
The third is poor accessibility. Custom-built sliders frequently leave keyboard navigation and screen reader support half-baked, making them costly and tedious to fix retroactively.
Carousels can now be built entirely with CSS
This is where new CSS pseudo-elements come in. The CSS Overflow Level 5 specification introduced ::scroll-button() and ::scroll-marker(), making it possible to create previous/next buttons and pagination indicator dots without any JavaScript.
The mechanism is simple. Arrange slides inside a horizontally scrollable container and snap them one by one using scroll snap. Then, generate previous/next buttons using ::scroll-button() and pagination dots using ::scroll-marker(). Clicking a dot jumps to the respective slide, and clicking a button moves back or forward—all handled natively by the browser as standard features.
.carousel {
scroll-snap-type: x mandatory;
overflow-x: auto;
scroll-marker-group: after; /* ドット群を下に配置 */
}
.carousel > .slide {
scroll-snap-align: center;
}
/* 各スライドに対応するドットを生成 */
.carousel > .slide::scroll-marker {
content: "";
}
/* 前後の送りボタンを生成 */
.carousel::scroll-button(left) { content: "‹"; }
.carousel::scroll-button(right) { content: "›"; }Zero external libraries are required. Highlighting the active dot indicator (:target-current) and managing keyboard navigation are handled directly by the browser. This is part of the ongoing evolution where CSS steadily incorporates UI patterns previously handled by JS into standard features, a broader trend explored in our modern native CSS features article.
Is it ready for full adoption in client work? The reality of browser support
While attractive, jumping in and adopting this across all client sites tomorrow would be premature. This is the most critical factor to evaluate.
::scroll-button() and ::scroll-marker() gained support in Chrome 135 (Spring 2025) and work widely across Chromium-based browsers. However, as of mid-2026, Firefox support remains partial, meaning behavior is not identical across all browsers. Depending on what browser a visitor uses, navigation buttons and indicator dots might not render.
This is where progressive enhancement proves valuable. If the baseline is built as a clean, horizontally scrollable container, visitors on unsupported browsers can still swipe through all slides with a finger or trackpad. Supported browsers then layer buttons and pagination dots on top. Built so that it remains functional without the feature and becomes more convenient with it, you can safely introduce it today without being held back by browser support.
| Traditional JS libraries | Native CSS + Fallback | |
|---|---|---|
| Additional overhead | Tens of KB of libraries | Virtually zero (CSS only) |
| Risk of breaking on update | Prone to layout breaks from dependency conflicts | Low risk because it uses standard browser features |
| Unsupported browsers | Depends on library implementation | Functions as standard horizontal scroll |
Case study: A company that removed a heavy slider to restore performance and maintainability
Here is a concrete example. On a corporate website for a manufacturing firm (kept anonymous), the client reported that their homepage slider was sluggish on mobile, occasionally broke its layout, and could no longer be fixed because they were no longer working with the agency that built it. Investigation revealed that a heavy library and several outdated dependencies were loaded exclusively for that slider, visibly slowing down the homepage's initial render.
We replaced the slider component with a native CSS carousel. Structuring the foundation as pure horizontal scrolling and layering navigation buttons and dots for supported browsers allowed us to strip away the entire legacy library bundle. As a result, heavy scripts disappeared from the homepage, initial load times dropped, and concerns about layout breaks from future updates vanished. No flashy features were added. What delivered results was returning UI that never needed JS in the first place back to robust, native standards. Where animated expressions were needed, we paired this with techniques from our article on scroll-driven animations, which also require no JS.
Start with your heaviest and most broken carousel first
Native CSS carousels are not a magic bullet meant to replace every slider overnight. However, replacing a single high-profile component that impacts page load speed and frequently breaks due to libraries—such as a homepage banner—yields massive benefits. The most practical starting point is to pick the heaviest or most broken carousel on your site and replace it with a fallback-equipped implementation.
If your homepage slider is sluggish or broken, if you cannot reach the original developer to fix it, or if you want to improve page load speed, feel free to contact GleamHub via our website production and renewal consultation. From auditing existing sliders to replacing them with native CSS and engineering resilient fallbacks for unsupported browsers, we will work with you without over-engineering.
Sources
- Carousels Using CSS | Chrome for Developers
- Creating Carousels with CSS - MDN Web Docs
- Carousels Can Now Be Implemented with Pure CSS! How to Use ::scroll-button() and ::scroll-marker() | Coliss
- Scroll-Driven CSS in 2026: Building Carousels Without JavaScript | SitePoint
- Building Pure CSS Carousels Using ::scroll-button and ::scroll-marker
