The front-end should be awesome: How long should the URL be ?, How long is the url?

Source: Internet
Author: User

The front-end should be awesome: How long should the URL be ?, How long is the url?

How long should a URL be? Why should I raise this question? There are many optimization guidelines for optimizing web page requests and loading by minimizing cookies, shortening URLs, and using GET requests as much as possible. However, the so-called "as much as possible" and "as much as possible" are only qualitative descriptions. in quantitative terms, the number of bytes to be shortened is only small?


In a revision of our home page, I saw several interesting URLs of. js files through http analyzers, as shown in the following figure:

[Xhtml]View plaincopy
  1. Https:// V = 083
  2. Https:// T = 20101012
  3. Https:// T = 20101012
  4. Https://
  5. Https:// B = javascript & f = arale/lang/aspect. js, arale/lang/md5.js, arale/lang/uri. js, arale/lang/tmpl. js, arale/lang/date. js, arale/lang/number. js, arale/http/jsonp. js, arale/http/ajax. js, arale/http/core. js, arale/event/event-chain.js, arale/class/declare. js, arale/fx/animator. js, aralex/widget. js, aralex/tplwidget. js, aralex/view. js, aralex/tab. js, aralex/dropdown. js, aralex/slider. js, aralex/slider/switchslider. js


Pay attention to the last one. Well, don't be surprised. The exact length of a URL is 443 bytes. But is it long? Still not long?

Take IE as an example. The URL length can be 2048 bytes ~~ In any case, IE can handle it. In fact, the general browser is okay, so "correctness" is okay. So next we will talk about efficiency.

  I. packet header in TCP/IP protocol

In TCP/IP networks, the underlying protocol is the same thing, and the application layer protocol is the same thing. Therefore, as an application layer protocol, HTTP can transmit much content and how to transmit it. (for example, an HTTP packet is typically bounded by 48 k. If it exceeds 48 k, an application layer packet is subcontracted, the so-called multipart) are all agreed by the application layer. In the underlying protocol, the link layer and the transport layer have their own conventions on the "transfer size package. In short, the transport layer defines the MSS (maximum segment size) of IP data packets, and the link layer defines MTU (maximum transmission unit ). If the size of an IP packet exceeds MTU (MSS + TCP Header + IP header> MTU), the IP packet is split into multiple information packets for transmission at the link layer.


MSS is related to different transmission environments and has two recommended values. In general, the default value of-MSS is usually 536 when the target address is not a local address (which is different from the source address in a network segment); otherwise, the default value of-MSS is usually 1460. MTU is related to the network environment and has two recommended values. Generally,-the serial port is 576 bytes, and-the Ethernet is 1500 bytes.

