How do I make GitHub Actions faster?

How can I speed up a GitHub Actions workflow?

Make GitHub Actions faster in four moves: cache dependencies and Docker layers so each run skips repeated work, run independent jobs in parallel instead of chaining them with needs, cancel superseded runs with a concurrency group, and run the jobs that are still slow on faster hardware. The first three cut the work; the last makes every remaining step faster, and it is one runs-on line. Sengi runs jobs on AMD Ryzen 9 7950X3D bare metal boosting past 5 GHz with local NVMe, builds up to 1.9× faster than GitHub’s runner, from $0.003 a minute.

Last checked October 23, 2026, against GitHub’s workflow syntax and caching documentation. Speed figures measured on Sengi in October 2026.

Which changes make GitHub Actions faster?

The first two together look like this:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  test:
    runs-on: sengi-standard-2-ubuntu-2404
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm test

Each fix, with its measurement, is in how to speed up GitHub Actions; for Docker, slow Docker builds in GitHub Actions.

How much faster does a faster runner make it?

On RunsOn’s open benchmark harness at 4 vCPU, run on Sengi October 9, 2026 against RunsOn’s published GitHub results, a production Docker image built in 7m34s against 14m36s, 1.9× faster at 74% less per build, and Rust, TypeScript and Docker builds together ran 1.8× faster. On the same 2 vCPU as ubuntu-latest, real CI jobs ran up to 1.8× faster. Every job runs on an AMD Ryzen 9 7950X3D desktop CPU boosting past 5 GHz, with local NVMe at 15× the random-read disk speed of GitHub’s runner, and 2 vCPU jobs start in 2 seconds.

Sengi costs $0.003 a minute at 2 vCPU, $0.006 at 4 and $0.012 at 8, against GitHub’s $0.006, $0.012 and $0.022. See faster GitHub Actions runners and the runner comparison.

Frequently asked questions

What is the quickest way to make GitHub Actions faster?

Turn on the cache your setup action already supports, such as cache: npm on actions/setup-node, and cancel superseded runs with a concurrency group. Both are a few lines of YAML. After that, changing runs-on to a faster runner speeds up every remaining step with one line.

Does caching always make GitHub Actions faster?

No. Restoring a cache takes time too, so cache what is slower to rebuild than to download: package-manager caches, compiled dependencies and Docker layers. A cache keyed on a file that changes every run never hits and only adds a save step.

How do I find the slowest part of a workflow?

Open the run and read each job's duration in the run graph, then each step's duration inside the slowest job. The critical path is the longest chain of jobs linked by needs; only shortening that chain shortens the run.

Will a faster runner help if my job waits in a queue?

No. Queue time is a label or capacity problem: no online runner matches the job, or a concurrency limit is holding it. Fix that first; a faster runner shortens the time after the job starts.