Portfolio/Resume Website Implementation - a 2020 retrospective

[joryphillips]

Portfolio/Resume Implementation - a 2020 retrospective

The current portfolio/resume website implementation has some advantages but also has some problems.

First, the positives:

• Doesn't rely on any JS libraries or build tools. Only needs the TypeScript compiler and (for now) a lightweight CSS library.
• Uses native HTML templating which is highly performant and also good to understand.

The negatives:

• The imported CSS library is nice little utility library, but after months away from regular use, it doesn't really make much sense. While I generally understand the intent of col col-6 sm-col-6 md-col-4 lg-col-3 px1 lg-px2 lg-p1 mb4, I think looking at line-by-line CSS rules that provide a grid, padding, and margins for that DOM element would be faster to understand and edit, as opposed to this long horizontal string of shorthand.
• JS is loading synchronously, then the JSON is loading, then images are loading. The only things that are async are the CSS with the initial JS, util.js and clock.js, and all the images.
• Page load is fast but could be even faster. It takes up to a couple seconds for everything to load. On the other hand, all the text content is loaded and showing in less than half a second (within milliseconds of the JSON loading).
• It is not great that none of the projects are showing until all the images are loaded. It also causes a content 'jump'.
• Stamping things into the DOM with JavaScript is not really scalable, at least without a library or more foresight than this implementation. 😃 If I write my own utility for doing this, it is not going to end up being better than LitHTML or similar.
• This implementation doesn't make it very easy to add additional functionality. Top feature request: make the projects interactive. Users (well... me) probably want something to happen when clicking on them, like providing more information and background. This means showing a popup, navigating to a new page, or moving/changing the information on the screen to make room for more text and possibly more images.

Some ideas:

• Drop the CSS library and rewrite it all by hand. CSS Grid is now standard since this page was originally made and should make a CSS rewrite relatively easy.
• Use the Intersection Observer to deal with image loading.
• Use loading="lazy" for images instead of the current Promise.all() then show method.
• Use a library for templating. LitHTML does a lot of what this code does and is likely just right for this.
• Start componentizing the webpage and make it more app-like. This might be overkill for the use case, but may also facilitate easier development of more dynamic, interactive content. React or LitElement are candidates.
• While loading the JSON with a fetch might be somewhat representative of a typical client-server relationship, it doesn't help in a meaningful way here. Changing it to be a JS object and bundling the module could speed things up. This does surface a good question: what is a good balance for easy content updates vs. easy implementation vs. fast end-user experience/downloading?
• Adding a new library will require also adding more advanced tooling, and with that comes the opportunity to bundle and minify the JS, which could help with load times (although this might be offset by adding a library).
• Probably should add a bundler in either event.

[joryphillips]

As expected, getting rid of the Promise.all() for all project images and instead using an intersection observer dramatically cut down on the page load time.

With a window size that fits eight images, the visible part of the page was fully loaded in just under 850ms.

It is probably good to note that the images themselves are in no way optimized for the size that they are displayed, so more gains could still be made in that regard.

[joryphillips]

Perf Analysis of Various Improvements

Moving the font import, along with bundling, minifying, and code splitting the JS had even more fantastic results.

I established a baseline test scenario by using Chrome DevTool's Fast 3G network throttle, and sized the viewport to only show 3 images in the page's 'Visuals' section. The cache is disabled for all tests.

Initial Code

Requested content painted at 18s The page loads but perf profiling stops before any projects or images are shown. With the network throttle, that finally happens nearly 18 seconds after the page is requested. The culprit is the author's foolish desire to have images all nicely fade in at once, which requires loading them all first with Promise.all(). Anyone working in a production environment would consider this broken and the implementation an anti-pattern for slow network bandwidth content delivery. Clearly this needed to be fixed (and was!).

Adding Intersection Observer

Requested content painted at 4.7s Only three images are loaded, which is all we need, but that doesn't happen until nearly 3 seconds have passed. Still, this change alone is a massive improvement for slow networks.

Bundle All JS

Requested content painted at 3.8s Converting static JSON data to TS and bundling it with all compiled JS into one big file results in the images starting to load about 1 full second sooner. This is a pretty big deal. Strangely, files don't start to load until after the CSS for the Google font is loaded.

Move font import to HTML, minify and code split JS

Requested content painted at 3.2s Finally, moving the Google font import to the HTML file drops the time to start loading images by just under a half second. Minifying the JS, and code splitting so that we aren't loading things we don't need yet, helps achieve this and drops JS load time by about 200ms.

Summary

After fixing the initial Promise.all() image load problem and using an Intersection Observer, we are able to decrease page load time by ~30% (1.5 seconds) on a throttled Fast 3G connection using bundling, minifying, code splitting, and being mindful about when and where fonts are imported.