Usually no, depth beats speed for the same query, unless the slow page is so slow it breaks the experience. When both pages are reasonably fast, content relevance and depth are the stronger signals, so a genuinely better page that takes a moment longer to load tends to outrank a fast page that barely satisfies the intent. Speed is a tiebreaker and a floor, not a substitute for actually answering the query. The fast-thin page wins only when the rich page’s slowness crosses from inconvenience into a broken experience.

The reason is what each signal does. Google’s first job is to return the result that best satisfies the searcher’s intent, and depth, relevance, and completeness drive that. A page that fully answers the question, anticipates the follow-ups, and earns the reader’s trust is doing the thing rankings exist to reward. Speed sits alongside that as part of page experience, it matters at the margins and helps separate otherwise comparable pages, but it does not turn a shallow answer into a satisfying one. A user who loads a thin page instantly still leaves unsatisfied, and that dissatisfaction outweighs the saved second.

The exception is real and worth respecting. If the rich page is so slow that it fails Core Web Vitals, frustrates users into bouncing, or genuinely degrades the experience, the calculus flips, because now the speed problem is harming the very satisfaction depth was supposed to deliver. The lesson is not that speed does not matter, it is that speed has to clear a reasonable floor, beyond which more raw speed buys little while more genuine depth keeps paying. Speed is necessary but not sufficient, depth is the lever.

So set your priorities accordingly. Build the deeper, more relevant page, then fix its speed to a sound floor, fast enough to pass Core Web Vitals and feel responsive, rather than chasing milliseconds at the cost of substance. If you are ever choosing between trimming the answer to load faster and keeping the answer complete, keep the answer complete and optimize the delivery instead.