Why a site about rendering
Most web performance advice was written for content sites: compress images, cache pages, trim plugins. That advice still matters, but it does not explain why a modern app built with React, Vue or Angular can load quickly and then ignore the first three taps. The answers sit in rendering strategy, hydration, JavaScript execution and the main thread, and they differ by framework and version.
Renderloria exists to explain those topics clearly, with sources, and to help teams that want an outside view of their own app.
What we publish
- Guides on rendering strategies, hydration, Interaction to Next Paint, long tasks, framework behaviour, monitoring and bundles, each checked against primary documentation and dated.
- Free tools that run in your browser: a rendering pipeline simulation, an INP budget planner and an optimization planner. None of them collects data.
- Illustrative examples that show the format of our findings, clearly marked as fictional.
Who it is for
Engineers, technical leads and product managers at product companies, agencies and in-house teams in Canada. The writing assumes you know what a component is, but not that you have read every framework's release notes.
How the site is funded
The guides and tools are free to use. Our funding and commercial interest are described in the site footer. We take no advertising, affiliate commissions or sponsored posts, and no framework, host or vendor pays for mentions.
What we will not do
- Invent numbers. Figures come from cited sources or are labelled illustrative.
- Show testimonials, logos or case studies we cannot back up. We have none to show yet, and we say so.
- Promise scores or rankings.
- Track you. This site uses no analytics or advertising scripts.
What a rendering problem looks like to users
Users do not talk about hydration or long tasks. They say a button "didn't work", a page "froze", or text "jumped" just as they went to tap. Behind those reports are measurable causes: a handler that was not attached yet, a long task holding the main thread, a font swap or a late banner shifting the layout. Much of our writing is about connecting those everyday complaints to the metrics and traces that explain them, so teams can fix the cause rather than the symptom.
Why Canada
We focus on Canadian product teams because it lets us write precisely about the context they work in: Canadian dollars in pricing, Canadian spelling, privacy rules under PIPEDA and Quebec's private-sector law when we discuss monitoring, and accessibility expectations such as Ontario's web requirements. The technical content applies anywhere, but the practical notes are written for Canada.
How this site is built
This site practises what it describes. Pages are rendered to static HTML ahead of time and need no JavaScript to read; the only script on the site powers the menu on small screens and the three free tools. There are no analytics, advertising or third-party scripts, and fonts are served from our own domain.
How we write
Guides are written by Isabella Ward, a pen name used by our editor. We use a pen name rather than list a team or credentials, and we would rather you judge the writing by its sources and reasoning. The editorial policy explains how we research, cite, correct and update.
Our standards for advice
Advice about performance is easy to give and hard to check, so we hold ourselves to a few rules:
- Every factual claim about a metric, browser API or framework feature points to its source.
- Every recommendation names its trade-off. Hydrating later saves start-up time but can delay the first interaction with that component; caching saves server time but needs a plan for invalidation.
- Version-specific advice names the version.
- We say when we do not know. If a change is likely to help but its size cannot be estimated before it ships, we say so.
Corrections are welcome
If a guide is wrong, out of date or unclear, we would rather hear about it than have it repeated. The editorial policy explains how corrections are noted.
How we choose topics
We pick topics from three sources: framework and browser release notes that change established advice, questions engineers raise in public discussions about performance, and the problems teams ask us about. A topic earns a guide when we can say something specific and checkable about it. When a release makes a guide out of date, updating that guide takes priority over writing a new one.
What success looks like for a reader
We consider a guide successful when an engineer can reproduce its method on their own app without contacting us: record the right trace, read the right fields and choose a sensible fix. If you used a guide that way, we would be glad to hear about it, and equally glad to hear where a guide fell short.
Get in touch
Questions about a guide, corrections, or a project you would like reviewed: write to hello@renderloria.online or use the contact page.