babylon.js_我们为什么以及如何将babylon.js迁移到Azure：CORS，gzip和IndexedDB

babylon.js

This article is part of a web dev tech series from Microsoft. Thank you for supporting the partners who make SitePoint possible.

本文是Microsoft的Web开发技术系列的一部分。 感谢您支持使SitePoint成为可能的合作伙伴。

You are working for a startup. Suddenly that hard year of coding is paying off, but with success comes more growth and demand for your web app to scale.

您正在为一家初创公司工作。 突然，艰苦的编码之年收获了，但是成功带来了更多的增长和对Web应用程序扩展需求。

In this tutorial, I want to humbly use one of our more recent success stories around ourWebGL open-source gaming framework, babylon.js and its website: babylonjs.com. We have been excited to see so many web gaming devs try it out.

在本教程中，我想谦虚地使用我们最近关于WebGL开源游戏框架babylon.js及其网站babylonjs.com的成功案例之一 。 我们很高兴看到如此多的网络游戏开发人员尝试一下。

But to keep up with the demand, we knew we needed a new web hosting solution. While this tutorial focused on Microsoft Azure, many of the concepts apply to various solutions you might prefer. We are going to see also the various optimizations we have put in place to limit as much as possible the output bandwidth from our servers to your browser.

但是为了跟上需求，我们知道我们需要一个新的虚拟主机解决方案。 虽然本教程重点介绍Microsoft Azure，但是许多概念适用于您可能更喜欢的各种解决方案。 我们还将看到我们已经进行了各种优化，以尽可能限制从服务器到浏览器的输出带宽。

• Introduction
  介绍

• Step 1: moving to Azure Web Sites & the Autoscale service

  步骤1：移至Azure网站和Autoscale服务

• Step 2: moving assets into Azure Blob Storage, enabling CORS, gzip support & CDN

  步骤2：将资产移至Azure Blob存储中，启用CORS，gzip支持和CDN

  • Enabling CORS on blob storage

    在Blob存储上启用CORS

  • Enabling gzip support on our blob storage

    在Blob存储上启用gzip支持

  • Enabling CDN

    启用CDN

  Step 2: moving assets into Azure Blob Storage, enabling CORS, gzip support & CDN

  步骤2：将资产移至Azure Blob存储中，启用CORS，gzip支持和CDN

• Step 3: using HTML5 IndexedDB to avoid re-downloading the assets

  步骤3：使用HTML5 IndexedDB避免重新下载资产

介绍 (Introduction)

Babylon.js is a personal project we have been working on for over a year now. As it is a personal (i.e.our time and money), we have hosted the website, textures and 3D scenes on a relatively cheap hosting solution using a small, dedicated Windows/IIS machine. The project started in France, but was quickly under the radar of several 3D and web specialists around the globe as well as some gaming studios. We were happy about the community’s feedback but the traffic was manageable!

Babylon.js是我们一个多年前从事的个人项目。 由于这是个人(即时间和金钱)，因此我们使用小型专用Windows / IIS机器在相对便宜的托管解决方案中托管了网站，纹理和3D场景。 该项目始于法国，但很快就受到了全球3D和网络专家以及一些游戏工作室的关注。 我们对社区的反馈感到高兴，但流量可控！

For instance, between Feb 2014 and April 2014, we had an average of 7K+ users/month with an average of 16K+ pages/viewed/months. Some of the events we have been speaking at have generated some interesting peaks:

例如，在2014年2月至2014年4月之间，我们平均每月有7,000多名用户/月，平均每月有16K +的页面/观看/月。 我们一直在谈论的一些事件产生了一些有趣的高峰：

But the experience on the website was still good enough. Loading our scenes was not done at stellar speed but users were not complaining that much.

但是网站上的经验仍然足够好。 加载场景的速度并不是很快，但是用户并没有抱怨太多。

However, recently, a cool guy decided to share our work on Hacker News. We were really happy for such news! But look at what happened on the site’s connections:

但是，最近，一个很酷的人决定在Hacker News上分享我们的工作 。 我们真的很高兴收到这样的消息！ 但是，请查看该站点的连接上发生了什么：

Game over for our little server! It slowly stopped working and the experience for our users was really bad. The IIS server was spending its time serving large static assets and images, and the CPU usage was too high. As we were about to launch the Assassin’s Creed Pirates WebGL experience project running on babylon.js, it was time to switch to a more scalable professional hosting by using a cloud solution.

为我们的小服务器而战！ 它慢慢停止了工作，我们的用户的体验真的很糟糕。 IIS服务器花费大量时间为大型静态资产和图像提供服务，并且CPU使用率过高。 当我们即将启动在babylon.js上运行的刺客信条海盗WebGL体验项目时，是时候使用云解决方案切换到更具扩展性的专业托管了。

But before reviewing our hosting choices, let’s briefly talk about the specifics of our engine and website:

但是在审查我们的托管选择之前，让我们简要地讨论一下我们的引擎和网站的细节：

1. Everything is static on our website. We currently don’t have any server-side code running.
   一切在我们的网站上都是静态的。 我们目前没有任何服务器端代码在运行。

2. Our scenes (.babylon JSON files) and textures (.png or .jpeg) files could be very big (up to 100 MB). This means that we absolutely needed to activate gzip compression on our “.babylon” scene files. Indeed, in our case, the pricing is going to be indexed a lot on the outgoing bandwidth.

   我们的场景( .babylon JSON文件)和纹理( .png或.jpeg )文件可能很大(最大100 MB)。 这意味着我们绝对需要在“ .babylon ”场景文件上激活gzip压缩。 确实，在我们的案例中，定价将在传出带宽上建立很多索引。

3. Drawing into the WebGL canvas needs special security checks. You can’t load our scenes and textures from another server without CORS enabled for instance.
   绘制到WebGL画布中需要特殊的安全检查。 例如，如果未启用CORS，则无法从其他服务器加载我们的场景和纹理。

Credits:I’d like to special thank Benjamin Talmard, one of our French Azure Technical Evangelists who helped us move to Azure.

鸣谢：我要特别感谢本杰明·塔尔玛德 ( Benjamin Talmard) ，他是我们的法国Azure技术传播者之一，曾帮助我们迁移到Azure。

步骤1：移至Azure网站和自动缩放服务 (Step 1: Moving to Azure Web Sites & the Autoscale service)

As we’d like to spend most of our time writing codeand features for our engine, we don’t want losing time on the plumbing. That’s why, we immediately decided to choose a PaaS approach and not a IaaS one.

因为我们想花费大部分时间为引擎编写代码和功能，所以我们不想浪费时间在管道上。 因此，我们立即决定选择一种PaaS方法，而不是一种IaaS方法。

Moreover, we liked Visual Studio integration with Azure. I can almost do everything from my favorite IDE. And even if babylon.js is hosted on Github, we’re using Visual Studio 2013, TypeScript and Visual Studio Online to code our engine. As a note for your project, you can get Visual Studio Community and an Azure Trial for free.

此外，我们喜欢Visual Studio与Azure的集成。 我几乎可以通过我最喜欢的IDE进行所有操作。 即使babylon.js托管在Github上 ，我们也会使用Visual Studio 2013，TypeScript和Visual Studio Online来对我们的引擎进行编码。 作为项目的注释，您可以免费获得Visual Studio社区和Azure试用版 。

Moving to Azure took me approximately 5 min:

迁移到Azure大约需要5分钟：

1. I created a new Web Site in the admin page: http://manage.windowsazure.com (could be done inside VS too).

   我在管理页面中创建了一个新网站： http://manage.windowsazure.com : http://manage.windowsazure.com (也可以在VS内部完成)。

2. I took the right changeset from our source code repository matching the version that was currently online.
   我从源代码存储库中选择了与当前在线版本匹配的正确变更集。

