使用最终方法最终类的必要性_如何加快您的网站-5个最终提示-CSDN博客

使用最终方法最终类的必要性

Site speed is important. It affects your users' experience directly, and a good user experience is extremely important to help drive sales and keep customers and visitors happy. Not only does it improve your site's UX, but a correctly configured website eats fewer resources and offloads work from the main server as well.

网站速度很重要。它直接影响用户的体验，良好的用户体验对于帮助推动销售并保持客户和访问者的满意度至关重要。它不仅可以改善站点的用户体验，而且配置正确的网站将减少资源消耗，并减轻主服务器的工作负担。

In this post, I'll discuss what I learned while getting an A grade on GTMetrix on codedamn - a platform for developers to learn programming in a new way. Let's start!

在这篇文章中，我将讨论我在codedamn上获得GTMetrix的A成绩时所学到的知识 -该平台为开发人员提供了一种以新方式学习编程的平台。开始吧！

1：压缩图像 (1: Compress Images)

Raw images are highly compressible, and you'd be surprised to find out how much bandwidth and data you could save just by compressing all your images.

原始图像具有高度可压缩性，您会惊讶地发现仅压缩所有图像就可以节省多少带宽和数据。

For production sites, I recommend tools like TinyPNG CLI which can compress your images on server in a directory. Here's a quick peek of how TinyPNG saved over 2MB on a high res photo I uploaded on their site:

对于生产站点，我建议使用TinyPNG CLI之类的工具，该工具可以将服务器上的图像压缩到目录中。快速浏览一下TinyPNG如何在我上传到其网站的高分辨率照片上节省了2MB以上的空间：

The great thing is TinyPNG allows 500 images free per month, so for a small to medium site, you can almost always stay inside the free quota!

很棒的事情是TinyPNG每月允许免费提供500张图片，因此对于中小型网站，您几乎可以始终停留在免费配额之内！

2：代码拆分和捆绑包拆分 (2: Code Splitting AND Bundle Splitting)

Code Splitting means that you split your code up into various chunks and lazily loading them when needed. You always need this on your site

代码拆分意味着您可以将代码拆分为多个块，并在需要时延迟加载它们。您始终在网站上需要它

Bundle Splitting refers to splitting individual files generated by code splitting further down into smaller bundles. This improves caching on browsers as well as bytecode caching by browsers.

捆绑包拆分是指将通过代码拆分生成的单个文件进一步拆分为较小的捆绑包。这改善了浏览器上的缓存以及浏览器的字节码缓存。

Although bundle splitting can be frowned upon as you increase HTTP requests, HTTP/2 has little to no impact on multiple requests until concurrency limits hit. And fortunately concurrency limits are in the range of hundreds of requests.

尽管在增加HTTP请求时可能会束缚拆分，但在并发限制达到之前，HTTP / 2对多个请求几乎没有影响。幸运的是，并发限制在数百个请求的范围内。

So if you're not making hundreds of HTTP requests (which you're probably not), you should be good with bundle splitting.

因此，如果您没有发出数百个HTTP请求(您可能没有)，那么捆绑拆分应该很好。

For code and bundle splitting, you need to integrate your project with a module bundler like parcel or webpack.

对于代码和捆绑包拆分，您需要将您的项目与模块捆绑包(如宗地或Webpack)集成。

Once you configure them correctly, they work like magic. And they can really bring down the load both on your server and on the client's browsers.

一旦正确配置它们，它们就会像魔术一样工作。它们确实可以减轻服务器和客户端浏览器的负担。

They do this by caching resources and not downloading resources you don't currently need - like, why would you want to send the JS code for /about route when I'm on /feedback route.

他们通过缓存资源而不下载当前不需要的资源来实现此目的-例如，当我在/feedback路由上时，为什么要发送/about路由的JS代码。

You should also minify your JS/CSS builds. For webpack, there are plugins like UglifyJS available. This helps reduce the size by trimming whitespaces, comments, shortening code, and so on – which will eventually reduce the size of the contents.

您还应该缩小JS / CSS版本。对于webpack，有可用的插件，例如UglifyJS。这有助于通过修剪空格，注释，缩短代码等来减小大小，最终将减小内容的大小。

3：请勿使用共享托管服务 (3: Do not use shared hosting services)

If you're a developer or someone who has a basic understanding of how to work with bash a little, there's simply no reason to go with shared hosting services.

如果您是开发人员或对bash的使用有基本了解的人，则根本没有理由使用共享托管服务。

In almost every case, either you can host your static assets for free on sites like GitHub pages, or you can go with more controlled options like cloud hosting. Almost all these cloud hosting players like AWS, Google Cloud, and DigitalOcean provide so many free credits that you can consume a lot of their services for free for a long time!

在几乎每种情况下，您都可以免费在GitHub页面等站点上托管静态资产，或者可以使用云托管等受控制的选项。几乎所有这些云托管播放器(如AWS，Google Cloud和DigitalOcean)都提供了如此众多的免费积分，您可以长期免费使用它们的许多服务！

In some cases, shared hosting is cheaper than alternatives like $5 DigitalOcean hosting. But these servers have very limited resources allocated to your website, which degrades the overall site performance. Jailed shells, shared vCPUs, and limited RAM are some things to begin with.

