6. Front-End and User Experience Architecture

Introduction and Context

Front-end architecture is the organisation of the client-side part of a web application: its components, pages, data flows, rendering mechanisms, interaction patterns, security controls, and delivery infrastructure. User experience (UX) architecture extends this concern beyond code. It asks how users understand, navigate, operate, and trust the application. A technically elegant interface can still fail if it is inaccessible, slow, confusing, or unreliable under real network conditions.

In a full-stack system, the front end is the boundary through which users encounter business rules and back-end services. It consumes APIs, manages local interaction state, displays asynchronous results, validates input, handles errors, and sometimes performs substantial computation in the browser. Consequently, front-end decisions affect maintainability, security, scalability, conversion, accessibility, and operational cost. The architecture must balance developer productivity with user needs and organisational constraints.

This chapter examines component-based design, routing, state management, reactive data flow, rendering strategies, micro-frontends, design systems, accessibility, internationalisation, browser security, performance, offline-first behaviour, and progressive web applications (PWAs). These topics are interdependent. For example, aggressive client-side caching may improve perceived performance but create stale-data risks; micro-frontends may support organisational autonomy but increase runtime and design-system complexity; and server rendering may improve first delivery while requiring careful handling of client hydration.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain the architectural role of components, routes, state, and reactive data flow.

2. Select suitable client-side rendering and delivery strategies for different applications.

3. Design front ends using reusable components and governed design systems.

4. Evaluate micro-frontend approaches and their organisational consequences.

5. Apply accessibility, internationalisation, security, and performance principles.

6. Design offline-capable and progressive web applications with appropriate data-consistency policies.

7. Analyse architectural trade-offs and justify decisions in professional contexts.

From Pages to Component Systems

Traditional web applications were often organised around documents or server-generated pages. Modern applications are commonly organised around components: cohesive units that combine structure, presentation, behaviour, and sometimes local state. A component may represent a button, date picker, navigation bar, product card, form section, or complete page region.

Componentisation is valuable when a component has a clear responsibility, a stable interface, and behaviour that can be tested independently. The interface of a component usually consists of inputs, outputs or events, and documented behavioural assumptions. A product-card component, for example, may receive product data and a display mode, while emitting an add-to-cart event. It should not silently modify unrelated application state or depend on a particular page layout.

A useful distinction is between presentational and container responsibilities. Presentational components concentrate on rendering and interaction. Container or feature components coordinate data retrieval, state changes, and business workflows. The distinction is not absolute, but it encourages separation of concerns. A component that fetches data, applies pricing rules, controls modal state, and renders a complex table may be difficult to reuse and test.

Component boundaries should follow change boundaries rather than visual fragments alone. Splitting every small element into a separate component can create indirection and excessive configuration. Conversely, a single large component becomes difficult to reason about. Practical design considers cohesion, reuse, testability, ownership, accessibility, and the frequency with which a unit changes.

A component tree provides the structural view of an interface. Data should generally flow in a predictable direction through this tree. Parent components provide data to children, while children communicate user actions through events or commands. This unidirectional pattern reduces hidden dependencies and makes state transitions easier to trace.

Routing as Application Structure

Routing maps a URL or navigation action to a view and its supporting data. It is not merely a visual convenience. Routes define resource identity, browser history, deep linking, access boundaries, analytics dimensions, and often the loading strategy for a feature.

A route architecture should distinguish public, authenticated, and privileged areas. It should define behaviour for unknown resources, unauthorised access, expired sessions, unsaved changes, and navigation during asynchronous operations. Route parameters identify resources, query parameters commonly represent filters or sorting, and fragments may identify a location within a page.

Nested routes can represent hierarchical domains such as `/accounts/:accountId/projects/:projectId`. However, deeply nested URLs may expose implementation details or create cumbersome navigation. Route design should express meaningful user-level resources rather than component names. Route guards can prevent access to protected views, but they are not a substitute for server-side authorisation. The server must independently enforce permissions because client code can be modified or bypassed.

Code splitting is often aligned with routes. A rarely used administrative feature need not be included in the initial download for every visitor. Lazy loading reduces initial transfer but may introduce a delay at navigation time. Appropriate prefetching, loading placeholders, and chunk-size monitoring help balance these effects.

State Management and Reactive Data Flow

State is any information whose value affects application behaviour or presentation. It is useful to classify state before choosing a management technique:

• Local UI state includes whether a menu is open, the current input value, or the selected tab.
• Feature state supports a bounded workflow, such as a checkout process.
• Shared client state is used across several distant components.
• Server state is fetched from external services and has freshness, loading, error, and cache characteristics.
• URL state includes route parameters, filters, and pagination that should be shareable and recoverable through navigation.
• Persisted state survives sessions through storage or an application database.

Many architectural problems arise when these categories are mixed. A search filter that belongs in the URL may be hidden in an in-memory store, making links impossible to share. Conversely, transient modal state does not normally belong in a global store.

Reactive programming models the application as values that change over time and as computations that respond to those changes. A view subscribes to relevant state; when state changes, the framework schedules an update. This reduces manual DOM manipulation, but it does not remove the need to understand subscriptions, cancellation, race conditions, and memory management.

A robust state transition is explicit and predictable: an event occurs, a transition applies a rule, and a new state is produced. Immutable update patterns can make change detection and debugging easier, although immutability may introduce allocation costs if used carelessly. Selectors or derived values prevent components from duplicating business calculations. Asynchronous operations should model states such as idle, loading, success, empty, and failure rather than treating loading as a temporary absence of data.

Server state requires particular care. Two users may change the same record, network requests may complete out of order, and cached information may become stale. Techniques such as request cancellation, version checks, optimistic updates with rollback, cache invalidation, and explicit refresh policies address these conditions. A global store is not automatically superior to local state; the correct choice depends on sharing, lifetime, consistency, and debugging requirements.

Choosing a Rendering Strategy

Rendering strategy determines where and when interface output is produced.

Client-side rendering (CSR) sends a relatively small document and JavaScript that constructs the interface in the browser. It can provide rich application interaction after startup, but the initial experience depends heavily on script download, parsing, and execution.

Server-side rendering (SSR) generates HTML on the server for each request or navigation. It can improve initial content visibility and support environments where search indexing or link previews matter. The browser may then hydrate the HTML by attaching interactive behaviour. Hydration requires the client and server to produce compatible output; mismatches can cause warnings, re-rendering, or subtle defects.

Static site generation (SSG) produces pages during a build process. It is effective for content that changes infrequently and can be distributed through a content delivery network. Revalidation or incremental generation can update selected pages without rebuilding the entire site.

Progressive or hybrid rendering uses different strategies for different routes or components. A public catalogue may use static generation, an account dashboard may use server rendering, and a highly interactive editor may rely mainly on client rendering. This approach recognises that one strategy rarely suits every part of a complex product.

Rendering choice should consider content freshness, interaction density, SEO requirements, infrastructure, data sensitivity, latency, caching, and team expertise. It should not be selected solely because a framework supports a particular mode.

Micro-Frontends and Organisational Boundaries

A micro-frontend architecture divides a front end into independently owned and potentially independently deployed parts. A banking application might have separate teams for accounts, payments, and support. The motivation is usually organisational: enabling teams to release features independently and align software boundaries with business capabilities.

Integration may occur at build time, through server composition, or at runtime. Runtime composition can increase autonomy but introduces concerns about duplicated dependencies, inconsistent versions, failure isolation, communication contracts, authentication, routing, observability, and performance. A micro-frontend is not simply a collection of visual widgets. It needs an ownership model, deployment policy, testing strategy, and contract for shared capabilities.

Communication should be deliberately limited. Stable events, URL changes, or well-defined APIs are generally safer than direct access to another team’s internal state. Shared design-system components can preserve visual and behavioural consistency, but shared libraries must be governed to avoid making every team dependent on simultaneous upgrades.

Micro-frontends are inappropriate when the product is small, the team is centralised, or independent deployment has little value. They can add operational complexity without solving a real organisational problem. The architectural question is not whether micro-frontends are fashionable, but whether the benefits of autonomy justify integration costs.

Design Systems and User Experience Consistency

A design system combines design principles, visual tokens, reusable components, content guidance, accessibility rules, and implementation standards. Tokens represent values such as colour, spacing, typography, elevation, and motion. Components encode recurring interaction patterns such as buttons, dialogs, tables, and form controls.

A mature design system has more than a component library. It includes contribution processes, versioning, documentation, examples, design and development collaboration, testing, and governance. It should define states such as hover, focus, disabled, loading, error, and empty. Without these states, teams often produce inconsistent and inaccessible interfaces.

Consistency should not become inflexibility. A design system needs extension mechanisms for legitimate domain requirements. Teams should be able to identify when a new component is genuinely different and when an existing component is being unnecessarily duplicated. Visual regression testing, accessibility checks, and usage analytics can support governance.

