Content tagged “performance”

  1. Request Map Generator

    Submit a URL to generate a node map of all of the requests on the page. Rapidly identify what third-parties are on your site, where your transmitted bytes are coming from and how slow your domains are!

    I can’t believe I haven’t saved this useful website before, but it made its way back into my timeline via Jeffrey’s notes from An Event Apart Chicago. Learn more about Request Map Generator by reading Simon Hearne’s introductory blog post.

  2. I Used The Web For A Day On A 50 MB Budget — Smashing Magazine

    The latest in Chris Ashton’s series of “I Used the Web for a Day…” articles is a doozy of a read chock-full of facts, figures, tips, and tricks.

    The cost (in dollars) of mobile and broadband data plans globally varies wildly and Chris’ post goes deep on how the cost (in page weight and in dollars) of our work building for the Web impacts users around the world. Chris concludes:

    We don’t have the power to change the global cost of data inequality. But we do have the power to lessen its impact, improving the experience for everyone in the process.

  3. Answers to Questions About Performance — Google Developers — Medium

    Google’s Paul Lewis answers the same questions that Matt Gaunt received (and that I previously linked to). Paul’s focus on the user and their experience of our work resonates strongly with me and is something I harp on quite frequently.

    I think performance, accessibility, and security share some traits: they can’t be retro-fitted to a project, they’re often thankless tasks, and they’re only notable by their absence. They’re all, however, the bedrock of a good user experience, onto which you can layer high quality designs and interactions.

    Paul also cites one of my favorite documents, the W3C’s HTML Design Principles:

    In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

    Truth.

  4. Web Development is a Balancing Act — Medium

    Google Chrome Developer Advocate Matt Gaunt publicly answers some Web performance-related questions he received. Many of the questions have to do with frameworks, a topic of great interest to me.

    A slow website, no matter how it’s built, means someone didn’t notice, didn’t care or couldn’t fix the problem. That doesn’t mean the framework or tools used to build it is the problem, it could be the way those tools have been used.

    It could also be that the chosen tool isn’t the best solution to the problem at hand.

  5. How Changing WebFonts Made Rubygems.org 10x Faster

    Nate Berkopec’s article is chock full of useful information, but I was particularly taken by his framing of a developer’s job (emphasis his):

    As developers, our job isn’t to tell the designers “Hey, you’re dumb for including over 500KB of WebFonts in your design!”. That’s not their job. As performance-minded web developers, our job is to deliver the designer’s vision in the most performant way possible.

    Equally interesting, but more technically-focused, is the rundown of how Google Fonts takes advantage of the unicode-range property to deliver smaller fonts.

    The unicode-range property describes what characters the font supports. […] By telling the browser what characters the font supports, the browser can look at the page, note what characters the page uses, and then only download the fonts it needs to display the characters actually on the page.

    Brilliant. I switched to serving fonts from Google and trimmed 45–70 kilobytes from my homepage. Your mileage may vary, but… not bad.

  6. Mobile Web Stress: Understanding the neurological impact of poor performance

    Slides from Tammy Everts’ 2013 presentation on the neurological effects of poor performance on our websites’ visitors reveal some startling facts. Right out of the gates, Tammy cites a 2010 EEG study of users navigating a site on a connection throttled from 5MB to 2MB. The study found that participants had to concentrate up to 50% harder and reported a negative brand association afterward.

  7. Yellow Lab Tools

    A cool new front-end performance analysis tool from Gaël Métais that offers code improvements.

    This is done by loading the webpage via PhantomJS and collecting various metrics and statistics with the help of Phantomas. These metrics are categorized and transformed into scores. It also gives in-depth details so developpers can correct the detected issues.

    Yellow Lab Tools dovetails nicely with more popular performance tools like WebPageTest.

  8. The future of loading CSS - JakeArchibald.com

    Chrome’s about to change how it handles <link rel="stylesheet">. This is big news and Jake’s got the rundown:

    The plan is for each <link rel="stylesheet"> to block rendering of subsequent content while the stylesheet loads, but allow the rendering of content before it. The stylesheets load in parallel, but they apply in series. This makes <link rel="stylesheet"> behave similar to <script src="…"></script>.

    It’ll take some getting used to sprinkling <link rel="stylesheet"> throughout a page’s <body>, but the performance benefits (coupled with HTTP/2) will be worth it.

  9. Chunked transfer encoding in Rails (streaming)

    Using the Transfer-Encoding: chunked header, the server will send chunks of the rendered page back to the browser so in the case of Rails, it starts with the layout and sends out the <head> part including assets like js and css.

    Chunked transfer encoding is a great way to improve page performance for the parts of your application that require time-consuming database queries. The Rails-level changes are straightforward, but unfortunately not all Ruby web servers support the feature (looking at you, Puma).

  10. Notes from “Designing for Performance”

    If you build websites for a living or work with people who do, stop what you’re doing and get yourself (or your team) a copy of this book.

    Published on .

  11. Abandoning Google Analytics

    As of today, I've removed Google Analytics from this site. Here's why.

    Published on .

  12. JavaScript dependency management and concatenation: Sprockets

    Sprockets is a Ruby library that preprocesses and concatenates JavaScript source files. It takes any number of source files and preprocesses them line-by-line in order to build a single concatenation. Specially formatted lines act as directives to the Sprockets preprocessor, telling it to require the contents of another file or library first or to provide a set of asset files (such as images or stylesheets) to the document root. Sprockets attempts to fulfill required dependencies by searching a set of directories called the load path.

  13. Jammit: Industrial Strength Asset Packaging for Rails

    Jammit is an industrial strength asset packaging library for Rails, providing both the CSS and JavaScript concatenation and compression that you’d expect, as well as YUI Compressor and Closure Compiler compatibility, ahead-of-time gzipping, built-in JavaScript template support, and optional Data-URI / MHTML image embedding.

  14. Code: Flickr Developer Blog » Building Fast Client-side Searches

    Yesterday we released a new people selector widget (which we’ve been calling Bo Selecta internally). This widget downloads a list of all of your contacts, in JavaScript, in under 200ms (this is true even for members with 10,000+ contacts). In order to get this level of performance, we had to completely rethink how we send data from the server to the client.