Content pfp
Content
@
0 reply
0 recast
0 reaction

Vladyslav Dalechyn pfp
Vladyslav Dalechyn
@dalechyn.eth
Frog & Next.js co-location at the current state *will* slow down your page that has a frame co-located first render, if you followed the exact tutorial here https://frog.fm/platforms/next#bonus-page--frame-co-location and it should be updated. Next.js docs state the next: "Next.js will wait for data fetching inside generateMetadata to complete before streaming UI to the client. This guarantees the first part of a streamed response includes <head> tags." This way if you're generating some regular OG metadata ("og:image", "og:title", etc) this makes it indexable by Robots as they take first response from the stream (if the response is streamed). However, we know that Frames are usually more UI-heavy than regular "og:image"'s. And since you're co-locating a frame within the page, this would mean that every time the page loads, the co-located frame fetch will delay the TTFB heavily. If your frame loads ~4 seconds, this will delay the Next.js page render by 4 seconds too! Continuing in a thread below this cast
1 reply
1 recast
8 reactions

Vladyslav Dalechyn pfp
Vladyslav Dalechyn
@dalechyn.eth
In order to speed the pages up, we can check if the request from a page comes from the user of from Client Proxy fetching the frame. In /frogfm, there is `isFrameRequest` helper that checks if `User-Agent` header has `FCBot` value there, and we can use it to co-locate the frame with the page dynamically! In the attached picture here's how I implement it, if the request comes from FCBot, I'm fetching the metadata for the frame and filtering out all non-fc and non-frog meta tags. This instantly made the Next.js page load much faster!
1 reply
0 recast
8 reactions