How Should an International NGO's Website Work on a Slow Connection and an Old Phone?
Key takeaways
- Low-bandwidth access is best practice, not a legal duty: no law requires it, and WCAG 2.2 sets no page-weight or bandwidth rule.
- The HTTP Archive's Web Almanac 2025 found the median mobile home page weighed 2.56 MB in its July 2025 crawl, with images the largest share, followed by JavaScript and fonts.
- ITU's Facts and Figures 2025 reports that subscribers in low-income economies spend about 22 times as much of their income on a mobile broadband basket as those in high-income economies.
- Core Web Vitals are judged at the 75th percentile of page loads, so a site whose visits come mostly from donors on good connections can pass while the people on the weakest connections are never measured.
- The pages to make light are the routes a person in difficulty needs: contact, urgent help and how to get a service, in every language you serve, each with a written weight budget and an owner.
- Chrome DevTools can throttle the network, disable the cache and turn JavaScript off, but Google's own documentation says it cannot truly simulate a phone's processor, so test on a real cheap phone as well.
Summary
An international NGO's website does not need to be light everywhere, but the pages a person in difficulty needs (how to contact you, how to get urgent help and how to get a service) should arrive quickly on a slow, expensive connection and be readable before anything else loads. That means a written weight budget for those routes, no heavy images, fonts or third-party scripts on them, and a way to reach you that needs no data at all. ITU's 2025 figures show that people in low-income economies spend more of their income on mobile broadband than people in high-income ones, so the same page can cost your programme audience more than your donors. WCAG 2.2 sets no page-weight rule, so this is a design and governance decision, tested on a throttled connection and a cheap phone before every release.
The Short Answer
Make the few pages a person in difficulty needs arrive quickly on a slow, expensive connection and make them readable before anything else loads. Those pages are how to contact you, how to get urgent help and how to get a service, in every language you serve. Give them a written weight budget, keep heavy images, fonts and third-party scripts off them, and offer a route that needs no data at all. Then test them on a throttled connection and a cheap phone. The rest of the site can be heavier.
Your website was probably approved on office broadband. The people your programmes serve are not using it.
The section checklist carries low-bandwidth access as a Best practice row. No law requires it. The case for it is who is on the other end.
Why the Weight Lands on Them
Web pages have grown heavy. The HTTP Archive's Web Almanac 2025 found that the median mobile home page in its July 2025 crawl weighed 2.56 MB, and that images took the most bytes, followed by JavaScript and fonts. That is the typical page, not the worst one.
The same bytes do not cost the same everywhere. ITU's Facts and Figures 2025 reports that subscribers in low-income economies spend about 22 times as much of their income on a mobile broadband basket as those in high-income economies. A page your London donor opens without thinking can be a real cost to the person your programme exists for. I have not found a primary source that prices a single page load country by country, so this post does not give one.
There is also a measurement trap. Google judges Core Web Vitals at the 75th percentile of page loads, segmented by mobile and desktop. If most of your visits come from supporters on good connections, the site can pass while the people on the weakest connections sit in the quarter the threshold never looks at. The performance benchmarks post covers what to report to a board. This post is about the routes those averages cannot see.
Decide Which Pages Must Be Light
Not every page has to be. An annual report with photographs, a campaign film or an interactive map can stay as it is. The pages that must be light are the ones a person needs to act: the contact page, the urgent-help page and the page that explains how to get a service. What those pages should say is covered in service pages for people in crisis. This post is about how they arrive.
Each of those routes needs a weight budget: a number, written down, that the page may not exceed. No published standard sets one for charity pages, so do not borrow one. Measure each route as it stands, strip it to what a person needs (text, a phone number, an address, opening hours, the steps), and make the stripped weight the budget. Put it in the brief for whoever builds or maintains the site, and check it at every release. A budget nobody checks is a wish.
Language is part of the budget. The essential pages in every language you serve must be light too, and they must change on the same day as the English. A helpline number corrected in English and left wrong in Arabic is worse than a slow page. Who keeps translations current is the subject of multilingual website governance.
Some publishers keep a separate text-only site. NPR's text-only site shows the shape: headlines and links, no scripts or images and a link back to the full site. I would rather make the essential pages light in the main site than build a second copy of them. A copied lite site drifts like an unowned translation. If you do build one, produce it from the same content, never by hand.
Images, Fonts and Scripts
Images. They were the largest share of bytes in the Almanac's data. On the essential pages, use none or one, sized for a phone screen, with its width and height set so the text does not jump when it arrives. Never put a phone number or an address inside an image. It cannot be tapped, copied or read aloud.
Fonts. A brand typeface is a file the phone must download before it can show your words in it. On the essential pages, use the fonts already on the phone, or at least make sure the text appears in a fallback font while the brand font loads instead of staying invisible. A second script, such as Arabic or Devanagari, may need another font file. Check each language on an old phone, because the phone's own fonts may not cover every script either.
Scripts. Chat widgets, analytics tags, video embeds, maps and social feeds each have to be downloaded and then run on a slow processor. On the essential pages, load nothing the person does not need to act. Put the address in text, and load the map only when someone asks for it. The page should still show the number, the address and the steps with JavaScript switched off.
Watch the consent banner too. On a small screen, a banner can sit on top of the very phone number someone came for.
This is a supplier question as much as a design one. Every third-party script on your site was added by someone, usually for a good reason. Decide who may add a script, and ask what it weighs and which pages it loads on before it goes live.
A Route That Needs No Data
Some people will not be able to load any page at all. Give them a way to reach you that works without mobile data: a phone number as a tap-to-call link and, ideally, a number that accepts text messages, linked so it opens the phone's own messaging app. Messaging apps that people in your programme countries already use are a second route, not a replacement.
Whichever routes you offer, say who answers, when, in which languages and how quickly. Be careful what you ask people to send. A message sits on a phone that someone else may see, which is the same risk the quick exit post deals with.
Label one-way channels honestly. UNHCR's Help site for Jordan is published in Arabic and English, sends people to a phone helpline from its contact page, says plainly that it no longer receives email petitions, and offers a WhatsApp channel for updates. The channel gives people news; the helpline is how they reach UNHCR. I loaded it, and NPR's text site, on 1 October 2026. Neither is a client.
Accessibility Is a Neighbour, Not the Rule
WCAG 2.2 sets no page-weight, speed or bandwidth requirement. A site can conform and still be too heavy for a slow connection, and a light page can still fail it. Do not tell your board that accessibility work has covered this.
The two do meet. Success Criterion 1.4.10 Reflow asks for content that works without scrolling in two directions at a width equivalent to 320 CSS pixels, and the same discipline serves a small, old screen. Real text rather than text in images helps a screen reader and a slow connection alike. The governance case for accessibility itself is in website accessibility for nonprofits.
Test It the Way It Will Be Used
You do not need to travel to see the problem. Chrome's DevTools has a Throttling menu in its Network panel with fast 4G, slow 4G and 3G presets. Tick Disable cache to see the page as a first-time visitor gets it, which is how someone reaching you for the first time gets it. Custom profiles, with your own download speed, upload speed and latency, are set up in DevTools settings.
A connection is half the test. An old phone is also slow at running the page. DevTools can throttle the processor too, but Google's Performance panel reference says that throttling is relative to your own computer and that DevTools cannot truly simulate a phone's processor. Keep a cheap, older phone in the office and load the essential pages on it.
Finally, disable JavaScript from the Command Menu and reload. The number, the address and the steps should all still be there.
Give the test an owner and a trigger: every release that touches the essential pages, and every new script anywhere on the site. Record the weight against the budget each time. Ongoing measurement is covered in nonprofit website performance benchmarks.
A fast site on office broadband proves the office can reach it. A light route on a cheap phone proves the people you serve can.
Further Reading
- Section 31: Low-bandwidth access
- Section 27: Language and translation
- Section 24: Get urgent help
- Website Performance Benchmarks for NGOs
- Multilingual Website Governance for International NGOs
- What Should a Charity's Service Pages Give Someone in Crisis?
- What Does a Quick Exit Button Protect, and What Does It Not?
What This Post Does Not Cover
This is about how the essential pages arrive and who keeps them light. It does not cover what a service page should say, which is in the service pages post, or how to staff a helpline or a text line. It is not a build specification and names no platform. Whether a messaging route suits your data protection position is a question for your data protection lead.
Free download
Your website, for the board.
A two-page briefing you can fill in and put in the next board pack. It covers the six things funders check, how to see what AI tools say about you, and the options to put to trustees.
That did not send. Email hello@socialectric.com and we will send you the briefing. The spam check did not finish. Try again, or email hello@socialectric.com and we will send you the briefing.
Frequently asked questions
- Does WCAG 2.2 set a maximum page weight?
No. WCAG 2.2 has no page-weight, speed or bandwidth requirement, so a site can conform and still be too heavy for a slow connection, and a light page can still fail it. The two meet in places: Success Criterion 1.4.10 Reflow asks for content that works at a width equivalent to 320 CSS pixels, which is also the discipline a small, old screen needs. The wider case for accessibility as a governance duty is in website accessibility for nonprofits.
- Should we build a separate text-only version of our site?
Only if it is produced from the same content as the main site. A copied text-only site is a second site to keep current, and it drifts the way an unowned translation does, until it gives out an old phone number. Making the essential pages light in the main site avoids the problem. The low-bandwidth row of the section checklist asks for a text-only route to the essentials, not a second website.
- How can we test on a slow connection without travelling?
Use the throttling built into your browser. In Chrome, the Network panel's Throttling menu offers fast 4G, slow 4G and 3G presets, and Disable cache shows the page as a first-time visitor gets it. Google's Performance panel reference says CPU throttling is relative to your own computer and cannot truly simulate a phone's processor, so finish on a real, cheap phone.
- Can a messaging app channel replace our contact page?
Not if it only broadcasts. A channel that sends updates is not a way to reach you, so label it as updates and keep a two-way route beside it: a phone number, ideally one that accepts text messages. Say who answers, when and in which languages. What else a service page needs to say is in service pages for people in crisis.
- What page-weight budget should we set?
There is no published standard for a charity's essential pages, so do not borrow one. Measure the contact, urgent help and service pages as they are, strip each to what a person needs to act, and make that stripped weight the budget. Write it into the brief, give it an owner and check it at every release. How to report site performance to your board is in website performance benchmarks for NGOs.