UX architecture also includes information architecture, content hierarchy, navigation, feedback, and error recovery. Users need to understand what happened, what they can do next, and whether their action succeeded. Good error messages identify the problem in understandable language and offer a recovery path; exposing an internal exception or generic status code does not.

Accessibility as an Architectural Responsibility

Accessibility is the design and implementation of products usable by people with diverse sensory, motor, cognitive, and speech abilities. It is not a final compliance task. Component APIs, keyboard behaviour, focus management, colour tokens, content structure, and testing practices all influence accessibility.

Semantic HTML should be preferred because native elements provide established keyboard and assistive-technology behaviour. Custom controls require equivalent semantics, focusability, keyboard interaction, and state communication. A modal dialog, for instance, must manage focus, identify its title, prevent confusing background interaction, and return focus appropriately when closed.

Accessibility work should consider:

• keyboard-only operation and visible focus;
• meaningful headings, labels, landmarks, and link text;
• sufficient contrast and non-colour indicators;
• text resizing and responsive layouts;
• captions, transcripts, and alternatives for media;
• announcements for dynamic content and validation errors;
• reduced-motion preferences and cognitive simplicity.

Automated tools can identify some defects but cannot determine whether a workflow is understandable or whether focus order is useful. Manual keyboard testing, screen-reader testing, user research, and review against recognised accessibility standards are complementary activities.

Internationalisation and Localisation

Internationalisation (i18n) prepares software for multiple languages and cultural conventions; localisation (l10n) adapts it to a particular locale. Architecture must avoid embedding assumptions about English text length, date formats, decimal separators, currency, names, addresses, time zones, and writing direction.

User-visible text should be externalised into translation resources, with contextual information for translators. Concatenating sentence fragments often produces grammatically incorrect translations because word order varies. Message formats should support pluralisation and gender where relevant. Layouts should tolerate expansion, truncation, and right-to-left scripts.

Dates and times require explicit treatment of time zones and locale formatting. A date-only birthday should not be converted into a timestamp that shifts across time zones. Currency calculations should use appropriate server-side rules and precision rather than relying solely on display formatting in the browser.

Internationalisation also concerns accessibility, search, content governance, and testing. Pseudo-localisation, which uses artificially expanded or altered strings, can expose layout defects before actual translations arrive.

Browser Security and Trust Boundaries

The browser is an untrusted execution environment. Front-end code, hidden fields, local storage, and client-side validation must not be treated as authoritative. Security-sensitive decisions belong on protected server boundaries.

Cross-site scripting (XSS) occurs when attacker-controlled content is interpreted as executable script. Context-aware output encoding, safe DOM APIs, sanitisation of permitted rich text, and a carefully designed Content Security Policy reduce risk. Avoiding unsafe HTML injection is preferable to attempting to clean arbitrary input after the fact.

Cross-site request forgery (CSRF) abuses a user’s authenticated browser to submit an unwanted request. Appropriate cookie attributes, anti-CSRF tokens, origin checks, and a sound authentication design help mitigate it. Cross-origin resource sharing (CORS) controls which origins browsers permit to read responses; it is not an authentication mechanism.

Sensitive tokens require careful storage decisions. Browser storage mechanisms can be exposed if malicious script executes in the page. HttpOnly, Secure, and appropriately scoped cookies can reduce some exposure, but session architecture must also address expiration, revocation, fixation, and transport security. Clickjacking protections, dependency scanning, secure headers, and third-party script governance are additional parts of the security model.

Privacy requires data minimisation, meaningful consent where required, retention controls, and transparent explanations of analytics or personalisation. A front end should not collect or transmit data merely because a library makes it easy.

Performance Budgets and Measurement

Performance is a user-experience property and an engineering constraint. A performance budget establishes limits for measures such as JavaScript transfer, image weight, number of requests, largest content rendering, interaction responsiveness, and layout stability. Budgets make performance a continuous architectural concern rather than a late optimisation exercise.

Measurement should combine laboratory testing, real-user monitoring, profiling, and business outcomes. Laboratory tools provide repeatable controlled comparisons; real-user data reveals device, network, geographic, and usage diversity. Averages can hide poor experiences, so percentile distributions are important.

Common architectural techniques include route-level code splitting, tree shaking, compression, responsive images, modern image formats where appropriate, caching, CDN delivery, resource prioritisation, virtualisation of long lists, and avoidance of unnecessary re-rendering. Third-party scripts deserve special scrutiny because they may block or delay interaction and are difficult to control.

