Some defects in Ajax requests

This article is a real essay. It refers to what I wrote when I was writing a front-end optimization ppt and what I wrote to which I was going to produce a copy of the stuff... lazy sorting... so release it to the zookeeper.

 

Ajax Optimization

 

1. Set a valid long-term expires for the requested resource and set a relatively short and reasonable max-age value

For example, the response header to a file server should contain

Expires:Tue, 01 Jun 2030 15:43:46 GMT

Cache-control: Max-age = 60

And one of the last modified header or etag header.

 

For ie browsers, the first two items are indispensable because

If there is no expires and no max-age for a file, there will be no expiration time for the cached file... Once a cached file has no expiration time, we use the xhr object to request the file from the server. this will cause IE to directly use the local cache file for us without initiating an HTTP connection request to the server.

We needUse independent etag for dynamic filesAlgorithmOr lastmodified algorithm to promptly update the content. the reason is that the IE browser will stubbornly cache dynamic files like aspx PHP and does not initiate HTTP requests during xhr object requests. In this case, the expires time of the IE cached files should be ensured selectively based on different situations. and Max-age or simply prohibit ie from caching files.

Never expect IE to use dynamic file types such as aspx PHP like Firefox Chrome safari. when the default HTTP header does not contain expires, Max-age, and last modified or etag. the self-claimed cache file does not initiate an HTTP request during xhr requests. 

Supplement: for dynamic files such as aspx IIS, the last modified or etag header is not sent by default. That is, IIS considers that new content should always be output to the client for dynamic files. therefore, the client does not always have the if modified since and if none match headers for dynamic files. This causes the xhr object of the browser to make a request to dynamic files and the 304 status code is not available. That is to say, once an HTTP request is initiated and if the returned data is successful, only 200 of the data may be returned. This is reasonable, but the problem with IE is that, as mentioned above, the difference between other browsers lies in the processing difference without epxires by default. fortunately, setting expires and max-age can completely solve these problems without browser differences.

 

It's okay if you only use expires instead of max-age. But here we need an expectation that the time difference between the client and the server is not very outrageous, but this is not guaranteed. max-age is required to ensure the accuracy of the expiration time.

However, if a request initiated by the xhr object of max-age ie still has a bug, the browser will directly discard the local cache and initiate a request to the server every time. This is obviously not the result we want.

 

Therefore, setting max-age and expires at the same time ensures that IE and other browsers comply with the following principles:

 

1The xhr request before the cached file expires is directly read to the local cache without initiating an HTTP connection request.

2If the server response header contains the last modified or etag header, the request will also contain the corresponding if-modified-Since Header or if-None-match header so that let the server determine whether to return the new file content or only return the 304 header to notify the browser that the local cache can trust the same file on the server.

 

 

 

 

2. xhr resource management should be abandoned for xhr requests that do not expect sequence.

 

That is, through a series of browser detection and HTTP Protocol version expectations, as well as the number of HTTP connections occupied by the current resource loading, the number of xhr objects finally controlled by the instance and their usage...

 

This behavior seems to avoid declaring too many xhr objects at the same time, but does not meet the corresponding number of connections, so that too many xhr objects may consume less memory in the browser queue.

 

But on the contrary, we should create a request immediately when xhr is needed and make it send the required request. All we have to do is destroy xhr immediately at the success callback function.

 

In this way, we can ensure the maximum concurrency of xhr with 100% confidence, without the need for our own analysis and judgment.

 

 

To resolve this issue, you need to add HTTP request header content to xhr.

 

My suggestion is:

Add an accept header, for example, */*. Once this header is not set, the default accept headers of all browsers are different. For example, Firefox may be a very long header, wasting bandwidth. therefore, agreeing to use accept and setting it as the type we need can reduce the data volume in HTTP requests.

 

An interesting problem is that if we do not add an IF-modified-since header to xhr, no matter whether the server return code is 304 xhr. status will be 200 unless we explicitly add a request header containing if-modified-since, then xhr. status = 200 is trustworthy. Otherwise. once the content is read from the cache, the status is always 200 instead of the expected 304. manually adding the IF-modified-since header to a date that is too early or too late (relative to the Last modified Date of the file on the server) will cause the server to verify the reliability of the cache file. therefore, the server always sends a 200 status code and sends the latest file data similarities and differences. therefore, to manually add the IF-modified-Since Header, be cautious and ensure its correctness. if we do not need to determine whether the data is read from the cache or sent from the server, we do not recommend that we add the IF-modified-Since Header manually.

 

In addition, in xhr requests, never try to manually send an IF-None-match header to the server. We generally get a 400 status code, that is, bad request, even if our content is a valid etag value.