Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce the JavaScript Bundle Size of MapTiler SDK (Currently 1.1 MB) #160

Open
andreseloysv opened this issue Jan 28, 2025 · 4 comments
Open

Comments

@andreseloysv
Copy link

The current size of the MapTiler SDK JavaScript library is approximately 1.1 MB, which is relatively large and impacts the loading performance of web applications, especially on slower networks or resource-constrained devices. Reducing the library size will significantly improve usability and adoption for developers.

Proposed Solutions:
1. Tree-Shaking & Modularization:
• Break the library into smaller modules or sub-packages so that developers can import only the features they need. For example:

import { Map } from 'maptiler-sdk/core';
import { Marker } from 'maptiler-sdk/marker';

•	Ensure tree-shaking compatibility with modern bundlers like Webpack, Rollup, and Vite.

2.	Code Optimization:
•	Remove unused code, polyfills, or legacy support if unnecessary for modern browsers.
•	Minify the library further using tools like Terser or ESBuild.
3.	Distribute Gzipped/Brotli Versions:
•	Provide precompressed versions of the library (Gzipped and Brotli) to reduce the transfer size over the network. For example:
•	Original size: 1.1 MB
•	Gzipped: ~300 KB
•	Brotli: ~250 KB
4.	Optimize Dependencies:
•	Analyze and reduce external dependencies included in the library, especially large or redundant ones.
•	Replace bulky dependencies with lighter alternatives, or implement critical features natively.
5.	Split Development and Production Builds:
•	Offer a smaller, production-ready build that removes dev-specific features like verbose logging or debugging helpers.
6.	Improve Documentation on Custom Builds:
•	Provide clear guidance in the documentation on how developers can create a custom build of the library with only the features they need.
7.	Lazy Loading for Features:
•	Implement lazy loading for features like markers, geolocation, or map styles so they are only loaded when needed.

Why is This Important?
Reducing the size of the SDK will:
• Improve page load times.
• Reduce bandwidth usage for end-users.
• Enhance performance on mobile devices with limited resources.
• Align with best practices for modern web development.

Additional Context:
Please let us know if there are any existing plans or ongoing work to reduce the library size. If possible, we’d love to contribute or test any experimental builds to support this effort.

Thank you for your work on the MapTiler SDK and for considering this enhancement! Let me know if you need more details or benchmarks.

@petrsloup
Copy link
Member

Looking at the composition analysis at https://bundlephobia.com/package/@maptiler/sdk@3.0.1 it can be seen that 80% of the bundle size comes from maplibre-gl, so there's not much that we could do on the maptiler-sdk level.

It would definitely be beneficial to implement tree shaking of the whole library and it's already being discussed in maplibre: maplibre/maplibre-gl-js#977

As for the CDN builds of MapTiler SDK, we provide the minified versions of the library with CloudFlare CDN in front handling the transit compression, so people using that are actually getting a brotli/gzip compressed version.
I expect people using the NPM version to eventually bundle their application together with MapTiler SDK for production deployment and distribute over some compression-enabled system as well -- basically you never want to transfer uncompressed assets anyway.

@andreseloysv
Copy link
Author

From version 2.3.0 to 3.0.1, the library grew by 230KB. I think we can take steps to improve it.

@petrsloup
Copy link
Member

Looking more into this, there seems to be +110 kB jump between v2.3.0 and v2.4.0 (comparing the (self) portion at https://bundlephobia.com/package/@maptiler/sdk@2.3.0 vs https://bundlephobia.com/package/@maptiler/sdk@2.4.0).

But I cannot find anything that would explain the size increase in the changelog: v2.3.0...v2.4.0
Maybe adding the @maplibre/maplibre-gl-style-spec dependency?

Anybody interested in digging deeper?

@andreseloysv
Copy link
Author

Looking more into this, there seems to be +110 kB jump between v2.3.0 and v2.4.0 (comparing the (self) portion at https://bundlephobia.com/package/@maptiler/sdk@2.3.0 vs https://bundlephobia.com/package/@maptiler/sdk@2.4.0).

But I cannot find anything that would explain the size increase in the changelog: v2.3.0...v2.4.0 Maybe adding the @maplibre/maplibre-gl-style-spec dependency?

Anybody interested in digging deeper?

Maybe because of -> import { validateStyleMin } from "@maplibre/maplibre-gl-style-spec"; link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants