Perf Planet

Subscribe to Perf Planet feed
News and views from the web performance blogosphere
Updated: 2 hours 43 min ago

Choosing the APM System that is Right for You

Tue, 06/24/2014 - 06:52
In my role as technology evangelist I spend a lot of time helping organizations, big and small, make their IT systems better, faster and more resilient to faults in order to support their business operations and objectives. I always find it frustrating to “argue” with our competitors about what the best solution is. I honestly […]

The Widespread Effects of Facebook’s Latest Outage

Thu, 06/19/2014 - 12:54

Every day, hundreds of millions of users access Facebook, either through the site’s homepage, or through widgets and APIs on other sites. So when the social media giant experiences an outage in their service, the ripple effects spread far and wide.

That’s precisely what happened for roughly half an hour on Thursday, June 19 from 3:50 to 4:21 am EDT. This has been reported as their longest outage in four years, but as we uncovered back in 2012, there were two instances of even longer ones (each over two hours) within a 12-hour timeframe.

Many sites experience outages such as this, which usually only affect users who are trying to log in directly from their homepage. Yet because the Facebook footprint is so huge, it had a drastic effect on many other sites which use Facebook  APIs for their login tools or widgets for commenting systems, sharing platforms, etc. Thus, many of these sites’ user experience was impacted.

As the chart shows, during the times when Facebook was down, the document complete took significantly longer for several sites, often over 30 seconds (represented by the red dots at the top).

If a site does not use an asynchronous tag of Facebook, the document complete on the page will be delayed until the Facebook request times out. And if the page was not coded correctly, certain interactions or content might not have worked properly, with the user being impacted by the dreaded pinwheel (or spinning hourglass).

For example, popular music streaming site Spotify, which uses a Facebook API to allow users to log in and share their playlists, saw a variety of performance issues. Obviously no one could use the FB Login API, but the site’s background images did not load as well.

Of course, Spotify was not the only affected site, because the practice of implementing asynchronous coding for third-party tags is not very widespread despite years of web performance experts advocating for its usage. Generally, adoption of such a policy requires that the vendor tags support it (which Facebook does offer), but also implementation on the part of the sites using it.

The lesson, therefore, is a poignant one: When utilizing any third-party tags, particularly ones that have such a big effect on your end users interaction with your site, it’s imperative that you make sure the code is asynchronous with your own to prevent it from affecting your entire site’s performance.

All website developers need to take note of this. In order to avoid similar problems in the future, ensuring that you’re using the proper third-party tags is essential.

The post The Widespread Effects of Facebook’s Latest Outage appeared first on Catchpoint's Blog.

Understanding Application Performance on the Network – Part II: Bandwidth and Congestion

Thu, 06/19/2014 - 05:55
When we think of application performance problems that are network-related, we often immediately think of bandwidth and congestion as likely culprits; faster speeds and less traffic will solve everything, right? This is reminiscent of recent ISP wars; which is better, DSL or cable modems? Cable modem proponents touted the higher bandwidth while DSL proponents warned […]

Local Database Stores

Tue, 06/17/2014 - 11:57

Modern browsers have powerful new database capabilities that enable applications to store data locally, and perform advanced indexed queries without a network connection. Applications can be built with offline support without any disruption to data interaction, including searching. However, these database capabilities have traditionally been difficult to use across browsers since Safari only supports WebSQL (although version 8 is slated to include IndexedDB support), and Firefox and Internet Explorer only support the W3C’s IndexedDB API (Chrome supports both). And these two interfaces couldn’t be more different, making it very problematic to write applications that work offline on all the major browsers.

But, it is now much easier to access these database capabilities. By taking advantage of the consistency of the Dojo object store implementation, in version Dojo toolkit version 1.10, dojox/store now includes object store implementations for IndexedDB and WebSQL, along with a wrapper that will automatically delegate to the appropriate store implementation based on browser support. With a single common interface, you can retrieve, update, add, and delete objects, and even perform sophisticated queries in exactly the same way with the different underlying storage implementations.

Using the LocalDB store

The dojox/store/LocalDB module is the main, recommended entry store for accessing the local database. This store will automatically load the database implementation supported by the current browser, and the new store instance can be used like any other asynchronous store (you can also directly load the individual store implementations, if you want to target a specific technology). In order to use this store, we create a database configuration object that defines the version, name, and the schema of the properties of the objects that will go in each store. This is necessary so that the appropriate indices and table columns can be setup by each store. We need to define all of the stores that will be included in the database in the same configuration object, along with a version and any database name, so that the stores can properly version and update the database. Here is an example of a database configuration, where we define the database version (the name is optional) and each of the stores. We define the properties for each store’s objects. Our property configurations are simply empty objects, using the default configuration for each property.

