This article is part of a series on building a sample application — a multi-image gallery blog — for performance benchmarking and optimizations. (View the repo here.)
本文是构建用于性能基准测试和优化的示例应用程序(一个多图像画廊博客)系列文章的一部分。 (在此处查看回购 。)
In this article, we’ll analyze our gallery application using the tools we explained in the previous guide, and we’ll look at possible ways to further improve its performance.
在本文中，我们将使用上一指南中介绍的工具来分析Gallery应用程序 ，并研究进一步改善其性能的可能方法。
As per the previous post, please set up Ngrok and pipe to the locally hosted app through it, or host the app on a demo server of your own. This static URL will enable us to test our app with external tools like GTmetrix and Pingdom Tools.
根据上一篇文章 ，请设置Ngrok并通过它通过管道将其传输到本地托管的应用程序，或者将该应用程序托管在您自己的演示服务器上。 该静态URL将使我们能够使用外部工具(例如GTmetrix和Pingdom Tools)测试我们的应用程序。
We went and scanned our website with GTmetrix to see how we can improve it. We see that results, albeit not catastrophically bad, still have room for improvement.
我们去了GTmetrix并浏览了我们的网站，看我们如何改进它。 我们看到，结果虽然不是灾难性的糟糕，但仍有改进的空间。
The first tab — PageSpeed — contains a list of recommendations by Google. The first item under the PageSpeed tab — a warning about a consistent URL — pertains to our application outputting the images randomly, so that is an item we will skip. The next thing we can do something about is browser caching.
第一个标签-PageSpeed-包含Google的推荐列表 。 PageSpeed标签下的第一项-有关一致URL的警告-与我们的应用程序随机输出图像有关，因此我们将跳过该项目。 我们可以做的下一件事是浏览器缓存。
We see that there is a main.css file that needs its Expires headers set, and the images in the gallery need the same thing. Now, the first idea for these static files would be to set this in our Nginx configuration:
我们看到有一个main.css文件需要设置Expires标头，并且图库中的图像需要相同的东西。 现在，这些静态文件的第一个想法是在我们的Nginx配置中进行设置：
location ~* \.(?:ico|css|js|gif|jpe?g|png)$ { expires 14d; }We can simply put this inside our server block and leave it to Nginx, right?
我们可以简单地将其放入server块中，然后留给Nginx，对吗？
Well, not really. This will take care of our static files, like CSS, but the /raw images we are being warned about aren’t really that static. So this snippet in our Nginx configuration won’t exactly fix this issue so easily. For our images, we have an actual controller that creates these on the fly, so it would be ideal if we could set our response headers right there, in the controller. For some reason, these weren’t being set properly by Glide.
好吧，不是真的。 这将处理我们的静态文件，例如CSS，但是我们被警告的/raw图像并不是真正的静态。 因此，我们的Nginx配置中的此代码片段无法如此轻松地解决此问题。 对于我们的图像，我们有一个实际的控制器来动态创建这些图像，因此，如果可以在控制器中在那里设置响应头，那将是理想的选择。 由于某些原因， Glide没有正确设置它们。
Maybe we could set our Nginx directive in a way to include the raw resources, but we felt the controller approach to be more future-proof. This is because we aren’t sure what other content may end up with an raw suffix eventually — maybe some videos, or even audio files.
也许我们可以将Nginx指令设置为包含raw资源的方式，但是我们认为控制器方法更具前瞻性。 这是因为我们不确定最终还有哪些其他内容带有raw后缀，例如某些视频，甚至是音频文件。
So, we opened /src/ImageController.php in our image gallery app, and dropped these two lines inside of our serveImageAction(), just before the line return $response:
因此，我们在图片库应用中打开了/src/ImageController.php ，并将这两行放在了serveImageAction() ，就在该行return $response ：
// cache for 2 weeks $response->setSharedMaxAge(1209600); // (optional) set a custom Cache-Control directive $response->headers->addCacheControlDirective('must-revalidate', true);This will modify our dynamic image responses by adding the proper Cache Control and Expires headers.
这将通过添加适当的Cache Control和Expires标Expires修改动态图像响应。
Symfony has more comprehensive options for the caching of responses, as documented here.
Symfony的有响应的缓存更全面的选择，如记录在这里 。
Having restarted Nginx, we re-tested our app in GTmetrix, and lo and behold:
重新启动Nginx之后，我们在GTmetrix中重新测试了我们的应用程序，瞧瞧：
Next, GTmetrix gave us a warning about the size and compression of our resources:
接下来，GTmetrix向我们发出了有关资源大小和压缩的警告：
In production, this is an insignificant thing, and improving on this wouldn’t make much of a difference in this particular case, with just a couple of kilobytes to spare. But, as these guides are here to show the way with other, more substantial applications, we’ll cover this improvement as well.
在生产中，这是微不足道的事情，并且在这种情况下进行改进不会有太大的区别，只剩下几千字节的空间。 但是，由于这些指南在这里说明了其他更重要的应用程序的方式，因此我们还将涵盖这一改进。
Images could be optimized in advance, but as these are dynamic images created with Glide, which we covered in another article, we won’t be doing that. In fact, Glide provides ways to set image quality. But sometimes we won’t be using Glide to handle our images, so we’ll first try another approach here.
可以预先优化图像，但是由于它们是使用Glide创建的动态图像，我们将在另一篇文章中介绍 ，因此我们不会这样做。 实际上，Glide 提供了设置图像质量的方法。 但是有时候我们不会使用Glide来处理图像，因此我们首先在这里尝试另一种方法。
Inside of our Nginx server block, we’ll add a couple of lines that instruct Nginx to compress our content:
在我们的Nginx server块内，我们将添加几行指令Nginx压缩我们的内容：
gzip on; gzip_disable "msie6"; gzip_vary on; gzip_proxied any; gzip_comp_level 9; gzip_buffers 16 8k; gzip_http_version 1.1; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/jpeg;An explanation of each of these settings would be out of the scope of this article. Each of these items is explained on the Nginx website, but one thing worth discussing is gzip_comp_level.
这些设置中的每一个的解释将不在本文的讨论范围之内。 在Nginx网站上解释了每个项目，但是值得一提的是gzip_comp_level 。
With compression, the common wisdom is that there’s a tradeoff. We gain some on network bandwidth, by making our files smaller, but then we lose some in our server CPU cycles required to gzip our resources on and on, on every request. Or as this Cloudflare blog post (which we’ll come back to later on) says:
通过压缩，通常的想法是需要权衡。 通过使文件变小，我们可以获得一些网络带宽，但是随后，在每次请求中不断地压缩资源所需的服务器CPU周期中，我们损失了一些带宽。 或正如Cloudflare博客文章 (我们将在稍后再讲 )中所述：
There is a tradeoff between compression speed and transfer speed. It is only beneficial to increase your compression ratio if you can reduce the number of bytes you have to transfer faster than you would actually transfer them.
在压缩速度和传输速度之间需要权衡。 仅当您可以减少传输的字节数比实际传输它们的速度更快时，增加压缩率才是有益的。
This is why people rarely set gzip_comp_level to the maximum 9, like we did. They usually settle for something like 6. This way, visitors still get compressed resources, but the CPU still isn’t being put under a big strain, especially during traffic spikes.
这就是为什么人们很少像我们一样将gzip_comp_level设置为最大9。 他们通常会选择大约6。这样，访问者仍然可以获得压缩的资源，但是CPU仍然不会承受太大的压力，尤其是在流量高峰期间。
But we won’t follow this common advice for two reasons: first, in production, odds are we would be deploying our application on a CDN, which would remove the burden from our server altogether, and second, even if we don’t use a CDN, we will use page caching, so this gzipping done by our server will — hopefully — be done just once per resource. And, with our browser caching fully on, even these cached gzipped resources won’t be requested so often.
但是由于两个原因，我们不会遵循此通用建议：首先，在生产中，我们很可能会将应用程序部署在CDN上 ，这将完全减轻服务器的负担；其次，即使我们不使用， CDN，我们将使用页面缓存，因此我们希望服务器完成的gzip压缩每个资源只需执行一次。 而且，在我们的浏览器完全缓存的情况下，即使是这些缓存的压缩资源也不会经常被请求。
So, this is the rationale to set our gzip_comp_level to 9, but in case we don’t intend to use page/HTTP caching, we would probably set this to a smaller number.
因此，这是将gzip_comp_level设置为9的理由，但是如果我们不打算使用页面/ HTTP缓存，则可以将其设置为较小的数字。
By doing this, we were able to improve our gzip result:
这样，我们可以改善gzip结果：
We weren’t able to achieve the same improvement with our images, though. So, we went back to the Glide documentation and found how to control the quality of our images: inside our serveImageAction() inside our ImageController, we found the line:
但是，我们无法通过图像获得相同的改进。 因此，我们回到了Glide文档 ，发现了如何控制图像的质量：在ImageController serveImageAction()内，我们找到了以下行：
$cachePath = $glide->getGlide()->makeImage($file, ['w' => $size]);We added a quality argument to the makeImage() second array argument:
我们在第二个makeImage()数组参数中添加了quality参数：
$cachePath = $glide->getGlide()->makeImage($file, ['w' => $size, 'q' => 60]);We didn’t want to set the image quality lower than that, because it wouldn’t look good:
我们不想将图像质量设置为低于此值，因为它看起来不太好：
Then we deleted all the images in our /var/uploads/cache folder, and retested. Our results on GTmetrix showed we were able to improve by 5%:
然后，我们删除了/var/uploads/cache文件夹中的所有图像，并进行了重新测试。 我们在GTmetrix上的结果表明，我们可以提高5％：
There’s still room for improvement, but in 99% cases, the steps we took to improve our images will be enough.
仍有改进的空间，但是在99％的情况下，我们采取的改善图像的步骤就足够了。
We also went to Pingdom Tools to check our website — and we were surprised to see that we got a 100% score. Although the page load time was still not what it should be, this was a significant improvement from the 92% score we got earlier:
我们还去了Pingdom Tools检查我们的网站-我们很惊讶地看到我们获得了100％的分数。 尽管页面加载时间仍然不是应该的，但与我们之前获得的92％得分相比，这是一个显着的改进：
These recommendations are a useful guideline, but our 100% score would be a mere vanity metric if our load time were to remain at 4.21 seconds, so we turned on Nginx caching we wrote about in Server-side Optimization with Nginx and pm-static. With caching enabled, our result was now 100% across all metrics, and our load time below 1 second:
这些建议是有用的指导，但是如果我们的加载时间保持在4.21秒，我们的100％得分将仅仅是虚荣的指标，因此我们打开了我们在Nginx和pm-static的服务器端优化中编写的Nginx缓存。 启用缓存后，所有指标的结果现在为100％，加载时间不到1秒：
We are attaching a HAR file of this test.
我们将附加此测试的HAR文件 。
Although we achieved 100 out of 100 with Pingdom Tools, there are metrics which are not 100% satisfied both on YSlow and PageSpeed (GTmetrix). However, these things are out of our hands — like the minification of resources (jQuery and Bootstrap) served by other CDNs. We could download and minify them, but it’s questionable how useful this would be considering most people already have them downloaded in their browser due to the resources’ widespread adoption.
尽管我们使用Pingdom Tools达到了100的100，但是有些指标在YSlow和PageSpeed(GTmetrix)上都不能100％满足。 但是，这些事情是我们无法控制的，就像其他CDN提供的资源(jQuery和Bootstrap)的最小化一样。 我们可以下载并缩小它们，但是考虑到由于资源的广泛采用，大多数人已经将它们下载到浏览器中，这是否有用呢？
There are things we didn’t cover in this article which would be recommended in production — or at least worth exploring — like Brotli compression. The people over at Cloudflare have written an interesting blog post about their results with this compression algorithm. As with all other things, before actual implementation it would be necessary to test it thoroughly on different kinds of resources and visitors’ connections. In our opinion, with HTTP caching enabled, even the CPU compression cost possibly incurred by high a compression ratio would still pay off, because it’s a one-time cost.
有些我们在本文中没有介绍的东西会在生产中被推荐，或者至少值得探索，例如Brotli压缩。 Cloudflare的人们写了一篇有趣的博客文章，介绍了使用这种压缩算法的结果。 与所有其他内容一样，在实际实施之前，有必要对各种资源和访问者的连接进行全面测试。 我们认为，启用HTTP缓存后，即使压缩率较高而可能导致的CPU压缩成本也将得到回报，因为这是一次性成本。
Nginx’s module for Brotli compression can be found here. This topic is further explored in this article.
Nginx的Brotli压缩模块可以在这里找到。 这个话题在进一步探讨这篇文章 。
If you know of any other improvements that could significantly impact performance, let us know!
如果您知道其他可能会显着影响性能的改进，请告诉我们！
翻译自: https://www.sitepoint.com/improving-performance-perception-pingdom-gtmetrix/
相关资源：jdk-8u281-windows-x64.exe