Tuning Swiper for Real Pages: Custom Pagination and Lazy Loading Without the Jank

A product gallery with forty high-resolution images will happily load all forty on first paint if you let it. On a mid-range phone over a mediocre connection, that means seconds of blank slider and a layout that jumps as images arrive. Swiper gives you two levers that fix most of this: lazy loading, which defers off-screen images, and a pagination system flexible enough to stay readable when forty bullets would be absurd. This post walks through both, with a configuration you can adapt directly. Examples assume Swiper 8 or later; version 6 changed initialization defaults, so check your installed version before copying anything.

Lazy loading: what it actually does

Swiper's lazy module swaps in an image's real src only when the slide approaches the viewport. You mark images with a placeholder class and a data attribute instead of a normal src:

<div class="swiper-slide">
  <img data-src="/photos/hero-01.jpg" class="swiper-lazy" alt="...">
  <div class="swiper-lazy-preloader"></div>
</div>

Then enable the module and control how far ahead Swiper loads:

const swiper = new Swiper('.swiper', {
  lazy: {
    loadPrevNext: true,      // preload adjacent slides
    loadPrevNextAmount: 2,   // how many neighbors
  },
});

The trade-off lives in loadPrevNextAmount. Set it to 0 and fast swiping shows preloader spinners; set it high and you've re-created the original bandwidth problem. For a full-screen gallery, 1–2 neighbors is usually the sweet spot. You can verify behavior in DevTools: open the Network tab, filter by images, and confirm that only the first few images request on load, with more appearing as you swipe.

Custom pagination that scales past ten slides

Default bullets fall apart with many slides — a row of forty dots is noise. Swiper's pagination supports a dynamicBullets mode that keeps only a window of bullets visible around the active one, and a renderBullet hook for full control:

pagination: {
  el: '.swiper-pagination',
  clickable: true,
  dynamicBullets: true,
  dynamicMainBullets: 5,
  renderBullet: function (index, className) {
    return '<span class="' + className + '">' + (index + 1) + '</span>';
  },
},

Two things to know here. First, clickable: true is required for bullets to respond to taps — it's off by default. Second, on mobile, clickable bullets can fight with swipe gestures if a user's drag starts on the pagination area. If you see missed swipes, try lowering touchRatio slightly or adding vertical separation between bullets and the slide container rather than disabling swipe entirely.

Responsive behavior and dynamic content

Lazy loading and pagination interact with responsive settings. A common pattern is fewer slides per view and fraction-style pagination on small screens:

breakpoints: {
  0: {
    slidesPerView: 1,
    pagination: { type: 'fraction' },
  },
  768: {
    slidesPerView: 3,
    pagination: { type: 'bullets', dynamicBullets: true },
  },
},

One caveat: if your slide markup changes dynamically (a CMS injecting slides after init), enable observer: true and observeParents: true, or Swiper will hold stale state — wrong bullet counts, lazy images that never load. With the observer on, Swiper re-reads the DOM on mutation. Test breakpoint behavior by resizing the viewport across your defined breakpoints and confirming slidesPerView and pagination type update without a manual re-init.

Verification and limitations

Don't trust the config; check the rendered result. After initialization, inspect the DOM for .swiper-pagination-bullet elements and confirm the count matches your slide count (or the dynamic window). In the console, swiper.params.lazy confirms the lazy settings that actually applied. Then do a before/after comparison: disable lazy loading, hard-refresh with the Network tab open, note total image bytes on first paint; re-enable and compare. The difference should be dramatic on image-heavy sliders — if it isn't, check that your images use data-src and the swiper-lazy class, since a plain src bypasses the whole mechanism.

A few limitations are worth knowing up front. Lazy loading only manages images inside slides — background images set via CSS load immediately regardless. Combining autoHeight: true with lazy images causes visible container reflow as each image arrives and reports its height; if that bothers you, set explicit aspect-ratio CSS on the image wrapper so the height is known before load. Finally, if you call slideTo() programmatically with a very low speed value on a heavily animated page, you may see dropped frames; test transitions on the slowest device you support, not your laptop.

The actionable takeaway: start with lazy.loadPrevNext: true, dynamic bullets with a small main-bullet window, and the observer enabled if your content is dynamic. Measure first-paint image bytes before and after — that number tells you whether the configuration is doing its job.