Making Sense of Google's Web Fundamentals, Part 1

Google is leading the charge to improve websites. With documentation provided by Web Fundamentals, the company lays out a wealth of info for creating top-notch experiences online.

However, combing through the verbose material in Web Fundamentals can seem overwhelming. For this reason, I created a summary ("cheat sheet") below.

Homepage: FIRE, RAIL, OH MY!

The homepage is probably the most overwhelming part. Skip this page for now and go straight to "App Shell Model" under "Architectural Patterns".

App Shell Model

An "App Shell" is the core HTML structure of your site. It may include elements like header, footer, navigation, as well as provide the core layout. Key takeaways:

• It's usually static and acts as a placeholder for dynamic content
• It is only useful if your site uses Javascript for most of its rendering
• It should be cached on the client by using Service Workers (more on this later)
• If you are creating a Single Page Application (SPA) using a popular framework like React or Angular, your shell is typically a "template" powered by client-side routing

Designing Great User Experiences

This section is more geared towards UX and design professionals. Developers should browse this section to get a better feel for your team's high-level goals. However, let's move on to the juicier technical stuff...

Accessibility

Developers often consider accessibility an afterthought. Unfortunately, this can lead to a lot of rework later on. Below are some of Google's takeaways for developing with accessibility in mind.

Focus

• Tab order determines the order in which HTML elements receive focus when pressing the tab key.
• Some elements are focusable naturally.
• By default, the order of elements on the page (DOM order) defines the tab order, even if the visual order is different (via CSS).
• Focus can seem to disappear with offscreen elements. When shifting elements offscreen, make sure to set display:none or visibility:hidden.
• Use tab index to override the default tabbing order of an element. Use with caution because it makes code harder to maintain
• To make items not focusable (i.e., certain hyperlinks), use tabindex="-1". This is safe to use at will.
• For input groups and select lists, use javascript and tabindex to handle custom keyboard functionality.

Semantics Built-in

• Always consider what type of HTML element to render for screen readers and other assistive technologies. For instance, don't use a div element for a button that is meant to be clicked.
• For labels associated with inputs, always include the for attribute, assigned to the name/id of the input field.
• For images, always include a descriptive alt attribute
• Use headings (h1-h6) responsibly to ensure the proper parent-child relationships for assistive technologies.
• Always include an href attribute for anchor tags assigned with a real URL. If the element is meant to be clickable, but does not relate to page navigation, consider a styled button element instead.
• Avoid anchor tags styled as buttons (if not used for navigation). Instead, just use the button tag.
• Always consider HTML5 semantic tags over plain div tags. These are header,footer,nav,article,section,main,aside
• For input groups and select lists, use javascript and tabindex to handle custom keyboard functionality.
• Avoid " keyboard traps" for elements (except those found in modal dialogs)

Semantics and ARIA

• Aria attributes allow for overriding an element's semantics for assistive technologies and should be used in cases where natural HTML isn't sufficient.
• The most-used attributes are aria-label, aria-labelledby, aria-owns, aria-describedby, and aria-hidden.

Accessible Styles

• For focused elements, use the default browser styling (glowing outline), or provide a custom alternative, such as background color. Providing a strong visual indicator that an element received focus is essential.
• Good responsive design also helps accessibility
• Color contrast is important for visually impaired users. Check your contrast ratios on this site.
• Avoid conveying meaning with color only.

Accessibility Reviews

• Finally, no matter how good your HTML is, accessibility reviews are a must to catch everything.

Animations

Animations can improve the user experience if applied correctly. Here are some of Google's best practices for animations:

• Use CSS for simple animations, and use javascript for better control. For web animations, consider using a 3rd party library like "anime.js." Someday the Web Animations API will be fully supported.
• Experiment with easing to determine your desired animation effects. "ease-out" is usually a good choice.
• For SPA's, consider animations when transitioning between pages.
• For modal dialogs, provide a nice transition when toggling to visible. For example, fade in a gray backdrop. Also, consider using a pre-built modal component.
• Avoid animations on expensive properties, such as box-shadow or width, that require browser repaints. Properties that perform reasonably well are transform and opacity.
• Use the will-change attribute as a hint to browsers to pre-optimize the animation.

Responsive Web Design

The percentage of users accessing the web on mobile is high. In addition, new devices with different dimensions emerge frequently. Your website should be able to render well on all web-enabled devices.

• Always use this meta tag to scale your site properly to the viewport:
  

      
        <meta name="viewport" content="width=device-width,initial-scale=1">
      
      

• Most of your box elements will be fluid. Avoid sizing box elements or images with a fixed width or height. (This concept is elaborated more in a later section )
• Avoid absolute positioning that can force elements out of smaller viewports. If using absolute positioning, place the elements relative to a fluid parent.
• Media Queries
  • Media queries help with changing layout when fluid sizing alone isn't sufficient.
  • Base your media query breakpoints on viewport width
  • Within your media query breakpoints, make sure to size box elements with relative units (usually percentages)
  • Design by starting with the smallest breakpoint and work up (aka "mobile first design")
  • Use Chrome Dev Tools, especially with Device Mode, to test breakpoints and general responsiveness
