6
Wack
5y

Question to the frontend devs: I'm currently trying to optimize part of our JS. How do sourcemaps influence loading/rendering Speed in the Browser?

In the `webpack.config.js` we use uglify as minimizer for js. It has the option `sourceMap` Set to `true`. Now as I understand it, this caused it to Inline a sourcemap inside the JS file (which leads to a slightly bigger file size and thus longer load time for the generated file...).

My Question: should sorcemaps be enabled for prod (minified) files? Why yes, why no? Do they help the browser parse the JS faster?

Comments
  • 2
  • 6
    Source maps are only for debugging minified and bundled scripts so you don't need (or want) them for prod libs
  • 4
    Yes, typically I'd say you want sourcemaps for prod.

    Maps only download when you open inspector. They are for you to debug prod code that is minified or whatever you do in your pipe because it's production.

    The added load/slight performance hit usually outweighs the lack of not being able to debug a prod issue.

    We disable them for dev and only build them for production (dev is typically unminified so no need, makes local builds faster when doing development).
  • 3
    @Vip3rDev He said they use inline source maps though
  • 3
    @12bitfloat oh.. Must of glossed over that point.

    Hes correct then that you do NOT want inline source maps for production, that is a performance hit that can be avoided.

    Ideally, provide separate .map files so they only load when someone pops inspector open.

    This is a great article that helped me with this issue using webpack as part of my build pipeline.

    https://survivejs.com/webpack/...
  • 1
    Those in favor of providing sourcemaps: why would you want anyone to be able to debug your production js code? Personally I would always advise against such debugability as to mitigate any attack as much as possible.
  • 3
    @CodeMasterAlex because frontend code can be hidden by obscurity? Come on, if it's frontend it's public.
  • 0
    @Wombat still, highly obfuscated code is much harder to understand. Of course, front end will always be front end, but the harder you make it, the better. At my current company (bank) we have everything assessed for security reasons by a 3rd party specialist in pen testing and other security related testing. Not obfuscating code or obfuscating and providing sourcemaps will yield a critical security finding. It is all about making it as hard as possible for an attacker and if it helps even a little by not providing sourcemaps then don't provide them.
  • 2
    Ideally you have a non-prod staging environment with identical code to debug prod issues in, then you don't really need prod source-maps at all (assuming you have decent logging and any other tools required to reproduce the issue).

    Otherwise they are useful (don't inline them though). And anyone who wants to debug or read your code can fairly easily de-compile it, so vulnerability really isn't a concern.
  • 1
    I do have staging setup, however it geht's the exactly same code as live and I run the "build" script for the assets on my machine... Yeah I should throw in some CI/CD magic there. Currently it's just dev and stage, where dev runs with debug settings and stage with prod settings connecting to a second db and automatically grabing code from github, once I push it...
  • 1
    @CodeMasterAlex have you heard about http://www.jsnice.org/ if not, try and Run your stuff through it... It'll probably blow your mind. Also ask your pen testers, if they are aware of such tools...
  • 1
    Yes, people can debug your obfuscated public JS code. But just out of principle I'm not going to make this easier for people. Let them put some minimal effort. No source map in production for my code. Always glad to see source naps for other's public code though. And yeah , separate staging branch for that.
Add Comment