1. 24 8月, 2020 1 次提交
    • T
      Add webpack 5 cache invalidation (#16494) · f2ba97d8
      Tim Neutkens 提交于
      Handles:
      
      - Next.js version
      - next.config.js `env` key
      - `NEXT_PUBLIC_` prefixed environment variables
      - next.config.js keys that affect performance
      
      Ideally we don't invalidate the whole cache when `NEXT_PUBLIC_` / `env` key variables change, but this is just to initially make the caching reliable, this behavior is similar to the current webpack 4 behavior, so it can only be improved 👍 
      f2ba97d8
  2. 22 8月, 2020 1 次提交
  3. 18 8月, 2020 1 次提交
    • T
      Add experimental webpack 5 cache option (#16307) · 0fbc9d23
      Tim Neutkens 提交于
      Don't use this yet as it's still being developed. This is a first iteration that enables the webpack cache. There's still more to do here, for example if css modules are used there's currently a bug where webpack does not save the cache for browser compilation (impacting build performance). @sokra is going to look into that issue.
      0fbc9d23
  4. 13 8月, 2020 1 次提交
  5. 11 8月, 2020 1 次提交
  6. 10 8月, 2020 2 次提交
  7. 06 8月, 2020 2 次提交
    • J
      882288b5
    • A
      Add experimental image post-processing (#15875) · b6060fa4
      Alex Castle 提交于
      This PR adds a second experimental post-processing step for the framework introduced by @prateekbh in #14746. The image post-processing step scans the rendered document for the first few images and uses a simple heuristic to determine if the images should be automatically preloaded.
      
      Analysis of quite a few production Next apps has shown that a lot of sites are taking a substantial hit to their [LCP](https://web.dev/lcp/) score because an image that's part of the "hero" element on the page is not preloaded and is getting downloaded with lower priority than the JavaScript bundles. This post-processor should automatically fix that for a lot of sites, without causing any real performance effects in cases where it fails to identify the hero image.
      
      This feature is behind an experimental flag, and will be subject to quite a bit of experimentation and tweaking before it's ready to be made a default setting.
      b6060fa4
  8. 05 8月, 2020 1 次提交
    • J
      Run Fast Refresh Loader in Babel Loader (#15851) · 754ec664
      Joe Haddad 提交于
      Next.js plugins like `@next/mdx` inject additional webpack loaders to compile files, but they omit the necessary loader for Fast Refresh to work.
      
      Instead of making these files deopt out of Fast Refresh, we can automatically detect and inject the loader in these cases.
      
      Fixes #13574
      754ec664
  9. 03 8月, 2020 3 次提交
  10. 31 7月, 2020 1 次提交
  11. 30 7月, 2020 1 次提交
  12. 28 7月, 2020 3 次提交
  13. 21 7月, 2020 1 次提交
  14. 20 7月, 2020 2 次提交
  15. 17 7月, 2020 1 次提交
  16. 16 7月, 2020 1 次提交
  17. 12 7月, 2020 1 次提交
  18. 10 7月, 2020 1 次提交
  19. 09 7月, 2020 2 次提交
  20. 06 7月, 2020 1 次提交
  21. 01 7月, 2020 1 次提交
  22. 28 6月, 2020 1 次提交
    • T
      Introduce react profiling production flag (#13873) · 1aed9eaa
      Todor Totev 提交于
      Closes [13709](https://github.com/vercel/next.js/issues/13709).
      
      The solution works, **(tested and confirmed with true and false flags with the latest next version)** though I am quite sure this is not the most elegant and proper way to implement it. I have spent the good part of yesterday and today's morning in order to make it more generic but since it's my first time working with anything related to webpack I have struggled miserably. Last, but not least I'm unsure if this is the most proper naming for the flag.
      
      Please, let me know what you want me to change and I'll get it done asap.
      1aed9eaa
  23. 26 6月, 2020 1 次提交
  24. 24 6月, 2020 2 次提交
  25. 23 6月, 2020 3 次提交
  26. 21 6月, 2020 1 次提交
  27. 18 6月, 2020 1 次提交
  28. 17 6月, 2020 1 次提交
  29. 11 6月, 2020 1 次提交