Hello.

In this blog post, I share some findings from my exploration of HTTP Archive data. I discovered that a significant number of websites using manifest.json files are using the default configuration generated by Create React App. I plan to investigate this further and determine how prevalent default manifest files are across the web.

I needed higher resolution screenshots for an ML model to classify elements on a webpage, but the default Lighthouse screenshot was too compressed. So, I created a custom Lighthouse Gatherer using Puppeteer. This gatherer captures a full-page, high-resolution screenshot encoded as base64 and returns it along with the device pixel ratio. This was a fun little project, and the code is surprisingly concise. However, future Lighthouse versions may include higher-resolution screenshots, making this gatherer redundant.

This blog post explores how machine learning (ML) can enhance the developer experience. Inspired by Corridor Crew's use of ML in VFX, I initially brainstormed ways ML could automate tedious developer tasks, like accessibility improvements and performance optimization. I also considered ML's potential for generating layouts and images. The emergence of tools like GitHub Copilot and DALL-E-2 significantly impacted my thinking, especially regarding the future of software development and my role as a DevRel lead. Ultimately, the transformative power of GPT-Chat, demonstrated through its ability to generate webpage layouts and populate them with images based on simple prompts, left me questioning the future of my profession and considering the role I might play in training the next generation of AI tools.

This post explores whether developers are actively addressing issues highlighted by Lighthouse performance audits. By analyzing HTTP Archive data and tracking Lighthouse scores over time, we aim to uncover potential improvements. While directly correlating specific fixes to Lighthouse test failures is challenging, we can investigate trends and infer the impact of Lighthouse on web development practices. A key consideration is the evolution of Lighthouse itself, such as changes to CPU performance calculations, which may affect the comparability of results over time.

akachan.app is a Single Page Application (SPA) built for instant loading without using JavaScript on the client-side. Instead, all JavaScript resides in a Service Worker and is also executable on the server. This approach offers significant performance benefits but introduces challenges regarding third-party sign-in integration and data synchronization.

The MDN Browser Compatibility Report 2020 surveyed web developers to identify pain points in cross-browser compatibility. Layout and styling issues, especially with Flexbox and Grid, topped the list, along with challenges related to viewport units, scrolling on mobile, and achieving consistent form styling. Internet Explorer and Safari were frequently cited as problematic browsers. While JavaScript was initially flagged as a concern, interviews revealed that transpilers like Babel largely mitigate core language issues, shifting the focus to browser APIs and their inconsistencies. The report highlighted ongoing efforts to improve compatibility, including fixes for Flexbox and Grid in Chromium and WebKit, the transition to Chromium-based Edge, and a commitment to enhancing MDN's browser compatibility data.

I needed a streaming template engine for a web app I'm building that works in Node.js, the browser, and service workers. Existing solutions like flora-tmpl were great for Node.js, but I needed something smaller and compatible with all environments. So, I created whatwg-flora-tmpl (name pending), a lightweight library based on the WhatWG Streams API. It uses template literals, handles dynamic content, and even supports nested streams. The example code demonstrates how it can be used to render HTML responses piece by piece instead of waiting for all data, significantly improving perceived performance. It's particularly useful for responses generated in service worker fetch events. Big thanks to Matthew Phillips, the creator of flora-tmpl, which served as the inspiration for this project.

This blog post discusses how to integrate Webmentions into a statically generated website built with Hugo, hosted on Zeit. Static sites lack dynamic features like comments, often relying on third-party solutions. This post explores using Webmentions as a decentralized alternative to services like Disqus. It leverages webmention.io as a hub to handle incoming mentions and pingbacks, validating the source and parsing page content. The integration process involves adding link tags to HTML, incorporating the webmention.io API into the build process, and efficiently mapping mention data to individual files for Hugo templates. Finally, a cron job triggers regular site rebuilds via Zeit's deployment API, ensuring timely updates with new mentions.

Excited for the 6th Chrome Dev Summit! Join us for two days of exploring modern web experiences. Day 1: Web of Today - focusing on Speed, UI, and Capability in modern web development. Day 2: Web of Tomorrow - a look at what we're working on for the future, including deep dives into new technologies and opportunities to give feedback. See you there!

