Full Width 
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from Marco.org
I’ve been taking a break from Mastodon as my social home on the web for about six weeks. It has been more difficult than I’d usually admit. I have an amazing local community in my town that I love and am deeply involved in. But nobody here is a programmer, or even a computer nerd, so it doesn’t serve my need for a tech community. I work alone, for myself, in my house. It’s a fortunate lifestyle with many upsides, but it means I don’t get that form of community at work, either. I’ve had this feeling before… as a teenager in the 1990s. It’s profoundly lonely. But when I got internet access, that started to change. I found my people. First in the Total Annihilation community (RIP, Annihilated), then the HardOCP Forum, then the Something Awful Forums, then Tumblr, then Twitter and our community of Apple bloggers, and then Mastodon. Communities form, change, and dissolve over time. None of those are, today, anything like what they were when I most enjoyed them. We change, too. I didn’t move on from most of those solely because they changed — it was usually because we both changed, and it was no longer a good fit. My break from Mastodon has been a relief in some ways, as I’ve felt increasing divergence between what I wanted and what I was getting from it, but I didn’t know where else to go. Instagram, TikTok, and YouTube are all more video-broadcast platforms than communities. All I’ve found on Bluesky is even more anger and politics, the last things I need or want. Threads hasn’t yet stuck for me, and it’s owned by an asshole. Twitter was an amazing product and community that was previously owned by assholes, and now it’s X, which has a strong but different tech community, and is owned by different assholes. So I’ve just been… nowhere, for the first time since the 1990s. It has been, once again, quite lonely. Sure, it’s been relaxing, too, but in the way a vacation is relaxing. It’s great to take breaks, but after a long vacation, I’m ready to turn my brain back on. Without participating in a large, broad tech community, I’m exposed to fewer new ideas, both of my main jobs (app development and podcasting) are much harder, the quality and reach of my work have suffered, my skills aren’t improving as much, my mind is less stimulated, and I feel disconnected from my professions and passions. My world has gotten smaller. I could keep going like this to prove a stubborn victory or purity test, but I’d mostly just be hurting myself. Communities change, conditions change, and we change. We’re all better off if we’re willing to change our minds, and if our communities let us, no matter how strongly our younger selves declared a previous position. So I’m going to wade back in and see how it goes, trying to find a better balance to hopefully have better results, including on Mastodon. My people are spread across multiple services, and I’m going to explore them all, despite most of them being owned by assholes. I’d love to participate in communities without any assholes benefiting from it, but in the modern world, that simply isn’t possible. The only alternative is to isolate myself and not have a community at all (or a job, or a smartphone, or a computer, or internet access, or a car, or most of my food, or my country). That’s neither a price I’m willing to pay nor a condition I’d try to impose on anyone else. I’d love to have your support, forgiveness, and grace as I try to find my people again, and I strive to offer the same to all of you. Everyone deserves to be part of a community. And as I grow, I’m learning to declare fewer absolutes in a complex, imperfect, and constantly changing world.
For the first half of my childhood in suburban Ohio, we lived next to Bob. Bob and his wife were a kind, reserved older couple who decorated their home mostly with crucifixes and talked about Jesus a lot. Bob helped my mom with a lot of common household tasks after my dad died. When she woke up to a small fire on our deck, she didn’t call the fire department — she called Bob.1 I never learned any of Bob’s political views, though I can make some guesses in retrospect. They never mattered. He was just our neighbor. We later moved, and hit the neighbor jackpot with Van. Van was deeply kind, generous, and friendly — the sort of neighbor everyone wishes for. In my lazy teenage years, he’d often mow our lawn or shovel our snow for us before I even woke up. As his mobility later declined, I was honored to return the favor. Van and his delightful wife passed away years ago, before I learned how either of them felt on any political issue. If they were my neighbors today, how likely would that be? * * * If I learn today that my neighbors have political views that my “side” considers unacceptable and unforgivable, should I be able to have dinner at their house, shovel their snow, or even greet them outside? Should I be condemned for supporting or associating with them in non-political contexts? Should I be condemned for not publicly condemning them myself? While privilege and power dynamics play a complex and unavoidable role in this, I don’t want to associate with any community that would insist on either of those.2 And I can’t help but feel that maybe we were better off before we knew everyone’s hot takes on everything. The town coffee shop was just a coffee shop. We weren’t publicly shamed for going there because one of the owners was an ass. It was just a place to hang out with our friends. Our casual work friends were just casual work friends. We didn’t expect them to take positions on the world’s most complicated conflicts. We could just talk about weather and TV shows, and maybe sometimes get a beer after work. And our neighbors were just our neighbors. That was the day I learned the word “SHIT!” ↩︎ Somewhere on Bob’s wall might’ve been a relevant statement from an influential political dissident about casting the first stone. ↩︎
I have ADHD. Probably.1 My entire adolescence was defined by forgetting to do my homework, disappointing everyone around me, and being told by every adult that I was lazy, “just” needed to try harder, and wasn’t living up to my potential. I’ll be working on the resulting shame and anxiety for the rest of my life.2 If someone tells me, “Remember to pick up the dry cleaning tomorrow,” I definitely won’t remember. If someone tells me, “Remember to put the laundry in the dryer in ten minutes,” I probably won’t even remember that. If you’re thinking, “It’s just ten minutes! Nobody can possibly forget that,” I have made an app that’s probably not for you. * * * Computers saved me. Despite constantly being told that I’d never get a good job, computers provided a lucrative career path filled with even worse academic performers who couldn’t care less about my grades. What a stroke of luck! I’d be mediocre to terrible at most jobs, but I turned out to be very good at using computers to turn coffee and Phish into money. But computers also save me in smaller, everyday ways. They help me remember. * * * Sorry, I just had to go put the laundry in the dryer, which I had forgotten. Really. It’s that bad. * * * Calendar alarms changed my life. Events without alarms don’t happen. (If you’re thinking, “Why doesn’t he just check his calendar?” I have made an app that’s probably not for you.) I had less success with reminders until we had ubiquitous voice capture. If I think of something at inconvenient times, like while driving or exercising, I need to capture it immediately or I’ll forget. It cannot wait until I get to my phone or computer. It has to be recorded right then or it’s gone. Siri, for all of its faults, has always been very good at creating tasks in Apple’s Reminders app — and Siri is everywhere. Computer. Phone. Car. Watch. I can almost always ask Siri to add something to Reminders. So Reminders’ integration and ubiquity are invaluable to me. The Reminders app, though, doesn’t fit me at all. I don’t like how it looks, how it works, or how it’s organized. Hell, I don’t even like its icon. There’s nothing about it I like. So I never open it. (Not as if I’d ever remember to check it anyway.)3 Most of my Reminders interaction has always been via Siri and notifications. And that fits me very well, with three major exceptions: If I say “Remind me to buy milk,” but I forget to specify a time (or Siri misses it), Reminders will never notify me, and I’ll never check the app, so it’ll be lost. If I inadvertently dismiss a Reminders notification without snoozing it, Reminders will never notify me about it again, so it’ll be lost. When I do snooze a Reminders notification, which I do a lot, the snooze options suck.4 This spring, I made myself an app to fix all three, and… it escalated. I’ve been using it for months, and it has profoundly improved my life. Today, I’m releasing it, in hopes that maybe it can help other people, too. * * * Introducing Unforgetful. The concept is simple: Reminders for ADHD. This means: It’s impossible to lose a task. Notifications always repeat, even if you miss or dismiss them, until the task is completed or deleted. Designed for procrastination. Snoozing is a core feature, with thoughtful intervals that scale as you snooze a task more. Nothing is hidden away. A hidden task is a forgotten task. No folders, no tags, no organization, no different views or modes. No judgment or shame. Nothing is overdue. You’re not in trouble. Everything is either due now or in the future. Didn’t get to it today? Maybe tomorrow. Every day is a fresh start. And Unforgetful does all of that with your Reminders data. That means: Siri works perfectly, everywhere. Just say “Remind me…” without having to specify an app. It replaces your Reminders notifications. Turn them off, turn these on. No import. This isn’t a new system to learn or migrate into. Your Reminders data is just… there. No export. If you try Unforgetful and it’s not for you, just delete it and turn Reminders notifications back on, and all of your data is right there in Reminders. Mix and match. Don’t like it everywhere? You can still use Reminders on your Vision Pro or whatever, or simultaneously use Unforgetful with Reminders or any other app that uses Reminders data. I’ve optimized lots of features and details for ADHD, too: Fast capture with dictation. Tap the microphone button in Unforgetful — or its full suite of widgets, or its Lock Screen or Control Center controls — and quickly dictate a task.5 Spaced-out notifications, not an overwhelming pile at once. If multiple tasks are set to alert you at the same time, they space themselves out so you’re not barraged with a hopeless stack of obligations. And the order changes every day, so nothing gets lost between things. Recurring-task backlogs don’t pile up. If you miss multiple intervals for a recurring task, completing it doesn’t make you click through all of your past failures to get to the present day… it just schedules the next one from now. Remind me 5 minutes after I get home. Location-based reminders can notify you after a set delay. Because if a “remind me when I get home” task fires as I pull into the driveway, I’ll forget it by the time I’m inside, unloaded, and ready to do anything about it. Unforgetful is a Mac and iOS app that’s $19.99 per year (US). One subscription buys all platforms. There’s a one-month free trial so you can really live with it and see if it’s right for you before paying. There are a million task-management apps. Unforgetful is not for everyone, but it’s really for me, far more than anything else has ever been. Frankly, I have no idea how to reach the other people it’s for. But I know you’re out there. If any of this resonates with you… give it a shot. Despite significant progress on my mental health around this from therapy and media, I haven’t (yet?) sought an official ADHD diagnosis because I haven’t sought medication, and that seemed like the main reason why I’d want a diagnosis. That’s probably worth reconsidering. I’ll make myself a reminder to do it. Someday. ↩︎ I saw a psychologist throughout high school for my homework problem. Rather than recognizing 7 of the 9 symptoms of what we now call “inattentive” ADHD, he was just one more adult condemning me for not caring. (I really did care. Nobody wanted me to be “better” more than me.) In the 1990s, if you didn’t do homework but weren’t hyperactive, you were obviously just choosing to be lazy, and the solution was apparently to apply more shame. Not all doctors are good. ↩︎ I’ve tried other apps that are beautiful and work differently, but they’re all complete task-management systems that introduce a lot of features and complexity that I neither need nor want, at the expense of Reminders’ ubiquitous integration that I highly value. I’ve also tried other apps that use the Reminders database, but I haven’t found any of them to be… good. (Sorry. I probably didn’t try yours.) ↩︎ At least they specify the actual snooze times now instead of vague descriptions like “the afternoon,” which I proudly take full credit for, since it happened to change only after I ranted about it relentlessly on our podcast for months. If I truly made this happen, it might be the greatest impact on the world I’ll ever have. ↩︎ Dictation just records every word you say as the title, which is extremely fast and reliable. It doesn’t yet recognize things like “Remind me to buy milk at 10 AM tomorrow.” I haven’t nailed that natural-language processing yet — coming soon, maybe! For now, Siri does that part better. ↩︎
As Apple celebrates its fiftieth birthday, we celebrate the spirit of its formation, when people who loved computers started making great computers to inspire more people to love computers. That spirit is difficult to find in the tech business today. Immense scale, soulless optimization, and an insatiable thirst for growth dominate its behavior and discourse, leaving little room for the spirit and principles embodied by Steve Jobs and Steve Wozniak. Apple still has this spirit, and I believe you do, too. But it’s not infinite or invincible. It’s under constant pressure, including from Apple itself. It seems likely that you’ll soon be leading Apple, which will place unfathomable responsibility on your shoulders. As you grow into the leader that we know you can be, I urge you, on behalf of everyone who loves computers as much as we do, to protect and cultivate this spirit of Apple’s founders as the company’s top priority: We love computers. We don’t hide that — we celebrate it! We use computers to enhance our minds, lives, and abilities — not to be controlled, restricted, tricked, placated, angered, or surveilled. Our computers work for us, with the utmost respect for our time, attention, money, data, and privacy. We are customers and owners — not resources to be harvested, annoyed, or badgered into ever more services and upsells. Apple leads the industry in these values, but leading doesn’t always mean excelling. Remaining true to these values requires constant diligence, honest evaluation, introspection, and the audacity and courage to effect change. Apple doesn’t settle for fine, functional, or good enough in its hardware (and thanks for your incredible work on that). We love making and using products that aren’t just great, but greater than they need to be, always raising the bar of greatness for its own sake. Software, services, revenue sources, and world impact need to be held to that same standard. Focus on making great computers with great user experiences above all else, and you can trust that every other major goal will follow: profit, market share, expansion, impact, and benefit to the world. Making great computers must remain Apple’s top responsibility, because if you don’t do it, nobody will.
Ten years ago, Apple’s Phil Schiller surprised Apple enthusiasts and developers by walking out on stage at John Gruber’s The Talk Show Live WWDC event and giving an open, human, honest interview to a somewhat jaded community. I wrote this in response: Both Apple and Phil Schiller himself took a huge risk in doing this. That they agreed at all is a noteworthy gift to this community of long-time enthusiasts, many of whom have felt under-appreciated as the company has grown. […] Phil’s appearance on the show was warm, genuine, informative, and entertaining. It was human. And humanizing the company and its decisions, especially to developers — remember, developer relations is all under Phil — might be worth the PR risk. This started a ten-year run of interviews by Apple executives on The Talk Show every year at WWDC that proved to be great, surprisingly safe PR for Apple. No executive ever said something they shouldn’t have (they’re pros), no sensational or negative news stories ever resulted from them, and Apple’s enthusiastic fans and developers felt seen, heard, and appreciated. * * * For unspecified reasons, Apple has declined to participate this year, ending what had become a beloved tradition in our community — and I can’t help but suspect that it won’t come back. (A lot has changed in the meantime.) Maybe Apple has good reasons. Maybe not. We’ll see what their WWDC PR strategy looks like in a couple of weeks. In the absence of any other information, it’s easy to assume that Apple no longer wants its executives to be interviewed in a human, unscripted, unedited context that may contain hard questions, and that Apple no longer feels it necessary to show their appreciation to our community and developers in this way. I hope that’s either not the case, or it doesn’t stay the case for long. This will be the first WWDC I’m not attending since 2009 (excluding the remote 2020 one, of course). Given my realizations about my relationship with Apple and how they view developers, I’ve decided that it’s best for me to take a break this year, gain some perspective, and decide what my future relationship should look like. Maybe Apple’s leaders are doing that, too.
More in programming
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…
Our public postmortem for the incident on October 20th, 2026.
