IT:AD:Non-Functional Requirements:UX:Web

• [NFR::SHOULD:Accessibility] To help low visibility users navigate pages quicker, use the role= tag on sections within visible Views.

  • Rational: Marking page sections with location roles are important to low-vision users, so that low-vision reader users can use a single key to skip the chaff, and jump to a section of interest (eg: “skip to navigation”, “skip to search”, *“skip to main content”, etc). Screen reader can use a single key to jump to each of these sections and know what the section's function is.

  • • location roles:
      • role=“banner” : for the header
      • role=“navigation”: for the site navigation area (within the banner/header)
      • role=“search”: for the site search
      • role=“document” : for the page's main purpose
      • role=“main” : for the main part of the “document”
      • role=“complementary” : for the aside/sidebar
      • role=“contentinfo” : for the footer
      • role=“presentation” : for stuff that is used only for presentation, and has no semantic meaning.
• [NFR:8sqzv:SHOULD:Accessibility] Use HTML5 tags (header, footer, aside) to define the role of sections, so that low-visibility Readers can navigate to/skip them.

  • Rational: Marking page sections with information as to what they are for is important to low-vision users, so that low-vision reader users can use a single key to skip the chaff, and jump to a section of interest (eg: “skip to navigation”, “skip to search”, *“skip to main content”, etc). Screen readers can use a single key to jump to each of these sections and know what the section's function is.

  • Note that not all browsers can read these tags, so the current recommendation is to double up (eg: marking footer with role="contentinfo").

• [NFR:8okym:SHOULD] Optimise the landing page¹⁾.

• [NFR::MUST:Responsivity] Follow the optimisation guidelines defined by the Yahoo Web Performance Best Practices and Rules²⁾.
  * [NFR:8r38h:SHOULD:Responsivity] Minimize the number of HTTP Requests required to render the page³⁾.

  • Rational: Responsiveness. Every request, whether it be for the page, images on the page, css, or javascript, sends headers (including cookies), and processes cookies. In addition, depending on the server only a small number of connections can be done at the same time (eg: 4), causing staggering of requests, therefore slow rendering. The less number of requests, the better.

  • Combine files: Combine JScript. Combine CSS. Use CSS Sprites.

• [NFR:8r38i:SHOULD:Responsivity] Use a Content Delivery Network (CDN) to deliver common libraries and css files⁴⁾.

  • Rational: Performance. Browsers cache content via url, not filename. This means that if they have visited beforehand another site that has used the same CDN hosted resource (eg: JQuery-latest), the files are already available in their cache, decreasing bandwidth consumed, as well as decreasing response time.

• [NFR:8r38j:MUST:Responsivity] Avoid empty src or href attributes.⁵⁾

  • Rational: Responsiveness

• NFR:8r38k
• [NFR:8r38l:SHOULD:Responsivity] Add an Expires or Cache-Control Header⁶⁾

  • Rational: Performance

  • For static content, set to 6 months in future, and add a Version No to the filename…

  • For dynamic content, use Cache-Control

• [NFR:8r38m:SHOULD:Responsivity] Gzip Components⁷⁾

  • Rational: Responsiveness

  • GZip is supported by 90% of current browsers, reduces payload by 70%.

• [NFR:8r38n:MUST:Responsivity] Include external CSS StyleSheets at the top of pages.⁸⁾

  • Rational: Responsiveness

  • This allows progressive rendering, rather than a blank page while waiting, then an initial rendering, then a subsequent repositioning when the css finally comes in.

    .

• [NFR:8r38o:MUST:Responsivity] Include external javascript scripts at the bottom of pages.⁹⁾

  • Rational: Responsiveness. Scripts block parallel loading - even across domains - so no images, or anything can come in till finished.

• [NFR:8r38p:MUST:Responsivity] Avoid CSS Expressions¹⁰⁾

  • Rational: Deprecated in IE8. Was too CPU Intensive.

• [NFR:8r38q:SHOULD:Responsivity] Make JavaScript and CSS External¹¹⁾

  • Responsiveness. Externalized as files (rather than Inline) means they can be cached by the browser.

  • External code files are easier to debug (current Browser developer tools cannot breakpoint inline code).

• [NFR:8r38r:MUST:Responsivity] Reduce DNS Lookups¹²⁾
  • Cache is cleared at most every hour. When cleared, the browser has to re-look up the IP. Between 2 (due to externalized static resources) but not more than 4…
• [NFR:8r38s:MUST:Responsivity] Minify JavaScript and CSS¹³⁾
• [NFR:8r38t:SHOULD:Responsivity] Put a trailing slash on urls!¹⁴⁾

  • Rational: Avoid Redirects improves performance

    * [NFR:8r38u:SHOULD:Responsivity] Remove Duplicate Scripts¹⁵⁾

  • Obvious…but it happens in 20% of sites.

• [NFR:8r38v:SHOULD:Responsivity] Configure ETags¹⁶⁾

  • Configure them for webfarms

