Prefetch apis for SPAs

[robinglen]

Hey guys,

First of all thanks for the module, it looks great and something we are really interested in using it.
However we have a slightly different request, because our website is an SPA. I'm interested in using it here:

https://www.mrporter.com/en-us/mens/clothing

This could be used for either linking to Product details, or using filters. Ignoring how we detect intention, I'm interested in prefetching data from the relevant api.

This can be interpreted from the products part number or the filters path.

I've not had a huge think about how this could be implemented yet, but if for example we might want to be able to have different api prefetches based on an element type:

• Filters elements prefetch GET /my-filters-endpoint/${filter-id}
• Product elements prefetch GET /my-product-endpoint/${product-id}

You would need the ability to prefetch based on the element "type", maybe this could be done with data attributes or configure different quicklink instances based on The DOM element to observe for in-viewport links to prefetch.

I just wanted to start the conversation, would people be interested in this?

[gilbertococchi]

@addyosmani

Hi Robin, thanks for submitting this feedback.
I believe it's a quite interesting case to consider whether QuickLink might evolve into something useful for API prefetching of Views instead of HTML incase of SPAs.

I think that data-attribute usage might help but it would also increase the DOM size if you have lots of PLP elements.

Another approach would be to possibly specify in QuickLink a Custom Handler to define the URL to be added into the Link=Prefetch tags, the callback would be responsible to either select the HREF attribute from the A as default or construct the API URL that in your case it would be the same as Prefetching the PDP itself from the Network point of view.

[dieulot]

They’re working on it.

[gilbertococchi]

Thanks Alexandre, @thearegee please check this pull request if it would satisfy your needs: #123

[robinglen]

@gilbertococchi this would be perfect for us, any progress on getting this merged?

[robinglen]

We used this PR: #123

To run some experiments to see if this was worth it, on this page:
https://www.mrporter.com/en-be/mens/clothing

We added quicklink to the product grid, so as the user scrolled it would preload the APIs:

When the customer clicked the product, the API would already be cached:

This effective saved the user 250ms of waiting.

However we decided vs the bandwidth cost:

And the fact that without naked eye we couldn't see the difference. It was not worth it. If interested this is our quick hack for how we referenced the API:

In this instance we will probably not follow this up.

[gilbertococchi]

It looks like ona Fast 3G Connection it would save approx 600-800ms TTFB time by downloading a 6-8KB JSON content.
That's a pretty powerful improvement for Mobile but I guess it would be better handled with a Service Worker dedicated Caching Entry.

[robinglen]

This is a good point, I think it could be done with both. A prefetch on intersected elements and then cached with SW. At the moment our API is just too large for all the prefetching. So I need to do some work to slim this down.

I still think this is a great addition to the library though but we can't experiment further without: #123

[demianrenzulli]

Hi @thearegee, this is an old issue, but #123 has finally landed into the library around October 2020.

From your previous comment it seems like this was everything you needed to make this work. Perhaps others can find your tests useful for similar needs as well.

Closing this one. Please, feel free to reopen if you need anything else.