FeliksM regarding 1. I have looked at how we can enable WebJobs in Windows Containers but so far that would be specifically for using the WebJobs SDK (How to use the WebJobs SDK - Azure App Service | Microsoft Docs ) this investigation work is ongoing. My personal background is in .NET however so I will also look deeper into the .NET Core Worker Services;
Regarding 2. When your site is allocated an instance or a number of instances based on your app service plan, that worker has a number of images pre-cached on the worker before we mark it ready to receive workloads. The full list is here - Configure a custom container - Azure App Service | Microsoft Docs these images are pre-cached in order to make loading of customer's customer containers as efficient as possible, which particular for Windows Containers, can be quite large.
In the case of the Full Windows Image then each time you deploy or scale to a new instance we need to pull and extract any additional base layers, we don't already have cached which make up that base image, in addition to those which contain your content as they don't already exist locally. However if you have multiple apps per app service plan that all use the same base image then we don't repull for each new app which starts up as the layers already exist, we just pull and extract the layers that are different (primarily app content).
In the event you stop or start your app we don't need to pull and extract again as the layers already exist on the instance on which you are running. I hope this explains our behaviour, any further questions on this please let me know and I'll be very happy to answer.
Out of interest, do you need to have the overhead of the Full Windows Server image, do you need to use a service/feature/api that is not available in the Nano images? You should still be able to expose a http endpoint on those images too, then you can also benefit for the massive reduction in container size.