CSS3 & Responsive Design

CSS Performance Optimization

25 min Lesson 58 of 60

How the Browser Processes CSS

Before you can optimize CSS performance, you need to understand how the browser processes CSS in the first place. When the browser receives an HTML document, it begins parsing the HTML to build the DOM (Document Object Model). Simultaneously, it encounters CSS through <link> tags, <style> blocks, or inline styles, and starts building the CSSOM (CSS Object Model). The CSSOM is a tree structure, similar to the DOM, that represents all CSS rules and their computed values.

The critical point is this: the browser cannot render anything until both the DOM and CSSOM are fully constructed. CSS is a render-blocking resource by default. This means that even if the browser has finished parsing all the HTML, it will not paint a single pixel to the screen until every CSS file has been downloaded, parsed, and the CSSOM is complete. This is because the browser needs to know the final computed style of every element before it can lay them out and paint them. Optimizing CSS performance means reducing the time it takes to build the CSSOM and minimizing the work the browser must do during rendering.

The Rendering Pipeline

HTML Document
    |
    v
[Parse HTML] ---> DOM Tree
    |
    |  (CSS files discovered)
    |
    v
[Download CSS] ---> [Parse CSS] ---> CSSOM Tree
    |                                    |
    v                                    v
         [Combine DOM + CSSOM]
                |
                v
          Render Tree
                |
                v
           [Layout]  (calculate sizes and positions)
                |
                v
           [Paint]   (fill in pixels)
                |
                v
         [Composite] (layer compositing for GPU)
                |
                v
          Pixels on Screen

Render-Blocking CSS

By default, every external CSS file blocks rendering. The browser will not display content until it has downloaded and parsed all stylesheets linked in the <head>. This is by design -- without CSS, the browser would first show unstyled content (a flash of unstyled content, or FOUC) and then suddenly restyle the page, which creates a terrible user experience.

However, not all CSS is needed immediately. A stylesheet that only applies to print layouts, or one that only applies at large screen widths, should not block the initial render on a mobile device. You can use the media attribute on <link> tags to tell the browser which stylesheets are critical for the current context:

Using Media Attributes to Reduce Render Blocking

<!-- This blocks rendering (default, applies to all) -->
<link rel="stylesheet" href="main.css">

<!-- This only blocks rendering for print -->
<link rel="stylesheet" href="print.css" media="print">

<!-- This only blocks rendering when viewport >= 1024px -->
<link rel="stylesheet" href="desktop.css" media="(min-width: 1024px)">

<!-- This only blocks rendering in portrait orientation -->
<link rel="stylesheet" href="portrait.css" media="(orientation: portrait)">
Note: The browser still downloads all stylesheets regardless of the media attribute. The difference is that non-matching stylesheets are downloaded with low priority and do not block rendering. This means there is no bandwidth penalty for adding media queries to link tags -- only a rendering performance benefit.

The Critical CSS Path

The critical CSS path refers to the minimum amount of CSS required to render the above-the-fold content of a page -- the part users see immediately without scrolling. By identifying and inlining this critical CSS directly in the HTML document, you eliminate the need for an external CSS file to complete rendering of the initial viewport. The rest of the CSS can be loaded asynchronously after the page has rendered.

Inlining Critical CSS

Critical CSS is placed inside a <style> tag in the <head> of the document. This CSS travels with the HTML response, so the browser has it immediately without needing an additional network request. The critical CSS should contain only the styles needed for the above-the-fold layout: the header, hero section, navigation, and any content visible without scrolling.

