Optimizing Nutrient size for web applications

When integrating Nutrient into web applications, you may have some concerns about the library’s size. This guide explains the reasons behind this size and provides strategies to optimize it.

Understanding Nutrient components

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

  1. Core library

    • Contains essential functionality for PDF rendering and manipulation.

    • Includes various modules for different PDF operations.

  2. GdPicture module

    • A separate Wasm (WebAssembly) module used for document conversion and template population.

    • Crucial for Office-to-PDF conversion functionality.

    • Significantly contributes to the overall size but is essential for certain conversion features.

  3. Localization files

    • Supports multiple languages and regions.

Deep dive into GdPicture

GdPicture is a critical component of Nutrient, especially for document conversion capabilities like the following.

  1. Functionality

    • Enables conversion of various document formats to PDF, including Office files.

    • Provides template population features for dynamic document generation.

  2. Performance characteristics

    • Loaded on demand, minimizing initial load times.

    • Utilizes WebAssembly for efficient execution in the browser.

  3. Customization options

    • Can be excluded if Office-to-PDF conversion isn’t required.

    • Offers control over which conversion capabilities to include.

Optimization strategies

To optimize the overall size of the Nutrient dependency, consider the following approaches.

  1. Lazy loading implementation

    • Use dynamic import to load Nutrient only when needed:

    PSPDFKit = await import("pspdfkit");

  2. Caching Nutrient assets

    • Implement effective caching strategies for Nutrient assets.

    • Use service workers for efficient caching.

  3. Selective feature usage

    • If document conversion isn’t needed, consider excluding the GdPicture module.

    • Use Nutrient’s modular structure to include only necessary features (e.g. Office conversion).

  4. CDN hosting for optimal delivery

    • Host Nutrient files on a content delivery network (CDN).

    • Reduces load on your main server and improves global access speeds.

    • Use Brotli or Gzip compression for serving Nutrient assets.

Some of the above techniques are extensively outlined and explained in our performance best practices guide.

Summary

While Nutrient’s size, including the GdPicture module, may initially seem substantial, its modular structure and lazy loading capabilities ensure it doesn’t negatively impact end user performance when properly optimized. For applications primarily using PDF web review and Office-to-PDF conversion, retaining the full library, including the GdPicture module, is recommended.

By implementing the strategies outlined in this guide, developers can optimize their Nutrient integration to balance functionality and performance requirements effectively. Remember that Nutrient’s architecture is designed for optimal performance, with components being loaded on demand, minimizing the actual impact on end user experience.

For further assistance or questions about optimizing Nutrient for your specific use case, including detailed queries about GdPicture integration, refer to our documentation or contact our Support team.