Web性能技巧-超越基础

最新推荐文章于 2023-05-20 08:28:03 发布

culh2177

最新推荐文章于 2023-05-20 08:28:03 发布

阅读量312

点赞数

文章标签： python java javascript 大数据人工智能 ViewUI

原文链接：https://www.sitepoint.com/web-performance-tricks-beyond-basics/

版权

This article was sponsored by New Relic. Thank you for supporting the sponsors who make SitePoint possible!

本文由New Relic赞助。 感谢您支持使SitePoint成为可能的赞助商！

We’ve had a lot of performance talk over the years here at SitePoint, and we believe it’s time to revisit the topic with some more advanced aspects. The approaches mentioned in this article won’t be strictly PHP related, but you can be sure they’ll bring your application to a whole new level if used properly. Note that we won’t be covering the usual stuff – fewer requests for CSS, JS and images meaning faster websites and similar hints are common knowledge. Instead, we’ll be focusing on some less known/used upgrades.

多年来，我们在SitePoint上进行过很多性能讨论，并且我们认为是时候从一些更高级的方面重新讨论该主题。本文中提到的方法与PHP并不完全相关，但是可以肯定的是，如果使用得当，它们会将您的应用程序提升到一个全新的水平。请注意，我们不会介绍常见的内容–对CSS，JS和图像的请求更少，这意味着更快的网站和类似的提示是常识。相反，我们将专注于一些鲜为人知/未使用的升级。

HTML (HTML)

删除不必要的标签 (Remove unnecessary tags)

The fewer elements, the better. Remove unnecessary HTML.

元素越少越好。删除不必要HTML。
```
<div>
    <div>
        <p>Some of my<span>text</span>.</p>
    </div>
</div>
```
vs.

与
```
<div>
    <p>Some of my<span>text</span>.</p>
</div>
```
Not applicable to all scenarios, of course, but structure your HTML in a way which lets you remove as many DOM elements as possible.

当然，并非适用于所有情况，而是以允许您删除尽可能多的DOM元素的方式来构造HTML。

You can also reduce the filesize of HTML documents by omitting some tags that aren’t needed. This does tend to look rather hacky and seems to go against standards, so it should only be done when deploying to production if at all – that way you don’t confuse other developers who work on the same code.

您还可以通过省略一些不需要的标签来减少HTML文档的文件大小。这看上去确实很hacky，似乎违反了标准，因此仅在完全部署到生产环境时才应该这样做—这样您就不会混淆其他使用相同代码的开发人员。
预取 (Prefetch)

Prefecthing is when you tell the browser a resource will be needed in advance. The resource can be the IP of a domain (DNS prefetch), a static resource like an image or a CSS file, or even an entire page.

完善是指您事先告知浏览器将需要资源。该资源可以是域的IP(DNS预取)，静态资源(例如图像或CSS文件)，甚至是整个页面。

When you expect the user to go to another domain after visiting your site, or, for example, you host your static resources on a subdomain like images.example.com, DNS prefetching can help remove the few miliseconds it takes for the DNS servers to resolve images.example.com to an IP address. The gain isn’t much, but accumulated, it can shave off some decent loading time off the requests you make your user’s browser do. DNS prefetching is done with a <link> in the <head> like so: <link href="//images.example.com" rel="dns-prefetch" /> and is supported in all major browsers. If you have any subdomains you expect the current visitor to load after they’re done with the page they’re currently on, there’s no reason not to use DNS prefetch.

如果您希望用户在访问您的站点后会转到另一个域，或者例如，将静态资源托管在像images.example.com这样的子域上，则DNS预取可以帮助消除DNS服务器花费的几毫秒的时间。将images.example.com解析为IP地址。收益虽然不多，但却是累加的，可以节省您使用户浏览器执行的请求所花的时间。 DNS预取是通过<head> <link>中的<link>完成的，如下所示： <link href="//images.example.com" rel="dns-prefetch" />并且在所有主流浏览器中都支持。如果您有任何子域，希望当前访问者完成对当前访问页面的加载，则没有理由不使用DNS预取。

