Performance work starts with a measurement, not a guess. The browser spends time in three places: fetching bytes, parsing and painting, and running your code. Each has a different unit and a different fix, and only a measurement tells you which one you are in.
About 1 min of reading
Get one honest number for one page
Open the network panel
Before you run it, say out loud what it will print. Then open the answer.
Read the critical request
Before you run it, say out loud what it will print. Then open the answer.
Throttle and re-measure
Before you run it, say out loud what it will print. Then open the answer.
Write both numbers down
Before you run it, say out loud what it will print. Then open the answer.
Milliseconds to the interaction, plus the bytes that made it. Two numbers per page is enough to decide what to fix and enough for someone else to reproduce.
The classic wrong guess is optimizing the biggest file when the slowness is a blocking request. Size and count are different axes and only measurement separates them.
Bytes over the wire cost time proportional to the network. Parse and paint cost time proportional to the document. Your JavaScript costs time proportional to what it does. A 2 MB image and a 2 MB JSON file are not the same problem.
A local server on an idle machine hides the network and the CPU throttle. Throttle the connection and the CPU in the tools before you believe any number.
Record the time to the thing a user interacts with, not the time to load. For a reading page that is when the text is readable; for a game it is when the first frame draws.