WHY YOU SHOULDN'T MERGE JAVASCRIPT IN MAGENTO

简介:

Most people - myself included - thought that merging all of your separate Javascript files was a healthy way to speed up the front end of your site. The logic was that by merging the files, you reduce the number of requests the browser makes when loading your site. This allows the request to complete quicker and results in your page loading faster. Let's walk through an example of this process in Magento and see what happens.

Imagine you have just enabled Javascript Merging in the Magento Admin and then a user visits your site. Magento collates all of the XML layout files and determines which Javascript files should be included for the homepage request. These files are then merged into a single file and saved using an md5 hash of their filenames. This new file, named f0eb853c09ba3e46ad21fb89b8d57626.js, is then served to the user, who downloads it and stores it in their browser cache.

Next, the user clicks a link to one of your categories. Once again, Magento collates the XML layout files and determines what Javascript files are needed for the category page. At this point, Magento realises that the exact same Javascript files used on the homepage are needed on this page. Instead of remaking the single Javascript file, Magento serves the Javascript file created when the user visited the homepage. This time though, the browser knows that it already has this file and therefore doesn't download it again. Instead, the file is loaded from the user's cache, saving time, bandwidth and computer resources!

So far everything has gone well; we have made the page load faster while decreasing the load on the server, but...

Next, the user is enticed by one of your products and clicks through to a product page. Once again, Magento determines which Javascript files are needed based on the layout XML files. At this point, Magento realises that the same Javascript files on the homepage are needed as well two new files. As a merged file containing this combination of Javascript doesn't exist, Magento merges the files and creates a new Javascript file named 139f9771ba2ba0cae754978fab4a3c35.js. Roughly 80% of this file is the Javascript that was used on the homepage and has been downloaded and cached by the user already. The final 20% accounts for the new Javascript files used solely on the product page. This file is then served to the user who is forced to download it all! Although this file is made of 80% code that has already been cached, the user's browser is completely unaware of this and will download 100% of the file and cache it again!