Optimisation must preserve correctness and accessibility. Lazy-loading essential content, excessive animation, aggressive cache policies, or complex memoisation can worsen the experience. The practical objective is not the smallest possible bundle but a responsive experience within an explicitly defined budget.

Offline-First Applications and PWAs

Offline-first design assumes that connectivity is intermittent rather than guaranteed. The application must define what can be viewed, edited, queued, or synchronised without a network. A service worker can intercept requests and apply caching strategies, while local databases can hold structured application data.

Caching strategies include cache-first for stable assets, network-first for frequently changing information, stale-while-revalidate for quick display followed by background refresh, and network-only for sensitive operations. These are policies, not universal solutions. Cached authentication pages or private data require careful invalidation and access controls.

Offline mutation is more difficult than offline reading. A queued change may conflict with a server update made by another user. Possible policies include last-write-wins, version rejection, field-level merging, domain-specific conflict resolution, or user-assisted reconciliation. The correct policy depends on the business meaning of the data. Users should be told whether an action is pending, synchronised, rejected, or in conflict.

A PWA commonly combines a web application manifest, service worker, responsive interface, secure delivery, installability features, and resilient loading. Installation is not the definition of quality. A PWA must provide an understandable experience when the network is slow, unavailable, or restored after interruption. Background synchronisation and push notifications should be used sparingly, with attention to permission, battery, privacy, and user control.

An Architectural Method for Front-End Decisions

A practical decision process begins with user journeys and operational conditions rather than framework selection. Architects can proceed through the following reasoning sequence:

1. Identify user groups, critical tasks, accessibility needs, locales, devices, and network conditions.

2. Map domain capabilities, page or route boundaries, data ownership, and security trust boundaries.

3. Classify state by lifetime, ownership, sensitivity, and consistency requirement.

4. Choose rendering and caching strategies per route or feature.

5. Establish component and design-system contracts.

6. Define performance, accessibility, security, and reliability budgets.

7. Select testing methods, observability measures, and release controls.

8. Revisit decisions using evidence from real users and production behaviour.

This process prevents a common failure mode in which teams select a framework first and then force all requirements into its default architecture.

Illustrative Case Study: A Multi-Region Public Services Portal

Background

A fictional public-services organisation operates a portal through which residents apply for permits, track applications, upload documents, and receive notifications. The portal must support mobile devices, multiple languages, keyboard navigation, and periods of unreliable connectivity.

Situation and Problem

The original system is a server-rendered collection of pages with duplicated styles and inconsistent forms. Residents report that pages are slow on mobile networks, error messages are unclear, and partially completed applications are lost when connectivity fails. Different departments want to release changes independently, but a proposal to adopt many micro-frontends has raised concerns about inconsistency.

Analysis

The most important journeys are application creation, document submission, status tracking, and renewal. Application drafts are sensitive and must be protected. The public information pages change less frequently than authenticated application workflows. Accessibility and translation are legal and service requirements, not optional enhancements. Independent deployment is useful for departmental content, but a fully distributed runtime architecture would create unnecessary complexity for the shared application shell.

Approach and Solution

The organisation establishes a design system containing accessible form controls, error summaries, upload states, progress indicators, and notification patterns. A central shell owns authentication, routing, locale selection, navigation, telemetry controls, and global error handling. Departmental features are modular and independently owned, but they use governed interfaces and shared design tokens rather than unrestricted runtime composition.

Public guidance pages use static generation and CDN delivery. Authenticated application pages use server rendering for initial delivery followed by client interaction. Draft data is stored locally in an encrypted or appropriately protected browser data store where feasible, with clear indicators showing whether the latest changes are synchronised. The server remains authoritative, uses version identifiers, and reports conflicts for user resolution.

The application models each form field with labels, descriptions, validation messages, and server-error states. Keyboard and screen-reader testing is included in release criteria. Translation resources support pluralisation and right-to-left layout testing. Route-level code splitting limits the initial JavaScript payload, while performance budgets are monitored in continuous integration and real-user monitoring.

Outcome

The resulting architecture improves consistency without requiring every department to release through one large codebase. Users can recover drafts after temporary network loss, understand synchronisation status, and navigate the service with assistive technologies. The organisation retains a clear path for independent feature ownership while avoiding uncontrolled micro-frontend proliferation.

Learning Points

