Emojis as favicons

2018-03-18T00:00:00Z

So I was working on jsonresume.io this weekend and really wanted a favicon for the page. I don't know about you but I kind of dislike having to add a favicon. I don't really know how to make a icon and so I keep reaching more and more into the ever expanding unicode emoji sets.

I really wanted just to drop a 📝 into a <link /> tag and call it a day. As far as I knew this wasn't possible, prompting this tweet:

Which technical committee do I need to submit a proposal to in order to get emojis as favicons? @WHATWG ?

To make a long story short, I made my way to whatwg.org to figure out how to make a proposal. That lead me to this issue #661. That mentions that you can set the favicon dynamically with a data uri.

Turns out I don't need to do a proposal at all! Even though it's not as easy as <link rel="icon" value="🍕" /> it's still pretty straightforward if you can write some JavaScript. Here's the code I wrote to set the favicon of this post:

const canvas = document.createElement('canvas')
canvas.height = 64
canvas.width = 64

const ctx = canvas.getContext('2d')
ctx.font = '64px serif'
ctx.fillText('🛰', 0, 64)
console.log(canvas.toDataURL())

const favicon = document.querySelector('link[rel=icon]')
favicon.href = canvas.toDataURL()

You could even wrap this in a function and dynamically set the favicon.

Let me know if you enjoyed this post on twitter 🙌.

March 24th 2018 update.

I refined the script a bit and it ends up looking like this:

const favicon = document.querySelector("link[rel=icon]");

if (favicon) {
  const emoji = favicon.getAttribute("data-emoji");

  if (emoji) {
    const canvas = document.createElement("canvas");
    canvas.height = 64;
    canvas.width = 64;

    const ctx = canvas.getContext("2d");
    ctx.font = "64px serif";
    ctx.fillText(emoji, 0, 64);

    favicon.href = canvas.toDataURL();
  }
}

This change means that I only need to include this script and set the emoji I want as a favicon like so:

<link rel="icon" data-emoji="🛰" type="image/png" />

Exactly what I wanted orginally! 🤙

♥

Stop trying to make things perfect

2022-12-13T00:00:00Z

I recently discovered the work of Tom Sachs, a contemporary artist known for his sculptural installations that often incorporate everyday objects and materials. After watching a number of his videos and reading about his creative process, I was struck by his philosophy of "just make the thing." In other words, don't try to overthink or perfect your work before you've even started - just get started and see where it takes you.

This philosophy resonated with me, as I often struggle with perfectionism in my own creative pursuits. For example, I have been thinking about creating a physical cookbook for some time now, but I have been stuck in the planning phase, trying to figure out the perfect layout and design before I even start writing any recipes. However, after learning about Tom Sachs' approach, I realized that I should just start writing down my recipes and worry about the design later. As Tom puts it, "Creativity is the enemy" - by trying to make everything perfect before we start, we risk stifling our own creativity and productivity.

To illustrate this point, consider the example of my mom's old cookbook. She used to collect newspaper clippings with recipes and handwritten notes, and would mark the good ones with "Great!" and add notes to the margins. This was not a fancy or professionally-designed cookbook, but it was functional and effective for her needs. It also allowed for flexibility and growth - she could easily add new recipes or make changes to existing ones by adding pages or making notes in the margins. This is the kind of cookbook I want to create for myself - one that is functional, flexible, and easy to use in the kitchen.

In conclusion, I think it's important to remember that perfectionism is often the enemy of creativity and productivity. Instead of trying to make everything perfect before we start, we should just get started and see where it takes us. By embracing the philosophy of "just make the thing," we can open ourselves up to new possibilities and creative growth.

Implementing View Transitions on koddsson.com

2023-05-31T00:00:00Z

Welcome to a development journey post for my personal website, koddsson.com. Today, we'll explore how I implemented view transitions to enhance the user interface and provide a more engaging browsing experience. The changes were made in a Pull Request titled "Implement View Transitions!".

View transitions are a key part of modern web design, adding visual continuity and smoothness when moving between different views or pages on a website. They can greatly improve the user experience by reducing visual abruptness and providing a sense of spatial awareness. Inspired by this, I decided it was time to introduce this feature to my own website, koddsson.com.

The process of implementing view transitions involved changes in two main files.

_layouts/default.html: Here, I introduced a meta tag <meta name="view-transition" content="same-origin"> to set the view transition property. This tag indicates that we want to enable transitions for navigations to and from this page.
css/index.css: This file saw a more substantial change. I added a CSS @supports rule that checks if the browser supports the property view-transition-name. If it does, two new properties are set: view-transition-name: header; under the header section and view-transition-name: main; under the main section. These properties enable the transitions for the header and main views.

Creating this Pull Request was a process of research, trial-and-error, and testing. I started by researching how view transitions could be implemented and found the explainer document to be extremely helpful. After writing the code, I thoroughly tested it to ensure it worked as expected. The Pull Request passed all six checks before being merged, confirming the changes didn't regress the performance or accessibility of the page in any way that Lighthouse CI can detect.