My QRCode scanner app in China ran into an issue offline: the camera wouldn't start due to a Google Analytics request hanging in the onload event. This highlighted a broader problem of render-blocking third-party assets. If these assets (like scripts) are critical, a slow or failed connection can prevent the page from rendering for over a minute while the browser waits for a timeout. This results in a blank screen for the user. This post explores the impact of render-blocking third-party resources on performance and how optimizing their integration can drastically improve the user experience, particularly in unreliable network conditions.

In this post, I share how I used Comlink to simplify the worker logic in my QRSnapper project, which aims to achieve 60fps UI and near-instant QR code detection using getUserMedia. The code now utilizes the Barcode Detection API within a Web Worker for efficient QR code scanning. If the native API is available, the code uses it; otherwise, it falls back to a polyfill. This approach keeps the UI responsive while offloading the processing to a separate thread, significantly improving performance.

A quick dive in to how to use Lighthouse to try and understand how users in a country might experience the web.

This blog post discusses the evolution of Progressive Web Apps (PWAs) since their inception in 2015. While PWAs offer numerous benefits like offline functionality, push notifications, and installability, the author observes that adoption hasn't been universal. Many developers and businesses misunderstand PWAs, sometimes treating them as separate products or focusing on single features like push notifications. The post argues that the focus should shift from "apps" to user experience. It proposes a set of principles for modern web experiences: discoverable, safe, fast, smooth, reliable, and meaningful. These principles aim to guide developers towards building better web experiences that naturally embody the core values of PWAs, benefiting both users and businesses.

We rebuilt Pinterest's mobile web experience as a PWA and the results after one year have exceeded our expectations. Weekly active users on mobile web have increased 103% year-over-year, with even higher growth in Brazil (156%) and India (312%). Engagement metrics also saw incredible growth: session length (+296%), Pins seen (+401%), and Pin saves (+295%). Perhaps most importantly, logins increased by 370% and new signups by a staggering 843% year-over-year, making mobile web our top platform for new signups. We've seen 800,000 weekly users add the PWA to their homescreen in under 6 months. Beyond performance, this new platform supports right-to-left languages and night mode, making it more accessible. We're proud of this user experience and excited to continue building on this foundation.

I recently had the pleasure of attending and thoroughly enjoying a live stream hosted by This Dot, featuring browser representatives from Brave, Beaker, Edge, Chrome, and Mozilla. They discussed recent updates and the future direction of browsers. Key highlights included Beaker Browser's innovative work on the distributed web, Edge's significant updates like Service Worker support and WebP integration, Mozilla's focus on Web Assembly, and Brave's progress with BAT. My team at Google is focused on Discovery, Speed & Reliability, UI Responsiveness, UX, Security, and Privacy. We're working to improve how developers build sites for headless services, optimizing for speed and reliability using metrics like TTI and FID, improving UI responsiveness with techniques like FLIP and Houdini, prioritizing user experience, and addressing security and privacy concerns in light of Intelligent Tracking Prevention and GDPR. It was also exciting to see a shared interest in bringing back Web Intents.

Feature Policy is a new web platform API designed to help developers maintain control over their web app's performance, security, and user experience. It allows developers to define policies that restrict access to certain features or modify the browser's default behavior. Examples include controlling autoplay, access to sensitive APIs, usage of fullscreen, preventing use of outdated APIs, and managing image sizes. Policies act as a contract between the developer and the browser, ensuring the developer's intent is followed even as the project grows and evolves. While adoption is a concern, its potential benefits for performance, security and privacy are substantial, especially if tied to incentives like app store listings.

Emscripten is a great tool for compiling to WebAssembly, but it can introduce unnecessary overhead. It's important to minimize the runtime size for any language compiled to WebAssembly. This post explores how to use Emscripten with a minimal runtime, avoiding excessive magic and focusing on efficiency.

A simple bookmarklet that will performance trace the current page and open in an hosted devtools instance

If we are to build HTML in Workers then we need some 'DOM' in them.

Summary of the challenges that I beleive we developers face every day.

How should Web and Chrome Developer Relations work?

