9 Rules to Increase the Speed ​​of your Website

9 Rules to Increase the Speed ​​of your Website Mars664

9 Rules to Increase the Speed ​​of your Website

Here is a breakdown of Google PageSpeed ​​Insight Rules and recommendations of best practices on optimizing web pages for greater speed performance. Because the need for speed never stops.

If you've put your URL into Google's PageSpeed ​​Insights in the last month, you'll have noticed that it looks a little different. Where you used to receive a simple optimization score, your scores are now broken down by platform and split into two scores, “Page Speed” and “Optimization.”

 

The changes were made as a result of the new speed update released on July 9, 2018. Now, instead of relying on lab data, Google uses field data to measure site speed. By pulling information from the Chrome User Experience Report (CrUX) database, Google can discern how quickly the average user finds your site.

 

That means that even if your website is extremely fast, visitors with older smartphones may experience lags, which could affect your speed score and possibly your website's ranking. If you haven't already, it's time to double down. speed optimization.

 

I'm going to break down Google's nine PageSpeed ​​Insight rules, list their best practice recommendations, and then dive into some advanced steps you can take to further optimize your site speed.

 

1. Avoid landing page redirects

Why it's important, redirecting slows down page rendering and slows down your mobile site experience. Each redirect adds hypertext transfer protocol (HTTP) and sometimes adds numerous additional traversals to also perform domain name system (DNS) lookup, transmission control protocol (TCP), and transport layer security. (TLS).

What Google recommends. Create a responsive website with no more than one redirect from a given URL to the final destination page.

Advanced recommendations. Try to avoid redirects completely. However, if you need to use redirects, choose the type of redirect according to your need:

  • 301 vs 302 Redirect. Use permanent redirects (301) when you remove old content and redirect to new content, or when you don't have an alternative page to redirect users. Use temporary redirects (302) when you make short-term changes, such as limited-time offers or when redirecting users to device-specific URLs. Don't worry, you won't lose the link value in any way!
  • JavaScript Redirection vs. HTTP. The main difference between JavaScript and HTTP redirects is that HTTP redirects cause some latency on the server side, while JavaScript-based redirects slow down the client side (they need to download the page, then parse and execute the JavaScript before activating the redirect) Googlebot supports both types of redirects.

 

2. Enable compression

Because it is important. Reducing the size of your content shortens the time it takes to download the resource, reduces data usage for the client, and improves page rendering time.

What Google recommends. Gzip all compressible content. You can find sample configuration files for most servers through the HTML5 Boilerplate project.

Advanced recommendations

  • Prioritize removing unnecessary data. Compression is great, but the best optimized resource is an unsent resource. Review your site's resources periodically and remove unnecessary data before compression to ensure the best results.
  • Consider alternatives to Gzip encoding. If you want to use a tool other than Gzip, Brotli is a lossless compression algorithm that combines a modern variant of the LZ77 algorithm, Huffman coding and second-order context modeling. It is supported by all modern browsers and has a compression ratio comparable to the best general-purpose compression methods currently available. Brotli compresses very slowly and decompresses quickly, so you should precompress static assets with Brotli + Gzip at the highest level and compress dynamic HTML with Brotli at level 1-4.
  • Use different compression techniques for different resources. Compression can be applied to HTML code, as well as various digital resources that your page requires, but you will need to apply different techniques and algorithms to your web fonts, images, CSS, etc. to achieve the best result. For example, if you are using HTTP/2, using HPACK compression for HTTP response headers will reduce unnecessary overhead.

 

3. Improve server response time

Because it is important. Fast server response times are a must; 53 percent of mobile visitors will abandon a page that doesn't load within three seconds.

High-quality website development is essential if you want to avoid central processing unit (CPU) starvation, slow application logic, slow database queries, slow routing, slow frames, and slow libraries.

What Google recommends. Server response time should always be less than 200 ms.

 

Advanced recommendations

  • Measures server response time and real user measurements (RUM). Use a tool like WebPageTest.org, Pingdom, GTmetrix, or Chrome Dev Tools to identify existing performance issues and discover what's slowing down your content delivery process. Remember, even if your tests show a site speed <200 ms, a user on an older generation of Android with slow 3G could experience 400 ms RTT and a transfer speed of 400 kbps. This will have a negative impact on your site speed score. To improve this user's experience, you should aim to:
  •   A first significant painting <1s.
  •   A SpeedIndex value <1250.
  •   Transmission time interval (TTI) <5s and <2s for repeat visits.

 

