Hi @benz1, I am very sorry for late reply, I wanted to write detailed answer but didn’t find time for it.
What you are saying shouldn’t happen. I don’t say that all sites will always be faster, but even when they are slower, other metrics should increase (Time to Start Render, Time to Interactive, Time to Visually Complete, Fully Loaded…), not Time to First Byte.
Reason for this is how commonWP works and what it can affect. On regular requests, it just loads its cache, which is single option field (on single site installation this is already loaded with wp_load_alloptions()
, on multisite this does makes new database query but that query is very simple; this is assuming that no object cache is enabled, in that case there will be no database queries at all), then for each script and style does simple assigning in case that script/style is in cache. All other stuff that requires more PHP resources is happening in background processes and won’t be seen by visitors. So, generating page on the server is almost the same, it has minor differences.
When commonWP offloads local files to jsDelivr, it should only affect the way browser loads HTML content and those files. There are a lot of variables that can affect: where is visitor located related to site server and to jsDelivr POP, what is connectivity to either, what protocol is either using, what compression is either using, how fast is site server, how many files page is using, what is distribution of used files (head, footer, above the fold…), in case jsDelivr is used, is any file already cached by browser, etc.
Another thing to consider is if site uses page cache. There is possibility that you are hitting site’s page just in time when it has empty page cache that’s needed to be regenerated, and depending on number of files your site uses it may take even longer to have fully active commonWP because both commonWP’s cache must be full and generated page cache must be with full commonWP’s cache.