OK, so I was able to get back to this and scrutinise my setup details. I thought I found the culprit when I managed to go down to below 300ms on average. The reason for the previous lack of performance (I thought) was that ChromicPDF instead of the current “Chromium” browser, picked a two years old “Chrome” I even forgot I had still installed. And since I blocked Google’s malware updater software from running, it wasn’t updated for over two years. So everything looked great… for a moment. Once things started to work well on the dev machine running “macos”, I moved to the one running GNU/Linux. In the end this is what production env runs. Here I also made sure that the very same, latest “Chromium” version[*] is run in place of previously installed packaged one, and still received times over two seconds (pooled). Yes, the Linux running machine is of similar hardware capabilities so that’s definitely not the up to 10x factor I observe. And yes that machine clocks similar times with wkhtmltopdf (around 800ms) as the “macos” computer I normally use for dev work.
Shall return to this and do some more “tracing”.
* - in both cases I downloaded the same version directly off the “Chromium” project rather than using packaged versions
