Mobile Responsiveness

Just because we have pages that meet accessibility, look nice, and have the perfect amount of content; none of that means anything if the mobile environment suffers from extended loading times and laggy or delayed interactions. 

Mobile environments are meant to be convenient, quick, and responsive. After all, with less screen estate to work with, that should be easy, right? Not just that, but design elements should also conform correctly to the display of the device.

Much of a mobile website's responsiveness is going to be degraded from dynamic components, such as Content Fragments, Data Tables, Embeds, and Images. Specifically, it's the amount of data being housed and loaded at runtime as well as the complexity of the component scripts.

Content Fragments dynamically pull in data from a stored source in the DAM. These individual fields combined with Content Fragment Lists or Content Fragment-driven Data Table allow users to create dynamic pages with specific setups and looks. Multiple components are used to create the "template" for these dynamic pages which may result in response issues if many fragment paths and references are loaded at once. 

Data Tables themselves pull in data from one of a multitude of sources, whether its asset or page paths, CSV files, or ElasticSearch. Regardless of the table used, they allow filtering, sorting, and specificity based on Tags and other field types. The backend has to be able to search, populate and filter through all of these matches in directories where hundreds or even potentially thousands of items exist.

There are special cases where CSV files are used, with the main uses being the Data Table [CSV] and Location Finder components. AEM has to read the CSV file and then perform operations on the data within before creating the data elements and display for the end-user. The larger the dataset, the longer it will take to render results.

The Location Finder is extremely susceptible to this, as the component not only loads CSV data into a table, but renders an along-side map component with pins, details, and categories, as well as functions for radius, search, and filters. A 1,000 row CSV file pulling into a Location Finder component as the only component on a page takes approximately 8 seconds to render and prevents the page from responding to user action.

It is recommended to keep CSV files under 1,000 rows to prevent significant delays and slowdowns.

Embeds and iFrames should be used as sparingly as possible, due to the nature of potential additional HTML code running alongside the page. What this essentially means is the additional pages or elements from these components have to finish before the page will fully load and respond.

Embeds are generally used for pulling in video content from an outside source, but the enhanced Super Embed component offers additional options for direct HTML scripting to be used while on the AEM site page. Additional uses are for creating dynamic maps and graphs when used in conjunction with javascript files saved in the DAM. If bad HTML is injected here, the page may fail to render the component, or even worse, the page itself may fail to render at all.

iFrames have the added issue that users are actually loading another full page within a page, meaning mobile users have to wait through content loads of 2 or more simultaneous pages. Imagine if an AEM page had an iFrame embed to another page which also had an iFrame.

These issues can compound quickly as mobile devices are forced to load significant amounts of data, or bad/inefficient HTML/Javascript embeds can completely break pages or create such complex tasks that initial page load times increase dramatically. Their use should be kept to a minimum, and the WCM team wants users to effectively move away from these Accessibility nightmares.

As mentioned previously, one of the biggest positive uses of mobile devices involves convenience; having the ability to hop on a device from anywhere in the world as long as the user has a Mobile Data or Wi-Fi connection. However, not all devices or connections are the same speed or even have the same connection quality.

This creates scenarios where poor reception equates to extremely long load times, even on pages that are light on content. In order to facilitate faster load times on content-heavy pages, several factors exist:

• Resolution/Re-sizing: All images and videos should be properly resized (resolution) and/or compressed to reduce file sizes. 4K videos are not needed! Remember, mobile data may have to be used to download and buffer through these videos, so the larger the video file size, the longer and more frequent the buffers if speeds can't keep up. 1080p and 720p videos will still look good, especially on mobile devices and will satisfy their use case. 
• Usage: Ensure image and video usage are appropriate. Littering a page with a bunch of different, fancy, large artwork backgrounds in containers will slow page load times as each image has to be downloaded and then rendered into their appropriate space. This also goes for embedding multiple videos on a page; attempt to minimize the amount of content as much as possible.

The best ways to increase responsiveness when using these components:

• Reduce the amount of items searched and returned - Having assets properly organized in folders can help by allowing components to be configured to look directly into a parent folder that houses only a majority of the expected results. By not having a "junk drawer" folder of assets, we help filter out immediately-unwanted items from being searched through by each dynamic component on the page; helping reduce load and overhead on page load times.
• Reduce the amount of dynamic elements on a page - Don't include multiple data tables. Use a single data table if the content can be seamlessly integrated together and then grouped or filtered. If many images are needed on a page, we have a Photo Gallery component meant for that use.
• Don't load resource-intensive Embeds - Use embeds sparingly. IFrames can present issues if the resource isn't configured correctly, which may cause pages to stop rendering.
• Ensure images and videos are compressed and the correct resolution for their use - Images should be under 300kb for normal use. Videos should be compressed to save storage space where able. The larger the asset download is, the longer users have to wait to view it.