Optimize for user experience. While you configure your server:

  • Use HTTP/2 (and remember that your CDNs also support HTTP/2) to increase performance.
  • Enable Online Certificate Status Protocol (OCSP) stapling on your server to speed up TLS handshakes.
  • Supports both IPv6 and IPv4. IPv6 Neighbor Discovery (NDP) and route optimization can make websites 10-15 percent faster.
  • Adds resource hints to warm up the connection and speed up delivery with faster DNS lookup, preconnect, prefetch, and prefetch.

 

4. Take advantage of browser caching

Because it is important. When searching for resources on the network, more round trips are needed between the client and the server, which means more delays and higher data costs for visitors. You can mitigate this slow and expensive process by implementing a caching policy that helps the client determine if and when it can reuse responses it has returned in the past.

What Google Recommends Responsive Explicit Cache Policies:

  1. Whether a resource can be cached.
  2. Who can cache it
  3. How long will it be cached?
  4. How to efficiently revalidate (if applicable) when the cache policy expires.

Google recommends a minimum cache time of one week and up to one year for static assets.

 

Advanced recommendations

 

  • Use Cache-Control to eliminate network latency and avoid data charges. Cache control policies let you automatically control how (for example, “no cache” and “no storage”) and for how long (for example, “max-age”, “max-stale” and “mini-fresh”). ) the browser can cache a response without needing to communicate with the server.
  • Use ETags to enable efficient revalidation. Entity Tag (ETag) HTTP headers communicate a validation token that prevents data from being transferred if a resource has not changed since it was last requested. This improves the efficiency of resource update checks.
  • See Google's recommendations for an optimal cache control policy. Google has created a checklist and flowchart that will help you store as many responses as possible for the longest possible period and provide validation tokens for each response:

The rule of thumb is that mutable (i.e., likely to change) resources should be cached for a very short time, while immutable (i.e., static) resources should be cached indefinitely to avoid revalidation.

 

5. Minify HTML, CSS and JavaScript

Because it is important. Shrinking removes redundant data from the resources delivered to your visitors, and can have a drastic impact on overall site speed and performance.

What Google recommends. That there is no redundant data within your web assets (for example, comments or spatial symbols in HTML code, repeated styles in CSS or unnecessary image metadata).

Advanced recommendations

 

  • Use minification in conjunction with compression. At first glance, minification sounds like compression, but it is much more granular. Compression algorithms are great for reducing page size, but most don't know how to remove unnecessary code from CSS (/*…*/), HTML () and JavaScript (//…) comments, collapse sheets cascading style (CSS) rules or perform dozens of other content-specific optimizations.
  • Apply minification to other types of resources as well. You can minify more than just text-based resources like hypertext markup language (HTML), CSS, and JavaScript. Images, videos and other types of content can also be minimized depending on your need. For example, images contain their own forms of metadata and various payloads, which you may want to retain if you post them to a photo-sharing site.
  • Automate minification. Use tools to ease the burden of minimizing thousands (if not millions) of different resources on your website. Google's page speed module does this automatically and can integrate with Apache or Nginx web servers. Alternatively, you can use third-party tools like HTMLMinifier (for HTML), CSSNano or CSSO (for CSS), and UglifyJS (for JavaScript).

 

6. Optimize images

Because it is important. Images make up an average of 60 percent of your web page size, and large images can slow your site to a crawl. Image optimization helps by reducing file size without significantly affecting visual quality.

What Google recommends. Make sure your website and images are responsive. Use relative sizes for images, use the image element when you want to specify different images based on device characteristics, and use an srcset attribute and the x descriptor on the img element to tell browsers when to use specific images.

Advanced recommendations

