To me this sounds like "code in pure HTML, no React/Angular or anything like that". Am I correct?
Some things I'd start with:
- Minimize images (tinypng/tinyjpg)
- Deactivate/Remove what you don't need (Plugins (!!!), RPC, Emojis, stuff like that which is ON by default in WP -> will strip down the code)
- Strip down & combine scripts
- Reduce third-party dependencies, try making them first-party (fonts, analytics)
- Minify scripts and CSS
- Use caching on the client-side through htaccess rules
But it's not what matters (at least, until you have hundreds of pages ranking).
Google Search is very similar to LinkedIn, TikTok, Facebook and Instagram in the sense that the better your UX metrics are (time on-site, pages visited, return visitors, etc) the more visibility Google will give you in the SERPs.
For most SaaS, there aren't a few valuable keywords, there are hundreds of valuable pages representing thousands of keywords to drive a qualified audience.
This means after you learn how to create highly valuable content, the next step is to scale your publishing velocity to increase your footprint in the SERPs.
I've brought 4 websites from 0 to 100,000+ organics/month by focusing on creating more reader value than any other page of content Google could show for the keywords I want to rank for, and publishing hundreds of pages of content.
IMHO actually good UX metrics mean as low time on-site and pages visited as possible. An ideal user experience (I would, as a user, be glad to pay for) is when you visit the page, immediately find what you want, do you job as quickly as possible and go away.
A good valuable website caring about users rather than ad-spamming them would optimize for this, not for users to waste huge amounts of time wandering through pages until they can achieve their goal.
Recipe related searches will have different UX metric gradient than "creating a PTO policy"
I also kindly disagree with your assessment.
All things being equal, if you're Google, and you want to keep users coming back to Google Search, and you could show one of two pages for any search query, I think the only reliably metric to evaluate whether one page adds more value to the user than another page is through UX metrics.
Generally, if you can't find what you're looking for - you'll bounce and look somewhere else.
But if you Google something, then get drawn into the website because the writer knew the 'intent' behind the search, the writer/website should ALSO know what you need to know next, or likely questions to have, and serve you that content after they finish answering whatever is you originally Googl'd for.
For example, if someone searches "content writer job description", I can guess that
1. This is an employer that is actively in the hiring cycle
2. The next things they might need to know are average comp for content writers, the best place to find content writers, the best way to evaluate / test / interview them, etc.
So, if I'm competing with a page of content that is just strictly about "content writer job description", and I go above and beyond to educate you on what you'll need to know next - I should end up with better UX metrics that reflect an increase in value I provided over the page.
Here is the playbook we used to grow a website from 0 to 1,500,000 organics/month: https://workello.com/0-to-1-500-000
I'd add that third-party dependencies are sometimes useful. Especially when they aren't served from the same location which gives and opportunities for the browser to open more HTTP connections: https://www.linkedin.com/pulse/why-does-your-browser-limit-n...
Also both Angular and React are not as heavy as one might expect, but 3rd-party components might bring tons of unnecessary deps.
It doesn't have to be that way though. If you want to use React, there are tools to help you easily make something like a static site generator (SSG) which will transform your React code down into pre-rendered HTML pages. Two popular ones are Gatsby (https://gatsby.dev/) and Next.js (https://nextjs.org/) which also supports Server Side Rendering (SSR).
So out of the box plain HTML / CSS might be more optimized than a fresh create-react-app repo, but if you prefer to use the toolset provided by React to build your site (or Vue or Angular, etc), there are plenty of options to make that equally performant.
That's not what I meant. With optimising page speed, there is a diminishing curve of returns from the perspective of time invested and the improvement that you make.
My idea, adding to the top comment mentioning the SEO, was to make sure that you don't slow down your landing pages / content unnecessarily which might lead to less organic growth and discovery.
While I wouldn't argue that this is the most important thing that will take your business off, a fast website and good content with keywords might provide you nice boost long term.