3. I right-clicked the Web project in the Visual Studio Solution Explorer.

   我在Visual Studio解决方案资源管理器中右键单击了Web项目。

   

   I right-clicked the Web project in the Visual Studio Solution Explorer.

   我在Visual Studio解决方案资源管理器中右键单击了Web项目。

4. Here comes the awesomeness of the tooling. As I was logged into VS using the Microsoft Account boundto my Azure subscription, the wizard let me simply choose the web site on which I’d like to deploy.

   这是工具的精妙之处。 当我使用绑定到Azure订阅的Microsoft帐户登录VS时，该向导使我可以轻松选择要在其上进行部署的网站。

   

   Here comes the awesomeness of the tooling. As I was logged into VS using the Microsoft Account boundto my Azure subscription, the wizard let me simply choose the web site on which I’d like to deploy.

   这是工具的精妙之处。 当我使用绑定到Azure订阅的Microsoft帐户登录VS时，该向导使我可以轻松选择要在其上进行部署的网站。

No need to worry about complex authentication, connection strings or whatever.

无需担心复杂的身份验证，连接字符串或其他问题。

“Next, Next, Next & Publish” and a couple of minutes later, at the end of the uploading process of all our assets and files, the web site was up and running!

“ Next，Next，Next和Publish ”以及几分钟后，在我们所有资产和文件的上传过程结束时，该网站已启动并开始运行！

On the configuration side, we wanted to benefit from the cool autoscale service. It would have helped a lot in our previous Hacker News scenario.

在配置方面，我们希望从出色的自动缩放服务中受益。 在我们之前的Hacker News场景中，它会有所帮助。

First, your instance has be configured in “Standard” mode in the “Scale” tab.

首先，您的实例已在“比例”选项卡的“标准”模式下配置。

Then, you can choose up to how many instances you’d like to automatically scale, in which CPU conditions and also on which scheduled times. In our case, we’ve decided to use up to 3 small instances (1 core, 1.75 GB memory) and to auto-spawn a new instance if the CPU goes over 80% of its utilization. We will remove one instance if the CPU drops under 60%. The autoscaling mechanism is always on in our case, we haven’t set some specific scheduled times.

然后，您最多可以选择要自动扩展的实例数量，在哪些CPU条件下以及在预定的时间。 在我们的案例中，我们决定最多使用3个小型实例(1个内核，1.75 GB内存)，如果CPU利用率超过80％，则自动生成一个新实例。 如果CPU降到60％以下，我们将删除一个实例。 在我们的情况下，自动缩放机制始终处于启用状态，我们尚未设置一些特定的计划时间。

The idea is really to only pay for what you need during specific timeframes and loads. I love the concept. With that, we would have been able to handle previous peaks by doing nothing thanks to this Azure service! This what I call a service.

这个想法实际上是只在特定的时间范围和负载下支付您所需的费用。 我喜欢这个概念。 这样，借助此Azure服务，我们将无需执行任何操作即可处理以前的高峰！ 这就是我所说的服务。

You’ve got also a quick view on the autoscaling history via the purple chart. In our case, since we’ve moved to Azure, we never went over 1 instance up to now. And we’re going to see below how to minimize the risk into falling into an autoscaling.

您还可以通过紫色图表快速查看自动缩放历史记录。 就我们而言，由于我们已迁移到Azure，所以到目前为止，我们从未超过1个实例。 我们将在下面看到如何最大程度地降低陷入自动缩放的风险。

To conclude on the web site configuration, we wanted to enable automatic gzip compression on our specific 3D engine resources (.babylon and .babylonmeshdata files). This was critical to us as it could save up to 3x the bandwidth and thus… the price.

总结一下网站的配置，我们希望对特定的3D引擎资源( .babylon和.babylonmeshdata文件)启用自动gzip压缩。 这对我们至关重要，因为它可以节省多达3倍的带宽，从而节省价格。

Web Sites are running on IIS. To configure IIS, you need to go into the web.config file. We’re using the following configuration in our case:

网站正在IIS上运行。 要配置IIS，您需要进入web.config文件。 在这种情况下，我们使用以下配置：

<system.webServer>
  <staticContent>
    <mimeMap fileExtension=".dds" mimeType="application/dds" />
    <mimeMap fileExtension=".fx" mimeType="application/fx" />
    <mimeMap fileExtension=".babylon" mimeType="application/babylon" />
    <mimeMap fileExtension=".babylonmeshdata" mimeType="application/babylonmeshdata" />
    <mimeMap fileExtension=".cache" mimeType="text/cache-manifest" />
    <mimeMap fileExtension=".mp4" mimeType="video/mp4" />
  </staticContent>
  <httpCompression>
    <dynamicTypes>
      <clear />
      <add enabled="true" mimeType="text/*"/>
      <add enabled="true" mimeType="message/*"/>
      <add enabled="true" mimeType="application/x-javascript"/>
      <add enabled="true" mimeType="application/javascript"/>
      <add enabled="true" mimeType="application/json"/>
      <add enabled="true" mimeType="application/atom+xml"/>
      <add enabled="true" mimeType="application/atom+xml;charset=utf-8"/>
      <add enabled="true" mimeType="application/babylonmeshdata" />
      <add enabled="true" mimeType="application/babylon"/>
      <add enabled="false" mimeType="*/*"/>
    </dynamicTypes>
    <staticTypes>
      <clear />
      <add enabled="true" mimeType="text/*"/>
      <add enabled="true" mimeType="message/*"/>
      <add enabled="true" mimeType="application/javascript"/>
      <add enabled="true" mimeType="application/atom+xml"/>
      <add enabled="true" mimeType="application/xaml+xml"/>
      <add enabled="true" mimeType="application/json"/>
      <add enabled="true" mimeType="application/babylonmeshdata" />
      <add enabled="true" mimeType="application/babylon"/>
      <add enabled="false" mimeType="*/*"/>
    </staticTypes>
  </httpCompression>
</system.webServer>

This solution is working pretty well and we even noticed that the time to load our scenes has been reduced compared to our previous host. I’m guessing this is thanks to the better infrastructure and network used by Azure datacenters.

该解决方案运行良好，我们甚至注意到与以前的主机相比，加载场景的时间有所减少。 我猜这是由于Azure数据中心使用了更好的基础结构和网络所致。

However, I have been thinking about moving into Azure for a whilenow. And my first idea wasn’t to let web sites instances serving my large assets. Since the beginning, I was more interested in storing my assets into the blob storage better designed for that. It would offer us also a possible CDN scenario.

但是，一段时间以来，我一直在考虑迁移到Azure。 我的第一个想法不是让网站实例为我的大型资产服务。 从一开始，我就对将资产存储到为此而设计的Blob存储中更加感兴趣。 这也将为我们提供可能的CDN方案。

步骤2：将资产移到Azure Blob存储中，启用CORS，gzip支持和CDN (Step 2: Moving assets into Azure Blob Storage, enabling CORS, gzip support & CDN)

The primary reason for using blob storage in our case is to avoid loading the CPU of our web site instances to serve them. If everything is being served via the blob storage except a few html, js&css files, our web site instances will have few chances to autoscale.

在我们的案例中，使用Blob存储的主要原因是避免加载网站实例的CPU为它们提供服务。 如果除少数html，js＆css文件外，所有内容都通过blob存储提供服务，则我们的网站实例将几乎没有机会自动扩展。

But this raises two problems to solve:

但这提出了两个要解决的问题：

1. As the content will be hosted on another domain name, we will fall into the cross-domain security problem. To avoid that, you need to enable CORS on the remote domain (Azure Blob Storage)
   由于内容将托管在另一个域名上，因此我们将陷入跨域安全问题。 为避免这种情况，您需要在远程域上启用CORS(Azure Blob存储)
2. Azure Blob Storage doesn’t support automatic gzip compression. And we don’t want to lower the CPU web site usage if in exchange we’re paying 3x time the price because of the increased bandwidth!
   Azure Blob存储不支持自动gzip压缩。 而且，我们不希望降低CPU网站的使用率，因为作为交换，由于带宽增加，我们付出的价格是价格的3倍！

