This article has participated in the third “topic writing” track of the Denver Creators Training Camp. For details, check out: Digg Project | Creators Training Camp third is ongoing, “write” to make a personal impact.

This article summarizes the methods of HTTP to improve the speed of network loading, perhaps not according to the specific page opening process.

The purpose is to better grasp how to optimize the relevant links. Thank you for your support

I have written two articles about the optimization of DNS and TCP:

Analysis of Web optimization from URL to page presentation (I, DNS and CDN)

Analysis from URL to page presentation Web optimization (II, TCP optimization)

I won’t repeat it here, hahaha

HTTP caching

The cache location

  • Service Worker(just look at caching for now)

    • The Worker thread running in the background can act as a proxy server to intercept requests initiated by users.
    • It must be HTTPS, which ensures security because request interception is involved.
    • Files can be cached locally and loaded directly from the cache for faster access.

  • Menory

    • In-memory cache. The duration is short, the process is released as soon as it’s released.
    • It is mainly the styles, scripts, images and other resources that have been downloaded on the page.

  • Disk

    • Cache in hard disk.
    • It is slower to read than Menory, but has a large storage capacity and a long storage time.

  • Push

    • Push caches, which are in HTTP2, are used when none of the above caches are hit.
    • Note: it only exists in the Session, is released when the Session ends, and the cache is short.

Process of caching

As shown above, the browser cache process is as follows:

  • The browser makes an HTTP request
  • A browser cache hit notifies the browser that the cache result and cache id for the current request are not in the cache
  • The browser makes an HTTP request to the server
  • The server returns the request result and the cache rule
  • The browser stores cache results and cache identifiers

Caches are classified into strong cache and negotiated cache.

Strong caching takes precedence over negotiated caching. If strong caching is in effect, the cache continues to be used, otherwise negotiated caching is performed.

Negotiation cache is determined by the server whether to use the cache. If the cache fails, the server will return the corresponding HTTP response and the cache id, 200 status code, and then save the cache in the browser. If it takes effect, the 304 status code is returned and the cache continues to be used.

If neither strong cache nor negotiated cache is set, the browser uses heuristic algorithms, which typically take 10% of the Date minus last-Modified value in the response header as the cache time.

Strong cache

Resources are read directly from the cache without making a request to the server.

Strong cache The cache is determined by whether the specified cache time or time period has been exceeded, regardless of whether the server file has been updated, which may cause the loaded file is not the latest file on the server. (If you need to determine whether the server file has changed, you need to negotiate the cache)

HTTP1.0’s strong cache is Expires:

  • The cache is the expiration time on the server.
  • Limited by local time, if the user changes the local time, it is useless.

HTTP2.0’s strong Cache is cache-control:

  • Set the expiration time period, that is, the number of seconds after the server time expires. If the URL changes, a new request is initiated. Hash directories that work well with Webpack.
  • Code code for 200

When two caches exist simultaneously, catch-control takes precedence over Expries.

Negotiate the cache

When the forced cache is invalid, it sends a request to the server with the cache id. The server decides whether to use the cache based on the cache ID. If the negotiated cache exists, return the status code 304 and Not Modified

Here is the request flow for a valid negotiation cache:

  • The browser sends the HTTP request first and the request is cached by the browser first
  • The browser cache determines whether the cache is valid and returns the cache id if the strong cache is invalid
  • The browser carries a cache identifier and makes an HTTP request to the server
  • The server receives the cache identifier, checks whether the requested resource has changed, and returns 304 to inform the browser that the resource has not been updated and uses the local cache
  • The browser requests the cached results again
  • Browser cache returns browser cache resources

If the negotiation cache is invalid, the status code 200 is returned

Here is the request flow for negotiating cache invalidation:

  • When the browser initiates an HTTP request, the request is cached by the browser
  • Browser strong cache invalidation returns cache id
  • The browser carries a cache identifier and sends an HTTP request to the server
  • The server determines whether the resource is updated and returns 200 in response to the new resource and cache identity
  • The browser stores resources and cache identifiers in the browser cache

HTTP1.0’s negotiated cache is last-modified:

  • View the time when the resource was last modified on the server and compare it to the time in the cache identifier.
  • One problem is that if the current resource is modified, but only with an extra space or the actual content has not changed, the browser will still be returned with the 200 status, the new resource and the cache id.