I'm exploring the best way to load web components, focusing on how to include styles and templates without creating uncontrolled blocking requests. I've experimented with using a single JavaScript file that encapsulates everything, including styles and a dynamically created template element. This approach avoids external requests but raises questions about extensibility and best practices. Should we revive HTML imports, embrace ES modules, or find a common model for handling templates and styles? Is inlining templates a reasonable solution? I'm looking for community input on how to balance performance and developer experience when deploying web components.

In this follow-up post, I've revised my blog's Service Worker and caching strategy to address previous issues, particularly the Firefox incompatibility due to the use of waitUntil and a misunderstanding of cache.put. The updated strategy now correctly fetches from the network, caches the result, and serves content from the cache, falling back to the network request if not found. The code has also been improved for readability and reliability.

TL;DR - Went well. Lots to learn.

This blog post discusses the implementation of a Service Worker for my blog, with a focus on the caching strategy. I've chosen a "Stale While Revalidate" approach, which prioritizes speed and resilience. The Service Worker intercepts network requests and serves cached content if available, while simultaneously fetching updated content in the background. This ensures the latest version is available after one refresh. The post also details the requirements considered when choosing this strategy, including development simplicity and compatibility with the existing hosting setup (Hugo and NGINX). The provided JavaScript code snippet demonstrates the Service Worker implementation.

Web Developers. It's a long road ahead

I've spent this week in India doing more research about Web Development in India and how mobile is changing that. Publically at least it is not rosey, app development and app thinking is very high whislt building for the web with mobile in mind is very low.

The web is changing, we need to adapt

On the web determining and adapting to network type the user is on is incredibly hard. Until now.

I love (actual love) the `window.performance` API. Use it to help speed up your site.

What are the properties that make the web the web? How can we keep differentiating from native to stay relevant in a mobile world?

Ruby frustrations and performance have frustrated me for a long time. Experimented with Hugo and ported blog in about 3 hours

The fastest QR Code scanner on the web

A weekly run-down of some interesting things that I have found

A weekly run-down for Feb

It might be surprising. But it's all possible on the web.

A spent a while living just with web apps. Here is my report.

I recently used Page Speed Insights for Mobile to improve my blog's page load time and one of the key recommendations was to reduce render-blocking CSS above the fold. This led me to explore the concept of critical CSS, which is the minimum CSS required to render the initial view of a page. I developed a proof-of-concept tool (bookmarklet and devtools snippet) that analyzes the DOM and extracts the critical CSS by iterating through visible elements and using window.getMatchedCSS(). This tool helps identify unnecessary CSS, integrate into build processes for optimization, and potentially generate page-specific CSS files for improved performance. It currently has limitations, working only in WebKit/Blink, ignoring media queries, and not handling pseudo-elements.

I've been working on making html5rocks.com more mobile-friendly, focusing on reducing "Time to first read". The main culprit was the Table of Contents (ToC). My initial experiment with an offscreen ToC using CSS had cross-browser inconsistencies. Now, using existing JS, the ToC is fixed to the footer and toggled into view. I'm still exploring pure CSS solutions. Initially, I favored a small scrollable ToC at the bottom, but Paul Lewis suggested a full-screen ToC, which proved better. It minimizes distractions and clutter, provides more screen space for a readable, easily navigable ToC with larger touch targets and subtle hierarchy, even for long lists. The before/after screenshots demonstrate the improvement.

AppCache, while crucial for offline web apps, has significant issues. One major problem arises when integrating with APIs like registerProtocolHandler or registerContentHandler, which use query parameters. AppCache caches each unique URI, including query strings, separately. This is fine online, but offline, only previously cached URIs with specific query strings will work. Updating the app cache also causes every unique URL stored in the app cache group to be re-downloaded, even if they're not in the current manifest, potentially leading to server overload. This post highlights these issues and calls for better documentation and patterns for offline app development.

LocalStorage is a flawed API with poor querying, performance issues, limited storage, inconsistent event handling, and locking problems. Its only advantages are its simple semantics and browser support. Continued use of LocalStorage hinders the development of robust offline and client-side web apps. We should transition to IndexedDB, a superior alternative. I've demonstrated this by converting the BackboneJS TodoMVC example from LocalStorage to IndexedDB using Julien Genestoux's adapter. This involved a few configuration changes, highlighting the ease of adopting IndexedDB, which is our only viable path forward for client-side storage. Let's abandon LocalStorage and embrace IndexedDB to unlock the potential of offline web apps.