在Blob存储上启用CORS (Enabling CORS on blob storage)

CORS on blob storage has been supported for a few months now. This article, Windows Azure Storage: Introducing CORS, explains how to use Azure APIs to configure CORS. On my side, I didn’t want to write a small app to do that. I’ve found one on the web already written: Cynapta Azure CORS Helper – Free Tool to Manage CORS Rules for Windows Azure Blob Storage

blob存储上的CORS已经支持了几个月。 本文Windows Azure存储：CORS简介介绍了如何使用Azure API来配置CORS。 就我而言，我不想编写一个小型应用程序来做到这一点。 我已经在网上写了一个： Cynapta Azure CORS Helper –免费工具，用于管理Windows Azure Blob存储的CORS规则

I then just enabled the support for GET and proper headers on my container. To check if everything works as expected, simply open your F12 developer bar and check the console logs:

然后，我刚刚在容器上启用了对GET和适当头的支持。 要检查一切是否按预期工作，只需打开F12开发人员栏并检查控制台日志：

As you can see, the green log lines imply that everything works well.

如您所见，绿色的日志行表示一切正常。

Here is a sample case where it will fail. If you try to load our scenes from our blob storage directly from your localhost machine (or any other domain), you’ll get these errors in the logs:

这是一个失败的示例案例。 如果您尝试直接从本地主机(或任何其他域)从Blob存储中加载场景，则会在日志中出现以下错误：

In conclusion, if you see that your calling domain is not found in the “Access-Control-Allow-Origin” header with an “Access is denied” just after that, it’s because you haven’t set properly your CORS rules. It is very important to control your CORS rules; otherwise, anyone could use your assets, and thus your bandwidth, and thus costingmoney without letting you know!

总之，如果您发现在“ Access-Control-Allow-Origin ”标头中找不到呼叫域，并且紧随其后的是“拒绝访问 ”，那是因为您没有正确设置CORS规则。 控制您的CORS规则非常重要； 否则，任何人都可能在不通知您的情况下使用您的资产，从而占用您的带宽，从而浪费金钱！

在Blob存储上启用gzip支持 (Enabling gzip support on our blob storage)

As I was telling you before, Azure Blob Storage doesn’t support automatic gzip compression. It seems to be also the case of competitors’ solutions like S3. You’ve got two options to workaround that:

正如我之前告诉您的那样，Azure Blob存储不支持自动gzip压缩。 像S3这样的竞争对手的解决方案似乎也是如此。 您有两种解决方法：

1. gzip yourself the files on the client before uploading, upload it in the blob storage using your classic tools and set the content-encoding header to gzip. This solution works but only for browsers supporting gzip (is there still a browser not supporting gzip anyway?)

   在上传之前，先在客户端上对文件进行gzip压缩，然后使用经典工具将其上传到blob存储中，并将content-encoding标头设置为gzip 。 此解决方案有效，但仅适用于支持gzip的浏览器(是否仍然存在不支持gzip的浏览器？)

2. gzip yourself the files on the client and upload two versions in the blob storage: one with the default .extensionand one with the .extension.gzip, for instance. Set up a handler on the IIS side that will catch the HTTP request from the client, check for the header accept-encoding set to gzip and serve the appropriate files based on this support. You’ll find more details on the code to implement in this article: Serving GZip Compressed Content from the Azure CDN.

   gzip自己在客户端上的文件，并在blob存储中上载两个版本：例如，一个版本具有默认的.extension和一个版本具有.extension.gzip 。 在IIS端设置一个处理程序，该处理程序将捕获来自客户端的HTTP请求，检查是否将标头accept-encoding设置为gzip并根据此支持提供适当的文件。 您将在本文中找到有关要实现的代码的更多详细信息： 从Azure CDN提供GZip压缩内容 。

In our case, I don’t know any browser supporting WebGL and not gzip compression. So if the browser doesn’t support gzip, there’s no real interest in going further as this probably means that WebGL is not supported either.

就我们而言，我不知道任何支持WebGL的浏览器而不支持gzip压缩。 因此，如果浏览器不支持gzip，那么继续前进就没有真正的兴趣，因为这可能意味着也不支持WebGL。

I have then chosen the first solution. As we don’t have a lot of scenes and we are not producing a new one every day, I am currently using this manual process:

然后，我选择了第一个解决方案。 由于我们没有很多场景，而且每天都不制作新场景，因此我目前正在使用以下手动流程：

1. Using 7-zip, I am compressing the .babylon files on my machine using gzip encoding and compression level to fastest. The other compression levels seems to generate issues in my tests.

   使用7-zip ，我正在使用gzip编码和compression level将计算机上的.babylon文件compression level到fastest 。 其他压缩级别似乎在我的测试中产生了问题。

2. I upload the file using CloudBerry Explorer for Microsoft Azure Cloud Storage.

   我使用CloudBerry Explorer for Microsoft Azure Cloud Storage上传文件。

3. I manually set the HTTP header content-encoding to gzip with CloudBerry.

   我使用CloudBerry手动将HTTP标头content-encoding为gzip 。

I know what you are thinking. Am I going to do that for all my files?! No, you’d build a tool or post-build script that would automate that. For instance, here is a little command-line tool I have built:

我知道你在想什么 我要对所有文件都这样做吗？ 不，您将构建一个可以自动执行此操作的工具或构建后脚本。 例如，这是我构建的一个命令行工具：

To use it, I could do UploadAndGzipFilesToAzureBlobStorage Scenes/Espilit C:\Boulot\Babylon\Scenes\Espilit\*.babylon* to push a scene containing multiple files (our incremental scenes with muliples.babylonmeshdata files)

要使用它，我可以执行UploadAndGzipFilesToAzureBlobStorage Scenes/Espilit C:\Boulot\Babylon\Scenes\Espilit\*.babylon*来推送包含多个文件的场景(我们的带有muliples.babylonmeshdata文件的增量场景)

Or simply UploadAndGzipFilesToAzureBlobStorage Scenes/Espilit C:\Boulot\Babylon\Scenes\Espilit\Espilit.babylon to push a unique file.

或简单UploadAndGzipFilesToAzureBlobStorage Scenes/Espilit C:\Boulot\Babylon\Scenes\Espilit\Espilit.babylon即可推送唯一文件。

To check that gzip was working as expected using this solution, I am using Fiddler. Load your content from your client machine and check in the network traces if the content returned is really compressed and can be uncompressed:

为了使用该解决方案检查gzip是否按预期工作，我使用Fiddler 。 从客户端计算机加载您的内容，并检查网络跟踪是否返回的内容确实经过压缩并且可以解压缩：

启用CDN (Enabling CDN)

Once you have done the two previous steps, you just need to click on a single button in the Azure administration page to enable CDN and map it to your blob storage:

完成上述两个步骤后，只需在Azure管理页面中单击一个按钮即可启用CDN并将其映射到Blob存储：

It is that simple! In my case, I need to simply change the following URL http://yoda.blob.core.windows.net/wwwbabylonjs/Scenes to http://az612410.vo.msecnd.net/wwwbabylonjs/Scenes. Note that you can customize this CDN domain to your own if you want to.

就这么简单！ 就我而言，我只需将以下URL http://yoda.blob.core.windows.net/wwwbabylonjs/Scenes更改为http://az612410.vo.msecnd.net/wwwbabylonjs/Scenes 。 请注意，您可以根据需要自定义此CDN域。

Thanks to that, we are able to serve you our 3D assets in a very fast way as you will be served from one of the node locations listed here: Azure Content Delivery Network (CDN) Node Locations.

因此，我们将以非常快速的方式为您提供3D资产，因为您将从此处列出的节点位置之一获得服务： Azure内容交付网络(CDN)节点位置 。

Our web site is currently hosted on the Northern Europe Azure data center. But if you are coming from Seattle, you will ping this server just to download our basic index.html, index.js, index.css files and a couple of screenshots. All the 3D assets will be served from the Seattle node just near you!

当前，我们的网站位于北欧Azure数据中心。 但是，如果您来自西雅图，则可以ping通此服务器，只是下载我们的基本index.html ， index.js ， index.css文件和一些屏幕截图。 所有3D资产都将通过您附近的Seattle节点提供！

Note: All our demos are using the fully optimized experience (blob storage using gzip, CDN & DB caching).

注意：我们所有的演示都使用了完全优化的体验(使用gzip，CDN和DB缓存的blob存储)。

步骤3：使用HTML5 IndexedDB避免重新下载资产 (Step 3: Using HTML5 IndexedDB to avoid re-downloading the assets)

Optimizing loading times and controlling output bandwidth costs is not just about server-side.You can also build some logic client-side to optimize things. Fortunately, we have done that since v1.4 of our babylon.js engine. I have explained in great details how I have implemented the support for IndexedDB in this article: Using IndexedDB to handle your 3D WebGL assets: sharing feedbacks & tips of Babylon.JS and you will find how to activate it in babylon.js on our wiki: Caching the resources in IndexedDB.

优化加载时间和控制输出带宽成本不仅仅涉及服务器端。您还可以构建一些逻辑客户端来进行优化。 幸运的是，从babylon.js引擎v1.4开始，我们已经做到了。 我在本文中详细解释了如何实现对IndexedDB的支持： 使用IndexedDB处理3D WebGL资产：分享Babylon.JS的反馈和技巧，您将在我们的Wiki的babylon.js中找到如何激活它。 ： 在IndexedDB中缓存资源 。

Basically, you just have to create a .babylon.manifest file matching the name of the .babylon scene,then set what you’d like to cache (textures and/or JSON scene).That’s it.

基本上，您只需要创建一个与.babylon场景名称匹配的.babylon.manifest文件，然后设置要缓存的内容(纹理和/或JSON场景)即可。

For instance, check what is going on with the Hill Valley demo scene. First time you are loading it, here are the requests sent:

例如，检查Hill Valley演示场景的情况。 首次加载时，以下是发送的请求：

153 items and 43.33 MB received. But if you have accepted to let babylonjs.com to use additional storage on your computer, here is what you will see the second time you will load the same scene:

收到153个项目和43.33 MB。 但是，如果您同意让babylonjs.com 在计算机上使用其他存储 ，则这是您第二次加载相同场景时看到的内容：

1 item and 348 bytes! We are just checking if the manifest file has changed. If not we are loading everything from the DB and we are saving 43+ MB of bandwidth.

1个348字节！ 我们只是在检查清单文件是否已更改。 否则，我们将从数据库中加载所有内容，并且节省了43 MB以上的带宽。

For instance, this approach is being used in the Assassins Creed Pirates games:

例如，在《 刺客信条：海盗》游戏中使用了这种方法：

Lets think about that: the game launches almost immediately once it has been loaded once as the assets are served directly from the local DB – your web storage is less stressed and less bandwidth is used costing you less money!

让我们考虑一下：游戏直接加载后就立即启动，因为资产是直接从本地数据库提供的–网络存储的压力减轻了，带宽占用也减少了，花费的钱更少了！

Now that will satisfy both your users and the person paying the bill!

现在，这将使您的用户和付款人都满意！

This article is part of a web dev tech series from Microsoft. We’re excited to share Microsoft Edge and its new rendering engine with you. Get free virtual machines or test remotely on your Mac, iOS, Android, or Windows device at modern.IE.

本文是Microsoft的Web开发技术系列的一部分。 我们很高兴与您分享Microsoft Edge及其新的渲染引擎 。 获取免费的虚拟机或者在你的Mac，iOS设备，Android或Windows设备上远程测试modern.IE 。

翻译自: https://www.sitepoint.com/migrated-babylon-js-azure-cors-gzip-indexeddb/

babylon.js