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
As with my last post on AI, let me open with a statement: Just because most people hold AI a certain way, doesn’t mean that we always must, either now or in the future. As I noted in that piece, and my shades of gray post, I am well aware — and agree with — … Continue reading Must we always use LLMs this way? →
TokyoDev has grown substantially over the past few years. We’ve expanded our community, dramatically increased the scope and frequency of our events, and have curated a library of articles for international developers. Despite all that, the way we run the business hasn’t changed much. I’ve continued to coordinate most of these activities myself, making the final decisions and keeping everything connected. In short, TokyoDev cannot run without my daily input. That approach worked well when TokyoDev was smaller, but it’s increasingly limiting how much we can accomplish. To help the business grow further, I wanted to find someone to take over some of my responsibilities and bring a fresh perspective. This is a significant step for me personally, as while I have worked with many contractors over the years, I have never actually hired a regular employee. Most importantly, I wanted to ensure that this person was someone I could trust to understand what TokyoDev stands for, and to make decisions in line with our philosophy. So I’m happy to announce that Scott Rothrock is joining TokyoDev full time as our Head of Operations. About Scott Scott has lived in Japan for nearly 20 years and has worked as a software engineer in multiple industries and environments, including small Japanese-owned businesses, overseas employers, and international companies based in Japan. Until the end of October 2026, he was the head of the Japan Markets team at Kraken Technologies, where he led an international team of software engineers in delivering complicated, regulated products on strict timelines for Japanese electricity and gas retailers, while also ensuring compliance with evolving organizational and global standards. He’s made a name for himself both inside and outside Japan as a kind, effective mentor who can cultivate great engineers and leaders. Scott’s previous role in TokyoDev Some of you may already know Scott in another capacity, as he has been involved with TokyoDev since 2022. He began as a community volunteer and later became our community manager, which also included responsibilities such as managing our article pipeline from submission to publishing. When I created TokyoDev’s Discord, I had no previous experience running an online community. Scott joined soon after I started and began helping other members, stepping in when people behaved inappropriately, and configuring our roles and permissions and safety features. I was impressed by his initiative and asked him to become an official moderator in January 2023. Outside of his role as a moderator, Scott has always pushed TokyoDev to grow; for example, he arranged internet events such as livestreamed AMAs and interviews. He organized TokyoDev’s first meetup as a volunteer in February 2023, which taught me that there was interest in TokyoDev events outside of the internet. By the end of 2023, I had brought him on as our part-time community manager. What I saw throughout his tenure was that Scott continued to take initiative in expanding TokyoDev. Scott was one of our first external contributors, writing about his experience living with a disability in Japan. He encouraged me to expand and refine both our editing and submission processes so that we could reach out to even more contributors and platform their perspectives. The editorial team now consists of him and Rebecca Callahan, and they’ve had a hand in every article that TokyoDev has published. In other words, since 2022, Scott has shown that he cares about TokyoDev as much as I do. He is invested in what we do and why we do it, and shares my vision for what TokyoDev can become. What changes now Scott’s experiences as an engineer, a mentor, and a leader make me confident that, as our Head of Operations, he will continue to help TokyoDev mature. A big part of what has made TokyoDev successful is that I see the software developers who use our site as my peers and genuinely want to help them. Scott shares that perspective, and will join me in ensuring that TokyoDev remains true to its principles while we grow. So what changes in the short term? Nothing dramatic. I will teach Scott about managing TokyoDev as a business, and he will document our processes and products as a part of that learning. He will also look for areas of improvement while ensuring that we remain compliant with regulations and labor law. Over time, I will hand over some other responsibilities. I will continue to run TokyoDev, but TokyoDev will become less dependent on me for its day-to-day operations. Long term, I’m excited about what this will enable us to do. TokyoDev has always been about helping international software developers build successful careers in Japan, and bringing Scott on full time puts us in a much better position to continue doing that. We look forward to writing the next chapter of TokyoDev together.
Kidz Fun Art is a drawing, colouring and animation app for kids that I’ve been building since 2021. It runs in the browser also as a simple wrapper app on iOS, iPadOS and Windows. It wasn’t getting a great click through rate on Google, even for people who directly searched for it. So, for two days I took a hard look at how fast it loads and how search engines see it. It wasn’t flattering. This post covers what I found, what I changed and what the graphs say now. Short version: on a simulated slow phone, the homepage’s Largest Contentful Paint got about 2.6× faster (15.9 s to 6.1 s) and its first load is about 82% smaller (4.2 MB to 0.75 MB). I also fixed a set of SEO mistakes that are, frankly, embarrassing to write down. I’ll write them down anyway. Part 1: Google had no idea what the site was for I started by reading 16 months of Google Search Console data. 9,380 clicks in total. About 9,200 came from people who had typed “kidz fun art” or a close spelling. People searching for what the app actually does (“coloring app for kids”, “ai art for kids”, “make a comic book”) sent the site 164 clicks. In 16 months. Total. When there was a relevant page, Google ranked it well. The site was #1 for things like “drawing app for kids ipad” and a German query that means “paint by numbers app without ads”. There just weren’t many relevant pages. Then I looked at the code, and the cause was obvious. The homepage <title> was “Kidz Fun Art” in all 12 languages. That’s a fine name, and a terrible title. It tells a search engine nothing. The homepage’s first <h1> was the pricing table’s “Choose your experience”. I was, in effect, telling Google that the most important thing on my homepage was the checkout. Every blog post had the same meta description: a generic line about “news, updates, tips”. Each post’s front matter already had a perfectly good excerpt field that nobody read. Blog posts had two <h1>s: the site header and the post title. There was no structured data at all. The sitemap that redirected every single URL This one stings. The sitemap is the one file whose whole job is to say “here are my URLs, please index them”. Mine listed 17 URLs, and every one of them redirected. The sitemap build used an environment variable that resolved to kidzfun.art. The site lives on www.kidzfun.art, so every URL got a 308. Only the English blog posts were listed. The other 11 languages appeared only as hreflang alternates, which pointed at redirecting URLs too. There were no <link rel="canonical"> tags on any page and no hreflang in the page <head>. Google was left to guess which URL was the real one, and it guessed wrong a lot. What I changed: The sitemap is now built on https://www.kidzfun.art, with 204 URLs: every home page, blog index, blog post, About page and gallery page, in all 12 languages. Each one lists all of its language alternates plus an x-default. A shared SeoLinks component adds an absolute canonical (www, no query string) and the full hreflang set to every public page. The ?v= cache-busting URLs that had been showing up as duplicates now canonicalise to the clean URL. /xx/blog/yy/... URLs, which returned a 500 in production (oops), now 308 to /blog/yy/.... Login, account, debug, export and embed pages send X-Robots-Tag: noindex, follow from next.config.js, so they stop using up crawl budget. robots.txt now mentions the sitemap. Novel idea. Why Google skipped half the site Search Console’s Pages report had 93 of 174 known pages not indexed. Every reason on that list traces back to the mistakes above: “Page with redirect” (22): that sitemap, plus internal links to the non-www host. “Duplicate without user-selected canonical” (18): I hadn’t selected any canonicals. Fair cop. “Crawled, currently not indexed” (39): mostly translated posts that Google reached through redirecting URLs, plus thin pages like /login. “Discovered, currently not indexed” (12): Google found these and decided they weren’t worth a visit. With no sitemap entry and no hreflang, I hadn’t given it a reason to. On-page fixes Titles and descriptions: Each blog post got its own seoTitle and description, in all 12 languages. The meta description now comes from the post’s excerpt, which is what that field was for all along. The About pages take their title and description from their own localized Markdown. They had been sharing an English title and a generic description. One <h1> per page: A # heading inside a post’s Markdown now renders as an <h2>, so the post title is the only <h1>. The About page opts back in with a keepH1 prop. Its Markdown heading is the page title. This fix arrived in two parts. The first part left the About page with zero <h1>s. I noticed, eventually. Structured data and social tags: JSON-LD for the home page (the app), blog posts (articles) and the embedded videos. Open Graph and X/Twitter tags on every public page, so shared links get a proper card. A real 404 for deleted gallery images: The AI gallery shows a friendly “AI Artwork Not Found” page when an image has been deleted. It used to return 200 OK, which Google calls a “soft 404” and dislikes. It now returns a 404 with noindex, and a 503 if the Firestore lookup itself fails, so a database hiccup tells crawlers “come back later” rather than “this is gone”. Part 2: Making the homepage fast The homepage is the app. It works offline, so every dialog (save, stickers, colouring pages, “get an adult”, “no wifi”) is server-rendered into the HTML up front. That’s a deliberate trade-off, and I kept it because I want new users to be able to immediately be able to start drawing as soon as they launch the app. What I hadn’t thought about was what it meant for the network. What the homepage downloaded before the app could start I measured the live site with a Lighthouse-style mobile profile: slow 4G (1.6 Mbps, 150 ms latency), 4× CPU slowdown, empty cache. First load: 4.5 MB over 198 requests. The homepage HTML alone was 358 KB, with about 77 <img> tags in hidden dialogs. The browser dutifully fetched every one of those images. The script that starts the app (main.min.js, 191 KB) sat at the very end of the document, so the browser found it last and gave it whatever bandwidth was left. The app script finished arriving at about 14 seconds. The CPU was not the problem. Every long task was under 300 ms. This was purely about bandwidth and request order. I had built a very polite queue and put my own app at the back of it. Watch the queue The waterfall is a simplified illustration. The milestone times (first paint, LCP, load) are measured: slow 4G + 4× CPU, local production build, median of 3 runs. My Largest Contentful Paint was the “Contact support” link The canvas doesn’t count toward LCP, and the toolbar buttons are small. So on a slow load the largest thing painted was… the loading dialog. The loading dialog fades in its “Taking a while? Contact support” text after 5 to 7.5 seconds. On a slow connection, that text became the page’s LCP element, at 15.9 s. I was measuring my page speed by how long it took to suggest the user complain about my page speed. There’s a lesson in there somewhere. The fix wasn’t to change the dialog. It was to make the app start sooner, so it paints before that text ever appears. What I changed Preload the app script. I added <link rel="preload" as="script"> in <head> for main.min.js and errorHandler.min.js. The <script> tags stay where they were, so execution order doesn’t change. The browser just starts fetching them before any image. This one line did more than anything else on this list. It’s a little humbling. Turn the three dialog GIFs into MP4s. Three animated GIFs: an arrow pushing pictures into a tablet (927 KB), a dancing rainbow pencil (650 KB) and a paper plane (305 KB). That’s 1.9 MB of decoration in dialogs most visitors never open on their first visit. I re-encoded them with ffmpeg: H.264 High profile, -preset veryslow -crf 20, yuv420p, +faststart, constant frame rate taken from each GIF’s frame delay. The commands are committed as scripts/gif-to-mp4.sh. The result is 130 KB in total, with SSIM between 0.988 and 0.993 against the originals. The pencil needed tpad=stop_mode=clone:stop_duration=0.2, because ffmpeg’s GIF reader drops the final 250 ms hold and the dance lost its big finish. The new <video autoplay loop muted playsinline> tags render at exactly the same size and class as the old <img> tags. Alt text moved to aria-label. Locked colouring thumbnails were full-size PNGs. In the colouring page picker, locked pages used the full-size colouring PNG as their background image, inlined into the HTML. That came to about 1.3 MB on every first visit, to draw thumbnails in a dialog that was closed. They now use the small image, set when the picker opens, like the unlocked ones always did. Sticker thumbnails wait their turn. I tried loading="lazy" first. It didn’t help: Chrome fetched the images before the stylesheet that hides the dialogs had arrived, so as far as it knew they were visible. Sticker thumbnails and the media library’s YouTube thumbnail now use data-deferred-src. They load 3 seconds after the load event, or as soon as their dialog opens, whichever comes first. The service worker preload starts after load. The offline preload queue (about 2 MB of colouring pages and stickers) used to start while the page was still loading and compete with it. Now it starts after the load event. Same files, same offline result, no fighting for bandwidth. Analytics is async. Nothing waited for it, so nothing needed to block on it. Cache headers. /images/*: max-age=86400, stale-while-revalidate=604800. It had been max-age=0, so every image was re-checked on every visit. Versioned /js, /css and /addToHomescreen files are immutable for a year in production. Offline still has to work Offline support is a core feature, so “just don’t download it” was never an option. Some of the changes above put it at risk, and a couple of things turned up along the way: Safari plays video from byte ranges. Safari requests video with Range: bytes=.... Answer that with a full cached response and the video won’t play. The service worker now answers Range requests from its cache with a proper 206 Partial Content slice (lib/util/rangeResponse.ts, with unit tests). First-visit gap: on a first visit the service worker isn’t controlling the page yet, so dialog images only reached the offline cache on the second online visit. The page’s own dialog images and videos now go to the front of the offline preload queue on the first visit. I nearly downloaded my whole site, 12 times over. The service worker cached every <link href> it found in the page. The new SEO work had just added canonical and hreflang <link>s pointing at all 12 localized homepages. So every new visitor would have downloaded about 12 extra homepages, in languages they don’t speak, “for offline use”. I caught it before production. The service worker now skips rel=canonical and rel=alternate. Safari stopped the service worker mid-download. The old preload queue ran on timers after the request had been answered. Safari considers an idle service worker fair game, so it stopped it after the first few images. The page now sends images in batches of 10, and the service worker caches each batch before it replies. A page lock-up I’d never noticed. resizeDialog added a new “image loaded” listener every time the window resized. With lots of images loading at once, the listeners multiplied until the page locked up. It now attaches one listener per image, which, in hindsight, is how many it needed. Part 3: The blog Blog index cards used the full 1920 px screenshots as covers, up to 500 KB each, in a box about 200 px wide. Each card was a little billboard, shrunk down by the browser on every visit. Covers now go through next/image with sizes that match the actual card widths, so the browser gets a resized WebP. The first few cards get priority. The rest load lazily. The first sizes hint was too small at some widths and made covers blurry. It now matches the real card widths, up to about 630 px between 769 px and 1028 px wide. Post pages: The cover image gets fetchpriority="high", and images further down the post load lazily. Five images were recompressed in place, keeping the same filenames and dimensions. The PNGs came out about 4× smaller and the JPEGs about 40% smaller. I deleted a 1.1 MB cover.png that nothing referenced. All 12 translations of that post used cover.jpg. The PNG had just been sitting in public/ taking up space. Results on the slow 4G profile: /blog LCP went from 13.3 s to 1.8 s. A typical post went from 3.9 s to 1.7 s. The gallery didn’t get faster, on purpose. It got a 5-minute edge cache and a cached Firestore image count, which fixed its slow server responses. I decided not to change its 20 full-size PNG thumbnails, so its lab LCP barely moved (8.4 s to 8.6 s). That’s a choice, and the chart owns it. Part 4: Lighthouse homework After the speed work went live I ran Lighthouse on the production homepage (mobile) and cleaned up what it flagged. Performance stayed in the low 70s, so I have some more work to do, but it’s moved nicely in the right direction. Part 5: Telling the search engines Fixing the site is half the job. The other half is getting crawlers to come back and notice. Google Search Console: Resubmitted the www sitemap. Clicked “Validate fix” on “Duplicate without user-selected canonical” and on the redirect errors. Requested indexing for the main language homepages and the top blog posts. The quota is about 10 a day, so it’ll take a few days. Wrote down a baseline from the Performance report, so in 4 to 8 weeks I can tell whether any of this worked. Bing Webmaster Tools: Submitted all 204 sitemap URLs through URL Submission. The daily quota is 10,000, so no trickle-feeding needed. Bing’s index also feeds DuckDuckGo and several AI search tools, so it’s cheap extra reach. Most of Bing’s “SEO recommendations” pointed at old ?v= URLs and old titles. They’ll clear as Bing recrawls. What I’m not watching: the Lighthouse score. Google ranks on real-user Chrome data (the Chrome UX Report): a rolling 28-day window, judged at the 75th percentile. So the honest answer to “did it work?” is “ask me in a month”. How I kept from breaking things The app has hundreds of unit and integration tests, all of which still pass (even though they do take over 30 minutes to run). I also manually regression tested all the riskiest changes. Hopefully I don’t make things worse before they get better… Lessons, mostly at my own expense Read your own sitemap. Actually open it and click a URL. Mine had been quietly redirecting for who knows how long. <link rel="preload"> for the script that boots your app is the cheapest big win there is. Browsers fetch resources in the order they find them. If your app script is at the bottom of a 358 KB document full of images, it really is last in line. Check what your LCP element actually is before you try to make it faster. Mine was a “Contact support” link. GIF is an image format from 1987 that I was using as a video format. A real video codec beats it by an order of magnitude at the same quality. try/catch doesn’t catch promise rejections. I knew that. My code didn’t. Every <link> you add to <head> is something your service worker might decide to download. Speed scores are for diagnosis. Rankings come from real users. Fix what the lab finds, then wait for the field data. Epilogue You’re still here? Wow. Cool. After all this, I’m hoping that users notice nothing other than quicker app start times. I’m looking forward to keeping an eye on traffic and retention in the coming weeks. Wish me luck!
Five months ago, we rebuilt our warehouse on DuckDB instead of ClickHouse. We did it because a shared ClickHouse cluster couldn't handle hours-long…