Silksoftware BBS

 找回密码
 立即注册
搜索
查看: 5276|回复: 0

制作优质页面必读 --- (五) [复制链接]

Rank: 2

发表于 2012-3-28 12:29:13 |显示全部楼层

Make Ajax Cacheable

tag: content


One of the cited benefits of Ajax is that it provides instantaneous  feedback to the user because it requests information asynchronously from the backend web server. However, using Ajax is no guarantee that the  user won't be twiddling his thumbs waiting for those asynchronous  JavaScript and XML responses to return. In many applications, whether or not the user is kept waiting depends on how Ajax is used. For example,  in a web-based email client the user will be kept waiting for the  results of an Ajax request to find all the email messages that match  their search criteria. It's important to remember that "asynchronous"  does not imply "instantaneous".

To improve performance, it's important to optimize these Ajax  responses. The most important way to improve the performance of Ajax is  to make the responses cacheable, as discussed in Add an Expires or a Cache-Control Header. Some of the other rules also apply to Ajax:



Let's look at an example. A Web 2.0 email client might use Ajax to  download the user's address book for autocompletion. If the user hasn't  modified her address book since the last time she used the email web  app, the previous address book response could be read from cache if that Ajax response was made cacheable with a future Expires or Cache-Control header. The browser must be informed when to use a previously cached  address book response versus requesting a new one. This could be done by adding a timestamp to the address book Ajax URL indicating the last  time the user modified her address book, for example, &t=1190241612. If the address book hasn't been modified since the last download, the  timestamp will be the same and the address book will be read from the  browser's cache eliminating an extra HTTP roundtrip. If the user has  modified her address book, the timestamp ensures the new URL doesn't  match the cached response, and the browser will request the updated  address book entries.

Even though your Ajax responses are created dynamically, and might  only be applicable to a single user, they can still be cached. Doing so  will make your Web 2.0 apps faster.

[/url]

Flush the Buffer Early

tag: server


When users request a page, it can take anywhere from 200 to 500ms for the backend server to stitch together the HTML page. During this time, the browser is idle as it waits for the data to arrive. In PHP you have the function [url=http://php.net/flush]flush()
. It allows you to send your partially ready HTML response to the browser so that the browser can start fetching components while your backend is busy with the rest of the HTML page. The benefit is mainly seen on busy backends or light frontends.

    A good place to consider flushing is right after the HEAD because the HTML for the head is    usually easier to produce and it allows you to include any CSS and JavaScript    files for the browser to start fetching in parallel while the backend is still processing.
Example:

      ... <!-- css, js -->    </head>    <?php flush(); ?>    <body>      ... <!-- content -->
Yahoo! search pioneered research and real user testing to prove the benefits of using this technique.



Use GET for AJAX Requests

tag: server


    The Yahoo! Mail team found that when using XMLHttpRequest, POST is implemented in the browsers as a two-step process:    sending the headers first, then sending data. So it's best to use  GET, which only takes one TCP packet to send (unless you have a lot of  cookies).    The maximum URL length in IE is 2K, so if you send more than 2K data you might not be able to use GET.

An interesting side affect is that POST without actually posting any data behaves like GET. Based on the HTTP specs, GET is meant for retrieving information, so it        makes sense (semantically) to use GET when you're only  requesting data, as opposed to sending data to be stored server-side.





Post-load Components

tag: content


    You can take a closer look at your page and ask yourself: "What's  absolutely required in order to render the page initially?".    The rest of the content and components can wait.

    JavaScript is an ideal candidate for splitting before and after the  onload event. For example    if you have JavaScript code and libraries that do drag and drop and  animations, those can wait,    because dragging elements on the page comes after the initial  rendering.    Other places to look for candidates for post-loading include hidden  content (content that appears after a user action) and images below the  fold.

    Tools to help you out in your effort: YUI Image Loader allows you to delay images    below the fold and the YUI Get utility is an easy way to include JS and CSS on the fly.    For an example in the wild take a look at Yahoo! Home Page with Firebug's Net Panel turned on.

    It's good when the performance goals are inline with other    web development best practices. In this case, the idea of  progressive enhancement tells us that JavaScript, when supported, can    improve the user experience but you have to make sure the page works even without JavaScript. So after you've made sure the page    works fine, you can enhance it with some post-loaded scripts that  give you more bells and whistles such as drag and drop and animations.



Preload Components

tag: content


    Preload may look like the opposite of post-load, but it actually has a different goal.    By preloading components you can take advantage of the time the browser is idle and request components    (like images, styles and scripts) you'll need in the future.    This way when the user visits the next page, you could have most of the components already in    the cache and your page will load much faster for the user.

    There are actually several types of preloading:

  • Unconditional preload - as soon as onload fires, you go ahead and fetch some extra components.        Check google.com for an example of how a sprite image is requested onload. This sprite image is        not needed on the google.com homepage, but it is needed on the consecutive search result page.
  • Conditional preload - based on a user action you make an educated guess where the user is headed next and preload accordingly.        On search.yahoo.com you can see how some extra components are requested        after you start typing in the input box.
  • Anticipated preload - preload in  advance before launching a redesign. It often happens after a redesign  that you hear:        "The new site is cool, but it's slower than before". Part of the problem could be that the users were visiting your old site with a        full cache, but the new one is always an empty cache experience. You can mitigate this side effect by preloading some        components before you even launched the redesign. Your old site  can use the time the browser is idle and request images and scripts        that will be used by the new site



使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

Silksoftware BBS

GMT+8, 2022-9-30 18:35 , Processed in 0.018725 second(s), 9 queries .

回顶部