Pipelines cache: copy/restore cache is longer than re-download dependencies

I enabled dependency caching for my ASP.NET Core project and found that time to save+restore cache is more that time to re-download dependencies from internet.

First, my bitbucket-pipelines.yml:

image: microsoft/dotnet
pipelines:
  default:
    - step:
        caches:
          - nuget
        script:
          - chmod 755 build.sh
          - ./build.sh
definitions:
  caches:
    nuget: ~/.nuget/packages

All real build job is done inside build.sh, which contains dotnet restore (restore dependencies) and dotnet test (to build and run tests) and some other light (not time-consuming) tasks.

Screenshot of build with empty cache:

"Netto" build time (right) is 26 seconds (2+1+23). "Brutto" build time (left) is 2m08s. I was watching build progress/logs and seen that my build.sh is over, and pipeline was "Uploading cache". It took 1.5 min to save my cache folder, which was downloaded in less than 23 sec (in build.sh step).

After that, my cache size (reported on Pipelines homepage) is 197 MB.

Now I made minor change and pushed new commit, which was built with cached stuff:

Now we see:

• "Brutto" build time is 37sec - "better" that previous one, but worse that "without-cache" (26 sec)
• "Build setup" stage took 17sec - to checkout changes (only one text file changed! - let's assume same 2sec as first build) and cache folder download/extract: 17-2 = 15 sec.
• "build.sh" took 14sec (compared to 23) - better, win is 9 sec.

Lets' summarize:

• I win 9sec on each build because of cached dependencies
• I lose 15sec on each build to "restore" cache
• I lose 1.5 min every 7 days (cache expiration)

So, there is no "win" in using cache due to long save/restore operations.