Skip to content

Latest commit

 

History

History
18 lines (17 loc) · 1.75 KB

performance.md

File metadata and controls

18 lines (17 loc) · 1.75 KB

How I debugged performance

  • enable webpack bundle analyzer
  • from here you can see which packages are causing trouble (the biggest ones)
    • in my case text-encoding was the problem
  • to find where text-encoding was being used I did a quick search through my codebase
    • no direct imports were present
  • next I ran yarn why text-encoding which revealed that expo-three -> @expo/browser-polyfill depended on it.
    • But that library shouldn't do anything because we're already running in the browser, so it had to be some other file referencing an already included package.
  • To find the actual problem file I rebuilt the project with EXPO_WEB_DEBUG=true expo build:web
    • This will build your project but prevent terser from minimizing the values
    • It'll also keep the paths and hints to why a file wasn't tree-shaken (it's extremely helpful)
  • Then I searched for text-encoding in the web-build/js/*.js files
  • I found that a file ./node_modules/expo-three/build/loaderClassForExtension.js had required a file from three that needed text-encoding.
    • You may think lazy loading a file with require() is the most optimal way to include files but that's not the case with Webpack. In Webpack the tree-shaking uses keywords like import/export to detect what can be safely removed.
    • Because loaderClassForExtension.js had both imports and requires Webpack just skipped tree-shaking it altogether.
    • Quickly editing the node_modules copy of expo-three verified that this was indeed the problem
    • After building again with the EXPO_WEB_DEBUG flag off, we could see that text-encoding was no longer in the bundle and our production build was now much smaller.