How to make GitHub Actions faster: six changes, measured first

Updated 24 Oct 2026 · prices and specs read on 24 Oct 2026

To make GitHub Actions faster, first find the slowest job and step, then: skip runs that cannot matter (path filters, cancel-in-progress), cache dependencies with actions/cache or a setup action's cache, split long test suites into parallel matrix shards, and give memory-bound jobs a runner with enough memory, because a job that runs short of memory slows down or is killed.

1. Measure before changing anything

Open a slow run and sort its jobs by duration; inside the slowest, find the step that takes the time. Most of a workflow’s minutes usually sit in one or two places: installing dependencies, building, or one long test job. Note the job’s queue time too (from queued to started): that is the runner’s start, not your code.

Also measure what the slowest job uses. /usr/bin/time -v <command> prints its peak memory (“Maximum resident set size”); on FlameWill every job’s log ends with its peak memory and CPU time.

2. Don’t run what cannot matter

Skip workflows when only unrelated files changed:

on:
  push:
    paths-ignore:
      - 'docs/**'

And stop paying for runs a newer push has already replaced:

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

3. Cache dependencies

Restore dependencies instead of downloading them on every run. The setup actions do this with one input; actions/cache does it for anything:

- uses: actions/setup-node@v5
  with:
    node-version: 24
    cache: npm
- uses: actions/cache@v4
  with:
    path: ~/.cache/ms-playwright
    key: playwright-${{ runner.os }}-${{ runner.arch }}-${{ hashFiles('package-lock.json') }}

Know the limits: 10 GB per repository by default, entries unused for 7 days are removed, and a branch can restore only its own caches and the default branch’s. Put runner.arch in the key if you run on both x64 and arm64.

4. Split long test suites into parallel shards

A 20-minute test job split four ways finishes in about five minutes of wall time (the minutes billed stay roughly the same). Jest, Vitest and Playwright all take a --shard option:

jobs:
  test:
    strategy:
      matrix:
        shard: [1, 2, 3, 4]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - run: npx playwright test --shard=${{ matrix.shard }}/4

5. Give memory-bound jobs the memory

A job short of memory slows down (the system swaps or the tool throttles itself) or is killed with exit code 137. GitHub’s standard runner in a private repository has 8 GB on 2 vCPU; on GitHub, more memory comes only with more cores. A runner sized by memory gives the headroom for less: FlameWill’s flamewill-2vcpu-16gb-ubuntu-2404 has 16 GB on 2 vCPU for $0.0015 a minute. See GitHub Actions out of memory for finding the peak.

6. Know what the runner adds before your first step

Every runner adds time before step one: queueing, starting the machine, setting up the job. GitHub-hosted runners keep machines ready; services that start a fresh machine per job add its boot (FlameWill: about 45 to 60 seconds today, not billed). For a short job that matters more than raw speed; for a 20-minute job it does not.