An indirect connection between those two is definitely plausible, since RAM exhaustion can cause both of them on its own:
You can look for swapping directly (instead of trying to infer it) by shelling into the Machine itself…
$ fly ssh console
# apt-get update
# apt-get install --no-install-recommends procps
# vmstat --unit M 1
(Ignore its first row of numerical output.)
You want the si (“swap in”) and so (“swap out”) columns to be mostly zero.
(Those are measured in megabytes per second, due to --unit M, in this version; older versions may report differently.)
I created a test program in Racket that constructed a 400MB array on a Machine with only 256MB RAM, and then iterated back and forth across it several times. The si and so numbers were up around 10MB/s for a couple minutes straight, 
.
Having said that, I think the memory leak itself is really the highest priority. You mentioned in an earlier thread that you only have 512MB of swap in the first place, so the leak has consumed the entirety of that. That is nearly guaranteed to cause poor system performance—one way or another.
The question of what exact mechanism is causing this to manifest as CPU steal is genuinely interesting, but I suspect that the answer will have the following structure: several paragraphs of dense explanation of VirtIO ring buffers, swap daemons, custom cgroup throttling, overlay storage systems, noisy neighbors, Node.js garbage collection, and fiery muppet backgrounds—finally ending in the sentence, “Consequently, definitely fix that memory leak”…