I'm comparing a React site against an Astro rebuild of the same page. In mobile Lighthouse, both sometimes sit blank for a long time before first paint, and other runs of the exact same page paint fast.

Setup: Lighthouse 13.0.1, Chrome 156, cold loads in separate fresh profiles, default mobile simulated throttling. I kept the traces, network logs and filmstrips.

Here's one matched pair (observed trace timings, not Lighthouse's simulated FCP):

Astro

• CSS done: 203ms
• Last preloaded font done: 286ms
• DOMContentLoaded: 426ms
• First Paint: 1301ms
• FCP: 1320ms

React

• CSS done: 573ms
• Last preloaded font done: 494ms
• DOMContentLoaded: 584ms
• First Paint: 1525ms
• FCP: 1540ms

The filmstrips stay blank right up to those first-paint times. Once painting starts, Paint to DrawFrame is only 10-13ms. So on Astro there's close to 900ms where everything's loaded and nothing shows up.

I don't see a long task on the renderer main thread covering that gap, though I know that doesn't prove the browser was actually idle.

I wondered about animations, so I ran one normal-motion vs reduced-motion pair on the Astro page. Both came back fast (FCP 318ms and 311ms), and the normal one still had its reveal animations, so that told me nothing either way. Desktop loads and a different page also painted quickly in the runs I checked.

One more thing: the fast traces show Scheduler::SetDeferBeginMainFrame events with short true-to-false spans. But the slow traces were captured with Lighthouse's default trace categories, which don't include those scheduler events, so I can't compare yet.

Has anyone run into this? A few things I'd like to figure out:

1. How do I tell whether the page is causing the delay, or whether it's Chrome's scheduling or something in the test environment?
2. Which trace categories or events would show why the first paint starts late, and not just that it did?

Just as the title asks. I am curious how you organize the various parts. I have been on teams that both do and don't use mono-repos. For the ones that did, there has been a wide variety of choices across the app and how it's organized.

Just as a small example: naming conventions. Sometimes the the repo is named for the app (let's say "OurApp") and the various parts of the file structure are "OurApp-", like OurApp-ui and OurApp-api and OurApp-db. Or there might just be a top-level folder for "frontend", "backend" and "database", etc.

I'm not talking about a debate of mono-repo vs. multi-repo approaches, but in a mono-repo, what are some of the code organization techniques you've liked and disliked in your experience?

UPDATE: The community turned out! Thanks for sharing your thoughts in the comments. I appreciate the discussions.

Websites built from scratch (no AI, no frameworks or libraries) that are more than just simple toy projects are becoming very rare, but i want to remind you guys that they still exist.

Three years ago, I posted this https://www.reddit.com/r/webdev/comments/161q3w8/i_coded_a_site_from_zero_without_any_libraries_it/, and that website is still being actively developed. I haven't used any AI-generated code or external libraries in all this time, even as it has become more complex with features like accounts, articles, comments, reviews, and just a few weeks ago forums.

I think the main reason why i stick with this is because features aren't planned in advance, they're just built bit by bit as the content needs them. I won't deny if AI could do better, but with a spread-out timeline and an unknown end result, it's easy to skip using AI as development mostly consists of small, precise tweaks with no definitive end goal. Coding also only small portion of time spent on developing the site so i don't feel the need to optimize it.

Anyway this is just me saying that i'm still here, not everything in this space become AI.

*note : i'm not saying that this is the better way to develop website. I just enjoy what i already used to do, and didn't bother to change it.