This issue is to document my thought process and my approach in attempting to solve the loading issue for the Fifth Row Directory page (directory.html), as well as to collect any possible external suggestions for an elegant solution.
Embedding 55 iframes on the same webpage are going to cause browser loading problems such as hanging up, lagging, or even crashing and burning down. In an attempt to solve this loading issue, I implemented lazyloading for both directory.html and watchlist.html. The implementation is twofold:
First, we set the data-src attributes of each iframe to their respective Microsoft Stream source URLs. Then, after we load all the iframes with their src attribute still undefined, we run this script to load only the on-screen iframes by setting their respective src attributes to their data-src attributes if native browser lazyloading is supported.
The else statement will then run if native browser lazyloading is not supported, which would lead to the fetching of the lazysizes.min.js file as a lazyloading solution provided by an external vendor. lazysizes will enable lazyloading for iframes with class="lazyload".
This solution worked for the short term, but admittedly it is neither permanent nor the most elegant solution. Once a user has accumulated enough loaded iframes, the browser will start to lag and slow down again. This might prevent a user from eventually loading all the iframes on the page (especially if their computer or device does not possess enough memory power). A possible solution to this would be to unload iframes as they go out of the load-in distance threshold. However, this might cause too many requests to the Microsoft Stream server since whenever the iframes scroll out of the user's viewport, when the users scroll back to said iframes, the iframes would need to re-load all of the content all over again. Thus, such a solution would be quite inefficient. Another solution would be to simply separate groups of iframes based on their cluster, but this will generate additional pages, which may seem a little not elegant. Another solution would be to combine the previous two solutions in a kind of hybrid implementation, whereby iframes in previous clusters/sections would be unloaded once the user scrolls past those iframes. While this hybrid implementation could work, it still faces the "repetitive loading" issue. Yet another possibility would be to just load still images of each video's thumbnail, which would then possess an a tag which opens up a new _blank page with the corresponding video's URL (similar to the implementation on YouTube's homepage). However, this will force users to tediously go back and forth between each page of each video and the main website page directory, at which point we might as well just redirect them to the SUTD DiscoverSUTD Fifth Row Showcase Microsoft Stream channel/group link instead (since the Microsoft Stream page has a sort-of "recommended" section as well).
If anyone has a suggestion on how to elegantly solve this issue, please feel free to comment down below. Otherwise, this issue will serve as a future reference. Future generations of DiscoverSUTD teams might want to investigate further into solving and eliminating this issue altogether.
Embedding 55 iframes on the same webpage are going to cause browser loading problems such as hanging up, lagging, or even crashing and burning down. In an attempt to solve this loading issue, I implemented lazyloading for both
directory.html
andwatchlist.html
. The implementation is twofold:data-src
attributes of each iframe to their respective Microsoft Stream source URLs. Then, after we load all the iframes with theirsrc
attribute still undefined, we run this script to load only the on-screen iframes by setting their respectivesrc
attributes to theirdata-src
attributes if native browser lazyloading is supported.else
statement will then run if native browser lazyloading is not supported, which would lead to the fetching of thelazysizes.min.js
file as a lazyloading solution provided by an external vendor.lazysizes
will enable lazyloading for iframes withclass="lazyload"
.This solution worked for the short term, but admittedly it is neither permanent nor the most elegant solution. Once a user has accumulated enough loaded iframes, the browser will start to lag and slow down again. This might prevent a user from eventually loading all the iframes on the page (especially if their computer or device does not possess enough memory power). A possible solution to this would be to unload iframes as they go out of the load-in distance threshold. However, this might cause too many requests to the Microsoft Stream server since whenever the iframes scroll out of the user's viewport, when the users scroll back to said iframes, the iframes would need to re-load all of the content all over again. Thus, such a solution would be quite inefficient. Another solution would be to simply separate groups of iframes based on their cluster, but this will generate additional pages, which may seem a little not elegant. Another solution would be to combine the previous two solutions in a kind of hybrid implementation, whereby iframes in previous clusters/sections would be unloaded once the user scrolls past those iframes. While this hybrid implementation could work, it still faces the "repetitive loading" issue. Yet another possibility would be to just load still images of each video's thumbnail, which would then possess an
a
tag which opens up a new_blank
page with the corresponding video's URL (similar to the implementation on YouTube's homepage). However, this will force users to tediously go back and forth between each page of each video and the main website page directory, at which point we might as well just redirect them to the SUTD DiscoverSUTD Fifth Row Showcase Microsoft Stream channel/group link instead (since the Microsoft Stream page has a sort-of "recommended" section as well).If anyone has a suggestion on how to elegantly solve this issue, please feel free to comment down below. Otherwise, this issue will serve as a future reference. Future generations of DiscoverSUTD teams might want to investigate further into solving and eliminating this issue altogether.