The view transitions have significantly improved the visual experience of browsing koddsson.com. The transitions between different views are now smooth and engaging. And according to the View Transitions explainer these transitions also: "[...] lower the cognitive load by helping users stay in context as they navigate from Page-A to Page-B, and reduce the perceived latency of loading." I encourage you to visit the website and experience these transitions firsthand.

You need to browse the website using Chrome and have these two experimental flags enable to be able to view these transitions:

chrome://flags#view-transition
chrome://flags#view-transition-on-navigation

Looking ahead, I plan to continue refining these transitions and exploring other ways to enhance the site's user interface.

In this post, we've delved into the process of implementing view transitions on koddsson.com. I hope this glimpse into my development process has been informative and interesting. As always, I welcome your feedback and questions. Happy browsing!

Changelog

May 30, 2023 Add instruction on how to enable View Transitions.

Web Performance — From the Lab to the Field

2023-08-13T00:00:00Z

The advent of the internet and the rise of digital technologies have transformed the way we live, work, and play. As we find ourselves increasingly reliant on web applications, the importance of Web Performance has never been more evident. In this post, we'll go over some basics of Web Performance, why Web Performance matters, and look at some real production data, how to collect it, and analyse it.

Understanding Web Performance and the need for speed

Web Performance is the amalgamation of objective measurements and the perceived user experience of load and run time. It encapsulates how long a site takes to load, become interactive and responsive, and how smooth the content is during user interactions. It is crucial to minimise the loading and response times, making the experience as available and interactive as possible, as soon as possible. ^[1]

Improving the loading performance of a web page is often one of the highest value performance optimisations that can be made. Users prefer web experiences that are fast to load and smooth to interact with. Good user experience includes ensuring your page loads quickly. The longer it takes for a site to respond, the more users will abandon the page for better user experiences.

To ensure optimal Web Performance, it's essential to test and analyse in a controlled lab environments, such as your own development machine, and in real-world field conditions.

Testing in the Lab

In the lab, controlled experiments can be conducted to measure Web Performance under specific conditions. This involves using various tools and techniques to simulate user interactions, network conditions, and device capabilities. By conducting tests in the lab, developers can gain valuable insights into the performance bottlenecks of their web pages and identify areas for improvement.

Lab testing often involves the use of performance testing tools, such as Lighthouse, WebPagetest, or browser developer tools. These tools provide detailed metrics and diagnostics related to page load times, network requests, rendering, and other performance-related aspects. They allow developers to analyse critical performance indicators, such as Time to First Byte (TTFB), First Contentful Paint (FCP), and Time to Interactive (TTI), to assess and optimise Web Performance.

Testing in the Lab has the benefit of repeatable results on a predetermined software and hardware which is very useful for debugging specific performance issues that your web page might have.

Testing in the Field

While lab testing provides valuable insights, it is equally important to understand how web pages perform in real-world scenarios. Real user monitoring (RUM) allows for comprehensive performance analysis by collecting data from actual users' interactions with the website.

RUM involves embedding lightweight tracking scripts in web pages to capture real-time performance data, including page load times, rendering speed, network latency, and user interactions. This data is then aggregated and analysed to understand the actual performance experienced by users in different geographical locations, on different devices, and across various network conditions.

By monitoring Web Performance in the field, developers can gain insights into long-term trends, identify performance issues that may be specific to certain user segments or geographic regions, and make data-driven decisions to optimise performance.

Embracing Web Performance in Practice

Let's take a look at how we implemented these principles on my website, koddsson.com. I started by implementing "in the lab" tests on each pull request created on the sites repository.

Testing in the Lab

For the pull request checks I used Lighthouse CI running in GitHub Actions. Lighthouse CI runs the same Lighthouse audits as you might have already run in your Chrome DevTools so they might look familiar. These audits provide detailed metrics and diagnostics related to page load times, network requests, rendering, and other performance-related aspects. These checks are then reported back to the Pull Request so I can make sure that I haven't regressed on any of the performance metrics.

By running Lighthouse audits in the lab, I'm able to identify performance bottlenecks and areas for improvement. The critical performance indicators, such as Time to First Byte (TTFB), First Contentful Paint (FCP), and Time to Interactive (TTI), allowed us to assess and optimise Web Performance. This iterative process of testing, analysing, and optimising in the lab helped me improve the site's speed and responsiveness.

Testing in the Field

While lab testing provides valuable insights, it's equally important to understand how web pages perform in real-world scenarios. Real user monitoring (RUM) enables us to collect data from actual users' interactions with the website and gain insights into their experiences.

For koddsson.com, I implemented real user monitoring by embedding lightweight tracking scripts in web pages. These scripts capture Core Web Vitals metrics during the users visit using the web-vitals npm package which is provided by Google.

Apart from the web-vitals library, the code to send the data to a backend system for processing is pretty minimal thanks to the sendBeacon API.

import {onLCP, onFID, onCLS, onINP, onFCP, onTTFB} from 'web-vitals';

