This diagram is an over-simplification of how the things work, to see in details what happens, I invite you to go directly to the specs, which have become actually quite readable and easily navigable these days.
From there you'll see that
[t]he microtask-queue is not a task queue.
If we take the over-simplification road ourselves to explain the event loop routine with only what we're interested in,
- messages from other processes and previous tasks will queue new tasks in various task-sources, themselves ending in fewer task-queues. (This feeds the left loop of Jake's diagram).
- at each iteration, the first step of the event-loop is to pick the first task from one of these task-queues (chosen as they wish, this allows task prioritization).
- after this main task is completed (step 7 in the specs), the event loop will look at the microtask queue in what is called a microtask-checkpoint.
- only for the Documents where the active display monitor did emit its SYNC pulse since the last iteration (once every 16.67ms on a 60Hz monitor), it updates the rendering (right loop in Jake's diagram, steps 11.6~11.15 in the specs).
- During these steps it will execute a few tasks like firing UI events, updating animations and run the animation frame callbacks. Every time one of these algorithm invokes a callback, the user-agent has to perform a new microtask-checkpoint as per the
clean up after running algorithm, so for instance every animation frame callback will get interleaved with such a checkpoint, and some of these algorithms even perform the microtask-checkpoint directly.
So this means that the microtask-checkpoint is not just executed in a single point in the event loop, it is executed once after the main task, and many times after each callback execution in the update the rendering steps.
The user-agent can not just delay the microtask, it has to execute it right after the task that queued it did complete, i.e, from the event loop perspective, microtasks are executed synchronously.
In the same way, the "render queue" is not a task-queue either, it has to run when the browser has a "rendering opportunity", it can't be part of the task prioritization mechanism (more here).
Because we know that the event loop sends functions in the event queue or job queue to the call stack in the javascript engine to run these.
Not exactly. First remember that javascript execution is only a part of what the browser does, many tasks don't involve javascript at all, for instance, even if you do disable the javascript from your web-browser, the event loop still has to run, it still has to update the rendering, it still has to send forms, it still has to react to network events like the loading of a media etc.
What the event loop does is to run the task's steps, but these can be a lot of different things and they may not necessarily send anything anywhere.
Also, specs don't say at all how computation should be distributed, but regarding the rendering, we can assume that in a nutshell everything from update the rendering until its 14th step should be done on the same process (it has to be ran sequentially), but the step 15 ("update the rendering"), which will actually paint everything to the monitor can be (and I think it is in all modern browsers) passed to an other process, dedicated to this rendering task.
You can check Chromium's documentation explaining how they manage the inter-communication between the browser process and the renderer.
. (I tried to implement it into the diagram :) )
