It is probably quite a bit slower though needing to have roundtrips at each stage of the resolution, which is also likely a reason that these public resolvers get so much use (latency improvement via caching).
The average load time for a website is 2.5 seconds. The added load time from running your own recursive resolver, which is only added the first time the site is loaded, would be around 50ms, or 2% increase load time.
DNS resolving is not a major aspect of a typical websites load time. If you want to speed things up, run a local proxy which local cached version of all popular web frameworks and fonts, and have it be be constantly populated by a script running in the background. That will save you much more than 2% on first load.
Recursively resolve bbc.com: 18ms https://pastebin.com/d94f1Z7P Recursively resolve ethz.ch: 17ms https://pastebin.com/x6jSHgDn Recursively resolve admin.ch: 39ms: https://pastebin.com/DUTg8Rit
Page load in Firefox: bbc.com DOMContentLoaded: ~40ms, page loaded: ~300ms reuters.com DOMContentLoaded: ~200ms, page loaded: ~300ms google.com DOMContentLoaded: ~160ms, page loaded: ~290ms
So it's quite reasonable to do full recursive resolution, and you'll still benefit from caching after the first time it's loaded. One other idea I had but never looked into it was instead of throwing out entries after TTL expiry to just refresh it and keep it cached, no idea if BIND/Unbound can do that but you can probably build something with https://github.com/hickory-dns/hickory-dns to achieve that.
Google page speed (https://pagespeed.web.dev/analysis/https-bbc-com/yxcpaqmphq?...) use two other terms. First Contentful Paint, that is the first point in the page load timeline where the user can see anything on the screen, and Largest Contentful Paint, the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page. For bbc.com, those sites around 1 second mark.
Other measuring aspect is Time to First Byte, which is the time between the request for a resource and when the first byte of a response begins to arrive. For bbc.com that is 300ms.
My experience does not align with this. My Unbound instances cache only what I am requesting and I have full control over that cache memory allocation, min-ttl, zero-ttl serving and re-fetching, cron jobs that look up my most common requests hourly, etc... I do not have to share memory with anyone outside of my home. Just about anything I request on a regular basis is in the micro-seconds always shows as 0 milliseconds in dig. I've run performance tests against Unbound and all the major DNS recursive providers and my setup always wins for anything I use more than a few times a month or more than a dozen times in a year.
For the cases where I am requesting a domain for the first time the delay is a tiny fraction of the overall page loading of the site as belorn mentioned. I keep query response logs and that also has the response time for every DNS server I have queried. I also use those query response logs to build a table of domains that I look up hourly NS and A records to build the infrastructure cache in addition to resource record cache.
Now where there would be latency is if I had to enable my local Unbound -> DoT over Tinc VPN -> rented server Unbound -> root servers. That would only occur if my ISP decided to block anyone talking to the root servers directly and my DoT setup would only be in place while my legal teams get ready to roast my ISP and I start putting up billboards. That would of course be a waste of time and money when I could just get the IP's of censored sites from a cron-job running on multiple VM's and shove them into my hosts file. This could even be a public contribution into a git repo and automated on everyone's machines.