If you're new to programming, or even a bit seasoned, you may notice at times that your web application is running.... slowly. Why is that? Well there could be a number of things. Here are some places to look for. We don't want to optimize too early if we don't need to, but it's a good idea to keep these sort of things in mind.
Step 1 for figuring out why your web application is slow is to ask a tool to figure it out for you. Get very familiar with Chrome DevTools for the various tabs it provides such as the performance monitoring tab, cpu utilization, memory usage, network traffic...etc. If you don't know what you're doing here then on to my next tip.
If you're running any kind of static website, one of the best things you can do these days is to run an audit on the performance of your site. This doesn't just mean raw performance, but things like SEO, accessibility, first to paint and more. Take advantage of https://developers.google.com/web/tools/lighthouse/ to keep your scores up. Lighthouse has a lot of really great straightforward tips for improving the overall performance here as it analyzes your site for you.
In case lighthouse isn't enough, or it directs you to make your assets smaller. Then I would suggest taking a look at services like https://www.highcompress.com/ for image compression. Marketing websites and landing pages tend to have a lot of image content. This will bloat the overall size of the page. (Hint: you can do more with less by using SVG, simple shapes, and css animations to create a unique experience without needing tons of custom images)
High Compress works by using machine learning to optimize using lossy compression techniques. It works a lot better when the complexity of the image is reduced. I've used a number of https://unsplash.com/ pictures and managed to compress them down to substantially small sizes.
You may have heard of these terms before, perhaps you haven't. In any case, when you build a web application you have a few choices. You can do it the vanilla way, or the single page application way. The vanilla way means you are just going to build a web server to serve some HTML. This is still an option for web sites and would work for the a lot over needing giant single page applications.
Do you really need all that data for the client. Maybe you are just trying to cram far too much or returning far too much from your web server. In any case, it might be a good idea to consider how little data you might actually need to power your website. Try and formulate your requests to the web server and apis in such a way that you can return only what you actually need and not the entire database.
This goes along with the less data mantra. Perhaps you are generating far too many dom elements and the browser simply can't keep up with the interactions. I've had websites where we are trying to display and manipulate 1000s of dom elements on the screen. Even with a brand new Macbook Pro, these sort of things aren't going to keep up unless you start thinking of virtualizing only what the user can see. You may not necessarily need to use a virtualized type of system, but try to think of other techniques that involve actually showing less information on the screen. This could be as simple as a pager or a more button instead of infinite scroll or trying to load everything at once.
There's loads of other things you can do to keep things quick and fast on your web application. If you're just starting out I would suggest trying to adhere to some level of minimalism to your approach. If you aren't showing much information, your designs are relatively clean, then you can focus your attention on what matters most: actually building a product. You'll have plenty of time to learn about framework xyz in your spare time.