HTTP2.0’s negotiation cache is Etag:

  • A value is set, such as:ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4If the resource of the response has not changed, the cache is used.
  • If it changes, it responds again and gives a new value.

Caching improves the speed of HTTP requests, which in turn increases the speed of network loading.

Second, the HTTP Cookies

An HTTP Cookie is a small piece of data that the server sends to the user’s browser and stores locally. It is carried and sent to the same server the next time the browser makes a request.

Cookies are mainly used in the following three aspects:

  • Session state management (such as user login status, shopping cart, game score, or other information)
  • Personalization (such as user-defined Settings, themes)
  • Browser behavior tracking (e.g. tracking and analyzing user behavior)

Create a Cookie

When the server receives an HTTP request, it can add the set-cookie option to the response header.

When the browser receives the response, it stores the Cookie. Each subsequent request carries the information to the server through the Cookie request header.

The server uses set-cookie:

HTTP/1.0 200 OK Content-type: text/ HTML set-cookie: yummy_cookie=choco set-cookie: tasty_cookie=strawberryCopy the code

The browser saves the Cookie and sends it to the server with each request:

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry
Copy the code

Define the Cookie lifecycle

There are two ways to the Cookie lifecycle:

  • Session cookies are the simplest Cookie: they are automatically deleted after the browser is closed. Session cookies don’t need to specify Expires or max-age

  • The lifetime of a persistent Cookie depends on Expires or a period of time specified by max-age.

Such as:

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
Copy the code

Note: When the Cookie expiration time is set, the date and time are only relevant to the client, not the server.

Limit the Cookie

There are two ways to ensure that cookies are sent securely and not accessed by unexpected actors or scripts: the Secure property and the HttpOnly property.

  • Secure

    • Cookies marked with this attribute should only be sent to the server through HTTPS encrypted requests.
    • However, even if Secure is set, sensitive information should not be transmitted through cookies because Secure does not provide a solid guarantee of security.
    • For example, someone with access to a customer’s hard drive can read it and repair the computer.

  • HttpOnly

    • The Document. cookie API in JavaScript cannot get/access cookies with an HttpOnly attribute.
    • This type of Cookie applies only to the server.
    • This helps mitigate XSS attacks.

Such as:

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
Copy the code

Cookie scope

The Domian and Path identifiers define the scope of the Cookie:

  • Domian:

    • Specifies which hosts can accept cookies. If not specified, the default is Origin and the subdomain name will not be included.
    • If specified, subdomain names will be included. That is, the child domain gets the Cookie of the parent domain.
    • For example, if you setDomain=mozilla.org, the mozilla.org subdomain will be able to use his Cookie.

  • Path

    • Defines which paths under the host can accept cookies. The subpaths are also matched.
    • For example, if path=/d, /d/c under /d will also be matched.

  • SameSite

    • Prevents cross-site request forgery attacks (CSRF) by allowing the server to request that a Cookie not be sent by the browser during a cross-site request.
    • Such as:Set-Cookie: key=value; SameSite=Strict
    • SameSite has three values:
    • None: The browser continues to send cookies in both same-site and cross-site requests, case insensitive.
    • Strict: The browser sends cookies only when visiting the same site.
    • Lax: The browser only sends a Cookie when visiting the same site, but the user carries a Cookie when navigating to a URL from an external site. The default option is available in newer browsers.

There are also some properties of document.cookie:

  • name
    • Field is required when creating or overwriting the name of a cookie
  • value
    • The value of the cookie
  • end
    • Expiration time set, number of seconds (Cookie that will never expire is Infinity). If not defined, it ends at the end of the session.
  • path
    • Same path as described above
  • domain
    • Same as the domain described above
  • secure
    • Same as Secure described above

To optimize the

The ability to speed up network requests by reducing the passing of cookies, such as the current request carrying all Cookie values. You can speed up requests by setting those cookies that do not need to be passed.

For example, in a cross-domain request, some of the values of the Cookie do not need to be passed and can be processed with the SameSite value Strict. For requests that require cookies, you can use path.

conclusion

This article focuses on HTTP caching and cookies, and how to optimize HTTP requests based on them.

  • HTTP cache is used to optimize HTTP requests
  • Reduce cookies to optimize HTTP requests