Previously: #14289

This serves as a tracking ticket for various suggested improvements to Travis build performance. See various comments within #14289 for more detail.

• Remove postinstall script from package.json (Plugin: Remove postinstall step #14353)
  • Most of our Travis jobs ultimately call npm run build twice, wastefully, because of the combination of the postinstall triggered by an initial npm install, and a subsequent explicit build
  • npm install is run in many separate jobs, but npm run check-licenses only really needs to be run at most one time, not in each job
• Remove npm / JavaScript build from the "PHP Unit Tests" job
  • Avoids lengthy install / build process
  • As best I can tell, there should be no need to rely on JavaScript produced by npm run build. Previously it may have been needed to use the npm scripts for npm run test-php and npm run test-unit-php-multisite, but these resolve to docker-compose commands anyways, so it seems reasonable enough to call them directly
    • As of Blocks: Re-register core blocks via build copy prefixing #13521, there is some PHP produced as the result of the Webpack build, though it is not subject to tests
• Split JavaScript tests into separate tasks (containers) (Build Tooling: Split JavaScript tasks to individual jobs #15229)
  • Separately resolves Make it easier for a contributor to determine what failed their build #10625
  • Not all of these tests need to depend on npm run build
  • In theory, frees up containers sooner by those which can finish early
• Split end-to-end tests into more containers (Build Tooling: Increase number of Travis E2E test jobs #15228)
  • Currently already split across 2; consider 3 or 4
  • Since a build takes as long as its slowest task, this would be key to shorter builds
  • See: Framework: Improve Travis build performance #14289 (comment)
• Leverage parallelization within end-to-end test containers
  • See: Framework: Improve Travis build performance #14289 (comment), Framework: Improve Travis build performance #14289 (comment)
• Pregenerate the plugin build to use across tasks
  • Related Travis documentation: https://docs.travis-ci.com/user/build-stages/#data-persistence-between-stages-and-jobs
  • Possible enhancement for gutenberg.run build result (offer plugin zip)
  • See: Framework: Improve Travis build performance #14289 (comment)
• Reduce build time (Scripts: Optimize default Webpack configuration #14860)
• Avoid "reset" set-up and tear-down tasks
  • If we can treat Travis as a fresh, throwaway environment, we can avoid running unnecessary tasks like reset-e2e-tests.sh or afterAll tasks like deactivating plugins, etc.
  • See: Build Tooling: Increase number of Travis E2E test jobs #15228 (comment) , Testing: Disable post locking in E2E tests #14245 (comment)
• Avoid Puppeteer's Chromium download except when necessary (Builld Tooling: Skip Chromium download in Travis by default #15712)
  • Related: Scripts: Download Puppeteer's Chromium binary on-demand #15667
• Streamline Docker setup
  • Consolidate docker-compose run commands where possible (example) (Framework: Consolidate Docker commands in site installation #15742)
  • Keep containers active while setup process is run (avoid Starting gutenberg_mysql_1 ... done)
  • Consider executing setup as shell script within container(s) to avoid repeated docker-compose connections
  • Reduce interval that attempted WordPress connection elapses (source), either by lowering sleep or a mechanism to be made aware immediately