This Week in Website Performance

by zhirayr | Aug 27, 2012

This Week in Website Performance is a weekly feature of the Monitor.Us blog. It summarizes recent articles about website performance. Why? Because your friends at Monitor.Us care.

---

 

 

When Milliseconds Are Not Enough: performance.now()

 

Author: Paul Irish.

This short article covers the performance.now() high resolution timer. Orders of magnitude more precise than Date.now() and tied to page load start rather than the Unix epoch it must be checked out by anyone looking for high precision time data for their pages. Returning this data to the server via XMLHttpRequestafter the onLoad event can provide consistent and easy to digest time data.

---

 

 

Improving ASP.NET Performance Part 16: Deployment Considerations

 

Author: Ard-Jan Barnas.

Physical deployment plays an important role in determining the performance and scalability characteristics of your application. Ten different best practices are offered for consideration covering many aspects of physical deployment.

---

 

 

Speed vs. security: Four ways that security solutions can cause performance problems

 

Author: Joshua Bixby.

Tradeoffs in the area of web performance are a continuous and necessary balancing act between delivering user requested content at an acceptable speed. The less obvious tradeoff is with behind the scenes action such as security. In this article the cumulative performance penalty of security, from user agent to server, is examined in four areas. While security is needed and direct change may be out of your control, this makes a compelling argument for why you need to optimize what is within your control.

---

 

 

Analysing performance data

 

Author: Philip Tellis.

LogNormal collects over a billion data points a month. In this article, some of the statistical methods they use to make sense of this data is gone over. You’d use these methods if you wanted to build your own Real User Measurement (RUM) tool.

According to Warren Gaebel, “the analysis techniques described in this article are relevant, but there’s one technique that is even more relevant (and simpler, too): Calculate the percentage of requests that are fully served in 2 seconds or less (bigger is better). Two seconds is the magic time after which users start getting antsy.”