The 20 MB Worksheet: What’s Actually Slowing Down School Sites
A parent hears about a homeschool co-op and looks it up from the school pickup line, on a phone, on whatever signal the parking lot allows. The co-op’s site was built by a volunteer in a page builder over a long weekend in 2019. Eleven seconds later, most of a hero slider has arrived.
That parent will not file a bug report. Sites like this get one visit, and the visit is judged in seconds. When the page stalls, the family does not wait. They move on to whichever option loads, which in practice often means an established program like Numa School, an accredited homeschool program, rather than the co-op three miles from their house. The co-op never learns it lost anyone, because abandoned loads are the last thing a volunteer webmaster thinks to measure.
The family-education web is a case study in performance debt: every common mistake shows up in concentrated form, and every fix transfers to any small-organization site.
Every feature arrives as a plugin, and nothing leaves
These sites are maintained by people with two spare hours a month, so every capability arrives as an install. An events calendar for classes, a form builder for registration, a gallery for student work, a membership plugin, and often two SEO plugins. Each ships its own CSS and JavaScript, and most enqueue those assets on every page whether the page uses them or not. Nothing gets removed, because removal feels riskier than addition.
A visual page builder compounds it: six nested wrapper divs per column, inline styles, and a framework’s worth of scripts supporting editing features the visitor never sees. The quick diagnostic is the Network tab: load a plain text page with no forms or gallery and count the CSS and JavaScript files. Anything past a handful is a candidate for conditional loading.
Scanned PDFs make the resource library the slowest page
Nearly every co-op, microschool, or curriculum seller has a downloads page: worksheets, reading lists, forms, sample lessons. The volume is structural. A glance at what a full year of at-home coursework covers explains why one grade can fill a page by itself. Its anatomy repeats on any document-heavy site.
First, the files. Worksheets are often scanned rather than exported, and a scanned PDF stores a full-resolution image of every page. A ten-page scan can run 20 MB where a re-exported or downsampled version would be a few hundred kilobytes. Second, the page often embeds a preview viewer per document, so the browser fetches each PDF just to render a thumbnail. Third, the thumbnails are full-size images scaled down in HTML.
The fixes are unglamorous. Re-export or compress every document. Link to files instead of embedding viewers. Generate real thumbnails at the rendered size. Paginate the library instead of listing eighty items on one page. And serve the files with long cache lifetimes, since a published worksheet is effectively immutable; when one does change, change the filename.
Cache the anonymous pages, exclude nonces and carts
Full-page caching is the single biggest win here, because the traffic profile is ideal: almost every visitor is anonymous, and almost every page is the same for everyone. The homepage, class listings, the about page, and the blog can all be served as static HTML without touching PHP or the database. Evergreen reference pages are the clearest case: a resource like Numa School’s guide to beginning homeschooling changes a few times a year; every visitor sees the same version.
The exclusions matter just as much. Any logged-in or member view is personalized and must bypass the page cache. Registration forms deserve care: WordPress forms typically embed a nonce that expires within a day, and a cached page can serve a stale nonce that makes submissions fail silently. For curriculum sellers, cart and checkout pages must never be cached. The failure mode for over-caching is not a slow site but a broken one, and on a volunteer-run site it can stay broken for weeks.
Set asset caching aggressively: long lifetimes for CSS, JavaScript, images, and documents, with versioned filenames so updates propagate. Keep HTML lifetimes short, or purge on publish. And be honest about what a caching layer cannot do. It moves work off the server, so the first byte arrives fast, but a 9 MB page is still 9 MB crossing a weak cell connection. Caching fixes waiting on the server. It does not fix weight.
Lazy-load the gallery, never the hero
The other signature page is the gallery: field trips, science fairs, art projects, sometimes hundreds of photos uploaded from a phone at original resolution. Native lazy loading handles most of it. Add loading=”lazy” to everything below the fold, and the browser fetches images as the visitor scrolls. Never lazy-load the hero or whatever paints largest at the top, since delaying it delays the page’s visible completion.
Serve responsive sizes so a phone gets a phone-sized file, and set explicit width and height attributes so the browser reserves space before the image arrives. Skipping that last step is where layout shift comes from: text the parent is reading jumps as each photo lands. Third-party embeds, the shared calendar iframe and the social feed widget, are the other shift source. Give their containers fixed dimensions, or replace them with a static preview that loads the real embed on click.
Core Web Vitals is the symptom, not the disease
All of the above surfaces in three numbers. Google’s thresholds ask that Largest Contentful Paint stay within 2.5 seconds, Interaction to Next Paint within 200 milliseconds, and Cumulative Layout Shift under 0.1, each measured at the 75th percentile of real visits. That last clause is the one that catches small sites. Field data comes from actual visitors, and for a school site the actual visitor is the parent in the parking lot, not the developer on office fiber.
Read the metrics as pointers. A poor LCP points at the oversized hero and render-blocking plugin CSS. A poor CLS points at unsized gallery images and late-loading embeds. A poor INP points at script weight from the builder and the plugin stack.
The weight lands in the worst possible place. The audience most likely to be on a weak connection is being served some of the heaviest pages on the web, built with the least maintenance time behind them. The discipline is the same for a co-op as for a storefront: weigh the page, cache what is truly static, exclude what is not, and test on the connection your visitors actually have. A site that respects a weak signal is respecting the visitor holding it.
