The Annual-Day Gallery That Takes 41 Seconds
Green Valley School uploads its annual-day pages to the school web space. The gallery page is at http://www.greenvalley.edu/annualday/gallery.html and the photographs and the school crest are kept in http://www.greenvalley.edu/assets/img/. The page contains and the crest does not appear; the browser's broken-image icon is shown instead. The crest is a 200×200 two-colour circular emblem that must sit on a dark blue banner. The gallery holds 12 photographs, each 4000×3000 pixels and about 4 MB, displayed at 400×300. On the school's 10 Mbps line the page took 41 seconds to display. The enquiry form posts prospective students' names, phone numbers and marks to a PHP script using method='get'; a parent complained that her daughter's marks were visible in the browser history.
1. Diagnose why the crest does not appear, give the corrected src value, and choose the best image format for the crest as against the photographs.
Read the worked answer
src='images/crest.png' is a relative URL, resolved against the folder of the page that contains it. The page lives in /annualday/, so the browser requests /annualday/images/crest.png. The files are actually in /assets/img/, the request returns 404, and the browser draws its broken-image icon.
Correct forms:
../assets/img/crest.png- go up one level from/annualday/, then down intoassets/img/./assets/img/crest.png- root-relative, resolved from the domain root.http://www.greenvalley.edu/assets/img/crest.png- absolute (works but hard-codes the domain, breaking if the site moves).
Format for the crest: PNG (GIF also works). The crest is flat, two-colour line art that must sit on a banner: PNG stores it losslessly and supports an alpha channel, so the circular outline stays crisp and the dark blue banner shows through the transparent corners. JPEG is built for continuous-tone photographs; on two-colour artwork it produces ringing and block artefacts along the edges, and it has no transparency, so the crest would appear inside an opaque white square on the banner.
Format for the 12 photographs: JPEG, at reduced pixel dimensions and moderate quality. Photographs have smooth tonal gradation where JPEG's lossy compression is least visible and where its small file size matters most - the opposite of the crest's case.
2. Use the figures given to show that the 41 seconds is a payload problem, not a coding problem, and propose concrete changes that would bring the page under about 5 seconds on the same line.
Read the worked answer
Payload: 12 × 4 MB = 48 MB = 48 × 8 = 384 Mbit. At 10 Mbps the theoretical minimum is 384 / 10 = 38.4 s. The measured 41 s corresponds to about 9.4 Mbps, i.e. roughly 94% of line rate. The line is already running near capacity, so no amount of HTML tidying, CSS minification or server tweaking will help - the number of bits must fall.
Budget for 5 s: 5 s × 10 Mbps = 50 Mbit ≈ 6.25 MB total, about 0.5 MB per photograph. Each image is 48 times wider and 10 times taller than its display size of 400 × 300, so 95% of the pixels are downloaded and then thrown away by the browser.
Actions, in order of effect:
- Resize each photograph to 400 × 300 (or 800 × 600 for retina screens) before uploading. This is not 'losing quality' - the extra pixels are never displayed.
- Re-encode as JPEG at quality ≈ 80, giving roughly 30–50 KB per image, about 0.5 MB for the whole gallery: under a second at line rate plus latency.
- Use thumbnails that link to the full-size image, so the 4 MB originals are downloaded only if a visitor clicks one.
- Add
loading='lazy'so off-screen photographs are fetched only when scrolled into view.
The same principle applies to the crest: a 200 × 200 PNG is a few kilobytes, whereas a JPEG of the same emblem would be both larger and uglier.
3. Explain precisely what was wrong with method='get' for the enquiry form, what changes with POST, and whether POST alone is sufficient.
Read the worked answer
With method='get', the browser appends every control to the URL as a query string, e.g.
enquiry.php?name=Anita&phone=98300xxxxx&marks=87
That URL is then stored in the browser history, shown in the address bar, saved if the parent bookmarks the page, written into the web server's access log and into any proxy or analytics log, and visible to anyone glancing at the screen. That is exactly how the parent saw her daughter's marks. GET also has practical length limits and is semantically meant for safe, repeatable retrieval - submitting personal data is neither.
With method='post', the field values travel in the request body, not the URL, so they do not appear in the address bar, history, bookmarks or standard access logs, and there is no practical size limit.
POST alone is not sufficient. The body is still transmitted in clear text over HTTP, so anyone on the path (school Wi-Fi, ISP) can read it. The form action must be https://, the server must redirect HTTP to HTTPS, the marks should not be echoed back into a URL or a hidden field, and only a session reference should persist. POST removes the shoulder-surfing and history leak; TLS protects the transit. Both are needed for personal data of this kind.