When you know some resources are going to be needed on the next visit, you can prefetch them and have them stored in the browser cache. For example, if you have a blog and on that blog a two-part article, you can make sure the static resources (i.e. images) from the second part are pre-loaded. This is done like so: <link href="//images.example.com/sept/mypic.jpg" rel="prefetch" />. Picasa Web Albums uses this extensively to pre-fetch 2 following images to the one you’re currently viewing. On older browsers, you can make this happen by loading a phantom Image element in JavaScript:

当您知道下次访问需要一些资源时，可以预取它们并将其存储在浏览器缓存中。例如，如果您有一个博客，并且在该博客上有两部分，则可以确保第二部分的静态资源(即图像)已预先加载。这样做是这样的： <link href="//images.example.com/sept/mypic.jpg" rel="prefetch" /> 。 Picasa网络相册广泛使用此功能将以下2张图像预取到您当前正在查看的图像。在较旧的浏览器上，可以通过在JavaScript中加载幻影Image元素来实现此目的：
```
var i = new Image();
i.src = 'http://images.example.com/sept/mypic.jpg';
```
This loads the image into the cache, but doesn’t use it anywhere. This method won’t work for CSS and JS files, though, so you’ll have to be inventive with those resources if you want them prefetched on ancient browsers. XMLHttpRequest springs to mind – load them via ajax, and don’t use them anywhere. See here on how to pull that off.

这会将图像加载到缓存中，但不会在任何地方使用它。但是，此方法不适用于CSS和JS文件，因此，如果希望在古代浏览器中预取这些资源，则必须对这些资源进行创新。想到了XMLHttpRequest –通过ajax加载它们，不要在任何地方使用它们。有关如何实现此目标的信息，请参见此处。

One thing to be mindful of is prefetching only the resources we’re certain or almost certain the user will need. If the user is reading a paginated blog post, sure, prefetch. If the user is on a form submission screen, definitely prefetch the resources they can expect on the screen they get redirected to after submitting. Don’t prefetch your entire site, and don’t prefetch randomly – consider the bandwidth, and use prefetching sparingly, keeping mobile devices in mind. Mobile devices are typically on limited bandwidth, and pre-downloading a 2MB image probably wouldn’t be very user friendly. You can avoid these issues by selectively prefetching – detect when a user is on a mobile device or on a limited bandwidth connection and don’t use prefetching in those cases. Better yet, add settings to your website and ask people to agree to prefetching – save their preference into localStorage and hash it with the user agent string, allowing them to allow or disallow prefetching on every device separately.

要注意的一件事是仅预取我们确定或几乎确定用户将需要的资源。如果用户正在阅读分页的博客文章，请确保预取。如果用户在表单提交屏幕上，则一定要预取他们可以在提交后重定向到的屏幕上期望的资源。不要预取整个站点，也不要随意预取–考虑带宽，并谨慎使用预取，牢记移动设备。移动设备通常带宽有限，并且预先下载2MB的图像可能对用户不太友好。您可以通过选择性地进行预取来避免这些问题-检测用户何时在移动设备或有限带宽的连接上，并且在这种情况下不使用预取。更妙的是，将设置添加到您的网站，并要求人们同意预取–将其首选项保存到localStorage中，并使用用户代理字符串对其进行哈希处理，从而允许他们分别允许或禁止在每个设备上进行预取。

You can also prefetch and prerender entire pages. Prefetching pages means fetching their DOM content – the HTML. This usually doesn’t provide much of a speed boost due to most of the content actually being in JavaScript, CSS and images – content not fetched by the page prefetch. This type of fetching is currently only fully supported by Firefox. Prerendering is another matter – prerendering is only in Chrome, and it not only fetches the DOM behind the scenes, but also all related content in the form of CSS, JS and images. In fact, it already renders the entire page in the background – the page is sitting in RAM, fully opened and rendered, waiting to be visited. This allows the change to be instant when a user clicks the prerendered link, but introduces the same problems as described in the previous paragraph – bandwidth can suffer. Additionally, your server registers this prerender as a visit, so you might get some skewed analytics if the user actually changes his mind and doesn’t end up opening the prerendered website. The prerender syntax is: <link rel="prerender" href="http://example.com/sept/my-post-part-2">.

您还可以预取和预呈现整个页面。预取页面意味着获取其DOM内容-HTML。由于大多数内容实际上都在JavaScript，CSS和图像中，而这些内容通常不是通过页面预取来获取的，因此通常不会提供很大的提速。 Firefox目前仅完全支持这种类型的提取。预渲染是另一回事–预渲染仅在Chrome中，它不仅获取幕后的DOM，而且还获取所有相关内容，包括CSS，JS和图像的形式。实际上，它已经在后台渲染了整个页面–该页面位于RAM中，完全打开并渲染，等待访问。这样，当用户单击预渲染的链接时，更改就可以立即进行，但是会带来与上一段所述相同的问题-带宽可能会受到影响。此外，您的服务器会将这个预渲染的网站注册为访问，因此，如果用户实际上改变了主意并且最终没有打开该预渲染的网站，则可能会得到一些偏斜的分析。 prerender语法为： <link rel="prerender" href="http://example.com/sept/my-post-part-2"> 。

At the moment, there is only one proper way to detect your page being prerendered or prefetched, and that’s with the Page Visibility API, which is currently supported in all major browsers except the Android browser and Opera Mini. You use this API to make sure the page is actually being watched, and then initiate any analytics tracking you might be doing.

目前，只有一种正确的方法可以检测到页面是否已被预渲染或预取，而Page Visibility API就是该方法，当前除Android浏览器和Opera Mini之外，所有主流浏览器均支持该功能。您可以使用此API来确保实际上正在监视页面，然后启动您可能正在执行的任何分析跟踪。

CSS (CSS)

CSS Lint (CSS Lint)

Use CSSLint to validate your CSS and point out errors and potential performance problems. Read and respect the rules as put forth in the CSSLint wiki to write the most efficient possible CSS.
使用CSSLint验证您CSS并指出错误和潜在的性能问题。阅读并遵守CSSLint Wiki中提出的规则，以编写尽可能高效CSS。
CSS说明 (CSS Explain)

Much like SQL Explain in the database world, there is a nifty CSS Explain tool too – https://github.com/josh/css-explain. You can use it to analyze your CSS selectors. If you’d like to test it out immediately, paste the contents of this file into your browser’s console, and just issue a command like cssExplain('.item.subclass.anotherclass').

就像数据库世界中SQL Explain一样，也有一个漂亮CSS Explain工具-https: //github.com/josh/css-explain 。您可以使用它来分析CSS选择器。如果您想立即对其进行测试，请将此文件的内容粘贴到浏览器的控制台中，然后发出诸如cssExplain('.item.subclass.anotherclass')类的命令。

The goal is to get the lowest possible score on the scale of 1 to 10. You can also try it out in my jsFiddle. While the results aren’t to be taken too seriously (you’re better off following the CSSLint advice), they still do a good job at explaining the complexity of selectors and at least hint at possible problems.

目标是获得最低的可能分数，范围是1到10。您也可以在我的jsFiddle中进行尝试。尽管不要过于重视结果(最好遵循CSSLint的建议)，但它们仍然可以很好地说明选择器的复杂性，至少可以提示可能的问题。
翻译与顶部/左侧 (Translate vs. top/left)

Use CSS 2D translate to move objects instead of top/left. There’s no point in trying to explain this in detail when Paul Irish and Chris Coyer did such a fantastic job. Make sure you read/watch their material and bake this knowledge in – use translate over top/left whenever possible.

