Thou shalt optimize and simplify
Choose the right deployment provider!
You may be questioning these:
Why do we talk about deployment first of all? 🤔
We hadn’t built anything yet, what do we have to deploy? 😕
Calm down! Calm down! Deployment provider has a huge influence on overall tech stack building and the overall performance of your website.
Most deployment providers say they support all web frameworks and all the latest technologies to attract customers 🎉, but they never tell you the whole story.
This article will show you how to evaluate a deployment provider 😃
HTTP/3 support
It’s 2022 already, you should start your new website with HTTP/3 support 😥.
To learn more about HTTP/3, you can read this article HTTP/3.
To check whether a provider support HTTP/3, you can use http3check.
Edge computing
On the first day, we serve static HTML files 📁.
Then we have Web 2.0 and we build Server Pages like JSP, ASP, … 📟
Then we have serverless functions like AWS Lambda, Azure Functions, Google Cloud Functions,… ☁️
Lately, some people decided to bring the servers next to your house 🏠 and we have Edge computing ⏩
Edge computing is worldwide distributed serverless computing with zero cold-start e.g. Vercel edge functions, Cloudflare Workers, Netlify Edge.
Pages
Whenever you wanna start a new website, you should think about the Pages providers first. You clearly don’t want to set up a huge distributed autoscaling clustering serverless cloud computing network worldwide 😵.
For example, Github Pages, Cloudflare Pages, …
While Github Pages doesn’t support server-side workers like Cloudflare Pages, it can still provide you a 100 GB bandwidth/month 😛.
Incremental rendering
Let’s answer these questions:
- Can your website be pre-rendered at compile time?
- Is your database change regularly or never change?
- What if you pre-render the whole database into HTML files and push them to Github Pages? 🤔
You can take advantage of CI/CD workflow to regenerate your HTML hooked by the database changes.
Most CI/CD providers give you around 1000–2000 free minutes for a private repository every month 🆓 which is enough for small shopping websites.
Caching
You should never try to cache the database query results or any intermediate results.
The only thing you should cache is the final HTML rendered result!
If you need to cache intermediate results, you should be rethinking your tech stack:
- How identical is the size of the intermediate results vs the HTML result? For example, your framework adds too much div wrapper just to show a span of ‘Hello World!’? 😥
- How about semantic tags 💡? Stop using so many divs! An intro to semantic HTML.
- Did you embed all JS and CSS into a single HTML output 😐?
Concurrent server-side
Sometimes, your API needs to fetch data from several other endpoints. Did you just await fetch every single one of them? 😖
Maybe you didn’t know that your deployment provider supports concurrent fetches? 😙
Promise.all([<fetch 1>, <fetch 2>, …])Continuous Integration frequency
Do you build a new website preview on every release? every pull request? or every new commit?
Providers always give you some free minutes every month. Is it enough for your project?
You may consider their paid plan too so that you don’t need to move to another provider once you realize the price is too high 🤑!
Monorepo support
Monorepo is a must in recent years because it follows the Single source of Truth 👊.
Imagine everything was perfect but your favorite deployment provider doesn’t support monorepo 😅. In that case, the recommended solution is the mirror your subproject into another standalone repository and set up your CD pipeline on that repo 😃.
References
https://blog.cloudflare.com/http3-the-past-present-and-future/