var dbConfig = { version: 1, // this is required stores: { product: { // just declare the properties, will configure later name: {}, price: {}, inStock: {}, id: {} }, order: { quantity: {} } } };

Now that we have a database configuration, we can instantiate individual stores by providing the database config and the name of the store:

require(['dojox/store/LocalDB'], function(LocalDB){ var productStore = new LocalDB({ dbConfig: dbConfig, storeName: 'product' });

Now, we can interact with the store using the standard dojo/store API:

productStore.get(id).then(object){ // get an object by id // we could make changes and store the object: productStore.put(updatedObject); }); productStore.add(newObject); // add a new object Querying

A major focus of this implementation is to provide not only basic data storage facilities, but uncompromising, high-performance database querying, so applications can continue to provide fast, full access to data, even when a large amount needs to be stored locally. Let’s start with the basics. To query a database, we use the store’s query() method. The first parameter can be a simple object that defines the filtering constraints on the data to be retrieved. For example, to retrieve all the products that are in stock, we can write:

var results = store.query({ inStock: true });

And then we can iterate over the results using standard iterative methods:

results.forEach(function(object){ // called for each object });

Remember that queries are asynchronous, so forEach() will return before all the results are returned. The forEach() method will return a promise that can be used to wait for the completion of the query.

The query() method also accepts an optional second parameter that may be used to specify sort order and/or request a range of the data. For example, if we wanted to sort in-stock products by price and return the first ten products, we can write:

var results = store.query({ inStock: true }, { sort: [{attribute: 'price'}], start: 0, count: 10 });

When performing a query with a range, we may also want to check how many objects match the query (not just the 10 items within this range). This can be accessed through the results’ total property, which is a promise that resolves to the total count.

Filtering by property equality is useful for some queries, but what if we need to find all the in stock products with a certain price or lower? Typically, with the Memory store we might have defined a custom filtering function to accomplish more sophisticated querying that involves more than simple equality checks (or used more specific querying functionality of a server with the Rest store), but a filtering function can’t be efficiently used in conjunction with database indices. So the LocalDB stores define specific object filter structures to specify ranges or limits in a query. We can create our query by defining a comparison in our filter object. A comparison object is an object with a from or to property that specifies the lower or upper bound (respectively) of the returned objects. We could find products for $100 or less by writing:

var results = store.query({ inStock: true, price: { to: 100 } });

We can also use the excludeFrom and excludeTo flags to exclude the limits, so we could get just the items less than $100 by setting excludeTo to true (again, remember these flags are specific to the LocalDB stores, they don’t apply to other stores).

We can also filter properties using a trailing wildcard. This means that we could search for all the products that have a name that starts with a ‘sh’ (this is particularly useful for autocomplete widgets). We can do this by using a regular expression in our query:

var results = store.query({ price: /sh.*/ });

By including multiple properties on the query object, we specify multiple constraints that must ALL be satisfied to be included in the results. However, we may want do a union of selections, where one constraint can be satisfied OR another constraint can be satisfied. This can be done by using an array of objects, where the results will include objects that match the results of any of the objects’ constraints. For example, if we want to find any product with a name of “shoe’ or any product that was $100, we can write:

var results = store.query([{ price: 100 }, { name: 'shoe' }]); Indexing

Proper indexing is critical for maintaining good performance as databases scale. Local store implementations index all defined properties by default, ensuring that most queries can be executed reasonably quickly. When a query is executed, the SQL store will translate it to a SQL query which uses the indices, and the IndexedDB store will use one of the indices to find the objects. However, we may want to provide further optimization of the index usage. We can specify a preference on the indexed usage of each property to help guide the IndexedDB store towards which index to give highest priority. For example, we may want to give higher priority to the ‘name’ index than the ‘price’ index, if we expect more unique values from the former property values than the latter property values. We can configure these preferences by setting the preference values in the database configuration schema.

We may also want to disable indexing on some properties. For example, if we don’t anticipate filtering on a particular property, we probably don’t want to index it. It is also generally advisable to avoid indexing boolean values (IndexedDB doesn’t actually support querying by boolean values). We can turn off indexing by setting the indexed property to false. However, it is important that the schema include all properties that could be filtered on, even if they aren’t indexed, to ensure that the proper SQL table columns are created on WebSQL databases. We can now update our database configuration with our index preferences. Note that any time we change the database configuration, we also need to update the database version number:

var dbConfig = { version: 2, // we increment this for every update stores: { product: { name: { preference: 10 }, price: { preference: 5 }, inStock: { indexed: false } Indexing Arrays

It is possible to store arrays in property values, and search on these arrays. We can configure a schema to index each item in an array by setting multiEntry: true. Unfortunately, despite the IndexedDB specification including multiEntry, Internet Explorer does not support this feature (as of IE 11). On other browsers, however, you can use multiEntry, and then set the filter’s contains property to search for objects with an array containing those items:

var results = store.query({ tags: { contains: ['fun'] } });

In future versions, we hope to shim this capability for Internet Explorer.

Additional Store Wrappers

In addition to the local database stores, we have added two more store wrappers as part of the 1.10 release that can provide helpful extra functionality, particularly in combination with the local database stores.

Transaction Store Wrapper

The dojox/store/transaction store wrapper provides support for storing multiple operations in a transaction log, and eventually sending these to a server in a single commit. The transaction store extends the dojo/store/Cache, and takes a single options arguments where we can define the three stores to compose its functionality:

  • Master store – This store is the canonical source of data. Any uncached data is retrieved from the master store, and committed operations are ultimately sent here. This should be assigned to the masterStore property of the single options argument to the transaction store function. This is typically a JsonRest store or something similar, that can retrieve and deliver data to the server.
  • Caching store – Any new, updated, or removed data is stored in the caching store, so that data can be accessed before it is committed to the master store. This should be assigned to the cachingStore property of the options argument. This is typically a LocalDB or a Memory store that will be storing the data locally.
  • Transaction log store – This store records a log of the operations that are part of the current transaction. This will default to a Memory store but may be any client-side store. For example, local database stores might be used to persist operations while offline so they can be sent to the server later when connectivity is restored. This can be set in the transactionLogStore property of the options argument to the transaction store function. If you are using LocalDB stores, you would most likely want to use the LocalDB stores for both the caching store and the log store.

As an example, you can create a transaction store and start and commit a transaction like:

require([ 'dojox/store/transaction', 'dojox/store/LocalDB', 'dojo/store/JsonRest'], function(transaction, LocalDB, JsonRest){ var masterProducts = new JsonRest({ target: '/path/products/on/server' }); var localProducts = new LocalDB({ dbConfig: dbConfig, storeName: 'products' }); var transactionLogStore = new LocalDB({ dbConfig: dbConfig, storeName: 'transaction-log' }); var transactionalProductStore = transaction({ masterStore: masterProducts, cachingStore: localProducts, transactionLogStore: transactionLogStore }); var transaction = transactionalProductStore.transaction(); transactionalProductStore.put(someUpdatedProduct); ... other operations ... transaction.commit();

When you call commit(), the list of operations within the transaction are sent to the master store. By default the master store will execute the operations one-by-one, which may result in a series of requests to the server. If you wish to send data to the server in a single bulk operation, you may want to override the commit() method and define a mechanism to send a set of operations in a single request.

Priority Store Wrapper

The dojox/store/priority wrapper allows you to prioritize different store operations. Each store can have a default priority (set in the priority property), and individual operations can set a priority in the options argument (the second argument on each method). If multiple operations are concurrently executing, higher priority operations are executed next. This can be useful when background synchronization operations should be lower priority than user interface requests that require immediate response. The priority also defines the maximum number of operations that can execute concurrently. We can define a prioritized store by passing any asynchronous store to the wrapper:

var prioritizedStore = priority(originalStore);

Then, for example, we could execute a put operation:

prioritizedStore.put(someObject, {priority: 2});

By setting a priority of 2, we are indicating that this operation should go in the queue and be executed once there are 2 or less other operations executing. Note, that the priority store wrapper only works with asynchronous stores (synchronously stores execute all operations sequentially, so prioritizing wouldn’t be meaningful).

Conclusion

Together these store wrappers and implementations pave the way for building client-side applications with large local storage needs, while maintaining the same fast and sophisticated querying capabilities that we have learned to expect from the server. These storage capabilities are available through the convenient Dojo object store interface and can even be used with transaction logging and prioritization wrappers.

Learning more

We cover object stores and custom object store creation in depth in our Dojo workshops offered throughout the US, Canada, and Europe, or at your location. We also provide expert JavaScript and Dojo support and development services, to help you get the most from JavaScript, Dojo, and managing data efficiently within your application. If you’d like more information about having SitePen assist your organization with managing data efficiently with JavaScript, please contact us to discuss how we can help.

SitePen offers beginner, intermediate, and advanced Dojo Toolkit workshops to make your development team as skilled and efficient as possible when creating dynamic, responsive web applications. Sign up today!

Software Quality Metrics for your Continuous Delivery Pipeline – Part III – Logging

Tue, 06/17/2014 - 07:30
Let me ask you a question: would you say that you have implemented logging correctly for your application? Correct in the sense that it will provide you with all the insights you require to keep your business going once your users are struck by errors? And in a way that does not adversely impact your […]

How SACK Transmissions Improve Web Performance

Tue, 06/17/2014 - 03:00

Have you ever been in the middle of a phone conversation when, suddenly, there is a loss of signal and you can’t hear the person on the other end? What do you do next? Tell the speaker the start and end of the part of the conversation that you didn’t hear?

Well, computers communicate the same way with a TCP acknowledgement option called Selective Acknowledgement.

TCP protocol utilizes retransmissions when packets are lost or damaged. The original TCP acknowledgement system can’t handle multiple segments that are lost; it only acknowledges the last successfully received segment (before the loss), which then leads to the retransmission of data that has been already received by the receiver. This is obviously unnecessary, as it is a waste of time and causes network congestion that could’ve easily been avoided.

Here is where Selective Acknowledgment, or SACK, is most beneficial.

SACK is the method of resending only the necessary packets that never reached the receiver. In return, this improves the network’s performance, as fewer packets being retransmitted means a more efficient use of bandwidth. This is especially noticeable for connections using large TCP window sizes.

Without SACK, in the case of packet loss, the receiver would send a Duplicate Acknowledgment (DUP ACK) saying that it has only received data up to a specific segment. The sender would then resend all of the following segments of data, even if the receiver already received most of them. This would cause the receiver to get duplicates of some of the data, which is a waste of resources.

There are two types of SACK options. The first, the SACK-Permitted Option, is only present in the SYN packet and informs the both sides of the connection that it can receive the SACK option, which is a part of the initial connection.

Below is a graphic representation of SACK-permitted Option from RFC 2018; this shows the TCP kind and length relative to SACK that is sent during initial connection.

The second type of SACK is the Option format. This is when the receiver gives the sender detailed knowledge of which data has been received, which in return allows the sender to retransmit the missing pieces of data. This will be sent when there is lost data during a packet transfer.

Here we see a graphic representation of the Option format from RFC 2018.

 

 

 

 

 

 

 

 

 

 

 

Now take a look at this step-by-step explanation of the SACK process.

Step 1
Sender sends 10 segments of data, each containing 100 bytes of data, to a receiver starting with a sequence number of 1000.

Step 2
The receiver receives segments 1 through 4 and 6 through 10.

Step 3
The receiver then realizes that it is missing some data and sends a TCP ACK segment back to the sender, with a SACK option specifying a left edge of 1400 and a right edge of 1500.

Step 4
The sender then retransmits the 5th segment back to the receiver all by itself.

Step 5
The receiver receives the 5th segment and sends an acknowledgement packet to the sender informing them that they have now received all of the segments.

Now, let’s dig deeper into the concept of SACK with a real world example captured by Wireshark. Here’s an example of a SYN Packet showing the SACK Permitted Option with a Kind of 4 and a Length of 2. See the last two lines of the capture below.

This shows that my computer, the destination host, was letting the server, the source host, know that it has SACK enabled. Therefore, my computer knows that it can send the source host information on which portions of data it hasn’t received.

Now, here’s a later packet capture showing an actual SACK option with the left edge of the block of data not received specified as 18225, and the right edge of the block of data not received specified as 18620. See the last section of lines in the capture below:

As you can see, the receiver informs the sender of the specific bytes of data that were lost. With SACK, my router now knows that it only has to resend the sequence numbers 18225 to 18620, which saved time and resources as a result.

Some problems have arrived since the early adaptation of SACK. For example, it’s possible for a receiver to receive packets out of order due to some unknown network connectivity problems. This would result in the sender retransmitting the skipped packet out, which will slow down the rate of data delivery.

Since then, there has been an extension implemented to SACK which has introduced duplicate selective acknowledgment, or D-SACK, in RFC 2883. This allows the sender to handle duplicate packets in an identical fashion as SACK and solves the problem of the sender not knowing what type of packet to send.

Unfortunately, the SACK option is not mandatory and is only used when both ends of the TCP connection support it. Luckily, all major recent TCP stacks now support it.

SACK is important because it allows for a more robust packet retransmission, allowing the sender to be notified of what pieces of data made it to the receiver when there is packet loss and the retransmission of duplicate packets with D-SACK. This promotes less network congestion and faster retransmissions, thus allowing a faster rate of data delivery.

 

The post How SACK Transmissions Improve Web Performance appeared first on Catchpoint's Blog.

How to Monitor the Web Performance of Your Competition

Wed, 06/11/2014 - 05:45
You can spend MILLIONS every year improving and maintaining your application, but if you have no insight into your competition how do you know your place in the market and if all that investment has been worthwhile? “If you know the enemy and know yourself, you need not fear the result of a hundred battles. […]

Apple’s Nitro JavaScript Engine Available To All Apps

Tue, 06/10/2014 - 12:33

Share

Last weeks announcement that Safari would support SPDY wasn’t the only interesting piece of web performance news to come out of Apple’s WWDC 2014 event. Apple also announced that, with iOS 8, apps using the embedded web browser control, WKWebView, will gain full access to the powerful Nitro JavaScript engine. And this is a big deal.


JavaScript engines have been undergoing incredible advances over the last several years. As web apps are using more and more JavaScript, the need for faster and faster JavaScript engines grows. This is not an easy task.

Traditional JavaScript engines are fairly basic interpreters. This was by necessity. JavaScript is highly dynamic language, from its dynamically typed variables to its ability to modify itself, its code, and its environment at runtime. Optimizing JavaScript is are harder, can be a more complex problem the optimizing compiled languages like C or C++.

However, in recent years, browser creators have invested heavily in improving JavaScript execution speed by adopting many tricks and techniques from optimizing compilers such as multi-stage JIT compiling and AOT compiling. Enhancements such as JavaScript’s "use strict" strict mode helps reduces some of the flexibility of JavaScript, but enables more accurate analysis of the source code making it easier to apply traditional compiler optimizations. Mozilla’s asm.js project extends this concept even more, further restricting what JavaScript code can do to allow for better optimizations.

The results of all this work is very impressive. For example, Apple’s Nitro engine uses a 4 tier compiling strategy which can execute JavaScript 40 times faster than a traditional JavaScript interpreter!

Unfortunately, this super fast JavaScript interpreter was not available to iOS apps using the embedded web view UIWebView. Those applications had access to a JavaScript engine, but it was just a traditional JavaScript interpreter. Google’s Chrome browser on iOS uses UIWebView and so it could not execute JavaScript as quickly as the built-in Safari browser, which did have access to the fully optimized JavaScript engine. Many iOS apps use UIWebView and were not as fast as they could be due to this limitation. This also impact performance testing applications, like MobiTest, which could not take accurate performance metrics because they could not access the fully optimized JavaScript engine.

Thankfully this is changing. Apple has added the new WKWebView control. This means that future iOS applications will gain access to a optimizing JavaScript engine and all the benefits of faster code execution! iOS 8 should be released some time in fall of 2014.

If you are interested in how JavaScript engines work, then you must care about performance. Which me you you will just love. We find what performance problems your website has and tell you how to resolve them! Zoompf tests your web application for over 400 performance issues. You can get a free performance scan of you website now and take a look at our full product.

The post Apple’s Nitro JavaScript Engine Available To All Apps appeared first on Zoompf Web Performance.

Understanding Application Performance on the Network – Part I: A Foundation for Network Triage

Tue, 06/10/2014 - 08:02
As a network professional, one of your newer roles is likely troubleshooting poor application performance. For most of us, our jobs have advanced beyond network “health,” towards sharing – if not owning – responsibility for application delivery. There are many reasons for this more justifiable than the adage that the network is first to be […]

HTTP Archive – new stuff!

Sun, 06/08/2014 - 23:11
Background

The HTTP Archive crawls the world’s top 300K URLs twice each month and records detailed information like the number of HTTP requests, the most popular image formats, and the use of gzip compression. We also crawl the top 5K URLs on real iPhones as part of the HTTP Archive Mobile. In addition to aggregate stats, the HTTP Archive has the same set of data for individual websites plus images and video of the site loading.

I started the project in 2010 and merged it into the Internet Archive in 2011. The data is collected using WebPagetest. The code and data are open source. The hardware, mobile devices, storage, and bandwidth are funded by our generous sponsors:  GoogleMozillaNew RelicO’Reilly MediaEtsyRadwaredynaTrace SoftwareTorbitInstart Logic, and Catchpoint Systems.

For more information about the HTTP Archive see our About page.

New Stuff!

I’ve made a lot of progress on the HTTP Archive in the last two months and want to share the news in this blog post.

Github
A major change was moving the code to Github. It used to be on Google Code but Github is more popular now. There have been several contributors over the years, but I hope the move to Github increases the number of patches contributed to the project.
Histograms
The HTTP Archive’s trending charts show the average value of various stats over time. These are great for spotting performance regressions and other changes in the Web. But often it’s important to look beyond the average and see more detail about the distribution. As of today all the relevant trending charts have a corresponding histogram. For an example, take a look at the trending chart for Total Transfer Size & Total Requests and its corresponding histograms. I’d appreciate feedback on these histograms. In some cases I wonder if a CDF would be more appropriate.
Connections
We now plot the number of TCP connections that were used to load the website. (All desktop stats are gathered using IE9.) Currently the average is 37 connections per page.  
CDNs
We now record the CDN, if any, for each individual resource. This is currently visible in the CDNs section for individual websites. The determination is based on a reverse lookup of the IP address and a host-to-CDN mapping in WebPagetest.
Custom Metrics

Pat Meenan, the creator of WebPagetest, just added a new feature called custom metrics for gathering additional metrics using JavaScript. The HTTP Archive uses this feature to gather these additional stats:

Average DOM Depth
The complexity of the DOM hierarchy affects JavaScript, CSS, and rendering performance. I first saw average DOM depth as a performance metric in DOM Monster. I think it’s a good stat for tracking DOM complexity. 
Document Height
Web pages are growing in many ways such as total size and use of fonts. I’ve noticed pages also getting wider and taller so HTTP Archive now tracks document height and width. You can see the code here. Document width is more constrained by the viewport of the test agent and the results aren’t that interesting, so I only show document height. 
localStorage & sessionStorage
The use of localStorage and sessionStorage can help performance and offline apps, so the HTTP Archive tracks both of these. Right now the 95th percentile is under 200 characters for both, but watch these charts over the next year. I expect we’ll see some growth.
Iframes
Iframes are used frequently to contain third party content. This will be another good trend to watch.
SCRIPT Tags
The HTTP Archive has tracked the number of external scripts since its inception, but custom metrics allows us to track the total number of SCRIPT tags (inline and external) in the page.
Doctype
Specifying a doctype affects quirks mode and other behavior of the page. Based on the latest crawl, 14% of websites don’t specify a doctype, and “html” is the most popular doctype at 40%. Here are the top five doctypes.

Doctype Percentage html 40% html -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd 31% [none] 14% html -//W3C//DTD XHTML 1.0 Strict//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd 8% HTML -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd 3%

Some of these new metrics are not yet available in the HTTP Archive Mobile but we’re working to add those soon. They’re available as histograms currently, but once we have a few months of data I’ll add trending charts, as well.

What’s next?

Big ticket items on the HTTP Archive TODO list include:

  • easier private instance - I estimate there are 20 private instances of HTTP Archive out there today (see here, here, here, here, and here). I applaud these folks because the code and documentation don’t make it easy to setup a private instance. There are thousands of WebPagetest private instances in the world. I feel that anyone running WebPagetest on a regular basis would benefit from storing and viewing the results in HTTP Archive. I’d like to lower the bar to make this happen.
  • 1,000,000 URLs – We’ve increased from 1K URLs at the beginning four years ago to 300K URLs today. I’d like to increase that to 1 million URLs on desktop. I also want to increase the coverage on mobile, but that’s going to probably require switching to emulators.
  • UI overhaul – The UI needs an update, especially the charts.

In the meantime, I encourage you to take a look at the HTTP Archive. Search for your website to see its performance history. If it’s not there (because it’s not in the top 300K) then add your website to the crawl. And if you have your own questions you’d like answered then try using the HTTP Archive dumps that Ilya Grigorik has exported to Google BigQuery and the examples from bigqueri.es.

SPDY coming to Safari, future versions of IE

Fri, 06/06/2014 - 09:55

Share

SPDY, the next generation web transport protocol, continues to gain ground and acceptance. I’ve been watching SPDY very closely and writing extensively about it for the last few years. Last year I broke the news that Facebook had adopted SPDY, ahead of other tech news sites like Wired. Zoompf has also built SPDYCheck.org, to help developers test their website for SPDY support and help them resolve any problems. This past week saw two great news announcements about SPDY that I want to share.

Internet Explorer commits to SPDY. Again.

I know what you are thinking. Didn’t Microsoft announce a year ago that IE would adopt SPDY? In fact they did. Microsoft announced in spring of 2013 that IE would support SPDY. And it was fantastic news at the time. Unfortunately, as I have discussed before, Microsoft only ships new features when it ships a new major version of IE. All those monthly updates to IE? They are only security patches and provide no new features, functionality, or support for new web standards.

When IE11 finally shipped in October 2013, its promise to deliver SPDY had diminished somewhat. IE11 does support SPDY, but only on Windows 8.1. IE11 on Windows 7 does not support SPDY.aspx#spdy3). So, while IE11 has a market share of 17% right now, all of those installs of IE11 can’t use SPDY. Can we figure out what percentage of IE11 can use SPDY? We can try!

IE11 runs on Windows 7 and Windows 8.1 (as well as a version of Windows Server, which accounts for so little web browsing traffic we will ignore it). IE11 does not run on Windows 8. Lets look at the OS market share numbers from NetMarketShare:


Windows 7 has 50% market share, and Windows 8.1 has 6.35%. We know that 100% of Windows 8.1 installs have IE11, but we don’t know the percentage of Windows 7 users that have installed IE11. If we conservatively estimate that 50% of Windows 7 users have IE11 (reasonable given that Microsoft has been automatically upgrading Windows 7 users to IE11 via Windows Update), then that means 20% of IE11 users are on Windows 8.1, and 80% are on Windows 7. In other words, we conservatively estimate that only 20% of IE11 installs can actually communicate with SPDY.

Needless to say, the promise of SPDY support in IE has fallen short somewhat. Today, the vast majority of IE11 users cannot use SPDY.

Luckily this is set to change. Last week Microsoft updated its IE status website and now lists HTTP/2 support as “in development”. As we know, HTTP/2 uses SPDY as its base. Presumably this means the next version of IE will support SPDY and HTTP/2. This is great news. IE is doubling down on its commitment to SPDY. In additional to supporting SPDY and HTTP/2 in new versions, as time passes, the market share numbers of Windows 8.1 should (hopefully) increase, meaning more IE users can take advantage of SPDY.

Apple announces SPDY support in Safari 8

Chrome, Firefox, and Opera have all supported SPDY for a number of years. As we have seen, IE is making slow yet steady progress s well. Safari has long been the last major browser without SPDY support. All that changed on Monday at Apple’s WWDC 2014 event.


Apple announced that its next version of Safari will support SPDY. In fact, of the 6 new features Apple chose to highlight SPDY support was #2, behind only WebGL. Safari 8 will ship with OS X Yosemite, which is “coming this fall.” This means that, by the end of 2014, all major browsers will support SPDY!

The post SPDY coming to Safari, future versions of IE appeared first on Zoompf Web Performance.

You Just Have to Be There: Delivering Content Within Mainland China

Thu, 06/05/2014 - 03:00

While many think of Hong Kong as just another part of China, it has a separate designation as a “Special Administrative Region” of the PRC, making it a semi-autonomous entity on the global stage. This distinction isn’t just political; it carries over to internet connections as well.

As such, we have been preaching that in order to deliver a great user experience inside Mainland China, you must deliver from inside the mainland itself, rather than from Hong Kong or other APAC locations.

We have been investing heavily in our node infrastructure in China, with 15 nodes on the mainland (plus an extra three in Hong Kong), and 15 more coming in a few days. These nodes rely on a Command and Control (C2) system based in both Hong Kong and Singapore. But with our node growth, we have noticed some performance and availability issues to reach that C2 system.

While many think of Hong Kong as just another part of China, it has a separate designation as a “Special Administrative Region” of the PRC, making it a semi-autonomous entity on the global stage. This distinction isn’t just political; it carries over to internet connections as well.

So we decided to investigate the build-out of our new C2 for our nodes inside China, and in Beijing in particular. The systems came online this week and we started testing the performance…the results are just staggering!

Here is a side by side view of the test going to HK vs. the test to China (Averages).

Here is a side by side view of the test going to HK vs. the test to China (Median).

As you can see, all of the key metrics went down: connection time, first byte received, and response time!

Here is another view by City:

Not only the performance improved, but the reliability as well, no more spikes and weird performance behavior we used to see when going out of China during peak hours.

Response time metrics by hour of the day (China Standard Time)

Delivering great performance inside China requires having a delivery and dns footprint inside (we decided not to rely on dns anymore)

欢迎到中国

Mehdi – Catchpoint

The post You Just Have to Be There: Delivering Content Within Mainland China appeared first on Catchpoint's Blog.

John Oliver Brings Down the FCC’s Website

Wed, 06/04/2014 - 15:31

As you likely already know, net neutrality has been a pretty hot topic in Washington and around the country (including the Catchpoint offices) over the past several months, with the FCC unveiling a new proposal last month which would regulate the way that ISPs work with companies who provide content.

Not surprisingly, the issue caught on with comedian John Oliver (formerly of the The Daily Show) on his new weekly HBO show, Last Week Tonight this past Sunday, as he uproariously dissected the issue from both a business and consumer perspective.

The most notable moment in that clip, however, comes around the 10:50 mark, when Oliver implores all the internet commenters out there to go take up the FCC’s invitation for feedback by logging onto its site to share their opinions on the issue.

The result was not only immense, but fabulously ironic.

Over the following two days, more than 45,000 comments were made on the FCC’s net neutrality feedback page, causing so much server traffic that they crashed the site.

To repeat: In expressing their outrage over the FCC trying to regulate how ISPs are allowed to deal with high-bandwidth sites, net neutrality advocates overloaded the FCC’s servers with too much bandwidth.

Even those who are against any sort of internet regulation have to admit that’s pretty funny.

The post John Oliver Brings Down the FCC’s Website appeared first on Catchpoint's Blog.

Fixing Real Problems with Real User Monitoring

Wed, 06/04/2014 - 06:54
Thanks to our guest blogger Derek Abing and his co-author Brian Perrault – both System Engineers with a leading insurance company focusing on application performance. More details about their work at the end of this blog. In production support it is often hard to correlate what might be happening on local servers with what users […]

Adaptive vs. Responsive Web Design: Which Is Right for Your Site?

Mon, 06/02/2014 - 10:20

Given the prominence of mobile web browsing, the practice of having multiple versions of a site (under multiple URLs) to accommodate all of the different mobile devices out there is already on its way out. The Responsive Web Design (RWD) revolution is in full effect, and in fact is already being expanded upon.

By tweaking a site’s CSS code, RWD allows the pages to adjust to the operating system and layout of any browser, be it desktop or mobile. The advantages of being able to implement such a technique are vast:

  • Consistency throughout the different platforms, creating easier navigation and a better user experience
  • Dramatic reduction in development time and costs by only having to create and maintain one URL as opposed to several
  • Improved SEO by streamlining all pageviews through one URL
  • More effective social sharing

However, RWD is not without its drawbacks, the most significant of which is load time. Since images and other high bandwidth features are simply scaled down rather than resized or eliminated outright, elements which may not be vital to user experience can cause poor performance.

Hence the rise of Adaptive Web Design (AWD) as an alternative to RWD. AWD maintains the end goal of creating a site which is applicable to a variety of different mobile platforms and layouts, while improving end user experience through better performance.

Rather than a scalable version of the same site, AWD allows the server to determine how to optimally render pages based on the user’s platform by only delivering elements which are necessary for the experience on that specific device and operating system. Images are resized, elements like JavaScript or Flash may be discarded entirely, and ads can be adjusted, culminating in the user getting a much different version of the site than they would if accessing it from a desktop browser.

As you can see in this example of an adaptive site, Ask.com has greatly altered the layout and functionality of their mobile platform, obviously aware that high-res images and additional content are not as important to their mobile users as fast response times.

With a responsive site like Microsoft.com, however, the mobile experience is more interactive and visually-based, as they know that their mobile users are there to check out their product rather than hunt for quick information or to buy goods.

This highlights the other significant advantage to an adaptive approach. Because it allows for such a different experience between the mobile and desktop versions, sites that want to deliver a different experience for their mobile customers (i.e. eCommerce, airlines, etc.) can do so without sacrificing quality in either version. It can also be tacked on to an existing site, whereas RWD requires rewriting all the original HTML code in the back end.

However, even with the latest advancements in AWD at your disposal, your mobile site’s performance can still be dragged down by the burden of too much data. If a mobile site is transmitting over 500K of content, it’s going to result in slow response time, which will only get worse when factoring in outside factors like network strength and latency.

To test this theory, we selected 15 examples of Adaptive and Responsive websites out of the Alexa Top 100 rankings (US), and tested the response times using Catchpoint’s 4G and last mile nodes across five major U.S. cities to see how the greater amount of data in responsive sites leads to higher latency. Unsurprisingly, the mobile response times showed a significant variance between AWD and RWD sites:

As you can see, the webpage response times (which measures how long it takes for all of the data on a site to be downloaded) are significantly faster for AWD sites when accessed on wireless networks due to the significantly smaller amounts of data which make up adaptive sites (an average of ~791 KB, compared to ~1.2 MB for responsive sites).

That changes, however, when we look at the times for desktop performance, as there is far less of a difference in the amount of data being transferred.

Business owners should consider putting themselves in their customers’ shoes when accessing their site from a mobile device. Most mobile users are operating on data plans with limits, so having a mobile site which transmits a large amount of data essentially limits the amount of times a user can access your site over the course of their billing cycle (before they start paying overages, anyway).

For example, let’s say you have a standard 1 GB data plan and use half of it on things like sending email, streaming music, posting photos to Facebook, etc. That allows for 500 MB of data, which means that you’d for a responsive site like Microsoft, which transmits ~1.45 MB of data, you’d be allowed roughly 345 pageviews per month. But for adaptive sites like Ask (~100 K) or USA Today (~730 K), that would mean 5,000 and 685 pageviews, respectively.

Determining whether your site should be using a Responsive or Adaptive design structure really depends on the needs of your users. If the goal of the site is to deliver a lot of content to users and doesn’t have much in the way of advanced functionality, then Responsive is probably the best way to go. In other words, if most of your users will be accessing your site from a desktop browser and won’t lose anything by using it on a mobile device, it’s the simplest – and cheapest – option.

However, if mobile is going to be your primary focus while maintaining eCommerce or other complex capabilities, and you can afford the investment of additional time and money to create it, then Adaptive would be the best route.

The post Adaptive vs. Responsive Web Design: Which Is Right for Your Site? appeared first on Catchpoint's Blog.

A Fond Farewell To OpTier

Thu, 05/29/2014 - 06:35
The Darwinian laws of software evolution have struck once again. As was reported last week by Gartner, OpTier is calling it quits. It’s no secret that OpTier and Compuware have competed fiercely over the years. But the disappearance of a well-known player in the Application Performance Management (APM) market is nothing to rejoice about. OpTier […]

Google Adds Ability for Better Performance Metics

Wed, 05/28/2014 - 09:58

Share

Last week, Google published a post entitled Understanding web pages better on Webmaster Central blog. The post discussed how the web has evolved from static HTML pages to richer content with lots of JavaScript and CSS and what this evolution means for Google’s web crawlers. But, as we will present here, Google’s post also has some interesting implications on the future of web performance and SEO.

Technologies such as single page apps, client-side template engines, and offline capabilities have helped move the construction and generation of content to the client. Instead of getting an HTML page with content to index, some applications are getting a simple HTML shell, and use JavaScript to fetch, format, and place content into the DOM. This creates a problem: how to index this dynamic content? Google’s solution is to make their crawlers work more like web browsers, by downloaded external resources and by executing client-side code. From the post:

In order to solve this problem, we decided to try to understand pages by executing JavaScript. It’s hard to do that at the scale of the current web, but we decided that it’s worth it. We have been gradually improving how we do this for some time. In the past few months, our indexing system has been rendering a substantial number of web pages more like an average user’s browser with JavaScript turned on.

Google enhancing the capabilities of their crawler to be more like a browser certainly helps their indexing goal. However, I believe will have an interesting fringe benefit as well: improving the performance metrics used in search engine rankings.

Performance’s relationship with SEO

While Google has announced many times that web page “performance” was a factor in its ranking algorithms, no one outside of Google knew what aspects of web performance Google used, and how much impact those metrics had on ranking. So, in August 2013, we worked closely with SEO researchers at Moz to try to determine what web performance metrics are used in search rankings, and what their effects were.

To answer these questions, Zoompf and Moz captured the top 50 search results for 2000 diverse search queries. We analyze those 100,000 pages for over 40 different performance metrics using a large cluster of WebPageTest instances. The full details of our approach and the results are beyond the scope of this post. I highly encourage you to review our research findings.

Our data showed no relationship between conventional metrics for web performance like page load time or document render time and search ranking. In fact, the only metric to with a correlation to ranking was the Time To First Byte (TTFB). This metric captures how long it takes your browser to receive the first byte of a response from a web server when you request a particular URL. In other words, TTFB encompasses the network latency of sending your request to the web server, the amount of time the web server spent processing and generating a response, and amount of time it took to send the first byte of that response back from the server to your browser.

In our conclusions, we wrote (emphasis added):

[Our] data shows there is a correlation between lower time-to-first-byte metrics and higher search engine rankings. This means that, despite conventional wisdom, it is back-end website performance and not front-end website performance that directly impacts a website’s search engine ranking. The question is, why?

TTFB is likely the quickest and easiest metric for Google to capture. Google’s various crawlers will all be able to take this measurement. Collecting document complete or fully rendered times requires a full browser. Additionally, document complete and fully rendered times depend almost as much on the capabilities of the browser loading the page as they do on the design, structure, and content of the website. Using TTFB to determine the “performance” or “speed” could perhaps be explainable by the increased time and effort required to capture such data from the Google crawler. We suspect over time, though, that page rendering time will also factor into rankings due to the high indication of the importance of user experience.

Now that sounds familiar! Our conclusions were that more sophisticated performance metrics weren’t used because they would be difficult to capture at scale. In fact, Google’s post last week specifically mentioned that emulating a browser and executing JavaScript is “hard to do that at the scale of the current web, but we decided that it’s worth it.”

Google’s effort to enhance their crawler to more closely behave like a browser means they can also collect richer performance metrics like window.onload, DocumentComplete, and fully rendered. This paves the way for Google to use more meaningful performance metrics than TTFB in its ranking algorithm.

The future of performance and SEO

As crawlers are capable of taking richer performance metrics, we expect to see a performance take on a larger role in search engine rankings. We already know how a fast website improves the user experience, revenue, and conversion rates. The addition of stronger ties between performance and search ranking truly means that a “speed is a feature”, and not a secondary and optional objective.

If you are interested on how performance impacts SEO, you will love Zoompf. Zoompf analyzes yours website for over 400 performance issues and tells you how to be faster. You can get a free performance scan of you website now and take a look at our full featured performance product today!

The post Google Adds Ability for Better Performance Metics appeared first on Zoompf Web Performance.

Web Service Monitoring 101: Identifying Bad Deployments

Wed, 05/28/2014 - 05:55
Have you ever deployed a change to production and thought “All went well – Systems are operating as expected!” but then you had to deal with users complaining that they keep running into errors? We recently moved some of our systems between two of our data centers – even moving some components to the public […]

Pages