How to improve page response speed

Intermediary transaction SEO diagnosis Taobao guest Cloud host technology Hall

Slow access to the Internet has become the past, but the page can be instantaneous rendering is only the future will happen. Christian Heilmann tips can now make your site more fluent.

The time delay when the page is first accessed is a very important problem in Web site and Web application design. Users always feel that the page is not fast enough.

Why do users feel this way? Perhaps the user still retains the habit of using the minutes-by-minute access network (which the hotel or airport still maintains), perhaps because the user feels that the page needs to respond quickly enough to be called the information highway. But in my opinion it's Hollywood's responsibility. In every Hollywood action blockbuster: Tapping on the keyboard, the computer screen will appear ultra-high resolution, with a dense data display of the exquisite site operation interface, and the Web site to read an encyclopedia is only a few milliseconds to complete.

But in real life this is not the case, because no matter how you try to simplify your page, the delay still exists. And in order to make the page more gorgeous, usually use flash, but if the misuse of flash can seriously affect the response speed of the page. As a network application, you must also ensure that the page elements are loaded in order, not because the page is not fully loaded elements are accessed by the user caused by the exception.

Those factors caused the site to respond slowly?

When it comes to improving the responsiveness of your Web site, the most common approach is to reduce the size of your Web site files as much as possible. (This also leads to endless discussions about the size of the JavaScript library file, but in the end there is no result.) In fact, there are a number of factors that affect the response speed of a Web page's initial access:

The size of the HTML document.
The size of the script, image, and multimedia element document embedded in the page.
The complexity of the HTML page. (browsers can quickly display simple pages)
User access Speed
The speed at which the third party content that the page accesses is accessed by the server.
The DNS resolution speed of the site domain name and the external domain name that the page contains.
The performance of the user's computer. (browsers can be slow to respond because the system consumes too much resources on other tasks).
The corresponding speed of the server.
In addition to the above technical factors will lead to slow response to the site, there are some people for design factors. For example: In order to avoid page loading process in the page area of confusion and no image display;

A quick way to respond to a Web site

Through practice, the following experience will help to solve the problem of slow response to Web sites due to technical and human factors.

Optimize HTML code as much as possible without affecting the quality of page display. (This includes removing comments from HTML documents and redundant line-wrapping tags when publishing pages.) But to keep the page readable, the code should remain in the source code as few other external references are included in the page, reducing dependencies between documents. (You can put multiple scripts into a script file, using CSS sprite techniques to combine multiple small pictures into a larger image, so that you only need to load one time) to ensure that you do not refer to third-party content from the external server: use a script to cache remote RSS feeds locally. This not only avoids the latency caused by DNS resolution, but also does not affect your service because of the downtime of external servers.

Make the picture as much as possible and the dimensions of the element that contains the picture. This can avoid the page when the picture is loaded and the page element is beating.

A large script is loaded at the end of the page so that the page can be displayed before a large script load completes. If you load a large script in the page header element, the browser waits until the script is fully loaded to display the page content.

Web development guidelines and improving response speed

Unfortunately, the above mentioned are in conflict with the principles of web development that we normally think of. Reducing the number of page-included files, for example, can cause product maintainability to become worse. The easiest way to keep a different page style for a site without a page (first, post, and archive page) is to store the special styles of different types of pages in their own style files. A page can have a basic style file, and then include the specified style file for that type of page based on the different types of pages.

Scripts can also be stored in the same way, with similar scripts in a file. This helps with code maintenance. You can quickly find the function you need without looking at all the scripting code. In addition, adding a script to the main part of the page is often considered a bad coding habit because he controls the structure of the logically embedded page with the user's behavior.

Fortunately, there are technical solutions to these problems.

Use a containing to refer to multiple styles or scripts.

Edwaraillo's solution is to use a PHP script to organize multiple CSS styles or scripts into a single file. This script can also be compressed for JavaScript to invoke the jsmin of Douglas Crockford ' s. This script is simple to use and can cache merged files until these merged files are modified. This means that when you modify a merged file, the script automatically repackage the cache. This is very simple to solve the Code maintenance and page response speed contradictions between.

