 Your new post is loading...
Your new post is loading...
Scoop.it!
Tips for web site speed optimization on your web server. Optimize page load time. 
No comment yet.
Sign up to comment
Scoop.it!
Covers the how's and why's of Web caching for people who publish on the Web. With FAQs.
Mickael Ruau's insight:
Hormis utiliser des informations de fraîcheur et une validation, il y a beaucoup de choses à faire pour rendre votre site plus convivial aux caches : Utilisez des adresse URL de manière cohérente — c'est la règle d'or de la mise en cache. Si vous servez le même contenu dans des pages différentes, à des utilisateurs différents, ou depuis des sites différents, il devrait avoir la même adresse URL. C'est le moyen le plus facile et le plus efficace pour rendre votre site convivial aux caches. Par exemple, si vous utilisez une première fois « /index.html » dans votre code HTML comme appel, utilisez-le toujours de cette façon ;Utilisez une bibliothèque commune d'images et d'autres éléments, et appelez-les depuis des endroits différents ;Faites que les caches stockent les images et les pages ne changeant pas souvent en utilisant une en-tête Cache-Control: max-age avec une grande valeur ;Faites que les caches reconnaissent les pages mises à jour régulièrement en indiquant un max-age ou une date d'expiration appropriés ;Si une ressource (un fichier téléchargeable spécialement) change, changez son nom. De cette manière, vous pouvez la faire expirer loin dans le future, tout en garantissant le service de la version correcte ; seule la page qui mène à elle a besoin d'une date d'expiration proche ;Ne changez pas les fichiers sans nécessité. Si vous le faites, tout aura une date Last-Modified faussement récente. Par exemple, lors d'une mise à jour de votre site, ne recopiez pas le site entier ; déplacez juste les fichiers que vous aurez changé ;Utilisez des cookies seulement si nécessaire — les cookies sont difficiles à cacher et ne sont pas nécessaires dans la plupart des situations. Si vous devez utiliser un cookie, limitez-en l'usage aux pages dynamiques ;Minimisez l'utilisation de SSL — parce que les pages chiffrées ne sont pas stockées par les caches partagés, ne les utilisez que quand il le faut, et utilisez avec parcimonie les images dans les pages SSL ;Utilisez le Cacheability Engine — il peut vous aider à mettre en pratique plusieurs des concepts de ce tutoriel.
Scoop.it!
A few useful, free tools to help you create and sustain high-performance web applications.
Mickael Ruau's insight:
Response times, availability, and stability are vital factors to bear in mind when creating and maintaining a web application. If you’re concerned about your web pages’ speed or want to make sure you’re in tip-top shape before starting or launching a project, here’s a few useful, free tools to help you create and sustain high-performance web applications. I’ve tried to include a wide variety of tools that are easy to use, and have tried to keep them as OS and technology-independent as possible so that everyone can find a tool or two.
Scoop.it!
Optimize your website with IndyLogix Solutions in terms of Loading Speed, Visual Appearance and Google optimization standards at affordable price.
Mickael Ruau's insight:
The challenge here is to minimize HTTP request without compromising on the quality of experience that your client gets while browsing your webpage. Some of the tips and way outs that could be useful are listed below: Using server side storage for most of your cookie payload helps to keep your cookie load low, minimizing the HTTP request header.Removing cookie fields that are not in use or duplicate.Using combined scripts and CSS files will help you minimize the request header.Combining all or most of the images on your page into a sprite will mean the multiple image requests will be replaced by just one request thus, minimizing the request load.Using Image Maps may also help when your webpage has contiguous images, whereby the image map will convert the multiple image requests to just one.Eliminating frames and java scripts will help.
Scoop.it!
Reflow is the name of the web browser process for re-calculating the positions and geometries of elements in the document, for the purpose of re-rendering part or all of the document. Because reflow is a user-blocking operation in the browser, it is useful for developers to understand how to improve reflow time and also to understand the effects of various document properties (DOM depth, CSS rule efficiency, different types of style changes) on reflow time. Sometimes reflowing a single element in the document may require reflowing its parent elements and also any elements which follow it.
Mickael Ruau's insight:
Additional resourcesMozilla's Notes on HTML reflowOpera's Repaints and reflowsSatoshi Ueyama's debug-Firefox reflow demos:google.co.jp reflowmozilla.org reflowja.wikipedia.org reflowNicole Sullivan on Reflows and Repaints
Scoop.it!
The HTTP protocol gives two ways to define how long a resource is valid: the Expires header and the Cache-Control: max-age header. The Expires header specifies a date after which a resource is invalid. At that point, the browser will ask for the resource again. max-age works much the same way but it specifies how long a resource is after it is downloaded instead of giving a specific date. That is nice because you can configure your web server with a constant value.
Mickael Ruau's insight:
For information on writing the headers, try a search for "expires header" and your web server or programming language. Here are a couple direct links: Apache Module mod_expiresPHP Header
Scoop.it!
What Are These Resources?
So the first question you might ask is what are these 24 resources BWI needs to load? They are the images, the page itself, its favorite icon, and the CSS file. Anything that needs to be download, needs a request, and it starts with the page itself. An obvious first step to reduce the RTT time is to simply reduce the number of resources. A quick example of this would be delete my logo. Then I would have just 23 requests.
Mickael Ruau's insight:
My final comment here is that when thinking about RTT, you could be actually scoring one for usability. Let me ask this. How many images are on your site right now that could easily be in text format (a suggested web usability method)? For every image that does, it is +1 to the RTT.
Scoop.it!
Every time a client sends an HTTP request, it has to send all associated cookies that have been set for that domain and path along with it. Most users have asymmetric Internet connections: upload-to-download bandwidth ratios are commonly in the range of 1:4 to 1:20. This means that a 500-byte HTTP header request could take the equivalent time to upload as 10 KB of HTTP response data takes to download. The factor is actually even higher because HTTP request headers are sent uncompressed. In other words, for requests for small objects (say, less than 10 KB, the typical size of a compressed image), the data sent in a request header can account for the majority of the response time. The latency can be higher at the beginning of a new browser session. To minimize net congestion, TCP employs the "slow start" algorithm for new connections. This limits the amount of data that can be sent by the initiator of the connection before the data must be acknowledged by the recipient. If the initiator sends more than that amount of data over a new connection, an additional RTT is incurred.
Mickael Ruau's insight:
The best way to cut down on client request time is to reduce the number of bytes uploaded as request header data. Minimize request sizeServe static content from a cookieless domain
Scoop.it!
Use Cookie-free Domains for Components | Improving Web site performance | dml research
Mickael Ruau's insight:
How Using Cookie-free Domains for Components improves Web site download performance
When the browser makes a request for a static image and sends cookies together with the request, the server doesn't have any use for those cookies. So they only create network traffic for no good reason. You should make sure static components are requested with cookie-free requests. Create a subdomain and host all your static components there.
Scoop.it!
Keep Components under 25K | Improving Web site performance | dml research
Mickael Ruau's insight:
How keeping Components under 25K improves Web site download performance
This restriction is related to the fact that iPhone won't cache components bigger than 25K. Note that this is the uncompressed size. This is where minification is important because gzip alone may not be sufficient. For more information check "Performance Research, Part 5: iPhone Cacheability - Making it Stick" by Wayne Shea and Tenni Theurer.
Scoop.it!
Combining external files and optionally including CSS and JavaScript directly within your XHTML pages, you can minimize the number of HTTP requests required to
Mickael Ruau's insight:
Combining external files and optionally including CSS and JavaScript directly within your XHTML pages, you can minimize the number of HTTP requests required to render your page. Each unique HTTP request requires a round trip to a server, introducing indeterminate delays. Users attune to fast, consistent response times. The more HTTP requests that your pages require, the slower and less consistent their response time will be. This technique is especially important in the head of your XHTML documents. With few exceptions, browsers must load and parse external CSS and JavaScript files referenced within the head of your XHTML before they parse the body content. By minimizing the HTTP request load you can maximize the initial display speed of your content.
Note that while JavaScript files are not reliably cached by browsers, CSS files are. The SSI technique included above should only be used on high traffic pages, like home pages. Note also that you can use XSSI or pre-merge these files into high traffic pages, to create conditional style and behavior. You can link to them normally for other pages and still separate presentation and behavior from structure, and benefit from caching. This technique also applies to adjacent graphics, which can also be combined or eliminated.
Scoop.it!
here are a few simple ways to improve the speed of your website. Evaluates the performance of web pages and get suggestions on how to improve them. Why
Mickael Ruau's insight:
10 Useful Tools for Improving Web Performance
1) Browserscope is a community-driven project for profiling web browsers http://www.browserscope.org/ 2) SpriteMe is a bookmarklet plugin that allows for easy generation of CSS Sprites. CSS Sprites are a method to improve page load time by combining multiple background images into a single image http://spriteme.org/ 3) Aptimize is a commercial Web accelerator that quickly improves Web performance http://www.aptimize.com/ 4) Cesium is a Mozilla project for programmatically collecting and monitoring YSlow (http://developer.yahoo.com/yslow/) Web performance statistics http://cm-cesium01.mozilla.org/https://wiki.mozilla.org/Webdev:Cesium 5) MSFast is Myspace’s browser plugin for debugging and analyszing Page performance. Myspace also featured a utiliy for analyzing Flash SWF Object performance, which is not currently available yet, but may be included in MSFast in the future. http://msfast.myspace.com/ 6) Jiffyweb Jiffyweb is an end-to-end real-world web page instrumentation and measurement suite.http://code.google.com/p/jiffy-web/ 7) dynaTrace Ajax Edition is a unique AJAX diagnostics too suite for analyzing and debugging AJAX Requestshttp://ajax.dynatrace.com/pages/ 8) Pagespeed is a Firefox Add-on from Google for diagnosing Web page performance based on a proposed set of best-practices http://code.google.com/speed/page-speed/ 9) SproutCore is a platform for building HTML5 High Performance Web Applicationshttp://blog.sproutcore.com/post/196959232/how-sproutcore-makes-your-app-run-faster 10) Cuzillion is a tool for quickly constructing web pages to see how components interact across different browsers http://www.stevesouders.com/cuzillion/help.php
|
Scoop.it!
In building any application, developers are often required to make ‘utilitarian’ choices. Pretentiously paraphrasing Jeremy Bentham, ‘utilitarian’ describes an approach that ‘does the greatest good for the greatest number.’ Many times, sacrifices in performance are made for a subset of users so that the average expected performance of all users will be better.
Mickael Ruau's insight:
There is plenty of precedent for this approach in real world Ajax apps. To exploit connection parallelism, the image tiles at Google Maps are served from mt0.google.com through mt3.google.com. Virtual Earth also uses this technique. You can also use this connection management approach to sandbox the performance of different parts of your application. If you have page elements that require database access and may be more latent than static objects, keep them from clogging up the 2 connections for image content by putting them on a subdomain.
Scoop.it!
While working on optimizing page load times for a high-profile AJAX application, I had a chance to investigate how much I could reduce latency due to external objects. Specifically, I looked into how the HTTP client implementation in common browsers and characteristics of common Internet connections affect page load time for pages with many small objects. I found a few things to be interesting: IE, Firefox, and Safari ship with HTTP pipelining disabled by default; Opera is the only browser I know of that enables it. No pipelining means each request has to be answered and its connection freed up before the next request can be sent. This incurs average extra latency of the round-trip (ping) time to the user divided by the number of connections allowed. Or if your server has HTTP keepalives disabled, doing another TCP three-way handshake adds another round trip, doubling this latency. By default, IE allows only two outstanding connections per hostname when talking to HTTP/1.1 servers or eight-ish outstanding connections total. Firefox has similar limits. Using up to four hostnames instead of one will give you more connections. (IP addresses don't matter; the hostnames can all point to the same IP.) Most DSL or cable Internet connections have asymmetric bandwidth, at rates like 1.5Mbit down/128Kbit up, 6Mbit down/512Kbit up, etc. Ratios of download to upload bandwidth are commonly in the 5:1 to 20:1 range. This means that for your users, a request takes the same amount of time to send as it takes to receive an object of 5 to 20 times the request size. Requests are commonly around 500 bytes, so this should significantly impact objects that are smaller than maybe 2.5k to 10k. This means that serving small objects might mean the page load is bottlenecked on the users' upload bandwidth, as strange as that may sound. Using these, I came up with a model to guesstimate the effective bandwidth of users of various flavors of network connections when loading various object sizes. It assumes that each HTTP request is 500 bytes and that the HTTP reply includes 500 bytes of headers in addition to the object requested. It is simplistic and only covers connection limits and asymmetric bandwidth, and doesn't account for the TCP handshake of the first request of a persistent (keepalive) connection, which is amortized when requesting many objects from the same connection. Note that this is best-case effective bandwidth and doesn't include other limitations like TCP slow-start, packet loss, etc. The results are interesting enough to suggest avenues of exploration but are no substitute for actually measuring the difference with real browsers.
Mickael Ruau's insight:
The above list covers improving the speed of communication between browser and server and can be applied generally to many sites, regardless of what web server software they use or what language the code behind your site is written in. There is, unfortunately, a lot that isn't covered. While the tips above are intended to improve your page load times, a side benefit of many of them is a reduction in server bandwidth and CPU needed for the average page view. Reducing your costs while improving your user experience seems it should be worth spending some time on.
Scoop.it!
Mickael Ruau's insight:
Reducing the number of unique hostnames has the potential to reduce the amount of parallel downloading that takes place in the page. Avoiding DNS lookups cuts response times, but reducing parallel downloads may increase response times. My guideline is to split these components across at least two but no more than four hostnames. This results in a good compromise between reducing DNS lookups and allowing a high degree of parallel downloads.
Scoop.it!
DNS Lookups help us to find the actual hosting server’s IP address from its domain name To service a high performance web server we have to take care of it
Mickael Ruau's insight:
There are several ways to reduce the DNS lookups. One of them is to host multiple properties on the same server or domain using different URL paths rather than hosting them in separate hostnames. This will reduce the unique hostnames and also the DNS lookups too. Hosting several services on a single domain improves the latency and enhances the end user’s experience. They will be able to experience different services through a single session and without any further DNS lookups. It also reduces the number of TCP connections made by the browser, hence reduces the round trip times too.
Scoop.it!
Shorten hexadecimal colour notation. “In CSS, when you use hexadecimal colour notation and a colour is made up of three pairs of hexadecimal digits, you can write it in a more efficient way by omitting every second digit: #000 is the same as #000000, #369 is the same as #336699
Mickael Ruau's insight:
Define pseudo classes for links in the LoVe/HAte-order: Link, Visited, Hover, Active. “To ensure that you see your various link styles, you’re best off putting your styles in the order “link-visited-hover-active”, or “LVHA” for short. If you’re concerned about focus styles, they may go at the end– but wait until you’ve read this explanation before you decide.” view plaincopy to clipboardprint?a:link { color: blue; } a:visited { color: purple; } a:hover { color: purple; } a:active { color: red; } Define element’s margin, padding or border in TRouBLed-order: Top, Right, Bottom, Left. “When using shorthand to specify an element’s margin, padding or border, do it clockwise from the top: Top, Right, Bottom, Left.” You can use shorthand properties. “Using shorthand for margin, padding andborder properties can save a lot of space. <em>CSS:</em> margin: top right bottom left; margin: 1em 0 2em 0.5em; (margin-top: 1em; margin-right: 0; margin-bottom: 2em; margin-left: 0.5em <em>CSS:</em> border: width style color; border: 1px solid #000; <em>CSS:</em> background: color image repeat attachment position; background: #f00 url(background.gif) no-repeat fixed 0 0; <em>CSS:</em> font: font-style (italic/normal) font-variant (small-caps) font-weight font-size/line-height font-family; font: italic small-caps bold 1em/140% “Lucida Grande”,sans-serif;
Scoop.it!
The amount of data sent in each server response can add significant latency to your application, especially in areas where bandwidth is constrained. In addition to the network cost of the actual bytes transmitted, there is also a penalty incurred for crossing an IP packet boundary. (The maximum packet size, or Maximum Transmission Unit (MTU), is 1500 bytes on an Ethernet network, but varies on other types of networks.) Unfortunately, since it's difficult to know which bytes will cross a packet boundary, the best practice is to simply reduce the number of packets your server transmits, and strive to keep them under 1500 bytes wherever possible.
Mickael Ruau's insight:
Minimizing the payload size of both dynamic and static resources can reduce network latency significantly. In addition, for scripts that are cached, cutting down their byte size speeds up the time the browser takes to parse and execute code needed to render the page. Enable compressionRemove unused CSSMinify JavaScriptMinify CSSMinify HTMLDefer loading of JavaScriptOptimize imagesServe scaled imagesServe resources from a consistent URL
Scoop.it!
Round-trip time (RTT) is the time it takes for a client to send a request and the server to send a response over the network, not including the time required for data transfer. That is, it includes the back-and-forth time on the wire, but excludes the time to fully download the transferred bytes (and is therefore unrelated to bandwidth). For example, for a browser to initiate a first-time connection with a web server, it must incur a minimum of 3 RTTs: 1 RTT for DNS name resolution; 1 RTT for TCP connection setup; and 1 RTT for the HTTP request and first byte of the HTTP response. Many web pages require dozens of RTTs. RTTs vary from less than one millisecond on a LAN to over one second in the worst cases, e.g. a modem connection to a service hosted on a different continent from the user. For small download file sizes, such as a search results page, RTT is the major contributing factor to latency on "fast" (broadband) connections. Therefore, an important strategy for speeding up web page performance is to minimize the number of round trips that need to be made.
Mickael Ruau's insight:
Since the majority of those round trips consist of HTTP requests and responses, it's especially important to minimize the number of requests that the client needs to make and to parallelize them as much as possible. Minimize DNS lookupsMinimize redirectsAvoid bad requestsCombine external JavaScriptCombine external CSSCombine images using CSS spritesOptimize the order of styles and scriptsAvoid document.writeAvoid CSS @importPrefer asynchronous resourcesParallelize downloads across hostnames
Scoop.it!
CSS optimization is the process of minimizing your markup and CSS files for maximum speed. To optimize your CSS group external files to minimize HTTP
Mickael Ruau's insight:
To optimize your CSS group external files to minimize HTTP requests, remove whitespace, and use shorthand properties. Group common declarations, selectors, and CSS code in multiple classes to save space. Use the simplest selectors you can, high in the document tree and let them cascade. Be as vague and as abstract as possible in your CSS selectors. Embed or SSI abbreviated styles for maximum speed.Minimize HTTP requests by grouping external CSS files.Link to external style sheets site-wide to cache in.Layer style sheets for speed. Use cascading to combine linked, alternate, and imported style sheets to layer your presentation for older browsers and alternate media (print), and to save bandwidth.Group selectors with the same declarations and declarations with the same selectors.Use simple selectors high in the document tree to set global and element-wide styles (that is, type styles like body, h1, p, and dt).Use descendant selectors to get specific without class or id selectors.Take advantage of your inheritance – don’t overspecify CSS; let it flow down the document tree.Use multiple classes to group common style declarations to save space.Use value replication on the border, padding, and margin properties.Use shorthand hex colors (such as #00f).Use shorthand properties to optimize your CSS (including font, background, margin, and border).Use short class and id names.Use shorthand hexadecimal colors or names, whichever is shorter.Use relative lengths for maximum flexibility.Remove whitespace.Cut the comments.
Scoop.it!
Choose link over import | Improving Web site performance | dml research
Mickael Ruau's insight:
How choosing link over import improves Web site download performance
One of the previous best practices states that CSS should be at the top in order to allow for progressive rendering. In IE @import behaves the same as using <link> at the bottom of the page, so it's best not to use it.
Scoop.it!
Develop Smart Event Handlers | Improving Web site performance | dml research
Mickael Ruau's insight:
How developing Smart Event Handlers improves Web site download performance
Sometimes pages feel less responsive because of too many event handlers attached to different elements of the DOM tree which are then executed too often. That's why using event delegation is a good approach. If you have 10 buttons inside a div, attach only one event handler to the div wrapper, instead of one handler for each button. Events bubble up so you'll be able to catch the event and figure out which button it originated from.
Scoop.it!
There are two things in this rule: For static components: implement Never expire policy by setting far future Expires header For dynamic components:
Mickael Ruau's insight:
Using a far future Expires header affects page views only after a user has already visited your site. It has no effect on the number of HTTP requests when a user visits your site for the first time and the browser’s cache is empty. Therefore the impact of this performance improvement depends on how often users hit your pages with a primed cache. (A “primed cache” already contains all of the components in the page.) We measured this at Yahoo! and found the number of page views with a primed cache is 75-85%. By using a far future Expires header, you increase the number of components that are cached by the browser and re-used on subsequent page views without sending a single byte over the user’s Internet connection. inShare
|
You need to have Apache's mod_expires on your server for this to work. If you have access to your servers config files, check if the following line is commented out in the load modules section:
LoadModule expires_module modules/mod_expires.soIn your .htaccess or preferably virtual host container insert something like this:
ExpiresActive OnExpiresByType text/html "access plus 30 seconds"
ExpiresByType text/css "access plus 2 weeks"
ExpiresByType text/javascript "access plus 2 weeks"
ExpiresByType image/png "access plus 1 month"
Modify to your needs. For every file type you would like to cache, insert an extra statement.
(...)
Compress text filesLoadModule headers_module modules/mod_headers.soLoadModule deflate_module modules/mod_deflate.so
The following directives don't work in .htaccess. You need to place them in your servers config, i.e your virtual host container:
# Compress some text file typesAddOutputFilterByType DEFLATE text/html text/css text/xml application/x-javascript
# Deactivate compression for buggy browsers
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# Set header information for proxies
Header append Vary User-Agent
The first line says what file types should be compressed. Add the uncompressed file types you host on your server. It makes no sense to compress already compressed files like images or archives. Compressing these files again will only increase your server's load.
Apache fine tuningHostnameLookups OffIn one last step, configure persistent connections in Apache's config. Persistent connections let the browsers request multiple files with one TCP connection, thus reducing overhead for TCP handshakes and speeding up requests a lot. These are the standard settings with Apache 2.2:
KeepAlive OnMaxKeepAliveRequests 100
KeepAliveTimeout 15