i

100

Adaptive Images detects your visitor's screen size and automatically creates, caches, and delivers device appropriate re-scaled versions of your web page's embeded HTML images. No mark-up changes needed. It is intended for use with Responsive Designs and to be combined with Fluid Image techniques.
Why? Because your site is being increasingly viewed on smaller, slower, low bandwidth devices. On those devices your desktop-centric images load slowly, cause UI lag, and cost you and your visitors un-necessary bandwidth and money. Adaptive Images fixes that.

skip_global_compinit=1

Add-ons provide many useful features and functions, but they can also cause Firefox to become slower. Some add-ons can even slow Firefox to a crawl and make it difficult to use for regular web browsing. If you think add-ons might be the reason Firefox is lethargic, check the list below for some of the biggest bottlenecks. And remember, for best performance you should disable add-ons that you no longer use regularly.

ab is a tool for benchmarking your Apache Hypertext Transfer Protocol (HTTP) server. It is designed to give you an impression of how your current Apache installation performs. This especially shows you how many requests per second your Apache installation is capable of serving.

The Site Speed report measures the page load time (latency) for a sample of pageviews on your website pages. It appears in the Content section of the Analytics reports. With this report, you can see which pages load the fastest and which ones are slower. You can also analyze your overall site speed along other important dimensions in order to learn how your site speed relates to a variety of factors. For example, you can view your site speed across the following categories:

Content—which landing pages are slowest?
Traffic sources—which campaigns correspond to faster page loads overall?
Visitor—how does latency compare by visitor type or geographic region?
Technology—does browser, operating system or screen resolution impact latency metrics?
Finally—and most importantly—you can take action to improve page load speed for slower pages and then track latency along these other dimensions to see if your actions resulted in desired improvements.

JavaScript to test each CSS class on a page and report which are hindering performance

Mobile tests - index

This is a mobile-optimised (i.e. style-less) link page to all my mobile pages.

Major changes may occur without warning. I advise you to save only this index page in your bookmarks.

Identification

I’m currently testing if StatCounter is good enough to use. What I really want to do is rewrite their detection script.

(Old mobile browser detect. Don’t use)

Browserscope tests

If you arrive here by mobile browser, please follow the link to the Browserscope test pages and let them run.

Browserscope
Current tests

Flash on Adobe’s product page
Simple WebGL test
@font-face test by Robert Nyman.
W3C Mobile Web Compatibility Test
HTML5 test
Ultra-simple canvas test
SVG test; London Underground map.
Touch action
Width tests
Zooming tests
clientX/Y, pageX/Y, screenX/Y
DOM speed
Drag-and-drop (iPhone, Android, Dolfin, desktop)
Multitouch drag-and-drop (iPhone)
Scrolling layer (iPhone, Android, Dolfin, BlackBerry)
jQuery Touch test page
Sencha test page
HTML Unknown
position: fixed
touchmove ghost click
Demo of position: device-fixed
Compatibility tables

The touch events
Widths and friends
Compatibility table (optimised for screen)
CSS compatibility table (optimised for screen)
Widget object compatibility table.
Phones of my Twitter followers (sortable table; doubles as medium-complex DOM test for test phones).
DOM Core module
CSS OM module (window width/height, offsets, getClientRects(), etc.)
Device properties list (not mine).
Old tests

Simple click test
Basic font CSS
Font sizes
Focus and blur events
Scroll event
Key events
Click event
Basic DOM
Basic Ajax
CSS @media handheld
Media queries
orientationchange, related events, and screen width and height - mobile
Basic event registration
Other tests

Acid 2 and Acid 3
Jake Archibald’s closure memory test
TaskSpeed tests
Cameron Moll’s mobile HTML and CSS tests
W3C compatibility test for mobile phones
Simon Pieters’s XHTML tests. Seems to be an older test; I don’t recognize any of the phone types he lists.
Mobile concurrency test by CloudFour.
Modernizr touch test

For all informations or contact, please go to http://eric.daspet.name/ (@edas_fr / @webperf_fr)

- Because of some abuse, I need to close write access from now on
- Please let me some times to recover deleted data
- If you want to help, please mail me to gain access. Please DO it if you are author of a library
- Authors of a library, please prefer fill your stuff in the "work in progress sheet", so we will have something clean at the end

DOM Monster: a cross-platform, cross-browser bookmarklet that will analyze the DOM & other features of the page you’re on, and give you its bill of health

Just install the DOM Monster bookmarklet, and use it on any web page or app. If there are problems, DOM Monster will point them out and even make suggestions on how to fix ‘em.

Learn more about the DOM Monster at mir.aculo.us/dom-monster

License
DOM Monster is is licensed under the terms of the MIT License, see the included MIT-LICENSE file.

Mike Chirico