Inlining Critical CSS

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>My Page</title>

    <!-- Critical CSS inlined for instant rendering -->
    <style>
        /* Reset and base */
        *, *::before, *::after { box-sizing: border-box; margin: 0; }
        body { font-family: system-ui, sans-serif; line-height: 1.6; }

        /* Header and navigation */
        .header { display: flex; align-items: center;
                  justify-content: space-between; padding: 1rem 2rem;
                  background: #fff; box-shadow: 0 1px 4px rgba(0,0,0,0.1); }
        .header__logo { font-size: 1.5rem; font-weight: 700; color: #111; }
        .header__nav { display: flex; gap: 1.5rem; list-style: none; }

        /* Hero section */
        .hero { padding: 4rem 2rem; text-align: center; background: #f8fafc; }
        .hero__title { font-size: 2.5rem; color: #111; margin-bottom: 1rem; }
        .hero__subtitle { font-size: 1.125rem; color: #6b7280; max-width: 600px;
                          margin: 0 auto; }
    </style>

    <!-- Full stylesheet loaded asynchronously -->
    <link rel="preload" href="styles.css" as="style"
          onload="this.onload=null;this.rel='stylesheet'">
    <noscript><link rel="stylesheet" href="styles.css"></noscript>
</head>
<body>
    <!-- Page content -->
</body>
</html>

Lazy Loading Non-Critical CSS

Once critical CSS is inlined, you need a strategy for loading the remaining CSS without blocking the page. There are several techniques for this. The preload technique shown above uses rel="preload" with as="style" to download the file with high priority but without blocking rendering. The onload handler then switches it to a regular stylesheet once downloaded.

Techniques for Lazy Loading CSS

/* Technique 1: preload + onload */
<link rel="preload" href="non-critical.css" as="style"
      onload="this.onload=null;this.rel='stylesheet'">

/* Technique 2: media trick (invalid media, switch on load) */
<link rel="stylesheet" href="non-critical.css"
      media="print" onload="this.media='all'">

/* Technique 3: JavaScript insertion */
<script>
    var link = document.createElement('link');
    link.rel = 'stylesheet';
    link.href = 'non-critical.css';
    document.head.appendChild(link);
</script>

/* Technique 4: requestIdleCallback for lowest priority */
<script>
    if ('requestIdleCallback' in window) {
        requestIdleCallback(function() {
            var link = document.createElement('link');
            link.rel = 'stylesheet';
            link.href = 'analytics-styles.css';
            document.head.appendChild(link);
        });
    }
</script>
Tip: Tools like Critical, Penthouse, and Critters can automatically extract critical CSS from your pages. In build pipelines, you can integrate these tools to generate critical CSS for each page template. This automates what would otherwise be a tedious, error-prone manual process.

Removing Unused CSS

One of the most impactful optimizations is removing CSS that your pages do not actually use. If you use a CSS framework like Bootstrap or a large design system, you may be shipping thousands of rules that no element on the page references. Every unused rule adds download size and CSSOM construction time. PurgeCSS and similar tools analyze your HTML and JavaScript templates to determine which CSS selectors are actually used, then strip out everything else.

Using PurgeCSS

/* Install PurgeCSS */
npm install purgecss --save-dev

/* purgecss.config.js */
module.exports = {
    content: [
        './src/**/*.html',
        './src/**/*.js',
        './src/**/*.vue',
        './src/**/*.jsx'
    ],
    css: ['./src/css/**/*.css'],
    output: './dist/css/',

    /* Safelist selectors that might be added dynamically */
    safelist: [
        'is-active',
        'is-open',
        /^modal-/,       /* Regex: keep all classes starting with modal- */
        /^tooltip/       /* Regex: keep all tooltip classes */
    ]
};

/* Before PurgeCSS: 250KB of CSS (full Bootstrap) */
/* After PurgeCSS:  12KB of CSS (only what you use) */
/* That is a 95% reduction! */

CSS Minification

Minification removes all unnecessary characters from CSS without changing its functionality: whitespace, comments, newlines, and redundant semicolons. Minified CSS is typically 20-40% smaller than the original. Combined with gzip or brotli compression, minification can reduce CSS file sizes by 80-90%. Every modern build tool supports CSS minification out of the box.

CSS Minification Example

/* Before minification (readable, 312 bytes) */
.card {
    display: flex;
    flex-direction: column;
    border: 1px solid #e5e7eb;
    border-radius: 12px;
    overflow: hidden;
    background-color: #ffffff;
    /* Card shadow for depth */
    box-shadow: 0 4px 6px rgba(0, 0, 0, 0.1);
    transition: box-shadow 0.3s ease;
}

.card:hover {
    box-shadow: 0 8px 16px rgba(0, 0, 0, 0.15);
}

/* After minification (175 bytes, 44% smaller) */
.card{display:flex;flex-direction:column;border:1px solid #e5e7eb;border-radius:12px;overflow:hidden;background-color:#fff;box-shadow:0 4px 6px rgba(0,0,0,.1);transition:box-shadow .3s ease}.card:hover{box-shadow:0 8px 16px rgba(0,0,0,.15)}

/* Common minification tools: */
/* - cssnano (PostCSS plugin) */
/* - clean-css */
/* - Lightning CSS */
/* - esbuild (built-in CSS minification) */

Selector Performance

Browsers match CSS selectors from right to left. When the browser encounters a rule like .sidebar .nav .link, it first finds all elements matching .link, then checks if each one has an ancestor matching .nav, and then checks if that ancestor has an ancestor matching .sidebar. While modern browsers have optimized selector matching to be extremely fast, overly complex selectors still have a measurable cost when you have thousands of elements and thousands of rules.

Selectors from Fastest to Slowest

Selector Performance Ranking

/* 1. ID selector (fastest, but avoid for styling) */
#header { }

/* 2. Class selector (fast, the sweet spot) */
.header { }

/* 3. Tag selector (fast for common elements) */
div { }

/* 4. Adjacent sibling (+) and child (>) combinators */
.nav > .link { }
.title + .subtitle { }

/* 5. General sibling (~) combinator */
.title ~ .paragraph { }

/* 6. Descendant combinator (slower, causes ancestor traversal) */
.sidebar .link { }

/* 7. Universal selector (matches everything) */
* { }

/* 8. Attribute selectors */
[data-theme="dark"] { }
[href^="https"] { }

/* 9. Pseudo-classes */
:nth-child(odd) { }
:not(.hidden) { }

/* 10. Pseudo-elements */
::before { }
::after { }

/* AVOID: deeply nested descendant selectors */
.page .main .content .article .section .paragraph .link { }
/* This forces 7 levels of ancestor traversal for every link */
Tip: In practice, selector performance rarely causes noticeable slowdowns on modern browsers. The real benefit of simple selectors is maintainability. However, if you have pages with 10,000+ DOM nodes and 5,000+ CSS rules (common in large web apps), selector complexity can add up to measurable delays during style recalculation. Use flat, single-class selectors whenever possible -- this is where BEM shines.

Expensive CSS Properties

Not all CSS properties are equal in terms of rendering cost. Some properties trigger expensive operations that force the browser to redo layout, repaint, or recomposite parts of the page. Understanding which properties are expensive helps you make informed choices, especially for animations and frequently changing styles.

Property Cost Categories

/* LAYOUT TRIGGERS (most expensive) */
/* These force the browser to recalculate geometry of elements */
width, height
padding, margin
top, left, right, bottom
display
position
float
font-size, font-family
border-width

/* PAINT TRIGGERS (medium cost) */
/* These force the browser to repaint pixels */
color
background, background-image
border-color, border-style
border-radius
box-shadow
text-shadow
outline
visibility

/* COMPOSITE-ONLY (cheapest) */
/* These only affect compositing, done on the GPU */
transform
opacity
filter (in some cases)
will-change

/* Animation best practice: */
/* PREFER these (composite-only, 60fps smooth): */
.animate-good {
    transition: transform 0.3s, opacity 0.3s;
}

/* AVOID these (trigger layout, cause jank): */
.animate-bad {
    transition: width 0.3s, height 0.3s, top 0.3s, left 0.3s;
}

The contain Property

The CSS contain property tells the browser that an element and its contents are independent from the rest of the page. This allows the browser to optimize by skipping layout, paint, or style recalculations for elements outside the contained subtree when something inside changes. Containment is one of the most powerful performance tools available in modern CSS.

CSS Containment

/* contain: layout */
/* Element's internal layout does not affect outside elements */
.card {
    contain: layout;
}

/* contain: paint */
/* Element's content will not be painted outside its bounds */
/* Browser can skip painting this element if it is off-screen */
.widget {
    contain: paint;
}

/* contain: size */
/* Element's size is independent of its children */
/* You MUST set explicit width and height */
.fixed-widget {
    contain: size;
    width: 300px;
    height: 200px;
}

/* contain: style */
/* CSS counters and other style features are scoped */
.scoped-section {
    contain: style;
}

/* contain: content (shorthand for layout + paint + style) */
/* Most common and safest to use */
.article-card {
    contain: content;
}

/* contain: strict (shorthand for layout + paint + size + style) */
/* Most aggressive, requires explicit sizing */
.grid-item {
    contain: strict;
    width: 250px;
    height: 350px;
}

/* Real-world usage: list of cards */
.product-list {
    display: grid;
    grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));
    gap: 1.5rem;
}

.product-card {
    contain: content;
    /* Now when one card changes (e.g., hover effect),
       the browser does not recalculate layout for
       the entire grid -- just this card */
}

content-visibility: auto

The content-visibility property is a game-changer for pages with lots of content below the fold. When set to auto, it tells the browser to skip the rendering work (layout, paint, and style resolution) for elements that are off-screen. The browser only renders these elements when they are about to scroll into view. This can dramatically reduce initial page load time for long pages.

Using content-visibility: auto

/* Apply to sections that are likely below the fold */
.article-section {
    content-visibility: auto;

    /* contain-intrinsic-size provides a placeholder size
       so the scrollbar does not jump as sections render */
    contain-intrinsic-size: auto 500px;
}

/* Common pattern for long feed-style pages */
.feed-item {
    content-visibility: auto;
    contain-intrinsic-size: auto 300px;
}

/* Blog post with many sections */
.blog-content section {
    content-visibility: auto;
    contain-intrinsic-size: auto 800px;
}

/* Important: Use contain-intrinsic-size to prevent
   layout shifts as content renders on scroll.
   The "auto" keyword remembers the actual rendered
   size after the element has been visible once. */

/* Performance impact example:
   Page with 100 feed items:
   Without content-visibility: 2.4s render time
   With content-visibility: auto: 0.3s render time
   That is an 8x improvement! */
Warning: Be careful using content-visibility: auto on elements that contain anchor targets, form inputs that might receive focus, or elements that use position: fixed or position: sticky. Since off-screen elements are not rendered, the browser may not be able to scroll to anchors or focus inputs inside them. Test thoroughly, especially for accessibility.

Reducing Paint Areas with will-change

The will-change property tells the browser that an element is going to change a specific property soon, allowing the browser to set up optimizations ahead of time. Typically, the browser promotes the element to its own compositor layer (GPU layer), which means future changes to that property can be handled entirely by the GPU without triggering layout or paint on the CPU.

Using will-change Correctly

/* CORRECT: Apply will-change before the animation starts */
.card {
    transition: transform 0.3s;
}

.card:hover {
    will-change: transform;
    transform: translateY(-4px);
}

/* BETTER: Apply via parent hover for advance notice */
.card-container:hover .card {
    will-change: transform;
}

.card:hover {
    transform: translateY(-4px);
}

/* CORRECT: Apply via JavaScript when animation is imminent */
/* element.style.willChange = 'transform';
   // ... animate ...
   element.style.willChange = 'auto'; // clean up after */

/* WRONG: Applying will-change to everything permanently */
/* This wastes GPU memory and can actually hurt performance */
* {
    will-change: transform; /* NEVER do this! */
}

.every-element {
    will-change: transform, opacity; /* Too broad, wasteful */
}

/* WRONG: Applying will-change and never removing it */
.sidebar {
    will-change: transform; /* If sidebar never animates, this wastes memory */
}
Note: Every will-change layer consumes GPU memory. On mobile devices with limited GPU memory, overusing will-change can cause the browser to evict other layers, leading to worse performance overall. Use it sparingly: only on elements that will actually animate, and remove it when the animation is complete. A good rule of thumb is to never have more than 10-15 will-change layers active simultaneously.

Efficient Custom Properties (CSS Variables)

CSS custom properties (variables) are incredibly powerful, but they can impact performance if used carelessly. When a custom property changes, the browser must recalculate styles for every element that uses that property, including all descendants. The higher in the DOM tree you define a custom property, the more elements are affected when it changes.

Custom Property Performance Patterns

/* INEFFICIENT: Changing a variable on :root affects the entire page */
:root {
    --primary-color: #2563eb;
    --header-height: 64px;
    --sidebar-width: 250px;
}

/* Changing --primary-color on :root forces style
   recalculation for EVERY element on the page */

/* EFFICIENT: Scope variables to where they are used */
.theme-toggle {
    /* Scoped to the theme section only */
    --theme-bg: #fff;
    --theme-text: #111;
}

.card {
    /* Scoped to cards only */
    --card-padding: 1.25rem;
    --card-radius: 12px;
}

/* EFFICIENT: Use static variables on :root,
   dynamic variables on specific elements */
:root {
    /* These rarely change -- safe on :root */
    --font-family: system-ui, sans-serif;
    --spacing-unit: 8px;
    --color-blue-500: #2563eb;
}

.sidebar {
    /* This changes on toggle -- scoped to sidebar */
    --sidebar-transform: translateX(0);
    transform: var(--sidebar-transform);
}

/* When toggling: only sidebar subtree recalculates */
.sidebar.is-collapsed {
    --sidebar-transform: translateX(-100%);
}

Reducing Specificity for Performance

High specificity does not directly slow down selector matching (the browser is fast at this), but it does create an indirect performance problem: it leads to more CSS rules being needed to override previous rules, which means larger stylesheets, more CSSOM nodes, and more time spent in style recalculation. Keeping specificity low and consistent means fewer rules overall and faster style resolution.

Specificity Reduction Strategies

/* HIGH SPECIFICITY: requires complex overrides */
#page .main-content .article .heading { color: #111; }
/* Specificity: 1-3-0 */

/* To override this, you need equal or higher specificity: */
#page .main-content .article .heading.special { color: #2563eb; }
/* Specificity: 1-4-0 */

/* LOW SPECIFICITY: easy to work with */
.article-heading { color: #111; }
/* Specificity: 0-1-0 */

/* Override with a simple modifier: */
.article-heading--featured { color: #2563eb; }
/* Specificity: 0-1-0 (same! later in source wins) */

/* Using :where() to zero out specificity */
:where(.card, .widget, .panel) {
    border: 1px solid #e5e7eb;
    border-radius: 8px;
    padding: 1rem;
}
/* Specificity: 0-0-0 (!) -- any class can override this */

/* Using @layer for specificity management */
@layer base, components, utilities;

@layer base {
    a { color: #2563eb; text-decoration: underline; }
}

@layer components {
    .nav__link { color: #374151; text-decoration: none; }
    /* Wins over base layer regardless of specificity */
}

@layer utilities {
    .u-color-red { color: #ef4444; }
    /* Wins over components layer */
}

CSS Code Splitting

Just as JavaScript benefits from code splitting, CSS can also be split into smaller chunks that are loaded on demand. Instead of shipping one massive stylesheet with every rule for every page, you split CSS by page, by component, or by feature. Users only download the CSS they actually need for the current page.

CSS Code Splitting Strategies

/* Strategy 1: Per-page CSS */
<!-- Homepage -->
<link rel="stylesheet" href="base.css">
<link rel="stylesheet" href="homepage.css">

<!-- Blog page -->
<link rel="stylesheet" href="base.css">
<link rel="stylesheet" href="blog.css">

<!-- Product page -->
<link rel="stylesheet" href="base.css">
<link rel="stylesheet" href="product.css">

/* Strategy 2: Component-level CSS (with build tools) */
/* Each component imports only its own CSS */
/* Webpack/Vite bundles only what is used per route */

/* Strategy 3: Dynamic CSS loading */
<script>
    // Load modal CSS only when user opens the modal
    document.querySelector('.open-modal').addEventListener('click', function() {
        if (!document.getElementById('modal-css')) {
            var link = document.createElement('link');
            link.id = 'modal-css';
            link.rel = 'stylesheet';
            link.href = 'modal.css';
            document.head.appendChild(link);
        }
    });
</script>

/* Strategy 4: Route-based splitting with frameworks */
/* Next.js, Nuxt, SvelteKit, etc. automatically
   split CSS by route when using CSS Modules or
   scoped styles */

Measuring CSS Performance with DevTools

You cannot optimize what you cannot measure. Browser DevTools provide several tools specifically for analyzing CSS performance. Learning to use these tools is essential for identifying bottlenecks and validating that your optimizations actually work.

DevTools Performance Analysis

/* Chrome DevTools Performance Panel */
/* 1. Open DevTools (F12 or Cmd+Option+I) */
/* 2. Go to Performance tab */
/* 3. Click Record, interact with the page, Stop */
/* 4. Look for these in the flame chart: */

/* "Recalculate Style" events */
/* - How many elements are affected? */
/* - How long does it take? */
/* - What triggered it? */

/* "Layout" events */
/* - How much of the page is being laid out? */
/* - Are there forced synchronous layouts? */

/* "Paint" events */
/* - How large is the paint area? */
/* - Can you reduce it with contain or will-change? */

/* Chrome DevTools Coverage Panel */
/* 1. Open DevTools */
/* 2. Cmd+Shift+P, search "Coverage" */
/* 3. Click "Start instrumenting" */
/* 4. Load your page */
/* 5. See exactly which CSS rules are used vs unused */
/* Red bars = unused CSS (candidates for removal) */
/* Blue bars = used CSS */

/* Chrome DevTools Rendering Panel */
/* 1. Cmd+Shift+P, search "Rendering" */
/* 2. Enable "Paint flashing" -- green overlays show repaints */
/* 3. Enable "Layout shift regions" -- blue shows layout shifts */
/* 4. Enable "Layer borders" -- shows compositor layers */

/* Lighthouse CSS Audit */
/* 1. DevTools > Lighthouse tab */
/* 2. Run Performance audit */
/* 3. Look for: */
/*    - "Reduce unused CSS" */
/*    - "Minify CSS" */
/*    - "Eliminate render-blocking resources" */

CSS Performance Audit Checklist

Use this comprehensive checklist to audit and optimize the CSS performance of any project. Work through each item systematically, measuring the impact of each change.

Loading Performance

  • Minify all CSS files -- Use cssnano, clean-css, or Lightning CSS in your build pipeline.
  • Enable compression -- Ensure gzip or brotli compression is enabled on your server for CSS files.
  • Remove unused CSS -- Use PurgeCSS or the Coverage panel to identify and remove unused rules.
  • Inline critical CSS -- Inline above-the-fold styles in the HTML and load the rest asynchronously.
  • Split CSS by page or route -- Avoid loading one giant stylesheet for all pages.
  • Use media attributes -- Add media="print" to print stylesheets and media queries to responsive stylesheets.
  • Preload key stylesheets -- Use <link rel="preload"> for stylesheets needed soon but not immediately.

Rendering Performance

  • Animate only transform and opacity -- These are composite-only properties and do not trigger layout or paint.
  • Use contain on independent components -- Apply contain: content to cards, list items, and widgets.
  • Apply content-visibility: auto -- Use on below-the-fold sections with contain-intrinsic-size.
  • Use will-change sparingly -- Only on elements that will animate, and remove it after the animation.
  • Avoid layout thrashing -- Do not read layout properties (offsetHeight, getBoundingClientRect) between style changes.
  • Reduce paint areas -- Use the Paint flashing tool to identify unnecessarily large repaint areas.

Selector and Architecture Performance

  • Keep selectors flat -- Single class selectors are fastest and most maintainable (BEM helps here).
  • Avoid deeply nested selectors -- No selector should need more than 3 levels of nesting.
  • Avoid the universal selector in key positions -- .container * forces matching against every element.
  • Scope custom properties -- Define dynamic variables on specific elements, not :root.
  • Use @layer for cascade management -- Reduces the need for specificity hacks and !important.
  • Reduce total rule count -- Fewer rules means faster CSSOM construction and style matching.

Font and Image Performance

  • Use font-display: swap -- Prevents invisible text while web fonts are loading.
  • Preload critical fonts -- Use <link rel="preload" as="font"> for above-the-fold fonts.
  • Prefer system fonts for body text -- system-ui, sans-serif requires zero download time.
  • Optimize background images -- Use modern formats (WebP, AVIF) and appropriate sizes.
  • Use CSS gradients over images -- When possible, pure CSS gradients are faster than image downloads.
Exercise: Open your project in Chrome DevTools and run a full CSS performance audit. First, use the Coverage panel to identify unused CSS -- note the percentage of unused bytes. Second, use the Performance panel to record a page load and look for long "Recalculate Style" events (anything over 10ms). Third, run a Lighthouse performance audit and check for CSS-specific recommendations. Based on your findings, implement at least three optimizations from this lesson's checklist: inline critical CSS, remove unused rules, and add contain: content to your card or list item components. Measure the before and after times to verify improvement.
Previous Lesson BEM Naming Convention & CSS Architecture
Next Lesson Debugging CSS: DevTools Mastery
Back to Course