Optimize Nutrient PDF SDK size | Nutrient

Nutrient Web SDK’s size reflects its comprehensive feature set. This guide explains what contributes to the size and how to optimize it.

Understanding Nutrient components

Nutrient Web SDK’s size is primarily due to its comprehensive feature set. Key components contributing to the size include the following:

  • Core library — Contains essential functionality for PDF rendering and manipulation. Includes various modules for different PDF operations.
  • GdPicture module — A separate WebAssembly (Wasm) module used for document conversion and template population. It’s crucial for Office-to-PDF conversions, among others, and it significantly contributes to the overall size.
  • Localization files — Supports multiple languages and regions.

Deep dive into GdPicture

GdPicture is a critical component of Nutrient, especially for document conversion capabilities:

  • Functionality — Enables conversion of various document formats to PDF, including Office files. Provides template population features for dynamic document generation.
  • Performance characteristics — Loaded on demand, minimizing initial load times. Uses WebAssembly for efficient execution in the browser.
  • Customization options — Controls which conversion capabilities to include. Exclude it if conversions such as Office to PDF aren’t required.

Optimization strategies

To optimize the overall size of the Nutrient Web SDK dependency, use the following approaches:

  1. Lazy loading implementation — Use dynamic import to load Nutrient only when needed:

    const NutrientViewer = (await import("@nutrient-sdk/viewer")).default;

  2. Preloading WebAssembly workers — After loading the SDK module but before opening a document, call NutrientViewer.preloadWorker() to fetch and compile WebAssembly artifacts in the background. This pairs well with lazy loading — import the module early, preload the worker, and the viewer is ready to render instantly when the user opens a document.

  3. Caching Nutrient assets — Implement effective caching strategies for Nutrient assets. Use service workers for efficient caching.

  4. Selective feature usage — If document conversion isn’t needed, exclude the GdPicture module. Use Nutrient’s modular structure to include only necessary features (for example, Office conversion).

  5. CDN hosting for optimal delivery — Host Nutrient files on a content delivery network (CDN). This reduces load on your main server and improves global access speeds. Use Brotli or Gzip compression for serving Nutrient assets.

For more detail on these techniques, refer to the performance best practices guide.

Summary

Nutrient’s modular structure and lazy loading capabilities ensure the SDK doesn’t impact end user performance when properly optimized. For applications using PDF web review and Office-to-PDF conversion, retaining the full library, including the GdPicture module, is recommended.

Nutrient’s architecture loads components on demand, minimizing the actual impact on end user experience. For further assistance with optimizing Nutrient for your specific use case, refer to the documentation or contact the Support team(opens in a new tab).