Community resourceWorksheet
OCR H446 1.3.4 Client-side and server-side processing
Part 6 of 8 · H446 1.3.4 · Web technologies
Deciding whether work happens in the browser or on the service's own infrastructure is the reasoning H446 1.3.4 rewards, and the language a task is written in is not the answer to it. This worksheet classifies tasks by data location, trust, responsiveness and shared state, then applies the split to a service running on weak devices over an unreliable connection.
Students will:
- classify tasks by where they run and say why that location is required
- explain why a check made in the browser cannot be trusted on its own
- identify the points where data crosses between browser and server
- recommend a processing split for a service limited by device power and connection quality
Inside: 5 explanation cells, 1 multiple-choice question, 2 fill-in-the-blanks cells and 2 written answers. 27 marks, about 40 to 50 minutes.
Series: H446 1.3.4 · Web technologies, part 6 of 8.
Shared by Coding PathwayVerified teacher
- 10 cells
- About 45 minutes
- CC BY-SA 4.0
- Shared 31 Aug 2026
- Updated 3 Sept 2026
Preview
The whole resource, exactly as a class sees it. Answers and marking are held back.
Client-side and server-side processing
Client-side processing runs on the user's device, commonly in the browser. Server-side processing runs on infrastructure controlled by the service. Classify the task, location, responsibility and data need, not only the language name.
One journey, two locations
HTML loading, CSS application and immediate browser interaction are client-side examples in OCR's model. A server can enforce authoritative business rules and query protected shared data. Both sides may validate: the client improves responsiveness; the server must not trust a client-controlled check.
Worked service: equipment booking
The browser shows the form, applies styles and immediately warns when an end time is earlier than a start time. It then submits the requested slot. The server checks the rule again, verifies identity, queries the shared booking database and accepts or rejects the request.
The first check reduces avoidable requests and provides quick feedback. The repeated server check is still needed because browser code and submitted data can be changed.
Which task most clearly belongs on the server side for a shared booking service?
- AApply the page's CSS colours
- BQuery the protected central database for current availability
- CDisplay a character counter while the user types
- DExpand a menu immediately after a click
- client
- server
- validate
- trust
For a library reservation, classify and justify: render HTML; apply CSS; update an on-page character count; check the member's borrowing limit; query whether the copy is available; return a confirmation page. State where data crosses between sides.
Treat confirmation generation as server-side when it depends on authoritative results; the browser renders the returned page.
Students type their answer here.
Apply the model independently
The remaining tasks change the context or reduce the support. Complete them without copying the worked model, then check that each explanation connects a mechanism to its consequence.
A field survey app serves old low-power tablets over an unreliable connection but stores sensitive shared records centrally. Compare moving more processing to the client with keeping more on the server. Recommend a split for form feedback, calculations that use only current input, identity/permission checks and database updates.
Use responsiveness, connection/traffic, client capability, central updates and protected data. Qualify every benefit.
Students type their answer here.
Review your understanding
Before submitting, check that you can explain the main distinction in your own words, apply it in an unfamiliar context and justify each consequence rather than only naming a feature.