How to Speed Up GitHub Actions

Why GitHub Actions pipelines go slow

Two patterns cause most of the pain on a growing Python (or Node) project:

1. No dependency caching - every job does a fresh pip install -r requirements.txt, downloading and building the same packages on every run.
2. Serial test suites - unit, integration, and e2e tests queue up inside a single job, each waiting for the one before it to finish.

Both are easy to fix with standard GitHub Actions primitives.

Cache pip dependencies with actions/cache

actions/cache@v4 saves and restores a directory between runs. For pip, cache ~/.cache/pip keyed on the hash of requirements.txt - so the cache is invalidated automatically whenever dependencies change:

- uses: actions/cache@v4
  with:
    path: ~/.cache/pip
    key: pip-${{ hashFiles('requirements.txt') }}

On a cache hit, pip install -r requirements.txt becomes a near-instant no-op (packages are already present). On a cache miss the install runs normally and the result is saved for the next run.

Parallelize test suites with strategy.matrix

strategy.matrix spins up one runner per value in the matrix, all at the same time. Replace a single bloated job with a matrixed job:

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        suite: [unit, integration, e2e]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - uses: actions/cache@v4
        with:
          path: ~/.cache/pip
          key: pip-${{ hashFiles('requirements.txt') }}
      - run: pip install -r requirements.txt
      - run: pytest tests/${{ matrix.suite }}/

With three suites and three runners, wall-clock time drops from unit + integration + e2e minutes to max(unit, integration, e2e) minutes. Combined with caching, a 40-minute pipeline commonly reaches 3-5 minutes.

Further improvements

• Restore keys - add a restore-keys: pip- fallback so a partial cache hit still saves most of the install time when requirements.txt changes.
• Per-suite caches - cache pytest result caches (~/.cache/pytest) or Node node_modules under their own keys for even faster incremental runs.
• Larger runners - GitHub's bigger runners (8-core) speed up heavy compilation or test suites that are CPU-bound rather than I/O-bound.
• Test-impact analysis - tools like pytest-testmon only run tests that touch changed files, skipping suites entirely on unrelated PRs.