Diagnosing and improving how quickly a website loads and responds. What's achievable depends entirely on the site - so the useful first step is looking at yours rather than promising a number.
Running a site through PageSpeed Insights shows two separate things. The headline score is a simulated test on a virtual device - useful for finding problems, but it isn't what search engines use directly.
Core Web Vitals are the other measurement: how quickly the main content appears, how much the layout moves while loading, and how responsive the page feels when someone interacts with it. These come from real visitors over time, which is why they can differ noticeably from the simulated score.
How much room there is to improve either depends on how a site is built, where it's hosted and what third-party scripts it carries. Some sites have a great deal of headroom, some have very little - which is why looking first is more useful than quoting a target.
A general outline. What actually applies to your project is worked out together, before anything is agreed.
Recording the current position from both the simulated tests and real-visitor data before changing anything.
Slow sites usually have one or two dominant causes rather than many small ones. Identifying those comes before any work.
Typically around how images, scripts, fonts and caching are handled - the delivery of the page rather than its design.
Re-running the same tests so the difference is visible rather than asserted.
Real-visitor measurements reflect changes gradually rather than immediately, so the picture takes a little time to settle after any work.
Send me the URL and I'll take a look at where it currently stands and how much room there realistically is. No obligation either way.