• [NFR:8r38w:SHOULD:Responsivity] Make AJAX Cacheable¹⁷⁾
• [NFR:8r38x:SHOULD:Responsivity] Flush the Buffer Early

  • Right after Head, so that it can go get css, etc. while waiting for server to build rest of page.

• [NFR:8r38y:SHOULD:Responsivity] Use GET for AJAX Requests¹⁸⁾

  • Rational: Responsivity. POST is a two step process.

• [NFR:8r38z:SHOULD:Responsivity] Post Load Components

  • Load non-visible images later (see YUI Image Loader, and YUI Get utitity)

• [NFR:8r394:SHOULD:Responsivity] Post-Load Components

  • For future pages…

• [NFR:8r395:SHOULD:Responsivity,Performance] Reduce the Number of DOM Elements¹⁹⁾
  • Obvious…CPU hit
• [NFR:8r396:SHOULD:Responsivity] No 404s²⁰⁾
• [NFR:8r397:SHOULD:Responsivity] Reduce Cookie Size²¹⁾

  • Rational:Responsivity. They are sent out with every request (images, css, etc.). That means more bandwidth, and time to process.

• [NFR:8r398:SHOULD:Responsivity] Use Cookie-Free Domains for Components²²⁾
  • A solution to the last issue…
• [NFR:8r399:SHOULD:Responsivity] Avoid Filters²³⁾
• [NFR:8r39a:SHOULD:Responsivity] Do Not Scale Images in HTML²⁴⁾

  • Rational:large images scaled to fit in small screens means that large images were sent anyway.

• [NFR:8r39b:SHOULD:Responsivity] Make favicon.ico Small and Cacheable²⁵⁾

  • Rational:Can cause 404's, will send cookies, is downloaded first…

• [NFR:8r39c:SHOULD:Responsivity,Mobility] Make things small (less than 25K):

  • Rational:iPhone won't cache things larger than 25K. Which means that the same image, css, script file will be re-retrieved on the next page view.

* [NFR:8syrs:SHOULD] When releasing an ASP.NET front-end on IIS: turn off debug="true" in web.config.

• • Increased memory footprint and unoptimized code are only two of the problems you'll see if the debug flag is set to true.
  • For more information:
    • ScottGu blogged about why.
    • Read through the ASP.NET Performance Coding Architecture Guides. Great book and also free.

• [NFR:8syrr:SHOULD] When developing an ASP.NET front-end on IIS, prefer the use of small message objects.

  • • Every object larger than 85k goes into the (Large Object Heap) LOH.
    • The problem with the LOH is that the .NET Framework has a hard time to Garbage Collect LOH objects frequently enough in certain web scenarios, e.g. if you allocate a large object for every incoming HTTP request.
    • See here

• [NFR:8syqh:SHOULD] If developing an PHP front-end on IIS, use FastCGI and not CGI.
  • • The IIS team is committed to make PHP run well on Windows.
    • Providing a first class FastCGI implementation was the first step which made this a reality.
    • The Web Platform Installer makes installing PHP on IIS a one-click experience (find everything else on Everything else on http://php.iis.net)
• [NFR:8syqh:SHOULD] If developing an PHP front-end on IIS, enable Wincache.
  • • If you run PHP without an output cache you will quickly run into performance problems.
    • Wincache is an Open Source output cache for PHP developed by the IIS team.
    • The simplest way to install it: Web Platform Installer
• [NFR:8syr5:SHOULD] PHP: Consider setting FastCGI MaxInstances to 0
  • • FastCGI spawns multiple PHP processes for each web application.
    • If you are in a hosted environment this might soon become an issue.
    • Here is a great blog post on how MaxInstances can mitigate this problem.

• [NFR:8syr4:SHOULD] Avoid embedding validation logic in the UI directly.
  • <div nav>
• (UP)

• Consider using Attributes on the ViewModels – better yet the Views themselves, but with a system to automatically port the Attributes to ViewModels used to represent them. Render the Attributes as JSON. Render the JSON to the Client, which uses client side code to convert the JSON into clientside code appropriate to the rendering technology chosen.

  • Consider a format able to describe Required, ConditionalOn, PreValidateReplacemnts, Range, Format, ValidateOnEvent, Selector.</WRAP>

  ### Responsiveness ###

  • [NFR:8ohyc:SHOULD] Landing pages should be kept small (see: [NFR:8ohsd]).

    • Rational: pages that are too slow to load wipe out whole continents of users ²⁶⁾

  • [NFR:8ohsd:SHOULD] Continuing [NFR:8ohyc], Home page loads should be less than 14K (TODO: recheck that limit).

    • Rational:Mobile usage is surpassing traditional desktops. Internally, this is not yet the case, but will be so during the lifetime of most apps starting from this point forward. Due to the characteristics of chunked cell phone communication, a page load is much more responsive if it all fits within a single chunk.

  • [NFR:8okzr:SHOULD] Optimise landing pages for mobiles.

    • See: http://blogs.keynote.com/the_watch/2014/06/faster-mobile-web-pages-part1.html

  ## Resources ##

  • http://developer.yahoo.com/yslow/