The case illustrates that architecture should begin with service journeys and constraints. Offline behaviour requires explicit business rules, not merely a service worker. Accessibility and localisation belong in component and data contracts. Finally, organisational autonomy can often be achieved through modular ownership and disciplined interfaces without distributing every part of the front end at runtime.

Challenges, Risks, and Professional Judgement

Front-end architectures fail when abstraction is applied without evidence. Excessive global state creates hidden coupling; excessive componentisation slows development; and premature micro-frontends multiply deployment and testing problems. Hydration defects can be difficult to diagnose, while caching can display information that users reasonably assume is current.

Common mistakes include treating client validation as security, storing sensitive information casually in browser storage, ignoring keyboard focus after navigation, using colour as the only error signal, concatenating translated strings, measuring only desktop performance, and implementing offline writes without conflict policy. Another frequent mistake is defining performance targets without assigning ownership or integrating measurement into delivery pipelines.

Professional judgement requires explicit trade-offs. A highly interactive internal tool may reasonably prioritise CSR and rapid feature delivery, while a public information service may prioritise static delivery, accessibility, and search visibility. The best architecture is contextual, observable, and capable of evolving.

Governance, Ethics, and Emerging Directions

Front-end governance includes accessibility conformance, privacy management, dependency licensing, secure development, content approval, design-system stewardship, and retention of audit evidence where required. Automated decision interfaces require special care: users should be able to understand consequential outcomes, correct inaccurate data, and obtain human assistance where appropriate.

Emerging practice is moving toward more selective hydration, server components, streaming interfaces, edge rendering, shared component standards, and browser capabilities that support richer offline applications. AI-assisted development can generate interface code, tests, and translations, but generated output requires review for security, accessibility, licensing, factual accuracy, and unintended data disclosure. AI should support engineering judgement rather than replace product research or accountability.

Best Practices

• Design components around clear responsibilities and documented contracts.
• Keep authoritative security and business rules on the server.
• Classify state before selecting a state-management tool.
• Choose rendering strategy per user journey and content requirement.
• Treat accessibility, localisation, security, and performance as architectural requirements.
• Use design-system governance to maintain consistency without blocking valid variation.
• Define cache freshness, offline mutation, and conflict policies explicitly.
• Align micro-frontends with genuine ownership and deployment needs.
• Measure real-user outcomes and enforce performance budgets continuously.
• Test failure, slow-network, keyboard, assistive-technology, and locale scenarios.

Chapter Summary

Front-end and UX architecture connects component structure with the conditions under which people use software. Components should have cohesive responsibilities and predictable data contracts; routing should express resources, access boundaries, and loading strategies; and state should be classified according to ownership, lifetime, and consistency. Reactive data flow supports responsive interfaces when transitions, asynchronous operations, and errors are explicit.

CSR, SSR, SSG, and hybrid rendering offer different trade-offs in delivery, interactivity, caching, and infrastructure. Micro-frontends can support organisational autonomy but introduce integration and governance costs. Design systems provide reusable visual and behavioural standards, while accessibility and internationalisation must be built into component and content architecture. Browser security requires respect for trust boundaries, and performance requires measurable budgets. Offline-first applications and PWAs extend resilience but demand deliberate caching, synchronisation, and conflict policies. Effective decisions begin with user journeys and evidence rather than technology fashion.

Key Terms

Component: A cohesive, reusable interface unit with defined inputs, outputs, and behaviour.

Routing: The mapping of URLs or navigation actions to application views and data.

Reactive data flow: A model in which views respond to changes in observable application state.

Local state: Short-lived state owned by a component or small feature.

Server state: Data obtained from an external service and subject to freshness and consistency concerns.

Hydration: The process of attaching client-side behaviour to server-rendered HTML.

Server-side rendering: Generating interface HTML on a server for delivery to a client.

Static site generation: Producing pages during a build process rather than per request.

Micro-frontend: An independently owned or deployed portion of a larger front-end application.

Design system: Governed guidance, tokens, components, and practices for consistent product experiences.

Accessibility: The design of technology so that people with diverse abilities can use it effectively.

Internationalisation: Preparing software to support multiple languages and cultural conventions.

Cross-site scripting: Injection of content that is interpreted as executable script in a user’s browser.

Content Security Policy: A browser security policy restricting permitted sources and behaviours.

Performance budget: A defined limit on resource or user-experience performance measures.

Service worker: A browser-managed script capable of intercepting requests and supporting resilient web behaviour.

Offline-first: Designing an application to remain useful when network connectivity is limited or absent.

