The current webRequest API allows extensions to intercept network requests in order to modify, redirect, or block them. It is frequently used by content blockers. Currently, with the webRequest permission, an extension can delay a request for an arbitrary amount of time, since Chrome needs to wait for the result from the extension in order to continue processing the request. The basic flow is that when a network request begins, Chrome sends information about it to interested extensions, and the extensions respond with which action to take. This begins in the browser process, involves a process hop to the extension's renderer process, where the extension then performs arbitrary (and potentially very slow) JavaScript, and returns the result back to the browser process. This can have a significant effect on every single network request, even those that are not modified, redirected, or blocked by the extension (since Chrome needs to dispatch the event to the extension to determine the result).
Google has noticed (as have I) that a typical chrome instance is significantly slowed down by things like adblock plus, because it turns out running every URL through a million regex's uses a massive amount of CPU and really slows down loading. As web pages get bigger and have more resources, it isn't going to scale.
This has been going on a long time, and there are totally ways to improve performance, but typically ad-blocker authors don't have a commercial incentive to make their software super performant, so as far as I know, none have even implemented basic performance features like prefix trees, bloom filters or hashed lookups.