My recently article on resolving the Flash of Invisible Text in Drupal left me wanting. It was never fully resolved since I was using Google Web Fonts, and they haven’t specified the CSS font-display property in their stylesheets. Using a pure CSS solution will have much better performance than Javascript, so I decided to do deeper investigation to see if this is solvable without self-hosting the webfonts.

There’s three things I want to test:

Website performance is arguably the single most important area where you can invest your development time and resources. No matter how unique your marketing message is, or how empowering your product, you will not see conversions if your site is slow to load. Mobile users on fast connections are still subject to network intermittencies. Peak traffic congestion can degrade the speeds that visitors normally connect with. Even disregarding dialup users, plenty of your desirable segment of visitors may be browsing from airports, traveling internationally, or at a coffee shop.

Progressive Web Apps are a great way to improve the performance of a website. Besides the functional behaviors that they provide, making a website feel more like a native app, they are predicated on leveraging service workers to improve site caching and offline support so the site can still be viewed even if the visitor has an intermittent (or unavailable) network connection. Follow along as I use Google's Lighthouse audit to enable Progress Web App capabilities on my Drupal-based website.

One of the biggest factors in page performance is render-blocking assets. These are assets that prevent the page from being rendered while they load. Typically this is Javascript and CSS in the head of the document. When you're using a CMS like Drupal, you often don't have much control over how these are structured since the CMS does its own management for combining various files into cached versions depending on what components or modules exist on a given page.

Today there are a plethora of fonts available for use on the web. All major browsers support web font technologies, and there are many foundaries and freely licensed fonts available for making a site look just so. We no longer have to deal with the extremely limiting set of baseline fonts installed on visitors' computers. However, the rise of webfonts also means that there is a performance impact to using them. When the browser loads the site, it also has to load the fonts, just like any other static asset.

When running a web-based CMS like Drupal or WordPress, it is not uncommon to have your site compromised by hackers who inject malicious files to use your site as a hosting platform for spaming, botnets, or other malicious activies. If this happens to you, don't fret, as it is very unlikely you were specifically targeted. Instead, it's most likely your site was found with automated scanners and targeted simply because it was identified as being out of date with security patches. To protect yourself, there's a few things you should do:

While working to improve the performance of my website, I have been using Google's Lighthouse to audit the page performance and looking for quick wins. One that comes up frequently, and is easily solved, is improving the cache policy on static assets. When running Lighthouse against my Drupal site, I get the warning "Uses inefficient cache policy on static assets". This will always occur on a Drupal site, but is really easy to improve the site performance to fix this:

As part of improving the performance of my site, and bringing it up to date with modern best practices, one step is to switch over to HTTPS instead of HTTP to secure the site. This is a required condition for a Progressive Web App, but it's a good practice in the modern age.

If you run a blog with comments enabled, you're probably painfully aware of the tedious task of dealing with all the spam issues. There's a many different approaches, and they all have tradeoffs:

After switching my site over to HTTPs and implementing a Progressive Web App, I was doing some browsing, impressed at how much snappier it feels. Until I ran into an issue: the images were missing from several of my articles! Instead of showing up, or even being missing, an empty grey box was showing in their place: