背景:我正在开发一个基于 GWT 的应用程序,该应用程序部署在 Google App Engine 上。我的应用程序使用自定义库,需要预先加载 6-7 个大核心 javascript 文件(总大小约 3 MB)。因此,即使加载我的应用程序的主页,也需要 20-40 秒,具体取决于带宽。最近,我开始着手解决页面加载缓慢的问题。
我制作了一个纯 HTML 主页,没有任何 GWT 或自定义库的组件。该主页包含一个登录按钮和一个简单的基于 jQuery 的图像滑块。我正在使用基于 Google 帐户的身份验证。在主页上,我使用此处介绍的“异步有序”Javascript 加载技术: http:// stevesouders.com/efws/loadscript.php?t=1303979716 加载所有核心 .js 文件。因此,当用户查看主页或与图像滑块交互时,.js 文件会在后台悄悄下载。用户登录后,控件将重定向到主 HTML 文件,该文件从缓存中检索 .js 文件并加载应用程序。这次应用程序的加载速度明显加快。因此,主页在 2-5 秒内加载完毕,主应用程序的加载速度也相当快。
这正是我所需要的。但有一个问题。
问题:如果用户单击登录按钮的速度太快(即在所有异步 .js 文件下载完成之前),异步下载就会中断。事实上,一旦用户离开主页(转到 Google 帐户登录页面或任何其他页面),所有异步下载都会中断。现在,当显示主应用程序时,它会从缓存中检索部分下载的 .js 文件并报告“意外的行尾”错误。
我可以做一件事来解决这个问题 - 禁用登录按钮,直到异步下载完成。这比当前情况稍好一些,因为它允许用户至少看到主页并与图像滑块交互。但这并不理想。
理想情况下,我正在寻找一种方法来检查主 HTML 中 .js 文件的哈希值(或文件大小),以查看它们是否正确。如果不匹配,请重新下载文件。但我无论如何都不是 Javascript 专家,甚至不确定这是否可能。所以,我在这里寻求专家的帮助。这可能是一个常见问题,人们已经通过其他方式解决了。因此,我也对其他选择持开放态度。
谢谢。
更新:
- 我有多个(6-7).js 文件要加载。
- .js 文件是独立的,需要按特定顺序加载。
Background: I'm working on a GWT based application which is deployed on Google App Engine. My application uses a custom library, which requires 6-7 big core javascript files (~3 MB total size) to be loaded up front. So to even load my application's home page, it takes anywhere from 20-40 secs depending upon the bandwidth. Recently I set upon the task to address the slow page load issue.
I made a plain HTML home page, without any GWT or custom library's components. This home page contains a login button and a simple jQuery based image slider. I'm using Google Accounts based authentication. On the home page, I use "asynchronous ordered" Javascript loading technique presented here: http://stevesouders.com/efws/loadscript.php?t=1303979716 to load all the core .js files. So while the user is looking at the home page or interacting with the image slider, the .js files quietly download in the background. After the user logs in, the control is redirected to the Main HTML file, which retrieves the .js files from the cache, and loads the app. This time the loading of the app is significantly faster. So, the home page loads up in 2-5 secs and the main app also loads up pretty fast.
It's exactly what I need. But there's an issue.
ISSUE: If the user clicks on the Login button too fast (i.e. before all the asynchronous .js file downloads are complete), the asynchronous downloads break. In fact, as soon as the user navigates away from the home page (to the Google Accounts sign-in page or any other page), all the asynchronous downloads break. Now when the main app is displayed, it retrieves the partially downloaded .js files from the cache and reports "Unexpected end of line" errors.
I could do one thing to address the problem - disable the login button until the asynchronous downloads complete. This is slightly better than the current situation because it allows the user to at least see the home page and interact with the image slider. But it's not ideal.
Ideally I'm looking for a way to check the hash (or file size) of the .js files in the Main HTML, to see whether they are correct. If there's a mismatch, download the files again. But I'm not a Javascript expert by any means and not even sure whether that's possible. So, I'm looking for help from experts here. This might be a common problem that people have addressed in other ways. So, I'm also open to other alternatives.
Thanks.
UPDATES:
- I have multiple (6-7) .js files to be loaded.
- The .js files are independent and need to be loaded in a particular order.
发布评论
评论(3)
3MB 的 Javascript 文件相当疯狂。你真的需要那么多吗?如果是这样,您应该考虑使用 jsmin 或 uglifyjs 连接/缩小它们。这将减少至少 50% 的大小。接下来,确保托管这些文件的服务器上启用了 gzipping。这应该会再减少 50% 的大小。
最后,您应该使用过期标头来确保该文件永远缓存客户端。要取消缓存更新 src 上的查询参数:
至于检查文件大小的哈希值,这并不完全可能,尽管您可以检查您的库引入全局命名空间的某些变量是否存在。例如:
3MB of Javascript files is pretty crazy. Do you really need that much? If so you should look to concatinating / minifying them using jsmin or uglifyjs. This will reduce the size by at least 50%. Next you ensure gzipping is enabled on the server hosting these files. That should reduce the size by another 50%.
Lastly you should use an expires header to ensure this file caches clientside forever. To uncache update a query param on the src:
As for checkinging hash of filesizes, not exactly possible, though you could check for the existence of certain variables your libs are introducing into the global namespace. For example:
在本例中,考虑到我们有大约 3 MB 的 javascript 需要加载,我将构建一个带有进度条的加载页面,用于下载所有 javascript,并在显示实际站点之前显示进度。这不会在任何程度上限制用户体验,而是让您有机会在加载时显示更新、新闻(甚至提要)、帮助消息。在加载页面上还有一个计时器,以检测是否花费了太长时间,并在花费太长时间时为他们提供执行其他操作的选项,例如在下载脚本之前显示禁用登录的登录页面。我在此处和此处
In this case, considering we have around 3 MB of javascript to be loaded, I would construct a loading page, with a progress bar, that downloads all the javascript, and shows the progress before showing the actual site. This does not limit user experience to any significant degree, it rather gives you an opportunity to show updates, news (even feeds), help messages while loading. Also have a timer on the loading page, to detect if it takes too long and give them an option to do something else if it does take too long, for example showing the login page with login disabled till scripts are downloaded. I have found scripts that do this here and here
您实际上可以压缩、包含版本、缩小和捆绑 js 文件,这可以减少 80% 以上的占用空间。看看雅虎的编码恐怖。您可以使用 jawr 完成所有这些操作
You can actually compress, include versions, minify and bundle the js files this reduces footprint by more than 80%. Have a look at Yahoo's Coding horror. You can do all these using jawr