cms快速建站_用CMS构建超快速，安全的网站没什么大不了的。还是？-CSDN博客

cms快速建站

by Ondřej Polesný

通过OndřejPolesný

用CMS构建超快速，安全的网站没什么大不了的。还是？ (Building a super-fast and secure website with a CMS is no big deal. Or is it?)

Can I break your site? Do you have any leftover scripts there that I can take advantage of? Is there a way to steal your credentials and change content on your site? Can I access private information? No? Are you sure? Or, am I never going to find out because your page takes ages to load?

我可以中断您的网站吗？那里有我可以利用的剩余脚本吗？有没有办法窃取您的凭据并更改您网站上的内容？我可以访问私人信息吗？没有？你确定吗？或者，由于您的页面需要花很多时间才能加载，我永远也不会发现吗？

At some point when creating a website you need to think about performance and security. It does not matter if you’re working on your personal website, or your client’s website. It is the same as backing up your local files. There are people who do regular backups, and people who have not yet lost any, so are less inclined to do it.

在创建网站的某个时候，您需要考虑性能和安全性。无论您是在个人网站还是客户的网站上工作，都没有关系。这与备份本地文件相同。有些人会进行定期备份，而有些人还没有丢失任何备份，因此不太愿意这样做。

传统CMS (Traditional CMS)

If you are using a traditional content management system (CMS), the situation is more complicated for you. These systems contain lots of features. They need to cover all potential use-cases any website might have. That means code. A lot of code. Thousands of files. And, that’s not all — the administration interfaces need to provide a nice UI for you to configure all these features. Potentially, another few thousand files.

如果您使用的是传统的内容管理系统(CMS)，则情况会更加复杂。这些系统包含许多功能。他们需要涵盖任何网站可能具有的所有潜在用例。那就是代码。很多代码。数千个文件。而且，还不止如此-管理界面需要提供一个漂亮的UI，供您配置所有这些功能。可能还有另外几千个文件。

安全 (Security)

It’s not your code, right? So it should already be secure. Well, many CMS vendors try their best to ensure their implementations are secure. They still have to cover a lot of files. And, every single file may contain an error, some code that was left behind, or maybe a querystring parameter that exposes a database. That in itself can create a potential vulnerability.

不是您的代码，对不对？因此它应该已经安全了。好吧，许多CMS供应商会尽力确保其实施安全。他们仍然必须涵盖许多文件。而且，每个文件都可能包含一个错误，一些遗留的代码或一个可能暴露数据库的querystring参数。这本身可能会造成潜在的漏洞。

Using open-source CMS can be even more dangerous, as the implementation is publicly known. Yes, you can argue that open-source is advantageous. Anyone can contribute and fix found issues. But, this only covers issues that are already known. Attackers would probably keep their exploits to themselves. Even if an issue was found and fixed, you still need to put a lot of effort into making sure your website is kept up-to-date. You have to perform upgrades every time a security hotfix is released.

由于实施是众所周知的，因此使用开源CMS可能会更加危险。是的，您可以说开源是有利的。任何人都可以贡献并解决发现的问题。但是，这仅涵盖已知的问题。攻击者可能会保留自己的攻击。即使发现并解决了问题，您仍然需要付出很多努力来确保您的网站保持最新状态。每次发布安全修补程序时，您都必须执行升级。

If you are interested in real-world statistics, take a look at hacked website report by Sucuri.

如果您对现实世界的统计数据感兴趣，请查看Sucuri的被黑网站报告。

So, what would attackers want to do with your website? Essentially, they want to get hold of your data, so they can misuse your website by:

那么，攻击者想对您的网站做什么？本质上，他们想掌握您的数据，因此他们可以通过以下方式滥用您的网站：

Getting access to your database through one of the scripts. This is usually the case of custom leftover scripts, testing pages, and others.
通过脚本之一访问数据库。自定义剩余脚本，测试页和其他情况通常如此。
Compromising and misusing your secret data. Configuration files are a typical storage option for various secret keys and credentials to other services or databases.
损害和滥用您的秘密数据。配置文件是典型的存储选项，用于存储其他服务或数据库的各种密钥和凭据。
Modifying your website content.
修改您的网站内容。
Making your website inaccessible, i.e. shut it down.
使您的网站无法访问，即关闭它。

性能 (Performance)

When you implement your website on a traditional CMS, you usually need to customize it, so there are files of the CMS and your custom files. All of them need to be compiled, and then together with precompiled libraries, brought up to the server memory before the server can actually start processing requests to your website. Or worse, if you are using a solution based on interpreted language like PHP, interpret all code for each request.

在传统CMS上实施网站时，通常需要对其进行自定义，因此存在CMS文件和自定义文件。所有这些都需要进行编译，然后与预编译的库一起被带到服务器内存中，然后服务器才能真正开始处理对您网站的请求。或更糟糕的是，如果您使用的是基于诸如PHP之类的解释语言的解决方案，请解释每个请求的所有代码。

Anyway, your website seems to run fine, so why should this be a concern? Well, because:

无论如何，您的网站运行正常，为什么要担心这个问题？好吧，因为：

you pay for your server computing power
您为服务器的计算能力付费
you compile and copy code of functionalities you never intend to use
您编译并复制您从未打算使用的功能代码
your website visitors wait for the response
您的网站访问者等待响应

Time to first byte of these websites can be way above 1 second. Sure, it can be optimized, but then you spend time and money on figuring out how to mitigate performance issues, and usually end up boosting CPU and memory, or worse, adding an additional server.

这些网站的第一个字节的时间可能超过1秒。当然，可以对其进行优化，但是随后您将花费时间和金钱来弄清楚如何缓解性能问题，通常最终会增加CPU和内存，或者更糟的是添加额外的服务器。

Check your site using Google PageSpeed or get more detailed analysis using SpeedCurve to see how your website is doing.

使用Google PageSpeed检查您的网站，或使用SpeedCurve获得更详细的分析，以查看您的网站运行情况。

基于API的网站 (API-based Websites)

Websites built on top of an API enable great flexibility. Ask yourself, do you need content management? If so, you can use a headless CMS. Do you need to store form submissions? Perfect, use a form service. Are you building a website for mountain hotel and want to display a weather forecast? There is a weather service with its API for you.

建立在API之上的网站具有极大的灵活性。问问自己，您需要内容管理吗？如果是这样，您可以使用无头CMS。您需要存储表单提交内容吗？完美，使用表格服务。您是否正在为山区酒店建立网站并希望显示天气预报？有一个天气服务及其API。

The number of files used for such websites corresponds to its functionality. But, what about the administration interface for content editing? Don’t worry. The headless CMS is handling that part for you, with no additional code you need to host or maintain.

用于此类网站的文件数量与其功能相对应。但是，内容编辑的管理界面如何？不用担心无头CMS正在为您处理该部分，而无需托管或维护其他代码。

安全 (Security)

When using API services, you do not need an administration service on top of your website. You configure all components when building the website. Like the weather component that should display a weather forecast for three days. Or that there should be four blog posts on the main page. The rest of the dynamic content can be managed in the headless CMS.

使用API服务时，您不需要网站顶部的管理服务。您在构建网站时配置所有组件。就像应该显示三天天气预报的天气组件一样。或者在主页上应该有四个博客文章。其余的动态内容可以在无头CMS中进行管理。

The main benefit of this approach is that you do not need a database. That’s right, no single point of data storage that an attacker can gain access to.

这种方法的主要好处是您不需要数据库。没错，攻击者无法访问任何数据存储点。

If your website is based on JavaScript, its implementation is basically open. It may be compiled, but whatever is provided to the browser is readable. This is yet another advantage. Yes, anyone can query the services endpoints directly. The published content you get from them is displayed on your website anyway, only transformed into a nicer visual. It’s like with news articles on websites, and RSS readers. For sensitive content you can always authenticate each user through another service, obtain their unique access token, and use it to ask for sensitive content over secure protocol.

如果您的网站基于JavaScript，则其实现基本上是开放的。它可以被编译，但是提供给浏览器的任何内容都是可读的。这是另一个优点。是的，任何人都可以直接查询服务端点。您从他们那里获得的已发布内容仍然会显示在您的网站上，只会转化为更好的视觉效果。就像网站上的新闻文章和RSS阅读器一样。对于敏感内容，您始终可以通过另一项服务对每个用户进行身份验证，获取其唯一的访问令牌，然后使用它通过安全协议请求敏感内容。

If you keep in mind that the JS implementation is open to everyone, and treat sensitive data the right way, you will have much less work to do in order to make your website secure. Not having a database and consuming all API services through secure channels closes almost all doors for a potential attacker.

如果您牢记JS实施向所有人开放，并以正确的方式处理敏感数据，那么您要做的工作就少得多，以确保网站的安全。没有数据库，无法通过安全通道使用所有API服务，几乎为潜在的攻击者关闭了所有大门。

性能 (Performance)

In this scenario, the webserver provides only assets. The business logic of your application is stored in a JS file. Content from various endpoints is gathered via asynchronous requests by visitor browsers.

在这种情况下，Web服务器仅提供资产。您的应用程序的业务逻辑存储在JS文件中。访客浏览器通过异步请求收集来自各个端点的内容。

Async requests to get content from third-party services? That must be slow, right? Well sure, they take some time. But, their delivery endpoints are usually built for speed, hosted in Cloud, and very flexible. You can also pick a headless CMS that uses a CDN for delivery, one of them is Kentico Cloud. That way the request will always be handled by the data center that is geographically closest to each of your visitors.

异步请求从第三方服务获取内容？那一定很慢吧？好的，他们需要一些时间。但是，它们的交付端点通常是为提高速度而构建的，托管在Cloud中并且非常灵活。您还可以选择使用CDN进行交付的无头CMS，其中之一就是Kentico Cloud 。这样，请求将始终由地理位置最接近您的每个访问者的数据中心处理。

Even if you use multiple services to build a single page, these requests are all asynchronous. Visitors wait only for the slowest one. When a page is composed on a server using traditional CMS, all communication with the database and other services is usually synchronous. Therefore, the server waits for each transaction to finish before starting another one. And, after all this is done, everything is put together and sent back as one big response.

即使您使用多个服务来构建单个页面，这些请求都是异步的。访客只等待最慢的一个。当使用传统的CMS在服务器上组成页面时，与数据库和其他服务的所有通信通常都是同步的。因此，服务器在开始另一个事务之前等待每个事务完成。并且，在完成所有这些操作之后，所有内容汇总在一起并作为一个巨大的响应发送回去。

Take a look how long it took the webserver to process incoming requests (light yellow background). All this time, the visitor is actively waiting, and cannot start downloading images and other assets. They will be known to the visitor’s browser only after the response is received.

看一下Web服务器处理传入请求所花的时间(浅黄色背景)。一直以来，访客都在积极等待，无法开始下载图像和其他资产。只有收到响应后，访问者的浏览器才能知道它们。

An API based website is much faster, as the initial response with static HTML file is instant. The browser downloads business logic of the website as one of the assets, and generates all subsequent asynchronous requests for content. The visitor sees a fully rendered page much quicker, and they also see something is happening. When they are waiting for a server-rendered page, all they see is a preloader in the address bar of their browser. The overall performance improvement of API based website is in this case over 50%. It can be much higher depending on the website implementation.

基于API的网站速度更快，因为静态HTML文件的初始响应是即时的。浏览器将网站的业务逻辑下载为资产之一，并生成所有随后的异步内容请求。访客更快地看到了完整呈现的页面，他们还看到了一些事情。当他们等待服务器渲染的页面时，他们所看到的只是浏览器地址栏中的预加载器。在这种情况下，基于API的网站的整体性能提高了50％以上。取决于网站的实现，它可能更高。

静态网站 (Static Websites)

So why would we bother solving performance, if we already have an API-based website?

那么，如果我们已经有一个基于API的网站，为什么还要麻烦解决性能问题呢？

Since the webserver only provides static files and assets, its performance is good. The fact that dynamic content is gathered later when the website is being rendered in visitor’s browsers can lead to some artifacts. Visitors may see an empty component that gets filled when it receives data from asynchronous request, and so on. People with a slow internet connection, or using older computers may find this disturbing.

由于Web服务器仅提供静态文件和资产，因此其性能良好。在访问者的浏览器中呈现网站时，稍后会收集动态内容的事实可能会导致某些伪像。访问者可能会看到一个空组件，当它从异步请求接收数据时会被填充，依此类推。互联网连接速度慢或使用旧计算机的人可能会发现此问题。

What can we do about this? No, we won’t add any preloaders. How does it make you feel when you see an infinite preloader that just spins and spins and spins? We can make our websites static, yet keep them dynamic.

我们该怎么办？不，我们不会添加任何预加载器。当您看到无限旋转的预加载器旋转时，感觉如何？我们可以将网站设为静态，但保持其动态。

The concept of static sites is about the output of your website. It starts with the content. Editors usually don’t update content that often. The website needs to be composed upon every single request (like traditional CMSs do). The idea is similar to caching — store generated data or pages in memory. But static sites go a bit further. The whole website, all pages with all content, is generated every single time an editor publishes content. So if you have 153 blog posts in your blog, the website will now have 153 static pages (plus some others like homepage, contact, and more).

静态网站的概念与您网站的输出有关。它从内容开始。编辑者通常不经常更新内容。该网站需要根据每个单独的请求来组成(就像传统的CMS一样)。这个想法类似于缓存-将生成的数据或页面存储在内存中。但是静态站点走得更远。编辑器每次发布内容时，都会生成整个网站，包括所有内容的所有页面。因此，如果您的博客中有153个博客文章，则该网站现在将有153个静态页面(以及其他一些页面，例如主页，联系人等)。

How are you going to manage 153 pages? Well, you don’t. You still manage just the implementation of a single dynamic page. The static site is generated by combining your implementation with content from a headless CMS. So when there is new content, the site is just automatically generated again.

您将如何管理153页？好吧，你没有。您仍然仅管理单个动态页面的实现。静态网站是通过将您的实现与无头CMS的内容相结合而生成的。因此，当有新内容时，该站点将再次自动生成。

You see the benefit of speed is not that significant compared to dynamic API-based websites. However:

您会发现，与基于动态API的网站相比，速度的好处并不那么重要。然而：

your visitors get the page and all content in the first response. They won’t be looking at a page that is being built. Their browsers don’t need to create additional async requests for content
您的访问者会在第一个响应中获得该页面和所有内容。他们不会查看正在构建的页面。他们的浏览器不需要为内容创建其他异步请求
all subsequent requests behave the same way
所有后续请求的行为均相同
visitors are navigating between set of static pages which is very fast
访客在一组静态页面之间导航，速度非常快
some tools for static sites generation enable additional cool features for visitors such as preloading of linked pages (which makes navigating to them instant) or displaying images in low quality before they are fully downloaded
一些用于静态网站生成的工具为访问者提供了其他很酷的功能，例如预加载链接的页面(可以立即导航到它们)或在完全下载它们之前显示低质量的图像

All that will leave your visitors with the impression of a blazing fast website.

所有这些都会给您的访问者留下令人印象深刻的快速网站的印象。

Of course, every website is different. You may need some personalization features, or want to display sensitive content. In those cases you may combine both approaches . Have a static website, and still use API-based services to deliver content that varies among visitors.

当然，每个网站都是不同的。您可能需要一些个性化功能，或者想要显示敏感内容。在那种情况下，您可以结合使用两种方法。拥有一个静态网站，并且仍然使用基于API的服务来交付访问者之间不同的内容。

结论 (Conclusion)

The performance and security aspects of every site are very important. Traditional CMSs are usually more resource demanding than API based websites, but they provide more functionality out-of-the-box.

每个站点的性能和安全性都很重要。传统的CMS通常比基于API的网站对资源的要求更高，但是它们提供了更多现成的功能。

On the other hand, API based websites are much faster and more secure. They enable you to save money on hosting, and provide a better experience for your visitors.

另一方面，基于API的网站更快，更安全。它们使您可以节省托管费用，并为访问者提供更好的体验。

Static sites are becoming a big hit nowadays, as their performance is the best by far. They also let you build part-static part-dynamic sites based on JavaScript that are nicely indexable by search engines.

静态站点如今已成为热门，因为它们的性能是迄今为止最好的。它们还使您可以基于JavaScript构建部分静态的部分动态站点，这些站点可以被搜索引擎很好地索引。

Is your website already static? Have you used any static sites generators? Let me know about your experience in the comments section below.

您的网站已经静态了吗？您是否使用过任何静态网站生成器？在下面的评论部分中，让我知道您的经历。

In my next article I will show you how to build a website on Vue.js using static site generator.

在下一篇文章中，我将向您展示如何使用静态网站生成器在Vue.js上构建网站。