Follow this checklist of the most common optimization techniques:

 

  • Remove unnecessary image resources.
  • Take advantage of CSS3 to replace images.
  • Use web fonts instead of encoding text into images.
  • Use vector formats where possible.
  • Minimizes and compresses scalable vector graphics (SVG) assets to reduce their size.
  • Choose the best raster formats (start by selecting the right universal format: GIF, PNG, or JPEG, but also consider adding WebP and JPEG Extended Range (XR) format assets in image formats for modern clients.
  • Experiment with optimal quality settings. Remember that there is no single best format or “quality setting” for all images: each combination of particular compressor and image content produces a unique output.
  • Resize on the server and serve images scaled to their display size.
  • Remove metadata
  • Enhances img tags with a srcset parameter for high dots per inch (DPI) devices.
  • Use the image element to specify different images based on device characteristics such as device size, device resolution, orientation, and more.
  • Use image spriting techniques carefully. With HTTP/2, it may be better to upload individual images.
  • Consider lazy loading for non-critical images.
  • Cache your image assets.
  • Automate your image optimization process.

When it comes to image optimization, there is no single “best” way to do it. Many techniques can reduce the size of an image, but finding the optimal settings for your images will require careful consideration of formatting capabilities, encoded data content, quality, pixel dimensions, and more. For more tips, visit Google guide to Optimize images.

 

7. Optimize CSS delivery

Because it is important. Browsers typically follow these five steps when rendering a page:

  1. Processes the HTML markup and creates the document object model (DOM) tree.
  2. Processes CSS markup and creates the CSS object model (CSSOM) tree.
  3. Combines the DOM and CSSOM into a rendering tree.
  4. Run the layout in the render tree to calculate the geometry of each node.
  5. Paint the individual nodes on the screen.

In other words, a page needs to render CSS before it can be rendered. When your CSS is full of external style sheets that block rendering, this process often requires multiple round trips, which will delay the time to the first render.

What Google recommends. Embed small CSS directly into the HTML document to eliminate small external CSS resources.

Advanced recommendations

 

  • Avoid including large CSS files. While including small CSS can speed up the time it takes a browser to render the page, including large CSS files will increase the size of your CSS and actually slow down rendering time.
  • Avoid including CSS attributes. Likewise, embedding CSS attributes in HTML elements often results in unnecessary code duplication, and is blocked by default with a Content Security Policy.

 

8. Prioritize visible content

Because it is important. If your above-the-fold content exceeds the initial congestion window (typically 14.6kB compressed), then loading your content will require multiple round trips to load and render your content. This can cause high latencies and significant page loading delays, especially for mobile users.

What Google recommends. Reduce content size by more than half to no more than 14kB (compressed).

Advanced recommendations

 

  • Limit data size necessary to display the content above the fold. If you've followed suit, you should already be using asset minification, image optimization, compression, and all the other tips and tricks to reduce the size of your above-the-fold content.
  • Organize your HTML markup to process above-the-fold content immediately. Changing the HTML markup structure can greatly speed up the speed at which your above-the-fold content loads and renders, but what you change will vary from page to page. For example, it may be necessary to split your CSS into different parts: an inline part responsible for styling the part of the content above the fold, and a style sheet that defers the remaining part. Or you may need to first change the order of what loads on your page (e.g. main content before widgets).

 

9. Remove display-blocking JavaScript

Because it is important. You may remember from tip no. Myth #7 that a page needs to build its DOM by parsing the HTML before a browser can display your page. Well, every time a parser encounters JavaScript, it has to stop and run this new script before it can continue building the DOM tree. This delay is even more pronounced in the case of an external script, and can add tens of thousands of milliseconds to the rendering process.

What Google recommends. Removes all blocking JavaScript, especially external scripts, in above-the-fold content.

Advanced recommendations

 

  • Make JavaScript not render the block. Marking the script tag as a sync will tell the browser not to block construction of the DOM while waiting for the script to load and run. However, you should only do this if you know that you don't need to change anything within the DOM tree while it is being parsed/built.
  • Inline critical scripts and defer non-critical scripts. Scripts that are necessary to render the page content must be embedded to avoid additional network requests. These should be as small as possible to run quickly and provide good performance. Non-critical scripts should be made asynchronous and deferred until after the first render. Just remember that asynchronous scripts are not guaranteed to run in a specific order.
  • Defer third-party JavaScript libraries until later. JavaScript libraries that improve interactivity or add animations or other effects (e.g., JQuery) generally do not need to be presented above the fold. Whenever possible, make these JavaScript elements asynchronous and defer them on the page.