Tell us about your nonprofit website
A senior engineer reads every message and replies within one working day.
Slow nonprofit websites are rarely slow for exotic reasons. These six causes are useful starting points for investigation; establish which ones affect your site before deciding between repair and redesign. Here is what actually breaks, what each fix costs, and the order to do them in.
Why are nonprofit websites so slow?
Because they accumulate. A tracking script for a grant report, a plugin for one event, a hero video added by a board member, photographs uploaded straight from a phone, and a hosting plan chosen in 2019. No single decision was wrong. Together they push a page past four seconds on mobile, which is where donors leave.
What are the most common causes?
| Cause | How often we find it | Typical time cost | Fix effort |
|---|---|---|---|
| Unoptimized images | Measure on representative pages | Measure on representative pages | Low |
| Too many third-party scripts | Measure on representative pages | Measure on representative pages | Low to medium |
| Plugin bloat | Measure on representative pages | Measure on representative pages | Medium |
| Cheap shared hosting | Measure on representative pages | Measure on representative pages | Low |
| Render-blocking fonts and CSS | Measure on representative pages | Measure on representative pages | Medium |
| Autoplay hero video or carousel | Measure on representative pages | Measure on representative pages | Low |
How much does slowness actually cost?
| Evidence to collect | What it tells you |
|---|---|
| Mobile loading by template | Where visitors wait for essential content |
| Giving-form starts | Whether visitors reach the giving task |
| Payment errors and completed gifts | Where the transaction actually fails |
| Like-for-like campaign comparisons | Whether completion changes after a repair |
A speed test alone cannot establish lost donations. Reconcile analytics with payment records, control for campaign and device differences, and report observed changes rather than assigning a universal revenue penalty to a load time.
What should we fix first?
In this order, because it is cheapest impact first:
- Compress and convert images to WebP or AVIF, cap hero images at 300KB
- Remove tracking scripts nobody owns, then defer the rest
- Delete unused plugins, replace the heavy ones
- Move to managed hosting with a CDN and object caching
- Self-host fonts, subset them, preload only what is above the fold
- Replace autoplay video with a poster image and click-to-play
Images and scripts are sensible first investigations. Measure the result on your own templates; neither a time saving nor a delivery window is guaranteed.
What does a performance fix cost?
| Scope | Cost | Timeline |
|---|---|---|
| Images, scripts, and caching review | Quote after assessment | Depends on affected templates |
| Broader performance remediation | Quote after diagnosis | Depends on implementation and testing |
| Rebuild or replatform | Quote against migration scope | Depends on content and approvals |
| Hosting change | Verify provider and migration fees | Depends on compatibility and cutover |
Start with diagnosis and a written repair scope. A rebuild is a decision to evaluate after identifying the causes, not the automatic result of a failed speed test.
What targets should we hold ourselves to?
| Metric | Good Core Web Vitals threshold | Why measure it |
|---|---|---|
| Largest Contentful Paint | At most 2.5 seconds | Loading of the largest visible content |
| Interaction to Next Paint | At most 200 milliseconds | Responsiveness to interactions |
| Cumulative Layout Shift | At most 0.1 | Unexpected layout movement |
| Page weight | Set a project-specific budget | Download cost on representative devices |
| Third-party scripts | Retain only justified dependencies | Loading, privacy, and reliability costs |
These Core Web Vitals thresholds come from web.dev’s Web Vitals guidance and are assessed at the 75th percentile of page visits. Additional page-weight and script budgets are project recommendations, not Google ranking or donation guarantees. Use field data alongside controlled lab tests.
Who should own performance after launch?
Name one person and give them a quarterly checklist: run field data on the top ten pages, review the third-party script list, check image sizes for anything added that quarter, and confirm the plugin and core updates ran. Budget enough time to investigate findings and test changes; a fixed quarterly time allowance cannot guarantee sustained performance.
Does hosting really matter that much?
Hosting affects server response, caching, availability, and operational support. Measure those factors before selecting a provider. Compare compatibility, backups, CDN behavior, incident response, and the cutover plan alongside price; no universal server-response time is promised here. Frontend images, scripts, and templates still need separate assessment after a hosting change.
What about accessibility and speed together?
They pull in the same direction more often than not. Lighter pages, fewer scripts, real text instead of images of text, and no autoplay media all improve both. Treat them as one workstream and you pay for the audit once.
Where to go next
Run your five most important pages through a field-data tool, write down the LCP numbers, and fix images and scripts first. Come back to the platform question only after that.
Related reading: the complete guide to nonprofit donation friction, how to fix nonprofit websites in 2026, and what nonprofits should look for in website development. Want the numbers for your site? Request a free website audit.
Frequently asked questions
/What should we review before changing our nonprofit website?
Start with the visitor task, the affected templates, accessibility barriers, publishing workflow, and integrations. Use actual visitor and editor evidence to prioritize the work rather than choosing features first.
/Do we need a full rebuild?
Not necessarily. A focused repair may address the problem if the content model and supported platform are suitable. Compare repair and rebuild scope after documenting the causes and ongoing support requirements.
/How much will the work cost?
The price depends on templates, migration, integrations, accessibility testing, training, and ongoing care. Review DoodleWeb pricing and request an itemized proposal rather than relying on a sector-wide price range.
/Can these changes guarantee more donations or applications?
No. Outcomes also depend on audience, campaign quality, program demand, and other factors. Agree on baseline measurements and review completed visitor tasks after changes.
/How can DoodleWeb help us assess the next step?
Use the contact form on this page to share the site, visitor task, and current constraints. Review the relevant published case study and ask for a scope covering assessment, implementation, testing, and handover.
Relevant client work
Miles Nadal Jewish Community Centre is a DoodleWeb client. We do not claim donation results for this engagement.
Young Americans Center: one platform, distinct audiences
Our published case study describes a shared WordPress component system for financial-education programs and the bank, with separate editorial tracks. It illustrates audience clarity and content organization, not a measured donation uplift.
Read the case study →Distinguish slow loading from slow publishing: they need different repairs.
- Measure campaign, program, and giving pages with representative mobile connections.
- Inventory scripts and plugins with an owner, purpose, and removal decision.
- Ask editors which routine updates require engineering help and identify the missing template or permission.
Sources and fact-check report
Reviewed 2026-10-05. Site sources substantiate published project scope and client recognition, not independently audited outcomes. Recommendations are editorial guidance, not revenue, ranking, compliance, price, or delivery guarantees.
- DoodleWeb Brand Book / brand guidelines
- DoodleWeb published identity and client recognition
- Published project scope: Young Americans Center
- W3C WCAG 2.2: Level AA conformance criteria
- Google web.dev: Core Web Vitals definitions and thresholds
- Reviewed claim: | Unoptimized images | 9 of 10 audits | 1.2s to 3.5s | Low |
Resolution:| Unoptimized images | Measure on representative pages | Measure on representative pages | Low |
- Reviewed claim: | Too many third-party scripts | 8 of 10 | 0.8s to 2.5s | Low to medium |
Resolution:| Too many third-party scripts | Measure on representative pages | Measure on representative pages | Low to medium |
- Reviewed claim: | Plugin bloat | 7 of 10 | 0.5s to 2.0s | Medium |
Resolution:| Plugin bloat | Measure on representative pages | Measure on representative pages | Medium |
- Reviewed claim: | Cheap shared hosting | 6 of 10 | 0.4s to 1.5s server time | Low |
Resolution:| Cheap shared hosting | Measure on representative pages | Measure on representative pages | Low |
- Reviewed claim: | Render-blocking fonts and CSS | 6 of 10 | 0.3s to 1.2s | Medium |
Resolution:| Render-blocking fonts and CSS | Measure on representative pages | Measure on representative pages | Medium |
- Reviewed claim: | Autoplay hero video or carousel | 4 of 10 | 1.0s to 4.0s | Low |
Resolution:| Autoplay hero video or carousel | Measure on representative pages | Measure on representative pages | Low |
- Reviewed claim: | Under 2s | Baseline |
Resolution:| Measure on representative pages | Baseline |
- Reviewed claim: | 3s | Roughly 20% fewer completed gifts |
Resolution:| Measure on representative pages | Establish a project-specific baseline |
- Reviewed claim: | 4s | Roughly 35% fewer |
Resolution:| Measure on representative pages | Establish a project-specific baseline |
- Reviewed claim: | 5s+ | Roughly half or worse |
Resolution:| Measure on representative pages | Roughly half or worse |
- Reviewed claim: | Quick-win pass (images, scripts, caching) | $2k to $6k | 1 to 2 weeks |
Resolution:| Quick-win pass (images, scripts, caching) | Quoted for the agreed scope | 1 to 2 weeks |
- Reviewed claim: | Full performance remediation | $8k to $22k | 3 to 6 weeks |
Resolution:| Full performance remediation | Quoted for the agreed scope | 3 to 6 weeks |
- Reviewed claim: | Rebuild on a performance-first platform | $30k to $90k | 10 to 20 weeks |
Resolution:| Rebuild on a performance-first platform | Quoted for the agreed scope | 10 to 20 weeks |
- Reviewed claim: | Managed hosting upgrade | $35 to $300/mo | Days |
Resolution:| Managed hosting upgrade | Quoted for the agreed scope | Days |
- Reviewed claim: | Largest Contentful Paint | Under 2.5s | Google field threshold and donor patience |
Resolution:| Largest Contentful Paint | Measure on representative pages | Google field threshold and donor patience |
- Reviewed claim: A $6/month shared plan often returns the first byte in 800ms to 1.4s, which no amount of front-end work can recover.
Resolution:Request a scoped estimate covering content, templates, integrations, testing, training, and ongoing support; the price and delivery date depend on the agreed work.
- Reviewed claim: The same six causes account for nearly every site we audit, and most of them are fixable in weeks without a redesign.
Resolution:These six causes are useful starting points for investigation; establish which ones affect your site before deciding between repair and redesign.
- Reviewed claim: | Load time on mobile | Relative donation completion |
| --- | --- |
| Measure on representative pages | Baseline |
| Measure on representative pages | Establish a project-specific baseline |
| Measure on representative pages | Establish a project-specific baseline |
| Measure on representative pages | Roughly half or worse |
A site with 40,000 annual sessions and a 4-second donation page is usually leaving five figures on the table each year. That is the number to bring to a board meeting, not a Lighthouse score.
Resolution:| Evidence to collect | What it tells you | | --- | --- | | Mobile loading by template | Where visitors wait for essential content | | Giving-form starts | Whether visitors reach the giving task | | Payment errors and completed gifts | Where the transaction actually fails | | Like-for-like campaign comparisons | Whether completion changes after a repair |
A speed test alone cannot establish lost donations. Reconcile analytics with payment records, control for campaign and device differences, and report observed changes rather than assigning a universal revenue penalty to a load time.
- Reviewed claim: > Most nonprofit sites gain a full second from the first two steps alone, in under a day of work.
Resolution:> Images and scripts are sensible first investigations. Measure the result on your own templates; neither a time saving nor a delivery window is guaranteed.
- Reviewed claim: | Scope | Cost | Timeline |
| --- | --- | --- |
| Quick-win pass (images, scripts, caching) | Quoted for the agreed scope | 1 to 2 weeks |
| Full performance remediation | Quoted for the agreed scope | 3 to 6 weeks |
| Rebuild on a performance-first platform | Quoted for the agreed scope | 10 to 20 weeks |
| Managed hosting upgrade | Quoted for the agreed scope | Days |
Start with the quick-win pass. If the site still cannot hit targets afterward, the platform or theme is the problem and a rebuild is a legitimate conversation.
Resolution:| Scope | Cost | Timeline | | --- | --- | --- | | Images, scripts, and caching review | Quote after assessment | Depends on affected templates | | Broader performance remediation | Quote after diagnosis | Depends on implementation and testing | | Rebuild or replatform | Quote against migration scope | Depends on content and approvals | | Hosting change | Verify provider and migration fees | Depends on compatibility and cutover |
Start with diagnosis and a written repair scope. A rebuild is a decision to evaluate after identifying the causes, not the automatic result of a failed speed test.
- Reviewed claim: | Metric | Target | Why |
| --- | --- | --- |
| Largest Contentful Paint | Measure on representative pages | Google field threshold and donor patience |
| Interaction to Next Paint | Under 200ms | Form responsiveness on older phones |
| Cumulative Layout Shift | Under 0.1 | Mistapped donate buttons |
| Page weight | Under 1.5MB | Rural and cellular donors |
| Third-party scripts | Under 6 site-wide | Every one is a dependency |
Measure with field data from real users, not a lab test on office wifi. A lab score of 95 and a field LCP of 4.1 seconds happen constantly.
Resolution:| Metric | Good Core Web Vitals threshold | Why measure it | | --- | --- | --- | | Largest Contentful Paint | At most 2.5 seconds | Loading of the largest visible content | | Interaction to Next Paint | At most 200 milliseconds | Responsiveness to interactions | | Cumulative Layout Shift | At most 0.1 | Unexpected layout movement | | Page weight | Set a project-specific budget | Download cost on representative devices | | Third-party scripts | Retain only justified dependencies | Loading, privacy, and reliability costs |
These Core Web Vitals thresholds come from web.dev’s Web Vitals guidance and are assessed at the 75th percentile of page visits. Additional page-weight and script budgets are project recommendations, not Google ranking or donation guarantees. Use field data alongside controlled lab tests.
- Reviewed claim: Fifteen minutes a quarter prevents the slow decay that brings sites back to us three years later.
Resolution:Budget enough time to investigate findings and test changes; a fixed quarterly time allowance cannot guarantee sustained performance.
- Reviewed claim: Server response time sets the floor for everything else. Request a scoped estimate covering content, templates, integrations, testing, training, and ongoing support; the price and delivery date depend on the agreed work. Managed WordPress or Drupal hosting with a CDN typically lands at 150ms to 300ms. For most nonprofits this is the highest-value line item per dollar on the whole site.
Resolution:Hosting affects server response, caching, availability, and operational support. Measure those factors before selecting a provider. Compare compatibility, backups, CDN behavior, incident response, and the cutover plan alongside price; no universal server-response time is promised here. Frontend images, scripts, and templates still need separate assessment after a hosting change.
Principal Engineer · Seattle, WA
Kamal builds and rescues Drupal and WordPress platforms at DoodleWeb. Most of his work involves performance budgets, accessible component systems, and migrations that keep editorial teams sane.
