Link Performance

[ViewableGravy]

In my companies application, we have a support centre page where we show our support articles. When we render the links, we render these are nested categories, sub categories and articles (articles being basically just a link element to a page that renders the actual article).

Recently having converted this particular page from react router v5 to tanstack, I'm noticing a significant delay in rendering time. For example, previously it was taking about 15ms to render the page and now it's easily over 200ms - not ideal.

Having done some investigation, it looks like each Link component on average is taking between 0.3 and 0.6ms to render which on this particular page, adds up to a lot since we render (in some cases) 300-500 links.

It doesn't help that we have hundreds of support articles on each page, so when we click an accordion, even if the existing links are optimized it still takes a long time to render because new links are being rendered.

Converting this directly to anchor elements seems to immediately resolve any performance issues.

It'd be great if this list was paginated, virtualized, etc, but it's really not something we can afford to be spending time on at the moment while this refactor is purely meant to be the routing side of things.

So I'm curious of any suggestions on how to actually improve the page performance apart from refactoring the entire page/structure.

Also, this performance issue can be seen easily by chucking this in the rootRoute of any of the example docs and checking the console which should immediately complain about the page taking too long to render

{Array.from({ length: 1000 }).map((_, i) => <Link to="/about" key={i} style={{ display: "block" }}>About</Link>)}

I also pulled tanstack router locally and tried logging different points in the Link component to see if anything else was slowing it down. Other than the context consistently taking 0.2ms to run, there wasn't anything that stood out to me.

--- Edit ---

It looks like the buildLocation function takes a long time to run during render time (relative) which adds up with hundreds of links. Building a custom Link component without the call to buildLocation resolves performance issues but means that we cannot have type safety so it's not ideal.

[ViewableGravy]

This isn't really a "solution" but I've basically solved the problem in my case by building a severely cut down version of the link component that does exactly what I need in this case.

/**
 * Faster version of the link component that only works with static routes (no params, search, etc). By avoiding this check,
 * the render time is much quicker
 */
const FastLink = ({ children, to }) => {
    /***** HOOKS *****/
    const navigate = useNavigate();

    /***** RENDER *****/
    return (
        <a
            href={to}
            onClick={(e) => {
                e.preventDefault();
                navigate({ to });
            }}
        >
            {children}
        </a>
    );
};

I've noticed calling useRouter doesn't really cause any problems, but as soon as I try to use buildLocation from useRouter, the render times get significantly higher, It seems like building the location is not a trivial task to do at runtime.

Perhaps having a select function on useRouter would solve this? For now this handles my use case, but I think some thought needs to be put into this because Link components are, in my opinion, now considered an "expensive" component despite being a foundational component in most applications.

[honzahruby]

We've observed the same issue. The time goes up dramatically when you have hundreds of registered routes and render hundreds of Links at once.

To reproduce this issue, I've used the large-file-based example as a base and rendered 10000 links with random IDs as a param. Then, I replaced the built-in Link component with router.buildLocation, then with interpolatePath and finally used an A element with hardcoded href.

Here's a comparison table with times to render taken from react dev tools:

	2 routes	400+ routes
hardcoded href	150ms	160ms
interpolatePath	180ms	190ms
buildLocation	360ms	1760ms
Link component	660ms	2160ms

None of the computations in path.ts and routes.ts are cached which slows down the buildLocation function. Internally, it uses matchRoutesInternal which traverses all flatRoutes with a huge performance hit with hundreds of routes.

@SeanCassiere Would you know where to look? 🙏

[SeanCassiere]

This is likely due to how the Link component functions, by running the validateSearch function to get the URL/href to be used on the component.

There'll always likely be some performance overhead since each link needs to reach into the Router to get the basepath at the bare minimum. From there on, depending on if it is a goal to not run these extra fns, it'll likely be a game of finding the right conditions to exit early.

• We need to keep in mind that relative navigation is a thing which is an automatic increase in processing overhead.

Likely a conversation worth continuing on Discord with @schiller-manuel and @tannerlinsley as I'm out till around October 16th.

[honzahruby]

Thanks for the response @SeanCassiere, I've opened #2359 in the meantime but haven't had time yet to finish it 🤞

[SeanCassiere]

@honzahruby thanks a bunch! have a good weekend!