The intended result of merging Javascript is a decreased page load time, but in the above scenario, the user has been forced to re-download a massive chunk of Javascript! This will no doubt have increased page load time (downloading ~40kb of Javascript that doesn't need to be downloaded), which goes against the idea of Javascript merging.

Let's consider what would happen if we hadn't of merged our Javascript...

When the user first requests the homepage, the merged Javascript files would be downloaded individually. Although the combined size of these Javascript files matched the size of the merged Javascript file, this request would take longer as each file would need to be requested, downloaded and cached separately. 1-0 merging!

Second, the user requested the category page, which uses the same files that were just downloaded and cached on the homepage. As a result this takes exactly the same amount of time it would if the Javascript files had been merged. In both instances, all of the required Javascript has already been downloaded and cached, meaning the browser can skip the Javascript altogether.

Lastly, the user visits the product page, which uses the Javascript files found on the home and category pages as well as two new files. The files used on both the homepage and category page have already been cached, so the browser skips these files and downloads and caches the two new files that haven't been experienced before! In the merging scenario, we mentioned that files used on the homepage in Magento make up about 80% of the total Javascript on the product page. With merging disabled, we have managed to skip downloading the 80% and just download the 20%. In the merging example, the full 100% had to be re-downloaded!

This problem is compounded for each page your user visits that has a combination of Javascript not found on another page. Each time this happens, the user will be forced to re-download Javascript that it has already downloaded and cached under a different filename.

WHAT CAN BE DONE?

While the current Magento merging system is flawed, it would only take a minor adjustment to fix this critical issue.

In Magento, Javascript is added to the Head block through XML and stored in an array, which is then iterated over and displayed in the head section of your HTML code. Our suggestion is that instead of simply adding Javascript files to the head, an extra parameter be included that allows you to specify a group for the Javascript. Consider the following code:

<default>
 <reference name="head">
   <action method="addJs"><script>prototype/prototype.js</script><group>global</group></action>
   <action method="addJs"><script>scriptaculous/builder.js</script><group>global</group></action>
   <action method="addJs"><script>scriptaculous/effects.js</script><group>global</group></action>
   <action method="addJs"><script>varien/form.js</script><group>global</group></action>  </reference>
</default>
 
<catalog_product_view>
 <reference name="head">
   <action method="addJs"><script>varien/product.js</script><group>product</group></action>
   <action method="addJs"><script>varien/configurable.js</script><group>product</group></action>
 </reference>
</catalog_product_view>

Notice the addition of the paramter  group ? Instead of all of the Javascript being merged into a single file, the group parameter would be be used to decide which Javascript files get merged together. The above code would result in two separate merged files being created for the product page; one containing the global Javascript that is used on the homepage (and the whole of the site) and a second containing the Javascript used solely on the product page. Although this would create an extra page request, time would still be saved by not having to re-download the Javascript used on the homepage! If this technique were applied to the whole Magento site, each piece of Javascript would be downloaded once and once only!


源文:WHY YOU SHOULDN'T MERGE JAVASCRIPT IN MAGENTO


目录
相关文章
|
8月前
|
机器学习/深度学习 编解码 计算机视觉
YOLOv11改进策略【卷积层】| ICCV-2023 SAFM 空间自适应特征调制模块 对C3k2进行二次创新
YOLOv11改进策略【卷积层】| ICCV-2023 SAFM 空间自适应特征调制模块 对C3k2进行二次创新
227 0
YOLOv11改进策略【卷积层】| ICCV-2023 SAFM 空间自适应特征调制模块 对C3k2进行二次创新
|
前端开发 测试技术 UED
使用Selenium WebDriver模拟用户操作防止滑动条验证
在进行Web自动化测试时,经常会遇到各种前端验证机制,如滑动条验证,这些机制设计用来防止自动化脚本模拟用户行为。在本文中,我们将探讨如何使用Selenium WebDriver来模拟用户操作,以规避这些验证机制。
|
11月前
|
人工智能 Oracle 关系型数据库
2024年客户口碑最好的CRM系统
本文介绍了客户关系管理(CRM)系统的重要性及评价标准,如功能性、用户体验、可靠性和稳定性、扩展性、性价比、用户评价、数据安全性和客户满意度等。随后,详细推荐了国内外8款主流CRM系统,包括销售易、简道云CRM、浪潮CRM、励销云、百应CRM、千百客CRM、创蓝CRM、企点CRM,以及国际知名的Salesforce、Microsoft Dynamics 365和Oracle CRM,帮助企业根据自身需求选择最合适的CRM解决方案。
|
机器学习/深度学习 人工智能 分布式计算
5分钟搭建企业级AI问答知识库
【8月更文挑战第14天】5分钟搭建企业级AI问答知识库
|
JSON JavaScript 前端开发
【面试题】:axios二次封装都进行了哪些配置以及如果项目里面有两个baseURL你怎么解决?
axios二次封装都进行了哪些配置以及如果项目里面有两个baseURL怎么解决?
398 0
|
存储 监控 安全
网络安全法中的 ISO 27001 和 CIA
【8月更文挑战第19天】
561 0
|
机器学习/深度学习 人工智能 运维
智能化运维:AI在故障预测中的应用
【6月更文挑战第8天】随着人工智能技术的飞速发展,其在IT运维领域的应用也日益广泛。本文将探讨AI技术如何助力运维团队实现故障的智能预测,提高系统稳定性和业务连续性。
|
JavaScript
vue列表信息展示中新增数据,与编辑数据页面复用,降低重复代码
vue列表信息展示中新增数据,与编辑数据页面复用,降低重复代码
532 2
|
弹性计算 双11
购买阿里云服务器先优惠券再购买流程参考
如果我们想阿里云服务器的价格更优惠一些的话,先优惠券再购买是非常有效的一个方式,首先就是要注意部分云服务器的购买条件,部分云服务器仅限新用户购买,其次一定要先领取阿里云送的各种优惠券,然后是在实际购买过程中尽量选择阿里云活动中的各种云服务器。本文为大家分享先领优惠券然后再通过阿里云的活动或者云服务器产品页面选购云服务器的实战教程,以供参考。
购买阿里云服务器先优惠券再购买流程参考