Debugging Slow Page Loads on the School Website
The school website's news page takes 6.2 seconds to load on the school network. It contains 40 images (average 900 KB each), three JavaScript files totalling 2.1 MB, and a single database query. The server is a modest shared host. A teacher suggests the problem is the database and wants to add indexes. A student measures that the HTML arrives in 0.3 s, images finish at 4.8 s, and scripts finish at 6.0 s. There are 1,200 students; at lunchtime 200 load the page within a few minutes.
1. Use the measurements to identify the dominant cause of the 6.2 s load. Evaluate the teacher's database hypothesis.
Read the worked answer
The HTML arrives at 0.3 s, so the server-side database query is not the bottleneck. Images finish at 4.8 s and scripts at 6.0 s, so the page is dominated by transfer of large assets: 40 x 900 KB = 36 MB of images plus 2.1 MB of scripts. On a shared host and a busy school network, that volume explains the delay.
The teacher's hypothesis is not supported: the single query completes within the 0.3 s HTML time. Adding indexes would not fix a transfer-bound page. The team should confirm with a waterfall chart before changing anything, then optimise assets.
2. Propose and prioritise fixes, estimating which gives the largest gain.
Read the worked answer
Priority 1: compress and resize images. 900 KB average is far too large for web display; converting to modern formats and serving at display size could cut 36 MB to a few MB, the largest gain. Lazy-load images below the fold so only visible ones load first.
Priority 2: bundle and minify the 2.1 MB of scripts, remove unused libraries, and defer non-critical scripts.
Priority 3: enable caching and compression on the server so repeat visits are cheap.
Database indexing is last because it is not the bottleneck. Estimate: image work alone could take the page well under 3 s; script work removes the remaining tail.
3. At lunchtime 200 students load the page within minutes. Explain how caching changes the load on the shared host, and one risk.
Read the worked answer
With browser caching and a server or CDN cache, the first request fetches assets and later requests are served from cache, so 200 near-simultaneous loads do not each hit the shared host or database. This reduces CPU, bandwidth and query load sharply.
Risk: stale content. If a news item is updated, cached copies may persist, so students see old news. Mitigate with versioned asset filenames (cache-busting) and short cache lifetimes for the HTML, longer for static assets. The team should test that an update appears promptly after publishing.