EcoConception Logicielle

You can simulate the elimination of JavaScript on web pages with Web Page Test. By blocking the loading of JavaScript you can approximate the effect of removing or deferring all of the JavaScript on the page or replacing it with CSS behavior on start render times. Start render and page load times can be increased significantly by combining or eliminating JavaScript files, and replacing them with CSS equivalents.

This article summarizes the report and gives major findings related to web performance including:

Many of these external resource delays are preventable. The solution is to periodically cache the resource locally on your server and serve it locally. You can use a CRON script to periodically copy the external resource over to your server. Here are some techniques you can use to minimize widget overhead.

This article shows how to simulate the elimination of CSS file to approximate refactoring your CSS code to be smaller and to be combined within a single file.

JPEGmini works by iteratively reoptimizing existing JPEGs using their own perceptual quality measure. ICVT developed a perceptual quality measure that imitates the qualities of the human visual system. This features enables JPEGmini to apply the optimal amount of compression to each photograph. Rather than using an arbitrary amount of compression as in Photoshop (low, medium, high), JPEG mini applies the optimum amount of compression for each given image, while maintaining existing perceived visual quality.

In terms of web performance, the most effective upgrade consumers can make is moving from 1-3 Mbps to 6-10 Mbps broadband. Above 10-12 Mbps, web page load times don't increase in proportion to broadband speeds. Despite the fact that speeds above 10-12 Mbps have little effect on web page browsing speeds, more people are upgrading from the mid-range tiers than other speeds.

The size of the average web page of the top 1000 websites has more than tripled since 2008 (our last update in May 2011 found it had more than septupled since 2003). In the past five years from 2008 to late 2012 the average web page grew from 312K to 1114K (see Figure 1), over 3.5 times larger (Domenech et al. 2007, Flinn & Betcher 2008, Charzinsk 2010, Souders 2012). During the same five-year period, the number of objects in the average web page has more than doubled from 49.9 to 100 objects per page in November 2012.

EHO is more of an attitude than a specific technique. Every byte counts. The idea is to use the minimum amount of markup to render a page that still works (and validates if desired). HTML optimization is the process of minimizing HTML file size to maximize page display speed. Typical Web pages have extra characters (comments, spaces, returns and redundant attributes) that can safely be removed with no change in appearance. EHO takes this process to its logical extreme within an anything goes approach, where no HTML is safe. EHO is not for everyone. Some of the techniques shown here violate HTML 4, and some don't. It's up to you which ones you use.

Web design is all about balance: a tradeoff between bandwidth and beauty. The skilled Web designer walks a fine line between appearance and functionality, and can craft pages that appear good but display quickly. That's a real skill, something that WYSIWYG HTML editors won't give you. In fact, I think there is a disconnect between what users want (info fast) and what Web designers are giving them (slow-loading glitz). Promulgated by WYSIWYG HTML editors, high-end how-tos, and overzealous designers there's a plethora of bloated pages out there that few users are willing to wait for. Unoptimized code is rampant on the Web. And I, for one, am on a mission to stop the madness.

Many sites now use Google Analytics to track their metrics. Google Analytics gives some useful statistics not normally found from server-side log files, including PPC versus natural SEO traffic and visitor behavior. Used as directed however, Google Analytics can slow down your pages. This article shows how improve the speed of web pages using Google Analytics with a few simple changes, while maintaining its advantages for faster-loading sites.

When a user requests a page, it can take from 200 to 500ms for the backend server to create the HTML. During that time the browser is idle, waiting for data to arrive. Developers can speed up start render times and the display of useful content by flushing the buffer. Flushing HTML sends a partial HTML response to the browser, which modern browsers can display. Flushing allows the browser to start fetching components and rendering the response while the backend can continue creating the rest of the HTML page.

These partial responses are called chunks, from HTTP 1.1's chunked encoding. Chunked encoding allows developers to send pieces of content to the browser, essentially breaking up a web page into separate components. This allows developers to progressively display portions of web pages, sending the most important parts to the client first.

Because JavaScript code can alter the content and layout of a web page, the browser delays rendering any content that follows a script tag until that script has been downloaded, parsed and executed. However, more importantly for round-trip times, many browsers block the downloading of resources referenced in the document after scripts until those scripts are downloaded and executed. On the other hand, if other files are already in the process of being downloaded when a JS file is referenced, the JS file is downloaded in parallel with them. For example, let's say you have 3 stylesheets and 2 scripts and you specify them in the following order in the document

The Time to First Byte is the amount of time it takes after the client sends an HTTP GET request to receive the first byte of the requested resource from the server. Time to First Byte as WebPageTest.org defines is it the time it takes for the browser to wait for the first byte of a requested resource to be received after the DNS lookup and connection time. Some definitions lump DNS, connection and waiting into the TTFB metric. So TTFB represents the amount of time it takes for the server to respond and build the web page.