Book: SQL Performance Tuning
Book: SQL Tuning
Book: The Art of SQL
Book: Refactoring SQL Applications
Book: Database tuning: principles, experiments, and troubleshooting techniques
Use The Index, Luke! - A Guide to database performance for developers
PostgreSQL (wiki) (PGsearch)

Performance Optimization
Quick PostgreSQL Optimization
Explain Analyze Interpreter
PostgreSQL Performance Tips
MySQL

Hidden Features of MySQL
Book: High Performance MySQL / Blog: High Performance MySQL
Blog: Xaprb (for MySQL DBAs)

// make an ajax request right away
$.ajax({
url: 'ajax.php',
success: function(data) {
$(document).ready(function(){ //<-- Hey Guys check this out!
for(var i in data) {
$('.app-container').append('<div>'+data[i]+'</div>');
};
});
}
});

souders: Awesome start to the 2010 Performance Calendar: Pat Meenan (http://webpagetest.org, now at Google) performance trends: http://bit.ly/i2vJkO

By default web browsers should cache content over HTTPS the same as over HTTP, unless explicitly told otherwise via the HTTP Headers received.

This link is a good introduction to setting cache setting in HTTP headers.

is there anyway to tell them it's ok to cache?

This can be achieved by setting the max-age value in the Cache-Control header to a non-zero value, e.g.

Cache-Control: max-age=3600
will tell the browser that this page can be cached for 3600 seconds (1 hour)

A cool new browser event just recently landed in the latest Firefox nightlies: an event announcing when the browser re-draws a portion of the page.

This particular event, called MozAfterPaint fires whenever something is drawn to the screen.

The event object contains two properties: .clientRects and .boundingClientRect, both of which refer to the result of the associated DOM methods.

In a nutshell, boundingClientRect gives you a single rectangle encompassing the entire area in which a paint operation could've taken place whereas clientRects gives you a number of rectangles, each encompassing an individual area that was drawn.

To test this I created a quick demo using CNN.com (only works in the latest Firefox nightlies).

John Resig posted today about a nifty new feature available in Firefox nightlies, browser paint events. He also posted an example script and bookmarklet called TrackPaint. He goes into greater depth in his post, so I won’t bother here.

I wanted something more “real-time” and closer to the Quartz Debug utility included with the Mac OS X developer tools (which essentially provides this feature for all of OS X), so I present my modified bookmarklet and code:

Nightly Tester Tools

This extension adds a few extras useful to those that regularly test nightly builds of Firefox, Thunderbird, Sunbird and Toolkit Seamonkey (Suiterunner).

Don’t forget that forcing an incompatible extension to install is risky. There are many cases where Firefox will stop working completely or behave incorrectly because an incompatible extension is being forced to work where the author never intended.

The following is a brief list of the extension’s features, for the full set of features please take a look at the features list.

* Extension compatibility fixing
* Titlebar customisation
* Build ID retrieval
* Screenshots
* Breakpad information
* Restoring tabs from previous session
* Leak log analysis

In addition, Thomas Robinson has created a very handy bookmarklet for debugging painting on a page you’ve loaded in the browser.

Due to popular demand, we’ve created a very experimental API for Firefox 3.5 to fire an event every time content is repainted. The event is is called MozAfterPaint and is fired at the document, bubbling up to the window. The event offers two attributes, clientRects and boundingClientRect, which tell you what was repainted, using the same objects and coordinate system as the getClientRects and getBoundingClientRect methods.

This is very useful for Firefox extensions and other “chrome” code that might be using the canvas.drawWindow method to capture the contents of windows. It might also be useful for tools like Firebug. But it’s also potentially useful for regular content, for example if you want to add some lightweight JS instrumentation to a page to measure what gets painted by Firefox, and when.

Caveats:

* This is Gecko-only. Do not use this for actual functionality on public Web pages – although I’m not sure why anyone would, so I don’t currently see this as a candidate for standardization.
* For security reasons, regular Web content is only notified of repainting that occurred in its own document – repainting caused by IFRAMEs is not reported to untrusted listeners attached to the IFRAME’s ancestors. (Listeners added by “trusted” content such as Firefox chrome are notified of all repaints to the window, however.)
* Currently the event might fire before the actual repainting happens. This shouldn’t matter much, and we’ll fix that at some point.
* If your event handler does anything that triggers repainting, such as changing the style of an element, you will probably trigger an infinite loop. The browser should stay responsive but your machine will contribute to global warming.
* Repainting of areas scrolled outside the viewport is reported, but repainting of areas scrolled outside overflow:auto elements and the like is not reported.
* Repainting in windowed plugins (i.e. most plugins in Windows and GTK) is not reported.

// This is the conclusion to my tests of determining the best way to cache images.
// I used apache access logs to determine when an image was actually requested from the web server.


// The following code, although not that elegant, works fine in IE6, IE7, IE8, FF3, Safari, Chrome, Opera

var _cacheImages = [];

function cacheImages(images){

$.each(images, function(index, val){

var image = new Image()
image.src = val;

_cacheImages.push( image );
});
};

// The following will NOT work in IE6:
function cacheImages(images){

$.each(images, function(index, val){

var image = new Image()
image.src = val;
});
};

// Also the following will NOT work in IE6 (sorry!)
function cacheImages(images){

$.each(images, function(index, val){

new Image().src = val;
});
};

// It seems you need to save a reference to the image object in order for IE6 to send a request to retrieve it

YSlow/PageSpeed only value reducing HTTP requests

Before I get into specifics about why I think LABjs brings something new and beneficial to the table, let’s tackle what I consider to be an interesting but perhaps misleading “truth”. I am firmly in a minority camp in my skepticism that reduction of HTTP requests is the only answer to the question of how to load a site more efficiently — actually, to be more accurate, how to load a site’s JavaScript more efficiently.

I bet that you are recalling the YSlow rules and the tried-and-true practice that concat’ing all your JS files into one file for production is the surest way to speed up your page loads. And you’re probably doubting my credibility because I would question such a fundamental “truth” as HTTP request reduction.

It is true that, especially for the largest sites on the internet (millions of page-views per month and more), the sheer volume of HTTP requests from a typical page profile (dozens of images, multiple style sheets, half a dozen JS files, etc) quickly overloads internet connections, server load-balancers, the user’s device, and even the browser itself. And anything you can do to reduce that overload will go a long way toward helping the site load with acceptable performance.

Sites like Yahoo and Google have taught us the basic principles of HTTP request reduction as an effective way to cut down on the overall page loading delays. For instance, consider Spriting to combine images External Link, CSS concatenation, and, yes, JavaScript concatenation. Some sites, like Digg, have even experimented with the extreme — inlining all page resources, even binary image data, into a single multi-part request! And just recently, we saw a proposal for Resource Packaging External Link as another way to combine multiple types of data into single responses for HTTP request reduction.

If you run a site that has well over 50 million page views per month (I sure don’t!), you probably would assert that this is the easiest and most effective page-load optimization. And I’d be hard-pressed to go up against the brightest and the best at the world’s largest web properties to suggest that it’s not true, at least at their page-view volume.

Inline <script> and <style> vs. external .js and .css — what’s the size threshold?

16th April 2010

When is it acceptable to use inline <script> elements? When is it better to use separate .js files? The same question can be asked about inline vs. linked CSS — where do you draw the line?

I had been pondering about this for a while, but while writing my post about optimizing the asynchronous Google Analytics snippet I was reminded I didn’t have a solid answer to my question yet. Is it worth it to separate the Analytics snippet into a separate .js file, so it can be cached? Or would that be a bad idea, considering the additional HTTP request needed to retrieve just a few hundred bytes of data?

Obviously, I wasn’t gonna figure it out by myself. So I decided to ask Kyle Simpson, creator of LABjs; and Billy Hoffman, of Zoompf fame. (Thanks, guys!)

Here’s what Kyle said (emphasis mine):

Stats.js
Javascript Performance Monitor

Flattr this

This class provides a simple info box that will help you monitor your code performance.

* FPS Frames rendered in the last second. The higher the number the better.
* MS Milliseconds needed to render a frame. The lower the number the better.
* MEM Mbytes of memory allocated. Make sure it doesn't keep incrementing. (Webkit-based browsers only)

Screenshots

We have dozens of best practices to improve performances. We also have common practices to accomplish daily tasks. This post is about the most used JavaScript ArrayLike Object, aka arguments, and its performances impact over basic tasks.

Inside every JavaScript function an arguments object is available containing all the parameters passed to the function.

function aha(a, b) {
console.log(arguments[0] === a); // true
console.log(arguments[1] === b); // true
}

aha(1, 2);
However, it's not a good idea to use arguments for the reasons of :

performance
security
The arguments object is not automatically created every time the function is called, the JavaScript engine will only create it on-demand, if it's used. And that creation is not free in terms of performance. The difference between using arguments vs. not using it could be anywhere between 1.5 times to 4 times slower, depending on the browser (more info and bench)

As for the security, there is the POLA (Principle of Least Authority) which is violated when one function A passes arguments to another B. Then a number of bad things can happen including:

B calls A through arguments.callee - something A never intended when calling B in the first place
B overwrites some arguments and causes A to misbehave
While in these scenarios B looks a little malicious, it can actually cause trouble unvoluntarilly. Consider this example that illustrates the second case (B changing values behind A's unsuspecting back)

Command line tool to upload files to Amazon S3 for static file hosting according to YSlow's best practices.

$gz = strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip') !== false ? 'gz.' : '';

Just when you thought you’d seen all the cool features of HTML5, I’m here to bring you yet another one. The internet is no longer about just websites; it’s about web applications. Often, our users are on portable or mobile devices, and they won’t always have access to a network. With HTML5’s Application Cache, you can provide them with all or some of the functionality they would have online, no matter where they go.