More from Joel Gascoigne's blog
Fourteen years It's a little hard to believe. Fourteen years ago today, I launched Buffer from my apartment in Birmingham, in the UK. The launch came seven weeks after I started working on the project on the side as a contract web developer. For a few weeks, I called it bfffr until I realized that no one knew how to pronounce it. Sometimes it's better to be clear than clever. So it became bufferapp.com. Even then, people thought we were called Buffer App for a while! Eventually we were able to acquire buffer.com and clear up the confusion altogether. When I started Buffer, I had no idea how far it could come. This was a case where the dream formed over time, rather than being fully formed on day one. There's a dogma that you need to have complete clarity of the vision and outcome before you even start (and go all-in and full-time, which I also disagree with). I think there's a beauty in starting with a small dream. It just so happens that every big thing started small. Early on, my dream was just to create a tool that made it easy to Tweet consistently, build it for myself and others, and make enough money to cover my living expenses and go full-time on it. The number for me to be able to work on it full-time was £1,200 per month, and that felt almost out of reach in the beginning. Today, Buffer generates $1.65 million per month, serves 59,000 customers, and enables fulfilling work for 72 people. I've had many dreams with Buffer, each one progressively becoming more ambitious. To me it's always felt like I can just about see the horizon, and once I get there, I see a new horizon to strive for. I've tried to embrace that Buffer can continue to evolve as I, the team, and customers do. A lot happens as a founder and as a business in fourteen years. I started the company when I was 23. I was young, ambitious, and had so much to learn. My naivety served me well in so many ways. At the same time, I like to think that the years have given me a more intentional, decisive approach to business. Broadly, it feels like we've had three eras to the company so far. In our first era, we found traction, we built swiftly and with fervor, we grew a special community of users and customers, and we did it all in our own way. We were a remote company before almost anyone else, and were part of the earliest days of building in public. There's so much we did right in that first era, though we also had wind in our sails which masked our errors and immaturity. The second era of Buffer was marked by growing pains, a struggle to understand who we really are, missteps and through that, transformation, clarity, and new beginnings. These years were very much the messy middle of Buffer. They were also where I experienced my lowest lows in the journey so far. As hard as this experience was, I am grateful as it was the path I needed to walk in order to grow as a leader, cement our independence and long-term ambitions, rediscover Buffer's purpose, and start to operate with greater conviction. We're a couple of chapters into our current era. With a renewed focus on entrepreneurs, creators, and small businesses, we started making bolder moves to serve them and create a more unique offering in what had become a very crowded and commoditized space. Through a clearer strategy, strengthening our culture, and improving how we work as a team, we emerged from a multi-year decline. Last year, we turned the ship around and had a flat year. This year, we're on track for over 10% growth and a profitable year. It doesn't feel like a coincidence to me that this final era has also been the phase where I've experienced one of the most joyful and demanding experiences as a human: becoming a parent. I have a wife and I have two young boys, and they mean the world to me. I also started prioritizing my community of family and friends, as well as cultivating hobbies again. I spend time on my health and fitness, try to keep up my skiing, and recently picked up playing the piano again. Time has become a lot more precious, and with that, clarity and conviction are more vital than ever. As much as it sometimes feels hard to fit everything in, to me, it's the whole package that makes life fulfilling. When I really stop to take a step back, I feel very lucky that I've been able to do this for fourteen years. It's a long time in any sense. In tech and social media it feels like almost a lifetime already. And yet, just like those early days when I could barely imagine reaching £1,200 per month, I'm still looking toward that next horizon. I see a clear opportunity to help entrepreneurs, creators and small businesses get off the ground, grow, and thrive long-term. Photo by Simon Berger on Unsplash.
The significance of Bluesky and decentralized social media I'm delighted to share that we have introduced support for Bluesky in Buffer. This is an important moment for us as a company, and there are a number of reasons that adding Bluesky is personally meaningful for me. With Bluesky, we now support the three major social networks pushing forward a new era of decentralized social media: Mastodon, Threads and Bluesky. We have been intentional about moving fast to add these channels to our tool. Supporting independence and ownership in social media Buffer has now existed for almost 14 years, and throughout that time I've seen a lot change in social media, and in our space of tools to support people and businesses with social. We're an outlier as a product and company that has existed for that kind of timeframe with leadership and values left in tact. We've had to work hard at times to maintain control over our destiny. In 2018, we made the decision to spend $3.3M to buy out the majority of our VC investors and be able to go our long-term path. We have continued to carry out buybacks each year since 2018, and at this stage we are majority founder and team owned. One of the things I'm proudest of is that we still wholeheartedly serve individuals and creators, and have not gone up-market as many other long-running companies in our space have done. We've been fortunate to be able to scale to 56,000 paying customers and over $18M in annual revenue while taking our own unique path. Through intentional choices over the years, we have maintained a level of optionality over our future that most do not have. This independence is something I don't take for granted. Keeping ownership of our company, and through that ownership having an ability to boldly go in the direction we believe is best for customers and the team, is very important to me. This is why, as a business, we feel so philosophically aligned with rising new decentralized social media networks, such as Bluesky and Mastodon. These networks have been started with a belief that individuals should maintain ownership over their content and the connection to their audience. They have data portability baked in from the beginning. When you use these networks, you are much more likely to be able to maintain control over your content and audience than if you use social networks owned by large corporations with complex ownership structures of their own, and often with public markets to answer to. The larger social networks provide a level of distribution that's worth tapping into, but I strongly encourage investing a portion of your energy into networks where you will be able to maintain ownership long-term. At Buffer, we will be doing everything we can to support the growth of new decentralized social media options, because we believe that individuals and small businesses should maintain control over their content and the connection to their audience. The resurgence of the open web with social media protocols I have been eagerly observing the emergence and growth of social media protocols, in particular with ActivityPub (and Mastodon as the prominent implementation), and AT Protocol from Bluesky. Open standards in social media could be as powerful as open standards have been for direct and private communication (email). What I find exciting about the development of these open standards, and more importantly the adoption of them and traction of social networks which support them, is that they can bring forth a new era of open standards for the web. The Internet was built upon open standards — HTTP, URL, TCP/IP, DNS, HTML. A vast many valuable internet businesses have built on these "shoulders of giants." ActivityPub and AT Protocol are built with open standards philosophies, and could similarly enable a new playground of innovation, with openness, ownership and interoperability at their core. I personally miss the earlier days of social media where the APIs had much greater parity with what could be done natively on the platforms. When I started Buffer, the Twitter and Facebook APIs were close to feature-complete, and brought about a lot of innovation in third-party development on top of those APIs. This is how Buffer was born, along with many other products in our space. Over time, we saw an era of closed APIs with reduced transparency and ownership of content and audiences. Mastodon and Bluesky bring the opportunity for a new era of innovation in our space, which I am welcoming with open arms. More innovation in the social media management space will be better for customers, and frankly makes for more exciting work to do. Bluesky is bringing innovation back to social media If you haven't had a chance to take a look at some of Bluesky's recent product and platform announcements, I highly recommend that you go and read them. In particular, what they've done with introducing custom feeds as well as starter packs gets me very excited about some real innovation from a social network. When I saw starter packs introduced, it immediately felt like a no-brainer feature for a social network, and such a powerful thing, especially for an emerging social network, to offer. Starter packs allow anyone to create a "getting started pack" for a new Bluesky user. This can include a set of recommended follows, and up to three recommended custom feeds (more on those below). This enables their passionate users to be able to personalize an introduction for people not yet on Bluesky. It's a smart way to activate users to play a meaningful role in onboarding new people to the network and grounding them with an existing community to interact with. Of course, Bluesky benefits by likely getting more people onto their new network than they would otherwise. Custom feeds are an incredible innovation that put the choice of algorithm for the social network in the hands of the wide range of users and different niche communities that exist on the network. The way that the Bluesky team have built custom feeds enables a ton of flexibility for the types of content alogrithms can serve up, and creates a marketplace for browsing and enabling different custom feeds you can choose to view. Something I've observed from the Bluesky team is their commitment to, and intentionality around, building tools for the governance of the network itself. It's very meaningful that on Bluesky you can choose your own algorithm and you can adopt an algorithm that someone else has written, or create your own algorithm for what content shows up in your feed. And I think it's very smart that Bluesky has done this — because it's both innovation and it's strong strategy because it's a highly defensible move which many of the other networks would not be able offer. It would be very unlikely for the commercial social networks to move away from the company, the network themselves, holding on to ownership of the algorithm and what is served up to you. I had a wonderful conversation with Rose Wang from the Bluesky team a couple of weeks ago and one of the topics we got into was around the values that are embedded in the Bluesky team and the work they're trying to do. It was clear to me how thoughtful and intentional they are being around the governance of the network and the flexibility they're building in to allow users to really shape the community and what is important to them. Something I appreciate about Bluesky is that their goal is to create a social network not controlled by a single company, while also ensuring that it comes together as a cohesive and easy-to-use experience. Decentralized social media can be daunting and feel complex and inaccessible to people initially, and so I think intentional work going into the simplicity of the experience is paramount. With great innovation from the Bluesky team such as starter packs and custom feeds, along with their focus on simplicity, I strongly encourage you to go and take a look at this new social network. This is a platform and community that's worth taking a deeper look at, participating in and investing time into. Join us in participating in a new era of decentralized social media By supporting Bluesky, along with Mastodon and Threads, we are playing our part in moving forward this promising new era of social media. Many of us in the team have been personally drawn to these networks for their special and supportive communities. We're here to see decentralized social media grow and become more meaningful for more people across the world. That's why we've put our scale, brand and resources into building awareness and providing tools to make participating on these new social networks more streamlined. I encourage you to add Bluesky to your channels in Buffer, and start participating in the social network today. Learn more and get started by visiting our Bluesky page. Photo by Kumiko SHIMIZU on Unsplash.
Our vision for location-independent salaries at Buffer Note: this was originally posted on the Buffer blog. I’m happy to share that we’ve established a long-term goal that salaries at Buffer will not be based on location. We made our first step towards this last year, when we moved from four cost-of-living based location bands for salaries to two bands. We did this by eliminating the lower two location bands The change we made resulted in salary increases for 55 of 85 team members, with the increase being on average $10,265. When the time is right, we will be eliminating the concept of cost-of-living based location bands entirely, which will lead to a simpler approach to providing generous, fair and transparent salaries at Buffer. In this post I’m sharing my thinking behind this change and our approach to pay overall. Location and Salaries It’s been interesting to see the conversation about location and salaries unfold both within Buffer and beyond. We’ve heard from many teammates over the years about the pros and cons of the location factor, and of course we’ve watched with interest as this became a regular topic of conversation within the larger remote work community. I've had many healthy debates with other remote leaders, and there are arguments for eliminating a location component which I haven’t agreed with. I don’t believe pay differences across locations is unethical, and it has made a lot of sense for us in the past. However, the last few years have seen a lot of change for remote teams. A change like this isn't to be made lightly, and at our scale comes with considerations. Our Compensation Philosophy Compensation is always slowly evolving as companies and markets mature and change. We’ve been through several major iterations of our salary formula, and myriad small tweaks throughout the last 8 or so years since we launched the initial version. Part of the fun of having a salary formula is knowing that it’s never going to be “done.” Knowing that the iterations would continue, Caryn, our VP of Finance, and I worked together to establish our compensation philosophy and document our principles on compensation to help us determine what should always be true even as the salary formula changes over time. We arrived at four principles that guide our decisions around compensation. We strive for Buffer’s approach to salary, equity, and benefits to be: Transparent Simple Fair Generous These are the tenets that have guided us through compensation decisions over the years. After we articulated them as our compensation principles, we were able to look at the location factor of our formula with new clarity. There are a few key considerations that were part of our discussions and my decision to put Buffer on a path towards removing our location factor from salaries that I'll go into more detail about next. Transparency, Simplicity, and Trust Our salary formula is one of the fundamental reasons that we can share our salaries transparently. Having a spreadsheet of team salaries is a huge step toward transparency, but true transparency is reached when the formula is simple, straightforward, easy to understand, and importantly, easy to use. In one of our earlier versions of the salary formula, we calculated the cost-of-living multiplier for every new location when we made an offer. That was cumbersome, and it meant that a candidate couldn’t truly know their salary range until we calculated that. This was improved greatly when we moved to the concept of “cost-of-living bands.”. After that, different cities and towns could more easily be classified into each band. This massively increased the transparency of the formula, and I think it helped create a lot more trust in this system. Anyone could relatively easily understand which band their location fit into, and with that knowledge understand the exact salary they'd receive at Buffer. This type of immediate understanding of the salary formula, and ability to run calculations yourself, is where transparency really gains an extra level of impact and drives trust within and beyond the team. However, with our four cost-of-living bands, there were still decisions to be made around where locations fall, and this has been the topic of much healthy and productive debate over the years. The conversations around locations falling between the Average and High bands is what led us to introduce the Intermediate band. And with four choices of location, it has meant there is some disparity in salaries across the team. With the benefits that come from the powerful combination of transparency and simplicity, alongside the increased trust that is fostered with more parity across the team, I’m choosing to drive Buffer’s salary formula in the direction of eventually having no cost-of-living factor. Freedom and Flexibility We’ve long taken approaches to work which have been grounded in the ideal of an increased level of freedom and flexibility as a team member. When I started Buffer, I wanted greater freedom and a better quality of life than I felt would be possible by working at a company. That came in various forms, including location freedom, flexibility of working hours, and financial freedom. And as we’ve built the company, I’ve been proud that we’ve built a culture where every single team member can experience an unusual and refreshing level of freedom and flexibility. Since the earliest days, one of our most fondly held values has been to Improve Consistently, and in particular this line: “We choose to be where we are the happiest and most productive”. This is a value that has supported and encouraged teammates to travel and try living in different cities, in search of that “happiest and most productive” place. It has enabled people to find work they love and great co-workers, from a hometown near family where it would be hard to find a local company that can offer that same experience and challenge. It has also enabled people to travel in order to support their partner in an important career change involving a move, something which allows an often stressful change to happen much more smoothly, since you can keep working at Buffer from anywhere in the world. Having a culture that has supported moving freely across the globe has been a powerful level of freedom and flexibility. That freedom has been matched with a salary system which adjusts compensation to accommodate those changes in a fair and appropriate way. However, knowing that your salary will fluctuate and can decrease due to a choice to be somewhere else, does limit that freedom and the ability to make a decision to move. Moving towards a salary formula with parity across all locations, will enable an even greater level of freedom and flexibility. It feels clear to me that choosing to move is a personal or a family decision, and it is ideal if Buffer salaries are structured in a way that honor and support that reality. I’m excited that working towards removing our cost-of-living differences will help significantly reduce the friction involved in making a potentially positively life-changing decision to live in a different city or country. Results, Independence, and Reward At Buffer, we are not on the typical hyper-growth VC path. This comes with some constraints: we don’t have tens of millions in funding and unlimited capital to deploy in an attempt to find a rapid path to $100m and going public (thankfully, that’s not our goal). This path also means that our experiences as teammates in a variety of ways are directly tied to whether we are successfully serving existing and new customers. For example, the level of benefits, ability to travel (in normal times), and competitiveness of compensation, are very much driven by our revenue growth and profitability. But, this is independence too. The thing we often need to remind ourselves of, is that while we may feel more constrained at times, we have full freedom of what we do with the success we achieve. Making a choice like this is one example of that. It is my intention as founder / CEO that as we succeed together as a company, we all benefit from that success and see adjustments that improve our quality of life and create wealth. We are in a position of profitability which allows us to take a significant step towards removing the cost-of-living factor from our salary framework, which I believe serves those goals. And removing it entirely will be determined by us successfully executing on our strategy and serving customers well. Reducing Cost-of-Living Bands The way our salary formula works is that we benchmark a teammate’s role based on market data at the 50th percentile for the software industry in San Francisco and then multiply that by the cost-of-living band. So, a Product Marketer benchmark at the 50th percentile of the San Francisco market data is $108,838. Depending on the teammate’s location this would be multiplied by a cost-of-living band (Low, Average, Intermediate or High). For example, if they lived Boulder, Colorado, a city with Average cost-of-living, the benchmark would be multiplied by 0.85 for a salary of $92,512. To best reflect our compensation philosophy, company values, and the path we want for Buffer, we have eliminated the Low and Average cost-of-living bands. What we’ve done is brought all Low (.75 multiplier) and Average (.85 multiplier) salaries up to Intermediate (.9 multiplier), which we now call our Global band. This is what resulted in 55 teammates seeing on average an increase to their salary of $10,265. Our two bands are now Global (.9 multiplier) and High (1.0 multiplier). This change is based on my vision for Buffer and how being a part of this team affects each of us as individually, as well as the direction I believe the world is going. I’m excited about the change first and foremost because it supports our goal of having a transparent, simple, fair, and generous approach to compensation. This is also a move that raised salaries right away for more than half of the team. This point in particular gives me a lot of joy because I want compensation to be one of the incredible parts of working at Buffer. Money isn’t everything, and we all need kind and smart colleagues, a psychologically safe environment, and to work on challenging and interesting problems, in order to be fulfilled at work. Beyond that, however, money really impacts life choices, and that’s ultimately what I want for every Bufferoo; the freedom to choose their own lifestyle and make choices for themselves and their families’ long-term health and happiness. It’s important to me that people who choose to spend their years at Buffer will have the freedom to make their own choices to have a great life. And, for our teammates who live in much lower cost-of-living areas, a Buffer salary could end up being truly life changing. I’m really happy with that outcome. The decision was also impacted by the direction that I believe the world is going (and, the direction we want to help it go). Remote is in full swing, and it’s increasingly breaking down geographical borders. I believe this is a great thing. Looking ahead 10 or even 5 years, it seems to me that we’re going to see a big rebalancing, or correction, that’s going to happen. I believe it’s important to be ahead of these types of shifts, and be proactively choosing the path that’s appropriate and energizing for us. What next? Our plan is to eventually get to one single location band, essentially eliminating the cost-of-living factor from the salary formula altogether. This will be possible once we can afford to make this change and sustain our commitment to profitability. So, this will be driven by the long-term results we create from our hard work, creativity in the market, and commitment to customers. What questions does this spark for you? Send me a tweet with your thoughts. Photo by Javier Allegue Barros on Unsplash.
More in programming
It's time for a dev blogger's favorite topic: blogging about my new blogging setup. After migrating my blog from Hexo to Eleventy, building a photography website and creating a personal one-pager, it was time to find a new digital home for all my projects. If you notice any issue after the migration, please let me know. I redirect the RSS feed to the new domain, but you might want to update the feed URL in your reader. Motivation I've been maintaining three different websites under two different names: a mostly developer-oriented blog, a photography portfolio and a one-pager gluing everything together. When I started blogging about my sabbatical journey, I was thinking about making yet another page to create a clear separation. I've decided to do the opposite and merge all my websites into one instead. As I further reduce my dependency on social media and third-party services, it has become even more important to have my own space and practice POSSE. Every decision I've made was driven by two main goals: simplicity and personality. Setup I've stopped chasing the latest and greatest. I want to keep the setup as clean as possible, which means pulling fewer dependencies. Every package adds complexity and maintainability costs, so I've only added what was necessary — no more Gulp, Sass or Tailwind. Instead of taking one of my existing websites as a starting point, I created this project from scratch. I reused some of my previous code, but I didn't want to take over any technical debt (especially with the advancements in CSS). The foundation of this website hasn't changed: Eleventy (Build Awesome). It covers the fundamentals of a static site and offers a great level of customization. I've made my project more and less dependent on Eleventy at the same time: I replaced Gulp as my build pipeline with pure Eleventy processing. I replaced most shortcodes with Markdown alternatives (and markdown-it plugins), which are better supported by editors like Obsidian. I've also replaced the Nunjucks template engine with Liquid, which comes with a few trade-offs. The main reason was to avoid creating a new collection for every set of posts I render. With Liquid, you can apply array functions like filtering or sorting in the template itself: {% assign drafts = collections.all | where: "data.isDraft" | reverse %} {% for draft in drafts %} … {% endfor %} Another advantage is having date formatting included, so I don't need another library or custom code. You can even set a default date format, so you don't have to provide it each time. What I don't like is the verbosity of the template language, although I've gotten used to it by now. Nunjucks: {{ "/tags/" + tag + "/" }} {{ modified or created or date }} {% set perspectives = ["dev", "photography", "life"] %} Liquid: {{ "/tags/" | append: tag | append: "/" }} {{ modified | default: created | default: date }} {% assign perspectives = "dev, photography, life" | split: ", " %} After migrating my existing content, I've noticed the build taking way too long, both in the dev server and the production build. I've found out that the Eleventy template cache is turned off for Liquid by default. This was useful during development, but when updating actual content, it caused every template and partial to be constantly recalculated. After turning the cache on, this issue was resolved: eleventyConfig.setLiquidOptions({ cache: true }); Check the colophon for the full tech stack overview. Perspectives The main challenge was finding a way to separate and present my main personas. The Venn diagram intersection of people interested in software development, photography and my personal life is probably small. I could use tags, but they don't offer the level of personalization I was looking for. Most personal blogs separate the content by post type (blog post, note, photo), but this doesn't fit my use case. Instead, I've decided to structure my website around three perspectives, a term I have borrowed from the Eclipse IDE. Each perspective comes with its own avatar, tagline and bio. If someone is interested in everything I share (hi Mom!), they can still view all my posts. Design Since building my photography website, I've made many changes, but I never got around to share an update. The biggest change was the design, which I have used as a blueprint for the new website. I've decided to mimic a social timeline/feed, which most people are familiar with. At the same time, it should be clear that it's a personal website and not yet another walled garden. Typography is an important part of every design. The first step is to choose between a system font stack and a custom font, which comes with the usual performance vs. personality trade-offs. I've decided to go with a uniform look across all devices. I've settled on Source Sans 3 for copy text and Hack for code. Another big change was introducing a sidebar. I always felt like the empty horizontal space was "wasted" on a desktop device, but getting the sidebar UX right is challenging. I'm happy with the result, especially with the last two panels adding a personal touch to the design. Images I've made several changes to the handling of image files. To make them compatible with Markdown editors, I had to replace my custom picture shortcode. The official Eleventy image plugin is a popular choice, but it violates my simplicity goal and doesn't support everything I needed. I've decided to go with a plain Markdown image markup and a single image file (no format fallback or 2x version for retina displays). Additionally, I wrote a markdown-it plugin to turn the optional title parameter into a caption. As for the file format, both WebP and AVIF have excellent browser support. For each image, I select the format based on the quality and file size. For my photos, I'm using WebP for the timeline thumbnails and JPG for the full-size version. Theme picker There have been some recent discussions about dark mode toggles, and I considered going for a light/dark solution based on the user's OS preference. Driven by the personality goal, I knew I had to add at least one more theme, so a proper theme picker was necessary. Similar to navigation, people like to hide the theme selection on mobile devices behind a burger menu or a dropdown. I prefer the solution by Sarah L. Fossheim, where all available themes are displayed above the page footer. A friend was scrolling through my new website, and their first question was "Why is the theme picker in the footer?". This tells me the solution was a good idea — I don't think he would have noticed a typical theme button in the header. The implementation follows standard practices: Use the light or dark theme as default based on the user's OS or browser preference. Store a selected theme in the local storage and use it as the single source of truth. Prevent a flash of inaccurate color theme. Make the theme play nicely with bfcache. I might have slightly gone overboard with my third theme, but the nostalgia kept me adding more and more features. Enjoy going back to the 90s: Feeds As browser vendors decided to remove XSLT support, I didn't bother to style my feed. Instead, I've created a new web feeds page, listing all available feeds and a short explanation. I provide one feed for every perspective and one with all my posts combined. I once offered tag-based RSS feeds. This was useful for my sabbatical, but even there I had only a single subscriber. Now, all tag feeds redirect to their main perspective feed. I've also dropped the JSON feed, despite having at least 16 subscribers. Given that every web feed reader supports Atom feeds, I don't see the value of providing a JSON alternative. A JSON feed doesn't add much complexity, but handling different media types (post, photo) and properly escaping the content is one more thing to implement and maintain. Quality assurance I've put a lot of effort into my new digital home, and I want to make sure it stays in good shape. I've included several tools, most running automatically as part of the CI pipeline: eleventyDataSchema — lint Eleventy data values like titles or dates markdownlint — format/lint Markdown files Vale — lint content (grammar, writing style, formatting) Lychee — find broken links (internal and external) Evaluatory — check accessibility and validate HTML Oxlint — lint JavaScript files Eleventy linters are another option to analyze a template's output, but I haven't found a use case for it yet. Not everything can be automated, so I also did the following manually: Test with Chrome, Firefox and Safari Test with Polypane Test with Google Lighthouse Test with a screen reader Test with JavaScript disabled Test with CSS disabled Test at 200% zoom Test with a bigger browser font size Test with custom fonts disabled Test with delayed assets Performance It's difficult to compare the performance of two separate websites with that of a combined one. Some parts got worse, e.g. bigger font files and more CSS. At the same time, I've noticed that gzip compression was turned off for anything but HTML for a few years now (I must have missed it when upgrading nginx) 🙈. One improvement was to implement on-demand assets. For example, the lite-youtube-embed CSS and JavaScript is only loaded if a <lite-youtube> element is present on the page. As before, JavaScript is fully optional (except for interactive demos in individual posts). I've been using a mix of <noscript> and CSS to hide elements that require JS (like the theme picker). I don't like the user experience of pagination, so I avoided it for years. But now that I have almost 300 posts, I've decided to finally add it. I display 30 posts per page, with images further down still being lazy-loaded for better performance. I haven't applied pagination to tag pages, as that's more complex with Eleventy. Bits and pieces Here are some other noteworthy changes: I've removed post-specific social share images and use a single WebP Open Graph image instead. I've dropped JSON-LD. Open Graph and microformats are sufficient. "Naming is hard" is a common expression in software development, but it also applies to photograph titles. I've decided to use a counter as the title, e.g. #0100. Sometimes I do come up with a title that I love, like the Castle in the Sky, so I might mention it in the description. On a photo page, you can now open the previous/next photo using the left/right arrow keys (in addition to the existing navigation buttons). It's now possible to filter photos by date, gear, or location. Check the explore page for an overview. I've learned about and used some experimental CSS features (with progressive enhancement), like scroll-triggered animations or squircle corners. I've added an AI statement on my LLM usage. I finally have a proper about page. Cool URIs don't change, but it's inevitable when moving to a new domain. All my previous URLs are redirected, except for some assets that are no longer used. I will keep the old domain, so the redirects will continue to work for a foreseeable future. I've kept my previous Easter egg and added a few more. Have a happy hunt! 🕵️♂️ Inspiration I visited hundreds of personal websites looking for inspiration. Here are a few that I kept coming back to: Emma Goto. I love Emma's approach to presenting the variety of her interests, even though I went a different route. Brennan Kenneth Brown. This website has so much to offer. It's a great example of what the open web looks like. Rex Barrett. The sentence "Collecting hobbies is my hobby." hit home — so much that I had to steal borrow it for my short life bio. Conclusion This project was mostly about merging the content of two websites into one. I knew this would take a considerable amount of time, but I still greatly underestimated the effort. In the end, it was all about the journey, not the destination. I loved fine-tuning the design and tweaking little details that probably no one will ever notice. I still have many more ideas left in my backlog. How do you like my new digital home? If you have an opinion, let me know! Reply via email
New electronica album by Warrington-Runcorn New Town Development Plan
To protect against link rot and disappearing content, I save local copies of web pages I like into my web archive. Ideally, this archive is completely self-contained. I want a local copy of each page’s HTML and all the assets it depends on (CSS, images, scripts, and so on). I don’t want my archived pages fetching resources from the original website, which could disappear at any time. Initially, I was verifying self-containedness by hand. I’d open each saved page in a web browser, and check the browser dev tools. I’d check the Console tab for errors and failed requests, and watch the Network tab for requests going out to the internet. That approach was tedious and error-prone, and I wanted something better. I now automate the process using Playwright, a testing framework that allows you to control web browsers. I open each page using Playwright, and check if it’s making external requests. Detecting external requests in Playwright When you open a page in Playwright, you can subscribe to request events which tell you when the page issues a request. In this Python snippet, we start Playwright, start a WebKit browser, and open a new page. We tell the page to append external requests to a list, and then load example.com. We see that example.com makes two requests on page load: one for https://example.com, and one for a JavaScript file. from contextlib import closing from playwright.sync_api import sync_playwright with ( sync_playwright() as p, closing(p.webkit.launch()) as browser, closing(browser.new_page()) as page, ): requests = [] page.on("request", lambda msg: requests.append(msg)) page.goto("https://example.com") print("requests:", requests) # requests: [<Request url='https://example.com/' method='GET'>, # <Request url='https://example.com/s.js' method='GET'>] In a more complex scenario, we might use Playwright to interact with the page after loading – for example, clicking a button or filling in a form, and then we could see the requests triggered by each action. Once we have a list of requests made by the page, we can inspect the url property to check if any of them were fetching from an external website. I wrote a function is_external_request to carry out this check: from playwright.sync_api import Request import urllib.parse def is_external_request(req: Request, original_url: str) -> bool: """ Check if a request has a different origin than the original URL. A request is considered internal if: - it matches the original URL exactly - it has the same scheme, host, and port as the original URL - it uses a `blob:` scheme (for example, in-memory media representations) """ if req.url == original_url: return False # Compare the scheme/host of the request to that of the original URL. org_url = urllib.parse.urlsplit(original_url) req_url = urllib.parse.urlsplit(req.url) if org_url.scheme == req_url.scheme and org_url.netloc == req_url.netloc: return False # Ignore blob: URLs, which are in-memory representation of some data, # and not an external request. # # Playwright detects blob: URLs when loading media files; for example # using the <audio> or <video> tag. if req_url.scheme == "blob": return False # Fail open: if we can't decide if a request was internal or external, # assume it was external. return True assert_page_is_self_contained(ctx, url) I’ve wrapped these two steps in a function assert_page_is_self_contained(ctx, url), which is part of my chives utility library. The function takes a Playwright Browser (or BrowserContext) and a URL, then: Opens a new page in the browser Loads the URL in the page Checks what happened when the page completes loading It throws an exception if there are any: Uncaught page exceptions or errors Console warnings or errors Non-GET requests Requests targeting external resources The function tries to trigger important network requests that might be skipped on the initial page load. For example, it evaluates the body’s offsetHeight to force a synchronous reflow, which causes the browser to request any lazily loaded images or fonts that might otherwise be missed. Here’s an example which verifies a file example.html from the working directory: from chives.browser_fixtures import assert_page_is_self_contained, file_uri from contextlib import closing from playwright.sync_api import sync_playwright with ( sync_playwright() as p, closing(p.webkit.launch()) as browser, ): assert_page_is_self_contained(browser, url=file_uri("example.html")) I originally passed a Page as the first argument, but changing the function to take a Browser or BrowserContext lets it manage its own pages. It gets a fresh page for every verification, and closes it when it’s done. (The first time I ran this, I created a new page for every verification, and never closed them – my computer ground to a crawl as my script opened hundreds of browser tabs.) If you create a new context, you can emulate different browser settings, like location, locale, and window size. Here’s an example where we use contexts to test the same page in light/dark mode: with ( sync_playwright() as p, closing(p.webkit.launch()) as browser, ): with closing(browser.new_context(color_scheme="light")) as light_ctx: assert_page_is_self_contained(light_ctx, url=file_uri("example.html")) with closing(browser.new_context(color_scheme="dark")) as dark_ctx: assert_page_is_self_contained(dark_ctx, url=file_uri("example.html")) In my web archive, I check every page in light/dark mode, and at 1×/2× pixel densities. It takes at least a second to run each verification, so I cache the results. As I save new pages, they’re added to a verification queue, and I’m warned of any missing assets. Unsurprisingly, the first run flagged many missing fonts and images, which I added to my local archive. Every saved page now passes cleanly. Browser is best-effort, but may still miss things Even with automated testing, it’s difficult to guarantee a completely self-contained archive. Different instances of a browser might load different assets, and a single page load might miss different variations: Responsive images – web pages can offer different sizes of an image, and the browser chooses a specific size based on the current window dimensions Appearance settings – a browser might load different fonts or images depending on light/dark mode Interaction-dependent assets – a web page might have assets that are only required on hover or user action You can mitigate some of this by testing with multiple contexts or adding post-load interactions, but every step makes the process take longer. Fortunately, most of the pages I save are simple, blog-style pages where I’ve stripped out the JavaScript. For my specific use case, initial load verification is more than good enough. Other uses for this code There are other projects where it could be useful to intercept and audit the requests made by a web page: Verifying your Content Security Policy (CSP). The CSP header restricts what resources can be loaded by a web page, and you could check that your configuration has the correct effect. Auditing login screens. You could check that sensitive pages don’t load any external scripts, which mitigates the risk of credential theft via a compromised third-party. Testing analytics and tracking. You could script user flows, like a shopping cart checkout, and confirm that tracking events fire correctly. I don’t do much front-end web development, but Playwright has become a key tool in my toolbox. I read a lot about people using AI agents and MCPs to interact with websites, but I prefer Playwright. It’s more fiddly and requires explicit instructions, but it’s constrained, deterministic, and I never have to worry about it doing something unexpected. [If the formatting of this post looks odd in your feed reader, visit the original article]
It’s four years since I bought a printer. I thought I would provide an update on running costs, print sales, and profit. I’m happy to be completely transparent about all this as I know it can be difficult to figure this out if you are thinking of creating your own printing business. January 11th 2026, 11:30am All the photos here are work shot in the last twelve months. Year Four Investment? Nothing other than consumables this year. I did purchase a high-spec film scanner last year, detailed here, but don’t consider that as part of this. The scanner has paid for itself several times over, and it may become a factor in future years (see below). Income Income is made up of sales through a local gallery that I am part of, along with web sales: 5,940.- CHF - sales through the gallery 80.- CHF - sales through web shop = 6,020.- CHF total income Total income is down about 50% compared to 2025. Costs I had to purchase consumables (paper and ink), at a total of 957.- CHF. That cost is included in the total here under the “print consumables” category. January 11th 2026, 3:30pm Rental cost of space in the gallery was reduced due to having overpayments of rent and my loan to the gallery, from the previous year(s), paid back to me. -1,500.- CHF - rental cost of space in the gallery -957.- CHF - print consumables (paper, ink) -1,138.- CHF - framing/mounting/postage -1,135.- CHF - commission to the gallery -300.- CHF - web shop subscription 0.- CHF - stripe / paypal fees 0.- CHF - advertising (none this year) = -5,030.- CHF total costs Total costs are down by about 60% compared to 2025. Total Profit 6,020.- CHF total income -5,030.- CHF total costs = 990.- CHF total profit A Quiet Year? Actually an average year. The previous couple of years were outliers, due to large orders, so really I’m back to normal in terms of sales. The key factors in managing to generate a [small] profit this year were: 1) no longer having to pay back the loan used to finance the printer, and 2) reduced rental cost of space in the gallery due to a previous loan to it being repaid. Also having to spend almost 1,000.- CHF on ink this year ate into profit. This is probably a “once every three years” cost given the rate I print at. The principal cost is rental of space in the gallery - in a normal year this would be 3,000.- CHF. Essentially this means, given the material cost of printing and framing/mounting and commission to the gallery, I need to make about 5,500.- CHF of sales to break even. Solar Eclipse, August 12th 2026 That’s a grind. However I did receive two substantial orders at the end of October, which haven’t made it in to this year’s figures and should boost next year’s. Maybe even a good sign for the year to come? At least now the original investment loan is repaid, the printing costs cover themselves in most years. I may look at offering scanning services now that I have a high-spec film scanner, which could become a scan + print service. More thoughts about that next time.