const endpoint = 'https://vitals.koddsson.workers.dev/';

function sendToAnalytics(metric) {
	const body = JSON.stringify(metric);

	// Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
	(navigator.sendBeacon && navigator.sendBeacon(endpoint, body)) ||
		fetch(endpoint, {body, method: 'POST', keepalive: true});
}

onCLS(sendToAnalytics);
onFID(sendToAnalytics);
onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onFCP(sendToAnalytics);
onTTFB(sendToAnalytics);

If you have your browser network monitor open while visiting http://koddsson.com you should see the data being sent:

The data gets sent to a Cloudflare Worker® which saves the values sent to a database. I won't put the whole worker in this post but here's the bit that accepts a POST request:

if (request.method === "POST") {
	const payload = await request.json();
	const { name, id, value, rating, delta, navigationType } = payload;
	const timestamp = Date.now();

	try {
		await env.DB.prepare(
			`INSERT INTO recordings (id, name, value, rating, delta, navitationType, timestamp) VALUES (?, ?, ?, ?, ?, ?, ?)
		`).bind(id, name, value, rating, delta, navigationType, timestamp).run();
	} catch (error) {
		console.log(error);
	}
	return new Response("", { status: 201 });
}

This data is then analyzed to understand the actual performance experienced by users in different geographical locations, on various devices, and across diverse network conditions.

By monitoring Web Performance in the field, I'm able to identify long-term trends and uncover performance issues specific to certain user segments or geographic regions. These insights allows me to make data-driven decisions and further optimize the performance of koddsson.com in the future.

Visualising and Charting the Data

To gain a deeper understanding of the collected Web Performance data, visualising and charting the data can be immensely helpful. By visualising the data, patterns, trends, and anomalies can become more apparent, aiding in the identification of areas that require attention and optimisation.

At this point though the data is all just dumped into a database which makes it hard to gleam insights about Web Performance about it.

It would be really good if I could explore and graph this data for insights and overview. First we need to export the data in some easy way in a portable format. JSON seems like a logical choice so I added a endpoint the fetches all the data and some convenience filtering by the metric type.

const type = url.searchParams.get("type");

try {
	if (!type) {
	    const { results } = await env.DB.prepare(`SELECT * FROM recordings`).all();
		return Response.json(results);
	} else if (["LCP", "CLS", "FID", "INP", "TTFB"].includes(type)) {
		const { results } = await env.DB.prepare(`SELECT * FROM recordings WHERE name = ?`).bind(type).all();
		return Response.json(results);
	}
} catch (error) {
	console.error(error);
}

I then tried to load the data into various data visualisation applications and using different kind of charting libraries. These all either didn't work properly or didn't give me the results I wanted. I might have been spoilt with my previous experience with DataDog. I really wish I could load the data into a service and then easily explore it and present it in different ways. I ended up just wanting something simple and easy to manage and I actually ended up using Google Sheets with the charting function! One problem though; there doesn't seem to be a easy way to import a JSON file or endpoint. No worries, lets just add functionality to our worker to return CSV as well:

const type = url.searchParams.get("type");
const csv = request.headers.get("Accept")?.includes("text/csv");
const formatResults = csv ? ResponseCSV : Response.json;

try {
  if (!type) {
    const { results } = await env.DB.prepare(`SELECT * FROM recordings`).all();
    return formatResults(results);
  } else if (["LCP", "CLS", "FID", "INP", "TTFB"].includes(type)) {
    const { results } = await env.DB.prepare(`SELECT * FROM recordings WHERE name = ?`).bind(type).all();
    return formatResults(results);
  }
} catch (error) {
  console.error(error);
}

Now I can import the CSV files into Google Sheets and start creating charts that help me (and other potential stakeholders) to visualise and better understand the data.

These are pretty minimal charts but they are currently working for my use cases. I'm planning on finding a even better solution but at least now I can actually view the data with charts.

Looking Forward

Web performance is a continuous journey, not a destination. Looking ahead, I plan to continue explore other ways to enhance the site's user interface. Web Performance is a vital area that needs constant attention and optimisation, but the results are definitely worth looking into.

You should note that I did all this without spending any money. I'll concede that I don't have huge site to manage, there's not a lot of traffic right now so there isn't a lot of data to crunch but I'm also not buying some system wholesale and letting them deal with it for me. DataDog and Sentry cost some amount of money (that I don't want to pay for on such a small site like koddsson.com and which doesn't make me any money). I had to do some work but it's just installing some npm packages, writing a little JS snippet and a worker to save the metrics to a database. The hardest part so far has been graphing the data up in meaningful way.

In conclusion, Web Performance is an essential aspect of providing a smooth, user-friendly online experience. As developers, we should strive to create web pages that are not only functional but also performant. Before knowing how to make your website faster you'll need to know what things can be improved and that starts by measuring. As the Dutch say: "Meten is weten!" (To measure is to know).

https://developer.mozilla.org/en-US/docs/Web/Performance ↩︎