Solve the problem of page loading

Another tricky problem is that scripts embedded in the page header elements need to wait for the page to be loaded before they can be invoked. This can be a bit of a delay, and it can also cause problems.

Latency is caused by the way browsers load, parse, and display documents. When you load a script with window onload events, the browser's processing order is this:

Parsing HTML code loading external scripts and style sheets
Execute the parsed script
Build HTML DOM tree
Loading pictures and other external references
Page load Complete

In most cases such loading is slower and some steps need to be advanced. Many smart programmers are committed to solving this problem, and there are new solutions coming out of the way. Most JavaScript scripts have event handling for onavailable or Ondocumentready. Such events are triggered when a portion of the document is loaded, rather than waiting for a large number of pictures to be loaded. But through practice and repeated testing, there is no unassailable solution for old browsers and operating systems. But I believe that as long as we continue to work hard, coupled with so little luck will find the final solution.

It is a fatal problem for Web applications to cause exceptions because of calls to an element that is not loaded. If this type of problem occurs in the page Beautification section, there will be some workaround.

In order to solve the problem of loading too much content at one time, the content can be loaded on demand separately.

In order to better decorate the page to load a lot of content at a time, often have problems. A lot of content may be that each tag contains too much text or a four-level navigation bar. Using the Javacript script can be very easy to dynamically display these content. But if the script is disabled, then the dynamic content will lose its style and be disrupted and not properly displayed, which is certainly not a good idea. The page also does not have to load all the dynamic exhibits at once, which increases the load on the page load.

The workaround is to dynamically load the displayed content with JavaScript when the user triggers the tag. A basic static text is also displayed when the user closes the script.

The way to load additional content depends on what you need to quote. The simplest method is to dynamically generate script tags. This is an early approach that is used to introduce a large number of JavaScript datasets or to introduce scripts after the page is loaded.

function Pull () {
var s = document.createelement (' script ');
S.type = ' Text/javascript ';
S.SRC = ' largejavascriptblock.js ';
document.getElementsByTagName (' head ') [0].appendchild (s);
}
Window.onload = pull;

The del.icio.us page is in this way to introduce the data returned by JSON. Since JSON returns nothing more than a bunch of JavaScript code, you can generate JavaScript script tags that contain the code after the page is loaded, and then execute the code to replace the contents of an element in the page. Dishy as an object that encapsulates JSON can make it easy for you to do this. Another is a less conspicuous Flickr avatar, Flickr displays your latest photos with JSON output, and when the user disables the script, which location displays only a link.

If you're introducing non-javascript content, you can use Ajax or Ahah or Hijax or some other Ajax that does not contain XML (you'll want to name whatever). For example, an AJAX-enabled navigation, which can even load more complex interfaces depending on the user's need to choose.

Imaging Trickery image Display techniques

The final source of the approach will be traced back to the possibility that you have not yet begun to contact the Web site development. At that time, the most IE competitor in the browser war, the poor Netscape (but in my opinion it was good at that time) browsers support a custom HTML attribute ' Lowsrc ', which specifies that a small picture can be loaded in advance as an alternative display image for a large image load. This allows you to see a preview of the image that is about to be rendered, even if the user's access rate is slow.

You can reuse the idea that when the page loads, do not embed a large picture but load a more normalized small picture, and then replace it with a large picture when the page is loaded. You can even simplify to start by loading only the background color, then wait for the page load to complete and then overwrite with JavaScript or DOM loading artwork.

This approach also applies to the number of images you need to get from multiple servers that cannot be cached. (for example, gravatars) you can usually load a placeholder image, and so on, and so on, and then dynamically get the small pictures scattered on other servers.

Summary
These are just some of the basic ways to improve page response speed, and I hope some of them will help you.
If you have some better ideas, don't hesitate to reply to me.