• Images
  • If fluid images aren't sufficient, and you need to provide different images based on different sizes or resolutions, you can use srcset or the picture tag
  • Vector images (svg for the web) scale better than raster. SVG is especially good for custom icons
  • Prefer svg-based icons over font-based
  • Research and choose the best file format for your images (svg vs jpg vs png). As a rule of thumb:
    • .jpg for photographs
    • .svg for logos and line art
    • .png (over .gif) for other images
  • Optimize images by using a post-processing tool, such as imagemin for webpack
  • Sprites are still a good solution if you need to display many small images
  • Lazy load images as they become visible on the screen (using javascript)
  • Use images sparingly, and prefer CSS for simple visuals like gradients, box shadows, and rounded corners

Add to Home Screen

Users can run a web app in full screen mode by adding it to the home screen. This is especially beneficial for mobile users. For Android users, home screen installations create a WebAPK

• To enable, you must provide a Web App Manifest and serve the site over HTTPS.
• To provide the best home screen experience, consider providing icon assets and colors that are optimized for devices using Android, IOS and Windows Mobile. (Using tools like Favicon Generator are a good starting point for icons.)

Device APIs (HTML5)

Geolocation

• Provides the most accurate solution for obtaining a user's location on the web
• Avoid prompting for location on page load. Instead consider a solution where the user "opts in", such as a button click.
• Handle any errors in code, such as ones generated when the user refuses to share her location. Any call to get location should provide both success and error callbacks.
• In the event of errors, consider providing a fallback solution. Fallback solutions, such as IPStack are usually IP-based and less accurate.
• Always detect if the current browser has geolocation capabilities:
  

        
        if (navigator.geolocation) {
          console.log('Geolocation is supported!') } else {
          console.log('Geolocation is not supported for this Browser/OS.')
        }
        
      

• If needed, use watchPosition() to monitor the user's location real time. Be aware that watchPosition() is resource intensive. Make sure to clean up afterwards using clearWatch().
• For a faster, but less accurate, response, use the maximumAge property.
• Set a timeout when requesting location, to avoid making the user wait indefinitely.
• Use Chrome Dev Tools to emulate geolocation.

Full Screen API

This API still has spotty browser support, so I'm skipping it for now.

Click to Call

This is fairly simple to achieve by providing a "tel:" hyperlink:

  <a href="tel:+1-303-499-7111">+1 (303) 499-7111</a>

Search Optimization (SEO)

• Serving your site through the same URLs for both mobile and desktop, and using Responsive Design, is recommended by Google over separate mobile sites or dynamic server-side solutions.
• However, if serving separate URLs for desktop and mobile, use link[rel=canonical] and link[rel=alternate]
• Or, if serving different HTML server side, use the Vary: User-Agent response header to avoid penalization by Google.
• Crawling versus indexing:
  • Crawling happens when the search engine analyzes page content.
  • Indexing is when the search engine stores page URLs for serving later in search results.
• Even if a page cannot be crawled, it can show up in search results, as in the case of a 3rd-party site linking to that page.
• If you need greater control over crawling behavior, use a robots.txt file. Use Google Webmaster Tools to test your robots.txt.
• To truly hide pages from search results, make sure NOT to exclude them from crawling and use the noindex meta tag. (Search engines need to read the noindex meta tag to omit the page from search results.)
• To remove a deleted page from search results, use Google Webmaster Tools, or equivalent for Bing.

Credential Management API

I'm skipping this for now, because it has poor browser support .

Social Discovery

If the default appearance is not sufficient when your pages are shared on social media, consider using:

• For Facebook, use Open Graph Protocol
• For Twitter, use Twitter Cards

User Input

• Make sure to leave autocomplete on in most cases (unless providing a custom autocomplete via javascript). Also, use autocomplete metadata, i.e., autocomplete="email".
• Prepopulate as much data as possible. For example, populate the "zip code" field of a form taken from a previous input step.
• Break long forms up with "wizard" steps, and use progress bars as indicators.
• Use calendars for date inputs, such as the one from AirBnb
• For text inputs, use the appropriate type. For example, for email, use type="email" rather than type="text". Most of these types have fallback support by just providing a plain text field.
• For usability and accessibility, always provide labels on form inputs. If you don't want the labels to appear, use a "screen reader only" CSS approach.
• Placeholders should not take the place of labels. Instead, they should act as "hints."
• Label tags should always have a for attribute assigned with the name or id of the associated field
• Use responsive design and media queries to position labels and inputs based on viewport size.
• Avoid custom javascript form validation that changes the user's input values. This will affect autocomplete and paste behavior.
• Use standard HTML inputs as much as possible. Only reach for a custom javascript fields when necessary. Also, make sure to test any custom js inputs heavily in mobile and review for accessibility.
• Validation:
  • Follow best practices for real-time validation.
  • Stick with HTML5 standards:
    • Use built-in attributes like pattern, required, min, max, etc.
    • If default HTML5 validation is not enough, consider providing custom validation using the Javascript Constraint API
• Use the user-select:none; CSS property to prevent text selection on elements like buttons when doing long clicks on mobile. Use with caution, because users may actually want to select text from other elements.
• Consider using custom gestures, such as "swipe left," for touch devices like tablets and phones. Detailed code samples can be found at Add Touch to Your Site on Web Fundamentals.

Web Payments

I'm also skipping this one; it's not ready for prime time.

Whew, time for some more caffeine! In part 2, we'll continue with the next sections, starting Web Push Notifications...