I think the SolidStart section might be more appropriate in the reference section as a callout so it doesn't get buried here.

Following that change, I also believe it might be better to show a basic code snippet of what the hover would look like. Doesn't have to be too complex, just enough to get the idea across for how it should look.

the code snippet is in the respective API references. This entry is to explain conceptually how preloading works in Solid Router. I added links to the the APIs so things didn't get too repetitive

Not sure what you mean about the hover snippet, that's just the browser API, there's no code from the user to manage or handle that. If they hover or focus the anchor tag, preloading will happen.

Remember: preloading is default behavior. Altering it is an advanced concept for users, most cases we want people to feel it "just works".

I think as it stands for me it feels more like an extension of the ref page vs an exposure to the concept as a whole. What I meant by the hover example was that it might make it feel less like a ref page if there is some form of an example on the page of what it'd look like to modify it.

My explanation wasn't entirely great (I'm sorry about that) but I'll try to give you a bit more of an idea as to what I mean tomorrow (unless @devagrawal09 has any ideas before then).

if there is some form of an example on the page of what it'd look like to modify it.
There's no way to modify the preload threshold. This is a magical number to prevent eager preloading.

The hover in this case is the regular browser hover, there's nothing framework specific on this. Regular mouse hovering a link will fire a 300ms timeout that will preload data once fulfilled.

Extending on this right here feels to me like documenting browser APIs or framework implementation details.
The reason I added this table here is only to be more transparent about how the framework works under the hood.

I agree with @LadyBluenotes that a more detailed explanation of what happens during SSR belongs in the solid-start docs, but it's definitely worth a callout on this page that during SSR the preload function will run before rendering, so that data fetching can be kicked off earlier.
SolidStart docs already explain this in more detail so we should provide a link here.

By the time the button is visible and before it's able to be clicked, <Nested /> is loaded and rendered already no?

Agreed, it should look something like this

const ComponentWithPreload = () => {
 const [showNested, setShowNested] = createSignal(false)
 return (
	<div>
	 <button
 onMouseEnter={() => Nested.preload()}
 onClick={() => setShowNested(true)}
 >Preload Nested Component</button>
 <Show when={showNested()}>
	 <Nested />
 </Show>
	</div>
 )
}

Given the context of this paragraph, the second sentence here seems misplaced and was the problem we were initially discussing on Discord. usePreloadRoute is for preloading routes directly. (await lazy(string)).preload() is what's necessary to properly preload nested lazy components. Was this maybe an editing mixup?

100%
Great catch!
I need to reword this entire paragraph 🤦

Cool, you seem pretty busy, so I can give it a try. Hopefully it's in the ballpark of what you had in mind.

haha yeah, I'm juggling some stuff. But I think everyone is :)

I'd be more than happy if you want to take over this PR, more because I like collaborating. So if you feel like it, it's yours :)

I'm honored! I'm super crazy under water this week, so if it's OK for me to pick this up next week, I'm happy to drive this PR to completion.

I don't think there's a concept of "top level lazy components". The only lazy components that are preloaded are route components, which means this section belongs in the router docs.

It's definitely worth calling out that lazy route components are preloaded automatically, but that callout should be further down in this page, and should link to the router docs where its explained in more detail.

Curious where you got the 300ms from. I can only see a 20ms timeout here