When I work with rural districts across the Great Plains, the same frustration comes up in different words: the course is built, the content is good, and a good share of the students cannot open it. The problem is rarely the pedagogy. It is a 3 MB page that takes most of a minute to load on the connection a family actually has.
Before getting into specifications, I want to say why I treat this as a design problem rather than an infrastructure problem I am waiting on someone else to fix. Melissa Sadorf, writing from thirty years as a rural educator and superintendent in The Resilient Rural Leader, describes what she calls high-capacity leadership: the reality that a rural administrator is often the district manager, the grants director, the HR office, and the technology coordinator at once. She does not treat that as a burden to be pitied; her point is that rural leaders are already resourceful, and that any outside help worth having starts from what a community has rather than what it lacks. Caitlin Scott at Education Northwest makes a related observation about the building itself: “in many rural areas, the school is already the hub,” the place where far-flung neighbors meet for everything from football to voting.
That framing changes what the technical work is for. Designing for a 1 Mbps connection is less a concession than a way of taking the community’s actual assets seriously: the phones people already own, the school building that already serves as the access point, and the teacher who is doing four jobs and does not have time to re-encode a video. It also means the outsider’s job, mine included, is to bring technical choices that fit the place rather than a platform that assumes a different one.
So if you are building online courses for students in that context, you need to design for the connections they have, not the ones you wish they had. What follows is specific.
What connection are you designing for?
Start by naming the target. Here is how different connection speeds translate to course design:
- 1 Mbps (rural DSL, poor connection): the baseline. Pages need to be under 500 KB to load in under 5 seconds.
- 3 Mbps (rural DSL, decent connection): a more realistic target for many rural areas. Pages up to about 1.5 MB still load in reasonable time.
- 5+ Mbps (good broadband): fine if your whole audience has it, but do not assume it.
Latency matters too. A rural satellite connection might show 10 Mbps download speeds and still take 600 milliseconds or more to answer each request, which makes every click feel sluggish. Test for that as well as for speed.
How small should images be?
Images are usually the heaviest thing on a course page, which makes them the biggest opportunity. Working targets:
- Content images: under 100 KB (aim for 50 to 80 KB)
- Hero or full-width images: under 200 KB
- Thumbnails: 10 to 30 KB
- Background images: under 200 KB
Format matters. WebP files run roughly a quarter to a third smaller than JPEG at similar quality, and every current browser supports them. The workflow is simple: 1) start with images no wider than 1200 to 1920 pixels, 2) export at screen resolution rather than print resolution, 3) compress with a tool like TinyPNG or ImageOptim, and 4) check the final file size before uploading.
The most common source of bloat I see is instructors uploading photos straight from their phones. A single training session on image optimization is usually enough to change that, and it is the highest-return hour in the whole process.
When is video worth the bandwidth?
Video earns its place for demonstrations and anything visual, but it is the heaviest thing most courses carry. For lecture-style content with little motion:
- 480p at 800 to 1,500 kbps works for most educational content
- 720p at 1,000 to 2,000 kbps if you need higher quality
- 360p at 500 to 800 kbps for truly constrained connections
A 10-minute lecture at 480p should come to roughly 60 to 110 MB, and at 720p roughly 80 to 150 MB. H.265 compresses better than the older H.264, but browser support for it is still uneven, so for anything students will stream in a browser, H.264 at a sensible bitrate is the safer default.
The question to ask first is whether the content needs video at all. Video earns its cost for procedural skills and visual demonstrations. For conceptual content and explanations, audio or text usually works as well at a fraction of the size. A one-hour audio lecture at 96 kbps comes to about 43 MB. The same hour of 720p video at 1,500 kbps is around 675 MB, roughly fifteen times as much. I make the longer case for this in Audio-Only Options.
What about audio?
For voice content, 64 kbps mono is acceptable, 96 kbps is a good default, and 128 kbps is only worth it when music or high-fidelity sound matters. MP3 at a constant bitrate plays on nearly every device. Audio works best for lectures, discussions, interviews, conceptual material, and learners who are on the move. Always provide a transcript alongside it, which serves accessibility, lets students scan and search, and gives them a text option if they prefer one.
How do you keep PDFs light?
PDFs are still essential in many courses, and they are often bloated. Aim for text-only documents under 100 KB, documents with images under 500 KB, and anything more complex under 2 MB, splitting larger documents into sections. When saving, turn on “Fast Web View” (also called linearization), which lets the file display page by page instead of waiting for the whole thing to download. For longer reading material, ePub is worth considering, since it is usually smaller than an equivalent PDF and reflows better on a phone. Keep PDF for materials that need a fixed layout or will be printed.
How do you test under real conditions?
You cannot see any of this from a fast connection, so you have to simulate a slow one. Chrome DevTools is the main tool: 1) open DevTools with F12, 2) go to the Network tab, 3) open the throttling dropdown, and 4) create custom profiles that match your audience. These are a reasonable starting set:
- Rural DSL (good): 5 Mbps down, 768 kbps up, 100 ms latency
- Rural DSL (poor): 1 Mbps down, 256 kbps up, 200 ms latency
- Rural 3G: 700 kbps down, 128 kbps up, 400 ms latency
Make sure to do an “Empty Cache and Hard Reload” (Ctrl+Shift+R in Chrome) so you see the page the way a first-time visitor does. For a second opinion, WebPageTest lets you pick a mobile device and a slow 3G profile and reports total page size, the number of requests (under 50 is good, over 100 needs attention), and load times. Lighthouse, built into DevTools, adds a performance score and specific suggestions. I would test every major course page before launch.
What should you change in the LMS?
Most LMS defaults are not set with slow connections in mind. In Canvas, steer video toward a host with adaptive streaming, such as YouTube, Vimeo, or an institutional platform like Kaltura or Panopto, so a student on a 1 Mbps connection automatically gets 360p that plays instead of 720p that buffers. Externally hosted video also stays out of the course storage quota, which account administrators can set and which is worth keeping modest to encourage lighter media habits. The Canvas Student app has an offline mode that, where it is enabled, lets students download pages, files, and other content to view without a connection; it will not cover quiz attempts or other interactive pieces, but it helps.
Structure matters as much as settings. A module with fifty or more items is slow to open on a weak connection, so keep modules to around 10 to 15 items, use Pages to gather related files and links instead of listing each one separately, and consider one module per week as the organizing unit.
How do you choose between text, audio, and video?
Use text when:
- Information is reference material (definitions, procedures, specifications)
- Content updates frequently
- Students need to search or scan quickly
- Bandwidth is severely constrained
Use audio when:
- Delivering conceptual explanations or lectures
- Visual elements are not essential
- Students might be mobile or multitasking
- Bandwidth is limited but not absent
Use video when:
- Demonstrating procedures or physical skills
- Visual details are essential to understanding
- Showing screen-based processes such as software tutorials
- Bandwidth supports it without shutting anyone out
Video is not the problem here. It just is not automatically the better choice, and when bandwidth is tight, the alternatives often do the same job for a fraction of the data.
What about progressive loading and offline access?
Lazy loading delays images and videos until the reader scrolls to them. Add this to image tags:
<img loading="lazy" src="image.jpg" alt="Description">On image-heavy pages this can cut the initial load considerably. Just do not lazy-load anything visible before the reader scrolls.
Adaptive bitrate streaming encodes video at several quality levels and switches between them based on the connection. Where the platform allows it, start at the lowest level (roughly 400 to 800 kbps for 240p to 360p) so playback begins right away, and let it step up when bandwidth allows.
True offline access takes a Progressive Web App built with service workers and cache storage. It is more work, but it lets students download whole modules (a reasonable target is under 50 MB each) and work with no connection at all.
What should you check before launch?
Page weight:
- [ ] Each page under 500 KB for a 1 Mbps target (or 1.5 MB for 3 Mbps)
- [ ] Under 50 requests per page
- [ ] All images under 200 KB, ideally under 100 KB
- [ ] PDFs under 2 MB with Fast Web View enabled
- [ ] Videos encoded at bitrates that fit the target connection
Load time:
- [ ] Course pages load within 5 seconds on simulated 3G
- [ ] WebPageTest results are acceptable
- [ ] Lighthouse mobile performance score above 50
Alternative access:
- [ ] Audio alternatives available for video content
- [ ] Transcripts provided for all audio and video
- [ ] Print-ready materials prepared for students who are offline
- [ ] Mobile offline access enabled in the LMS
Structure:
- [ ] Modules limited to about 10 to 15 items
- [ ] External video hosting set up
- [ ] Navigation that keeps page loads to a minimum
How do you explain the requirements?
With instructors, turn the constraint into something concrete: every 1 MB added to a page is about eight more seconds of waiting for a student on a 1 Mbps connection. Specific targets work better than general advice to “keep things small.” With administrators, the case is that a page that loads quickly on a weak connection also loads quickly on a strong one, so the work helps every student rather than a subgroup. With students and families, be clear about the minimums, roughly a 1 Mbps connection (3 Mbps recommended), a phone, tablet, or computer with an updated browser, and a couple of gigabytes free for offline materials, and list the places they can get online if home does not work, such as the library, a community center, or the school building itself, along with who to contact for help.
How do you roll it out in a rural district?
Start with a pilot at two or three representative sites, and put the training in the school building where people already gather rather than asking teachers to travel or log in from home. Treat the pilot as the needs analysis instead of running a separate one first; you will learn more about actual connectivity and devices from three weeks of real use than from a survey. Then collect specific feedback on what worked and what did not in those conditions before scaling. Most of what goes wrong in rollouts like this is a question of fit rather than technology, which is the same thing the bandwidth work is about.
What does this add up to?
Low-bandwidth course design is a set of deliberate choices: images under 100 KB, video at 480p with an audio alternative, pages under 1.5 MB. None of those numbers is arbitrary, and all of them come from what works on a 1 to 3 Mbps connection with rural latency. The practical move is to start with one course, run it through the checklist, test it throttled, fix the biggest problems, and then do the next one.
I do not want to pretend this fixes the underlying problem. Rural connectivity is an infrastructure and policy question, and designing around it well can make it easier for everyone else to leave it unsolved. But the students in these courses are enrolled now, and a lighter page is something a designer can deliver this semester, so I would rather do both: build for the connection families have while saying plainly, to anyone who will listen, that they should not have to settle for it.
If you have built for low-bandwidth students and found numbers that work better than these, I would like to hear about it. You can reach me at licht.education@gmail.com, and there are more tools, articles, and resources at bradylicht.com.