At Google IO, we were asked how to optimize Google Fonts for mobile performance. We focused on visual appeal by using mobile-friendly fonts like Droid Sans and Lato. To minimize requests, we leveraged App Cache, storing the CSS and font files for faster subsequent loads. While the Web Font API abstracts URLs, we found the font URLs within the CSS response and cached them. Although subsetting fonts is possible, we didn't use it given the potential character range needed for news articles.

During our Google IO talk on Mobile Web Development, we received a great question about handling AppCache storage limits in modern browsers. Our approach was straightforward: we primarily used AppCache for program code, including CSS and JS, along with the main page. Our application's size remained manageable, helped by minifying the JS in our production build using uglifyJS. Although we could have compressed the CSS, we prioritized ease of development. If space became an issue, our plan was to AppCache only form-factor specific code and assets, but thankfully, that wasn't necessary.

Tired of recursive DOM traversal headaches? Check out the DOM TreeWalker API! This powerful tool lets you efficiently navigate the DOM, filtering nodes as you go. It's perfect for tasks like finding specific text nodes or elements, highlighting content, or even building Chrome extensions. I've included a simple example of how to use TreeWalker to find and linkify Twitter usernames on a page. Give it a try and see how much easier DOM manipulation can be!

This blog

Day 2 of DevWeek was packed with insightful sessions. Niels Berglund's talk on ADO.NET v.Next and the Entity Framework highlighted the potential for simplifying database interactions by mapping database models to programmer-friendly models. Kelvin Henney's lecture on streamlined object-oriented analysis emphasized the importance of modeling the current system before designing solutions, using UML and Use Cases. Ingo Rammer's presentations on scalability and performance, and Windows Workflow integration, offered practical advice and cleared up some misunderstandings. I also had a chance to visit vendor booths, with Infragistics' XAML components and Dev Express's slick presentations standing out. Overall, the quality of the lectures has been excellent, but the vendor presence could be improved.

I've started testing Windows Live OneCare Beta 1.5.1785.18, switching from Windows Defender. While the Protection Plus firewall alerts are helpful, the TuneUp feature feels lackluster. It doesn't provide enough detail about its actions (like during defragmentation) and lacks advanced tuning options I'd expect, especially given Microsoft's SysInternals acquisition. It's good for automating basic maintenance, but the performance hit and limited functionality don't justify a paid subscription yet.

This post responds to Mike Champion's comment on my previous XLinq blog post. I clarify the XML file used (Wikipedia XML Abstract) and explain why I chose an XMLReader for its speed, especially when combined with custom data structures for a cyclic graph representation. XLinq's syntax and lambda expressions felt less intuitive for my task of converting XML into SQL statements. The project involves relating "title" elements with "sublink" entities, resulting in a complex graph structure not easily handled by XLinq without excessive data duplication and memory consumption. While XStreamingElement offers some improvement by avoiding redundant data scans, I desire deferred data loading for processing only necessary slices of the XML. This approach could handle selects, wheres, and counts efficiently in a single pass, and even joins with clever indexing. Defining a schema during XML iteration seems redundant when XLinq expressions already specify data requirements. Pre-loading entire XML documents into memory feels inefficient when only a small portion is used. I propose deferring data loading until needed, despite potential issues with repeated XDocument inspections. Ideally, XLinq should scale without forcing users to revert to less efficient methods due to data size limitations. I inquire about potential hard limits and scaling formulas related to XML document size in XLinq.

I'm highlighting a comment from Mike Champion, XLinq's program manager at Microsoft, addressing the issue of querying large XML files with XLinq. He discusses their current investigation into this problem and seeks feedback on how large XML documents are typically structured. Specifically, he asks about the structure of my 900MB XML file to better understand user needs and design appropriate solutions within XLinq. He mentions exploring options like a LINQ-queryable XmlReader or a lazy evaluation approach similar to XStreamingElement, while aiming for simplicity and avoiding dependencies on schemas or XPath. He's open to further discussion via his blog's contact form.

