Largest Contentful Paint (LCP)

Take out the redirect and put everything from app.tsx into root.tsx. Now, your main file should be root.tsx instead of app.tsx. Also, could you share your app._index.tsx and app.tsx files?

Remove the app part from all your file names. For example, change app.settings.tsx to settings.tsx. Your homepage should be called _index.tsx instead of app._index.tsx.

This way every route will be under / not /app and won’t require any redirect

I’d also be really interested in how this performs compared to if you hosted the app on something like Cloudflare for example too. To see if the Fly compute you’ve got is slow to render

Thanks for your suggestion.

From my point of view, I don’t see that it has many differences if we remove the prefix /app route thought I hadn’t tried it.

It will be great if you can share the TTFB score will be improved when we remove the prefix /app route

I see the other devs also using Fly without any issue so I choose them but I will try Cloudflare as your suggestion in the future

By simplifying routes and removing /app prefix, you can skip the redirect from / to /app when someone first opens or installs your app. But if fixing it feels like too much work right now, you can keep it as it is.

Changing the server might not really improve LCP. I’m using GCP App Engine F1 with 384MB RAM and ~0.25 CPU, and it has autoscaling, but it never even needed to scale up. You might need bigger specs depending on your app, but that alone won’t help unless caching and SSR are optimized. I also tried upgrading server specs first when I was working on LCP, and it made no difference for me.

Cloudflare Workers might help since they are global and work like a CDN, so your server isn’t stuck in one region. I tried moving to Cloudflare for this, but it needed remix template changes to make it compatible. It looked like too much work for me, so I dropped it.

1 Like

Thanks for sharing.

Currently, I have no idea how to improve the TTFB time; my Fly has 3 machines with 3 regions: US, Euro & Singapore, so I don’t think it’s the problem.

Are you using any CDN? if yes, what assets are being cached there?

I don’t use any CDN here, only push the code Fly server only

What is the config of those servers? Do you have any performance monitoring of them?
The time to first byte is the time it takes to connect to your server and then it needs to do all the processing to generate the page. Because its remix, it is mostly doing this when the request is made and so the less powerful a server the slower this will be.

I beleive most issue here is the Waiting for server response is way to high, almost reach to the requirement metric of LCP.
We maintain the this embedded url response in about 300ms and archive the lcp around 1.2-1.5s in total

Pay your attention at it.

Yes, a lot of devs look at the wrong things when trying to fix LCP. If TTFB isn’t optimised, it’s almost impossible to reliably bring LCP down to required value.

Also, can you please share your framework, server, CDN etc setup? It might help other devs too

Hi Gulam,

My app has a file running a service in the background that calls pub/sub from Google Cloud. Is it a problem that makes our TTFB increase? I tried to remove it in the and running in the localhost but nothing seem changed