在某些情况下，共享托管比诸如$ 5 DigitalOcean托管这样的替代方案便宜。但是这些服务器分配给您的网站的资源非常有限，这会降低网站的整体性能。入狱的外壳，共享的vCPU和有限的RAM是一开始的事情。

Since we, as developers, always want to be in control, and going with a IaaS or a PaaS is always a solution.

由于我们作为开发人员始终希望受到控制，因此使用IaaS或PaaS始终是一种解决方案。

Although you can go with any cloud provider of your choice, I would recommend DigitalOcean - the one I use for codedamn currently. It is dead simple to setup, and you can get $100 worth of free cloud credits with this link.

尽管您可以选择任何一家云提供商，但我还是建议您使用DigitalOcean-我目前正在使用该代码的公司。设置非常简单，您可以通过此链接获得价值100美元的免费云积分。

Choosing a cloud provider can really give you resources and infrastructure which will automatically bump your server performance (and your site performance) a bit.

选择云提供商确实可以为您提供资源和基础架构，这将自动使您的服务器性能(以及站点性能)有所提高。

4：设置HTTP Expiry标头 (4: Set HTTP Expiry headers)

Just like we discussed above, caching is extremely important to setup correctly. HTTP expiry headers inform the browser what to cache and for how long. Cached resources are not fetched from the remote servers, so it's important not to cache main entrypoint resources like index.html - the first file you serve. You must also implement cache busting appropriately.

就像我们上面讨论的一样，缓存对于正确设置非常重要。 HTTP到期标头告知浏览器要缓存什么以及缓存多长时间。不会从远程服务器获取缓存的资源，因此，重要的是不要缓存主要入口点资源，例如index.html您提供的第一个文件。您还必须适当地实现缓存清除。

Again, for module bundlers like webpack, you can implement cache busting by having [contenthash] in the name of the bundles it spits out. Also, this requires that browsers never cache your index.html or any other HTML file you're using as an entrypoint to your site. How can we achieve that?

再次，对于像webpack这样的模块捆绑器，您可以通过将[contenthash]作为其退出的捆绑器的名称来实现缓存清除。此外，这要求浏览器永远不要缓存您的index.html或您用作站点入口点的任何其他HTML文件。我们如何实现这一目标？

For static file serving and HTTP expiry headers, use NGiNX. NGiNX can manage all of that stuff for you. Here's a sample configuration recommended for setting HTTP expiry headers:

对于静态文件服务和HTTP到期标头，请使用NGiNX。 NGiNX可以为您管理所有这些东西。建议使用以下示例配置来设置HTTP到期标头：

This configuration simply sets caching off for text/html resources. For others, it sets it to the maximum possible time the browser can hold the cache.

此配置只是为text/html资源设置了缓存。对于其他用户，它将其设置为浏览器可以保留缓存的最大可能时间。

Note that this configuration strongly relies on the fact that you have your cache busting mechanisms implemented in your module bundler (like the [contenthash] we talked about above).

请注意，此配置强烈依赖于您在模块捆绑器中实现了缓存清除机制的事实(例如我们上面讨论的[contenthash] )。

5：启用Brotli压缩 (5: Enable Brotli Compression)

Brotli compression is a compression algorithm designed by Google, which is 20-25% more efficient than the well-known GZIP compression.

Brotli压缩是Google设计的一种压缩算法，比众所周知的GZIP压缩效率高20-25％。

Brotli compression can be implemented on sites, again, using NGiNX. Let's take a look at an example of what happens when Brotli compression is enabled:

同样，可以使用NGiNX在站点上实施Brotli压缩。让我们看一个启用Brotli压缩时发生的示例：

The first file size is 3.33 MB - without compression.

第一个文件大小为3.33 MB-不压缩。

When it is compressed using Brotli - the size drops to 572KB.

使用Brotli压缩时-大小降至572KB。

When it is compressed using GZIP - the size only drops to 783KB.

使用GZIP压缩时-大小仅为783KB。

Brotli saves over 200KB compared to GZIP, and over 2.5MB compared to no compression. And it is not even performing at its peak! That's over 82% compression! Very cool.

与GZIP相比，Brotli可以节省200KB以上，与无压缩相比，可以节省2.5MB以上。而且它甚至还没有达到顶峰！压缩率超过82％！很酷。

而已！ (That's it!)

That's basically it! Without going much into the details of how to implement these specific techniques, we covered some of the most important things to consider when speeding up your site.

基本上就是这样！在没有详细介绍如何实现这些特定技术的细节的情况下，我们介绍了一些在加速网站时要考虑的最重要的事情。

I did not go into the specific details as your mileage may vary with your server setups and configurations - but the general concept remains same.

由于您的工作量可能会随服务器设置和配置的不同而有所不同，因此我没有详细介绍-但总体概念仍然相同。

Make sure you follow these best practices and let me know what you think by saying Hi on my twitter handle.

确保您遵循这些最佳做法，并在我的Twitter句柄上说“嗨”，让我知道您的想法。

If you liked this article, let's meet on social media. Here's my Instagram and Twitter. I'm super active, and would love to have a chat! Let's connect.

如果您喜欢这篇文章，让我们在社交媒体上见面。这是我的Instagram和Twitter 。我非常活跃，很想聊天！让我们连接。