I've been experimenting with XLinq in C# 3.0, but I'm not impressed with its querying capabilities. It seems to require loading the entire XML document into memory, which caused problems when I tried to process a 900MB file. A simple XML reader was much more efficient for this task. I'd like to see an XLinq implementation that can process XML data in a streaming fashion, similar to SAX or XmlReader, to avoid memory issues. This would make it more practical for large documents. Perhaps XLinq already supports this, but I haven't found how. For now, it seems best suited for smaller files.

Code optimization is crucial, especially for critical sections of an application. Before jumping into optimization, profiling is essential to pinpoint actual bottlenecks. Relying on assumptions can lead to wasted effort on non-critical areas. While I haven't personally experienced the Java-specific examples mentioned in the linked article, the core message about profiling holds true regardless of the programming language.

I've updated my site's settings to display fewer posts on the homepage, resolving a recent issue I was having with Feedburner.

I've been exploring the Amazon Web Service API, comparing its REST and SOAP interfaces. Initial impressions suggest the REST API is significantly faster, especially compared to my experiences using the SOAP API with C# and Web References. However, it's worth noting that these observations aren't based on rigorous testing and the different environments (Windows Forms vs. a Linux server on a fast network) could be influencing the perceived performance difference.

I'm considering compressing Yahoo Search results from my proxy, as suggested in a Yahoo Developer Blog post. I'm unsure if it's easy, worthwhile, and where to implement it (client-side or proxy-side). I'll need to handle browsers without compression support. Any advice?

Quick update on the AJAX Tagger 2 development. Priority queues are working well, but might need some tweaking on queue numbers and polling intervals. Querying Technorati for tag counts is proving slow (around 2 seconds per query). Any tips on speeding this up, perhaps by limiting the number of blogs returned? Currently working on improving the related documents results, which now includes counts for all selected tags, not just the last search. Need to refine this area. More updates to come!

This post kicks off documenting the requirements for the next version of AJAXTagger. The goal is to create a successful application (by my definition) by outlining features across functional areas, UI/UX, client/server-side business logic, data access, and dependencies. Key features include easy journal tagging, related information retrieval (tags, articles, blogs, websites), diverse search provider integration, streamlined results presentation, image inclusion, and efficient article pulling/saving. The UI should minimize user effort, provide immediate feedback, and offer information hiding. Performance is crucial, targeting IE6/7 and Firefox, with emphasis on minimal server round trips, client-side optimization, and error handling. Data storage is preferably client-side, with external access optimized for speed and resilience. External dependencies include various search engines/services, while internal constraints involve limited server access and reliance on HTML, JavaScript, and XmlHTTPrequest.

In this part of my series on my first AJAX application, I discuss how my initial hopes for AJAX as a solution to bandwidth and UI problems, and for speed improvements, weren't fully realized. The first version, which incorporated Technorati stats and Yahoo's TermExtraction API, was slow due to sequential queries and Technorati's performance. I removed these features because I wanted a fully rendered page, which negated AJAX benefits. The next version will be fully asynchronous, with a request manager for trickle filling and background processing. Check out my AJAX Technorati Tagger to see what I'm aiming for.

Technorati is experiencing performance issues and support backlogs, impacting users like myself. Despite sending a support request weeks ago, I haven't received a response. While I appreciate Technorati's free service and its positive impact on my blog's readership, they need to address these support issues. I'll continue using the platform regardless.

I uninstalled Google Desktop Search Beta 2 because it was slowing down my computer. I kept the search index, though, just in case I decide to reinstall it later. My computer's speed is back to normal now.

Google Desktop Beta 2 is slowing down my computer significantly, affecting web browsing, IE7 tabbed browsing, and Blogger's editor. It also hogs CPU and makes Outlook integration and IMAP usage very slow. While the What's Hot widget and Gmail integration are nice, the lack of UK news and email ordering issues are disappointing. I plan to uninstall it soon.

This blog post explores the arguments for and against Binary XML. While some argue that Binary XML addresses XML's verbosity, text processing speed, and inability to store binary data, I question its practicality. I've found that XML's drawbacks can be mitigated through compression and concise tags. Binary XML raises concerns about readability, schema management, querying, and the potential for increased complexity. The post links to external resources offering further insights into the debate.