使用CSS 2D转换而不是顶部/左侧移动对象。当保罗·爱尔兰和克里斯·科耶做得如此出色时，试图详细解释这一点毫无意义。确保您阅读/观看了他们的资料并掌握了这些知识- 尽可能在顶部/左侧使用翻译 。
平滑滚动 (Scroll smoothly)

You may have noticed that sites like Facebook and Google+ take ages to become scrollable when opening them. It’s almost like they need time to warm up. This is a problem on many of today’s websites, and a huge UX gutpunch. Getting your page to scroll smoothly isn’t as difficult as it may seem – especially when you know what to look out for. The key to reducing scroll lag is minimizing paints – paints are what happens when content on your screen changes from frame to frame, and the browser needs to repaint it on the screen – it needs to calculate a new look, and slap this new look onto one of the layers a rendered website consists of. For more information on these issues, and to find out how to diagnose paint problems, see Paul Lewis’ excellent post.

您可能已经注意到，像Facebook和Google+这样的网站在打开时需要经过一段时间才能滚动。几乎就像他们需要时间来热身。这在当今的许多网站和庞大的UX gutpunch中都是一个问题。使页面平滑滚动并不像看起来那样困难，特别是当您知道要寻找的内容时。减少滚动滞后的关键是最大程度地减少绘画效果–当屏幕上的内容从一帧到另一帧变化并且浏览器需要在屏幕上重新绘画时，绘画就是发生的事情–它需要计算新外观并将此新外观拍到呈现网站的组成层之一。有关这些问题的更多信息，以及如何诊断油漆问题，请参阅Paul Lewis的精彩文章。

服务器 (Server)

通过轻松获胜来优化您PHP (Optimize your PHP with some easy wins)

There are many things you can do to speed up your app from the PHP side. For some easy wins, see Fredric Mitchell’s last article or any of the other performance related articles here on SitePoint.

从PHP方面，您可以做很多事情来加快应用程序的速度。要获得一些轻松的胜利，请参阅SitePoint上的Fredric Mitchell的上一篇文章或其他与性能相关的文章。
使用Google的PageSpeed模块 (Use Google’s PageSpeed Module)

The PageSpeed Module by Google is a module you can install into Nginx and Apache which automatically implements some best practices for website optimization. The module evaluates the performance of a website as perceived by the client, making sure all the rules are respected as much as possible and improving the serving of static resources in particular. It will minify, optimize and compress CSS and JavaScript for you, reduce image size by removing meta data that isn’t used, set Expires headers properly to better utilize browser cache, and much more. Best of all – it doesn’t require any architecture changes from you. Just plug it into your server and it works. To install the module, follow these instructions – you’ll need to build from source for Nginx, but that’s a mere couple commands of work. To get properly introduced to Pagespeed, see the following video – it’s a bit long and old by now, but still an incredibly valuable resource:

Google的PageSpeed Module是一个模块，您可以将其安装到Nginx和Apache中，该模块会自动实现一些用于网站优化的最佳实践。该模块评估客户认为的网站性能，确保尽可能遵守所有规则，尤其是改善静态资源的服务。它将为您最小化，优化和压缩CSS和JavaScript，通过删除不使用的元数据来减小图像大小，正确设置Expires标头以更好地利用浏览器缓存，等等。最重要的是–它不需要您更改任何体系结构。只需将其插入您的服务器即可。要安装该模块，请按照以下说明进行操作 –您需要从Nginx的源代码进行构建，但这仅是几个工作命令。要正确地介绍Pagespeed，请观看以下视频-到目前为止，它已经有些陈旧，但是仍然是非常宝贵的资源：
使用SPDY (Use SPDY)

