Skip to main content

​
Perceived Performance

Perceived performance and technical performance are two different things. Technical performance is how fast the site is, as measured by tools like Lighthouse, WebPageTest, or Chrome DevTools. Perceived Performance is how fast the site feels to the user. It’s possible to have a site that is technically fast, but feels slow to the user, and vice versa. Perceived performance can have a greater effect on the user’s willingness to stay on the site than technical performance. Perceived performance is tipically measured as the time it takes for the content to be usable, this may occur before assets have finished rendering (images, fonts, JavaScript). It is important the both technical and perceived performance are optimized. Perceived performance can be improved by
  • Using system fonts
  • If web fonts are used, initial render ought to use system fonts and switch to the web font once it completes loading (FOUT). In recent browsers this can be achieved in CSS using font-display: swap.
  • As assets load, images, advertisements, video and other embeds, they can cause text content to jump around on the page. Avoid this by using CSS and/or width and height attributes to allow space for this content to fill.
  • Lazy load images

​
Eliminate Unnecessary Downloads

Render blocking downloads will have the largest effect on the perceived performance of a web page. Having some blocking requests is unavoidable but they should be kept to a minimum. Google’s Lighthouse documentation identifies render blocking resources. Assets used together should be combined into as few downloads as possible. Each file added to a web page introduces additional overhead - even on HTTP/2.

​
Progressive Enhancement

Progressive enhancement emphasizes core webpage content first. This strategy then progressively adds more nuanced and technically rigorous layers of presentation and features on top of the content as the end-user’s browser/internet connection allow. The order of displaying content: First content (HTML), then presentation (CSS) and after that client-side scripting (Chocolatey Layers of Progressive Enhancement). The basic render should include content for the lowest end browsers and allow for JavaScript to fail. Additional content (carousel frames, items behind accordions, etc) can be loaded and rendered via JavaScript.

​
Accessibility

We aim to meet the WCAG accessibility guidelines at level AA. The most important topics for accessibility are:
  • Semantic, error free HTML5
  • All essential functionality can be executed by keyboard only
  • All content is available for all users
  • A logical order of content in a web page, tell a story with your HTML
  • Dynamic changes on a web page are announced
  • Good colour contrast between text and background
  • Colour alone isn’t used to convey meaning (for example with error messages)
  • Animation is stoppable by the user
  • In the Markup Style Guide and the WordPress Accessibility Handbook you’ll find information on how to apply this in your work.