Best Practices for Loading SpreadJS Libraries – Performance Optimization & Lazy

Best Practices for Loading SpreadJS Libraries – Performance Optimization & Lazy

Posted by: luisdaniel.madrigal on 9 July 2025, 10:57 am EST

• 

  luisdaniel.madrigal

  • Post Options:
  • Link
    Copy

  Posted 9 July 2025, 10:57 am EST - Updated 9 July 2025, 11:01 am EST

  Hi Mescius Support Team,

  We are currently using SpreadJS in a TypeScript-based web application, and I’d like to ask for advice regarding best practices to improve performance when loading the SpreadJS libraries.

  This is how we are currently importing the packages:

  // SpreadJS styles
  import '@mescius/spread-sheets/styles/gc.spread.sheets.excel2016colorful.css';
  import '@mescius/spread-sheets-designer/styles/gc.spread.sheets.designer.min.css';
  
  // SpreadJS dependencies
  import '@mescius/spread-sheets-io';
  import '@mescius/spread-sheets-shapes';
  import '@mescius/spread-sheets-charts';
  import '@mescius/spread-sheets-print';
  import '@mescius/spread-sheets-barcode';
  import '@mescius/spread-sheets-pdf';
  import '@mescius/spread-sheets-designer-resources-en';
  import '@mescius/spread-sheets-designer';
  
  // SpreadJS Designer and Core
  import * as GCDesigner from '@mescius/spread-sheets-designer';
  import * as GC from '@mescius/spread-sheets';

  While everything works correctly, all these libraries combined are adding approximately 26 MB to our bundle, which has a noticeable impact on initial load performance.

  Additionally, based on future business needs, we may need to include even more SpreadJS libraries, which makes scalability and modularity even more critical.

  Questions:
  
  Are there recommended best practices for loading SpreadJS libraries more efficiently?

  Is it possible to lazy load or dynamically import some of the features (like charts, PDF export, designer, etc.) on demand, rather than including everything upfront?

  Are there tree-shaking strategies or modular approaches you recommend to reduce the initial bundle size?

  We want to ensure we’re following the most efficient approach for performance and scalability.

  Any tips or examples would be greatly appreciated!

  Best regards,
  
  Luis

• 

  priyam.kushwaha

  

  • Post Options:
  • Link
    Copy

  Posted 10 July 2025, 5:36 am EST

  Hi Luis,

  We understand your concerns regarding bundle size and performance when working with multiple SpreadJS modules. Here are some recommendations and best practices to help optimize SpreadJS loading in a scalable and efficient way:

  1. Use Individual Modules

  To minimize bundle size, consider using SpreadJS with individual modules instead of the full bundle. This allows you to include only the components you need. Refer to the following documentation for guidance:
  
  Using SpreadJS with Individual Modules: https://developer.mescius.com/spreadjs/docs/javascript-frameworks/spreadjs-with-individual-modules

  2. Lazy Load the Designer Component

  The Designer is relatively heavy. If it’s only required in specific views (such as an admin panel), consider lazy-loading it and its related styles. This ensures it only loads when needed, improving initial load times for users who don’t access the Designer.

  3. CDN-Based Loading (Optional Strategy)

  As an alternative, you can load SpreadJS modules via CDN to reduce your bundle size and take advantage of browser caching. This approach moves the library loading outside of your main bundle.
  
  Please note: using CDN requires proper handling of global variables (e.g., window.GC) and is better suited for teams familiar with dynamic script loading patterns.

  Best regards,
  
  Priyam