In an effort similar to PageSpeed, Google also leads the development of SPDY. mod_spdy is another Apache module designed to serve your website much faster. Installing it is not as straightforward as one might like, and it needs browser support as well, but that’s looking better by the day. SPDY is actually a protocol (much like HTTP is a protocol) which intercepts and replaces HTTP requests where able, serving the site much faster. See this high level overview for more info, or even better, this newbie friendly breakdown. While using SPDY can be risky as we still wait for more widespread adoption, the gains seem to outweigh the risks by far.

在类似于PageSpeed的工作中，Google还领导了SPDY的开发。 mod_spdy是另一个Apache模块，旨在更快地为您的网站提供服务。安装它并不像人们希望的那样简单，它也需要浏览器支持，但是今天看起来情况越来越好。 SPDY实际上是一个协议(很像HTTP是一个协议)，它会拦截并替换HTTP请求，从而可以更快地为站点提供服务。有关更多信息，或什至更好的新手友好分类，请参阅此高级概述。尽管使用SPDY可能会带来风险，因为我们仍在等待更广泛的采用，但是到目前为止，收益似乎远远超过了风险。
对图像使用WebP (Use WebP for images)

WebP is an image format aiming to replace all others – JPG, PNG and GIF. It supports alpha layers (transparency), animation, lossless and lossy compression, and more. Browser adoption has been very slow, but it’s easy to support all image types these days with tools that automate the WebP conversion like the aforementioned PageSpeed module (it can automatically convert images to WebP on-the-fly). For an in-depth introduction and discussion about WebP, see this comprehensive guide.

WebP是一种图像格式，旨在替代所有其他格式-JPG，PNG和GIF。它支持Alpha层(透明度)，动画，无损和有损压缩等。浏览器的采用速度一直很慢，但是如今，使用自动化WebP转换的工具(如上述的PageSpeed模块) 可以轻松支持所有图像类型(它可以即时将图像自动转换为WebP)。有关WebP的深入介绍和讨论，请参阅本综合指南。
用Zopfli压缩 (Compress with Zopfli)

Use Zopfli compression to pre-compress your static resources. It’s an open source compression algorithm, again spearheaded by Google, which increases the compression by 3-8% when compared to the usual compression methods used online. On smaller websites this hardly makes a difference, but if you’re scaling your app or serving your static content to a lot of clients, it will definitely make a noticeable difference, as reported by the Google Web Fonts team:

使用Zopfli压缩来预压缩您的静态资源。这是一种开源压缩算法，再次由Google牵头，与在线使用的常规压缩方法相比，压缩率提高了3-8％。在较小的网站上，这几乎没有什么不同，但是，正如Google Web字体小组报告的那样，如果您要扩展应用程序或向大量客户提供静态内容，则肯定会产生明显的变化：

结论 (Conclusion)

There are many ways to improve the performance of your app, and as is often in life – the whole is greater than the sum of the parts. Implement some of the measures we’ve mentioned in this article and those preceding it, and you’ll get a nice, tangible improvement. Implement them all, and you’ve got an app so fast and light it can travel through time. Monitor your app, utilize HAR, look at Dev Tools profiling or sign up for services that do all this for you – just don’t ignore the performance aspect of your site. While most project these days are “do and depart”, don’t leave your client with a website you’re not proud of.

有很多方法可以提高应用程序的性能，并且在生活中经常出现–整体大于各个部分的总和。实施本文中及本文前面提到的一些措施，您将获得不错的，切实的改进。实施所有这些，您便拥有了一个如此轻巧的应用程序，它可以随时间流逝。监控您的应用程序，利用HAR ，查看Dev Tools配置文件或注册可为您完成所有这些工作的服务 -只是不要忽略您网站的性能方面。尽管这些天大多数项目都是“走走走走”的，但不要让您的客户拥有一个您不为之骄傲的网站。

Never underestimate the small fixes you can do – you never know which one will be the tipping point to excellence!

永远不要低估您可以做的小事-您永远不知道哪一个将成为卓越的转折点！