Progressive web application: A web application combining web delivery with capabilities such as installability and offline resilience.

Optimistic update: Updating the interface before server confirmation, with a plan for rollback or correction.

Design token: A named, reusable value for a design property such as colour, spacing, or typography.

Review Questions

Short Answer Questions

1. What distinguishes local UI state from server state?

2. Why is client-side route protection insufficient for security?

3. Define hydration in the context of web rendering.

4. What is the purpose of a performance budget?

5. Why must offline applications define conflict-resolution policies?

Long Answer Questions

1. Explain how component boundaries, unidirectional data flow, and state classification contribute to maintainable front-end architecture.

2. Compare CSR, SSR, SSG, and hybrid rendering, including the circumstances in which each is appropriate.

3. Discuss the organisational and technical trade-offs involved in adopting micro-frontends.

4. Explain how accessibility and internationalisation influence design-system and component architecture.

5. Describe a complete architecture for an offline-capable PWA, including caching, synchronisation, security, and testing.

Analytical / Application Questions

1. A retail application has a public catalogue, an authenticated order workspace, and a real-time inventory dashboard. Recommend rendering, routing, and state strategies for each area and justify the differences.

2. A team proposes storing authentication tokens and draft medical records in browser storage to support offline use. Analyse the security, privacy, and reliability risks and propose a safer design.

3. An organisation wants ten independently deployed micro-frontends but currently has one small development team and inconsistent UI patterns. Evaluate whether the proposal is justified and recommend an alternative architecture if necessary.

22. Multiple Choice Questions with Answers

Question 1

A team is deciding where to store a shareable product filter that must survive navigation and be copied as a link. Which state location is most appropriate?

A. A component-local variable

B. The URL query parameters

C. A temporary modal state

D. A server-side session only

Correct Answer: B. The URL query parameters

Question 2

Which statement best explains why client-side route guards cannot replace server-side authorisation?

A. Client-side guards make pages load more slowly

B. Users can bypass or modify client-side code

C. Route guards work only with static sites

D. Servers cannot inspect user identity

Correct Answer: B. Users can bypass or modify client-side code

Question 3

An application generates HTML on the server and then attaches browser-side interaction to that HTML. What process is being used?

A. Tree shaking

B. Hydration

C. Virtualisation

D. Pseudo-localisation

Correct Answer: B. Hydration

Question 4

Which situation most strongly justifies a micro-frontend architecture?

A. A small team building a simple website

B. A single form with no independent release needs

C. Several domain teams require autonomous ownership and deployment

D. A page needs a smaller image file

Correct Answer: C. Several domain teams require autonomous ownership and deployment

Question 5

Which practice most directly reduces the risk of cross-site scripting?

A. Treating hidden form fields as trusted

B. Using unsafe HTML injection for all content

C. Applying context-aware output encoding and safe DOM APIs

D. Disabling server-side validation

Correct Answer: C. Applying context-aware output encoding and safe DOM APIs

Question 6

A mobile application must display cached catalogue data immediately and refresh it in the background when connectivity exists. Which caching strategy best matches this requirement?

A. Stale-while-revalidate

B. Network-only

C. No-store for every request

D. Last-write-wins conflict resolution

Correct Answer: A. Stale-while-revalidate

Question 7

Why is concatenating translated sentence fragments generally poor internationalisation practice?

A. It prevents JavaScript from executing

B. Word order and grammatical rules vary across languages

C. It always increases image size

D. It disables browser caching

Correct Answer: B. Word order and grammatical rules vary across languages

Question 8

Which statement about performance budgets is most accurate?

A. They are limits defined only after production failure

B. They replace the need for accessibility testing

C. They establish measurable constraints that can be monitored throughout delivery

D. They require every route to use identical rendering

Correct Answer: C. They establish measurable constraints that can be monitored throughout delivery

Question 9

An offline form update conflicts with a newer server update made by another user. What architectural requirement is most important?

A. A policy for detecting and resolving conflicts

B. A larger colour palette

C. A client-only authorisation check

D. Removal of all local state

Correct Answer: A. A policy for detecting and resolving conflicts

Question 10

Which design-system practice best supports both consistency and accessibility?

A. Documenting only the default visual state

B. Providing governed components with focus, error, loading, and disabled states

C. Allowing every team to redefine keyboard behaviour

D. Avoiding semantic HTML in reusable components

Correct Answer: B. Providing governed components with focus, error, loading, and disabled states