If your nonprofit's website takes more than a few seconds to load, you are losing donors and search rankings you never see leaving. Speed is not a vanity metric. It is the difference between a visitor who reaches your donate button and one who gives up before the page even paints.
Google measures this directly, and so do your would-be members. Here is what the numbers mean, what actually slows a site down, and how to fix it - in plain language, from someone who tunes these for a living.
The three numbers Google actually measures
Google's Core Web Vitals are three real-world measurements of how a page feels to a human:
- Largest Contentful Paint (LCP) - how long until the main content shows up. Aim for under 2.5 seconds.
- Interaction to Next Paint (INP) - how quickly the page responds when someone taps or clicks. Aim for under 200 milliseconds.
- Cumulative Layout Shift (CLS) - how much the page jumps around as it loads. Aim for under 0.1.
These are not academic. They feed Google's ranking systems, and they track almost exactly with whether a visitor stays or bounces. A page that paints fast and holds still converts; one that stalls and jumps loses people before they read a word.
Why nonprofit sites get hit hardest
Mission-driven sites tend to collect the exact things that slow a page down:
- Heavy, unoptimized images - event photos and hero banners shipped at full camera resolution.
- Template and plugin bloat - a theme plus a dozen plugins, each loading its own scripts and styles whether the page uses them or not.
- Third-party tags - analytics, donation widgets, social embeds, chat boxes - each one a request to someone else's server that you do not control.
- Rented platforms - all-in-one tools that load the same generic bundle for every org, tuned for nobody in particular.
None of these are moral failings. They are what happens when a busy team bolts on what it needs over the years. But they compound, and the donor on a phone with two bars of signal is the one who pays for it.
What actually makes a site slow
When I audit a slow site, the cause is almost always one of four things, roughly in this order:
- Images. Usually the single biggest win. The fix is boring: resize to the dimensions actually displayed, compress, and serve modern formats.
- Render-blocking and unused code. CSS and JavaScript the browser must download and process before it can show anything - much of which the page never uses.
- Third-party scripts. The tags above, running on the main thread and blocking everything else. Deferring them until the page is interactive often recovers whole seconds.
- Where and how it is hosted. A page prebuilt and served from a global edge network beats one generated on a single origin server on every request.
How to fix it without a full rebuild
You rarely need to start over. In order of return on effort:
- Optimize your images first. On most sites this alone moves LCP under the threshold.
- Defer non-critical third-party scripts so they load after the page is usable, not before.
- Set explicit width and height on images and reserve space for embeds, so the layout stops jumping. That is your CLS.
- Cut the plugins and scripts you no longer use. Every one you remove is bytes the visitor no longer downloads.
If the platform itself is the bottleneck - a rented all-in-one that ships the same bloated bundle to everyone - speed becomes one more reason to ask whether you should own your site instead of rent it.
Speed is a donation and membership multiplier
Here is the part that should get a board's attention: every second of delay costs you conversions. Slower pages mean fewer completed donations, fewer event registrations, and fewer membership sign-ups - on traffic you already paid to attract. Fixing speed does not just help SEO; it raises the return on every visitor who was already coming.
It is also one of the cheapest growth levers you have. You are not buying more traffic. You are keeping the people who already showed up.
How to measure it honestly
Two kinds of data matter. Lab tests like PageSpeed Insights simulate a load and give you a score to act on. Field data - Google's CrUX, gathered from real Chrome users - tells you what your actual visitors experience, and it is what Google ranks on. Chase the field data; use the lab score to find what to fix. A small site with little traffic may not have field data yet, which is its own signal worth noticing.
For what it is worth, this site loads its main content in under two seconds on a phone, with effectively no layout shift. That is not a brag - it is the baseline every site should clear, and most can clear it in a focused afternoon of the work above.
Fast is not a feature you add at the end. It is the result of not shipping the things that make a site slow.
If your site feels sluggish and you are not sure why, that is exactly what a short audit answers. The free Replatform Risk Checklist covers speed among the things to protect when you change platforms - or tell me what you are running and I will tell you where the seconds are going.