['Journal'] Website Flashing

In a recent deployment of my static website, I encountered a curious issue that provided an opportunity to explore CSS performance and rendering behavior. Issue: despite the simplicity of the site, each navigation link click prompted an unexpected visual disturbance—a flash that was inconsistent with the anticipated static page transition.

The site’s architecture was initially highgly modular in its CSS approach, sectioned by components, pages, and functionality for ease of maintenance and scalability. This modular approach, while organizationally sound, I suspected, introduced a performance concern due to the increased number of HTTP requests—one for each of the six to seven CSS files, including those dedicated to various font families.

Performance Considerations for Modular CSS

It’s said that every external CSS file incurs an HTTP request, and as such, has the potential to increase page load times due to the render-blocking nature of CSS. This impact is compounded in the absence of HTTP/2, which significantly improves loading times and resource management through multiplexing and server push capabilities.

Plan

Prior to restructuring the CSS, a detailed record was maintained to serve as a benchmark for evaluating the performance impact post-optimization. The plan was as follows:

  • An exhaustive review of the CSS was conducted to identify and remove any redundant or superfluous selectors and rules.

  • Font Management: Font styles and weights were audited to ensure only the used variants were loaded, thus avoiding unnecessary bloat.

  • CSS Consolidation: All individual CSS files were merged into a singular file, leveraging build tools such as Webpack for bundling and Gulp or Grunt for task running, which streamlined the deployment process.

  • Minification: Post-consolidation, CSS minification was performed to reduce file size and enhance loading efficiency. This process was automated as part of the build step following the Hugo static site generation.

—

Despite these optimizations, the unpleasant flash persisted. Then I thought that this styling, was causing the flash underscored the nuanced nature of CSS rendering:

a:visited, a:active {
  /* conflicting styles */
}

Removing this code resolved the flashing issue temporarily, but after a while, the issue re-surfaced.

While CSS refactoring and optimization did not address the flash directly, they significantly improved the site’s performance, and made the page jumps more smoother.

My next step is to keep examining the <a> properties that I have set, and see what may be causing the issue. This is a bit difficult because this issue isn’t visible during the development when I am viewing the site on localhost—it only emerges when navigating the official, deployed version.

—

After trying a few more things, none of which ended up working, I am guessing it’s normal page regresh/reload issues; and so, I decided to add a faux delay whenever a link is clicked within the site, so that the user doesn’t experience those background flashes. Works pretty well!

The original modular CSS was more than adequate for a simple, static website such as this. However, enhancing performance where possible and reducing the overall size for the user’s benefit is always something worth trying; and it ended up being a good learning experience for me. I will, at some point, post a quick gif of how it was before and after.