The two recommended values of MTU and MSS are 40 bytes different, that is, the general value of (TCP Header + IP header, this value is limited to 120 bytes (20 + 20 bytes of IP/TCP Header; 40 + 40 bytes of IP/TCP optional Header ). Therefore, in a complex network environment, the maximum size of a single data packet available for the network protocol at the application layer should be less than 536-80 = 456 bytes, the limit is 1460-80 = 1380 bytes. Such restrictions are the result of comprehensive consideration of transport layer and link layer protocols. However, the 536/1460 value is also used in some common suggestions. There is no essential difference from the discussion here. I just stressed that if we want a "sufficiently optimized request", what is the limit?

  Ii. packet header in HTTP

Now, we come to the HTTP application layer protocol. An HTTP request consists of a header and a data zone. For an http get request, there can be only a header but no data zone, the reason is that the content of the HTTP header is as follows (the header must end with two consecutive carriage returns ):

[Xhtml]View plaincopy
  1. ---------
  2. GET (...) HTTP/1.1
  3. Accept :*/*
  4. Referer:
  5. Accept-Language: zh-cn
  6. User-Agent :(...)
  7. Accept-Encoding: gzip, deflate
  8. Host:
  9. Connection: Keep-Alive
  10. Cookie :(...)
  11. ---------


Here, GET (...) can be followed by a complete GET request URL, and the parameters of the GET request are also placed on this URL, so there is no need for a separate data zone. In the preceding HTTP request, some specific clients may have several or fewer http head fields, but the fields are usually relatively short. We only use this example to illustrate how many bytes are used for the "default (incomplete) HTTP header?

The answer is 184 bytes. However, it should be emphasized that Referer is directly related to the currently browsed URL. For example, the currently browsed page is a 500-byte long URL, the Referer field will fill in the 500-byte URL when the hyperlink is clicked on the current webpage. The URL that is too long in the webpage will consume more transmission when the hyperlink is clicked. This is also an example.

So we will not discuss the influence of the Referer field. Taking the preceding example as an example, the best value we can use is 456-184 = 272 bytes. The 272 bytes are used in three places: GET, User-Agent, and Cookie. The User-Agent field is related to the browser. Different browsers and the browser process different operating systems. This field is often used in JS and server statistics software to determine the browser environment, such as OS and version. The value of this field is sometimes long. Take my current machine as an example. The value is --------- Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; QQWubi 108; EmbeddedWB 14.52 from: 14.52 ;. net clr 2.0.50727; InfoPath.2 ;. net clr ;. net clr 3.5.30729 ;. net clr 1.1.4322 ;. net clr 3.5.21022 ;. NET4.0C ;. NET4.0E) --------- takes up 274 bytes. That is to say, in the ideal environment, 456 bytes is not enough. Based on the previous discussions, we can proceed to the next step:-Use the 536-byte boundary value, that is, the optional Header of the 80-byte TCP/IP is not considered.

In addition, we need to emphasize the variability of the User-Agent length, for example, the preceding "EmbeddedWB ......" 64 bytes may not exist in general computers. This is a third-party component. Similarly, this field may be longer due to other browser environments (such as aoyou. Based on this fact, I still analyze this special situation in this example.

Taking 536 bytes as an example, we actually have 78 bytes available, so here we willThe optimized level 1 is 70 bytes.It is recommended that the company obtain a balance value based on the data collected by the server.


3. COOKIE consumption can be reduced to 0

Currently, the Cookie is the largest consumption. Taking my current machine as an example, this value has several situations (for different protocols and domains, it is different ):

(1) For the homepageHttp://, With a value of 49 Bytes:Ali_apache_id =; lastpg =

(2)Http: // *, With a value of 171 Bytes:Ali_apache_id =; ali_apache_sid = | 1289988948; ALIPAYJSESSIONID = nobody; ali_apache_tracktmp = uid =

(3)Https://, With a value of 307 Bytes:Cna = Alibaba; ali_apache_id = Alibaba; payMethod = directPay; _ tb_order = 38016166656317; defaultBank = ICBC; _ utma = Alibaba; _ utmz = Alibaba = | utmccn = (referral) | utmcmd = referral | utmcct =/index. php

(4) For http (s): //, the value has a slash:Apay_id = signature; cna = AKaaAhYBhU0BAeMdAHlnHNcd; ali_apache_id = signature; payMethod = directPay; _ tb_order = 38016166656317; defaultBank = ICBC; _ utma = signature; _ utmz = 22931947.1282287558.2.2.utmcsr = | utmccn = (referral) | utmcmd = referral | utmcct =/index. php

(5) other cases.

Why does the cookie usage surge in the case of 2, 3, and 4? In fact, although there are slight differences between 3 and 4 cases, the root cause of the problem is exactly the same as that of Case 2. Therefore, this document uses case 2 as an example. After tracking the http request process, the server returns four set-cookie responses when the homepage is requested.


The four responses (http response head) are as follows :--------

Set-Cookie: ali_apache_sid = secure | 1289988948; path =/; domain = Set-Cookie: JSESSIONID = secure; Path =/Set-Cookie: ALIPAYJSESSIONID = secure; Domain =; path =/Set-Cookie: ali_apache_tracktmp = uid =; Domain =; Path =/


Therefore, all subsequent http requests will use 171-byte cookies, for example, response (3. However, obviously, these cookies are meaningless in at least the following situations:-If a redirected page is accessed, including Status Code: 302 redirection is returned, and Use http-meta redirection in html pages.-If the accessed page is cached, for example, the "Not Modified" file in Status Code 304 is returned.

Obviously, images or other static resources in img and static can be cached, And the cookie value is meaningless whether cached or accessed for the first time. For static page (.html), if we do not want to analyze the access to static pages through http server, these cookies are not required. Refer static page, we may only need to analyze the session id of the user access chain ).

The method to optimize cookies is simple: deploy these static resources in a server/group that does not use as the domain, or use other independent domain names. In this case, the COOKIE consumption can be reduced to 0 for the specific -- of course the largest part -- resource.

  4. Shorten the url

The question is: how long can a URL be? Through the previous analysis, we still have 70 million character books available, even if under certain conditions, we need to leave track data (such as session) for some page access, then we stillThere are 40 ~ 50 bytes can be used. However, we are still far from the 443 bytes mentioned in the beginning of this article.


But do we really need such a long URL?

The answer is no. we can shorten the URL. For example, in the previous example, the get part of the original URL is:

[Xhtml]View plaincopy
  1. ---------
  2. /Min? B = javascript & f = arale/lang/aspect. js, arale/lang/md5.js, arale/lang/uri. js, arale/lang/tmpl. js, arale/lang/date. js, arale/lang/number. js, arale/http/jsonp. js, arale/http/ajax. js, arale/http/core. js, arale/event/event-chain.js, arale/class/declare. js, arale/fx/animator. js, aralex/widget. js, aralex/tplwidget. js, aralex/view. js, aralex/tab. js, aralex/dropdown. js, aralex/slider. js, aralex/slider/switchslider. js
  3. ---------


After careful observation, it actually means ---------/min? B = javascript & f = ...---------

The field f is followed by some static Resources in the arale script project. On the server side, the min program is based on the parameter "B = javascript & f =... "splice some script fragments into a separate one. the js file is returned to the browser. If no change is made, the Status Code: 304 is returned directly.

In fact, the parameter blocks after the "f =..." field in each request will be exactly the same. Or, even if the list of files to be spliced is different under different circumstances, there is only a limited combination. This makes us naturally think of something: sum. In this way, calculate a key (such as hash, md5, and crc) for the preceding string, and then we can use this unique key to find the spliced key. js content-this also means that the min program does not need to splice text every time. In this way, the above URL can be changed to (take the 396-byte crc32 after the f field as an example): ---------/min? B = javascript & f = 313466DB --------- different version management considerations: ---------/min? B = javascript & v = 0.9b & f = 313466DB ---------

Now, we control the URL to a relatively small scale, and add version management and content validation. If necessary, the server-side min program can also be dynamically generated and cached. These transformations do not conflict with our original needs. It is important that we have successfully controlled the get request to 35 bytes, and the remaining space fully satisfies our needs.

Overall Optimization needs:Level 1 optimization, 70 bytes!

  V. technical maturity and Value

1. twritter has long used this technology.

2. Similar to the arale project, YQL (Yahoo! Query Language) projects have similar requirements, so they turn "upload an SQL in URL" into a short name through the above technology, for example: is equivalent to Q = select % 20 woeid % 20 from % 20geo. places % 20 where % 20 text % 3D % 22san % 20 francisco % 2C % 20ca % 22

3. Microsoft is still "stupid and unclear", so it is very slow to see their official website. ^.

4. When we have the condition to reduce the http header to less than 456 bytes, we should do our best. For example, trademanager can customize http request headers to reduce User-Agent fields because it has independent clients.

5. When we always send a minimal HTTP request from the browser, the network can always submit the request to the server as quickly as possible without waiting for multiple packages to be combined. This will be extremely effective in slow networks and networks with large volumes of packet loss. Simply put, if someone uses thunder or BT in the LAN, minimizing HTTP requests will significantly improve the web browsing experience.

6. We should manage versions of static resources such as scripts.


Q: How can I remove the length limit of url short chains?

Same solution ......
In ajax, I asked the front-end to transfer the user name and password to the background for background processing. How should I write the url in open?

Open (method, url, Async, user, password)
You? The next thing is the parameter you passed!

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.