This article summarizes the efforts and explorations made in experience optimization for International Station stores over the past two years, which have yielded good results. We hope this sharing will be helpful for other similar scenarios.
Performance optimization can generally be divided into network performance optimization and interactive experience optimization:
- Interactive experience optimization focuses on improving the page’s interactive experience, such as smooth scrolling, timely click feedback, and absence of lag during operations.
- Avoid DOM repaints and reflows
- Minimize DOM operations or merge them
- For animated elements, use positioning that takes them out of the document flow, such as
absolute.
- Ensure timely feedback to user actions and maintain a refresh rate of 60fps
- Ensure each JS task completes within 1000/60 = 16.67ms
- Offload complex computations to worker processes
- Avoid DOM repaints and reflows
- Network performance optimization, in most cases, focuses on initial page load performance.
- Reduce TTFB (Time To First Byte)
- Reduce DNS lookups, TCP handshakes, and SSL connection establishments
- Avoid 302 redirects
- Reduce backend RT (response time)
- Reduce resource download time: e.g., reduce HTML content, enable gzip compression.
- Reduce frontend blocking resource load time
- Reduce synchronous CSS resources
- Avoid synchronous JS tags
- Add appropriate caching
- Utilize ServiceWorker and other methods for preloading and prerendering.
- Reduce TTFB (Time To First Byte)
Specifically for International Station stores: on a page built by the user backend and generating frontend scenarios, optimizations still follow the directions mentioned above. Below are some attempts I’ve made in experience optimization, combined with the actual situation of the stores (due to compliance issues, some business data has been anonymized):
- Network Performance Optimization Measures
- Interactive Experience Optimization
- Summary
Network Performance Optimization Measures
PC Storefront - Decoration Backend Image Optimization
Background
A storefront is a scenario where sellers can build their own pages. Many sellers like to upload a background image to enhance the store’s aesthetics. However, these images are often very large, with a 1920 * xxx sized image typically exceeding 1MB, leading to slow loading times in non-Wi-Fi network environments.
Solution
Optimizing this cannot be solved by simple image compression, as in many cases, compression leads to severe image distortion, prompting sellers to file complaints. Therefore, we needed another method to reduce image size. Upon observation, it was found that in most cases, the central part of the background image is covered by regular modules, and what’s visible on the frontend is content outside the display width of these central modules. So, we can try to cover the middle part of the image with a solid color, which can significantly reduce the size of user-uploaded background images.
The principle of implementation is simple: draw the background image onto a canvas, then fill the central 1200px width with a solid color. The core implementation code is as follows:
/**
* 用纯色填充指定区域
*/
coverArea (canvas) {
const { coverColor, coverWidth } = this.props
if (!this.state.needCover) {
return canvas
}
const w = canvas.width
const h = canvas.height
const ctx = canvas.getContext('2d')
const gap = (w - coverWidth) / 2
// 清除中间 1200px 部分的内容
ctx.clearRect(gap, 0, coverWidth, h)
ctx.fillStyle = coverColor
// 用给定的颜色填充中间 1200px 的内容
ctx.fillRect(gap, 0, coverWidth, h)
return canvas
}
After testing: For a detailed 1920 * 1080 landscape image in JPEG format, the original image was 1.6MB. After cropping, it was 464KB, reducing it to 464/(1.6*1024) = 0.2832, approximately 30% of the original size, a significant improvement, as shown below:
This optimization not only improves page loading speed but also reduces CDN traffic consumption, killing two birds with one stone.
PC Storefront - Third-Party Module User Performance Optimization
Background
Currently, static resources for third-party templates1 are served via Alibaba Cloud’s CDN, with the domain shopmod-icbu.alicdn.com. This CDN has fewer overseas nodes, leading to slow resource loading and impacting user experience.
Therefore, we attempted to use Akamai’s CDN, which has more overseas points of presence, for forwarding. This aims to accelerate access speeds for overseas users visiting stores that use third-party templates, thereby enhancing the user experience for third-party template merchants.
Solution
Replace shopmod-icbu.alicdn.com/1dbb3279357007484e7778d9a1060811/web-index.css with http://i.alicdn.com/@shopmod/1dbb3279357007484e7778d9a1060811/web-index.css, which is then forwarded by i.alicdn.com.
All JS files on the storefront frontend are asynchronously loaded, controlled by intl-mod-loader, which is referenced by shop-render. For first-party modules, ownType is *, and resource addresses are determined by shop-render’s config. For third-party modules, ownType is **, and resource addresses are determined by assetsCss and assetsJs within the mds of the third-party module’s module-data. The assetsCss and assetsJs addresses for module data are modified in the backend application.
Results
Initial page load time was further reduced by 12.4% on top of previous optimizations, dwell time increased by 4.6%, and bounce rate decreased by 5.2%.
PC Storefront - Module Asynchronization
Background
The backend RT for the homepage was somewhat long compared to the overall store or International Station, ultimately affecting the initial page load speed.
Analysis
It can be seen that the backend RT for the storefront homepage was around **0ms, while the overall RT was around **0ms. Therefore, reducing the homepage’s RT was a good starting point. The reason why the homepage’s RT was significantly higher than the average is that the homepage supports user-defined decoration, meaning the number of modules is not fixed, and each module’s rendering and data retrieval takes time.
Previously, we traced the entire rendering pipeline with backend colleagues and found that data retrieval for product recommendation modules took a long time, averaging around **0ms per category module. So, if a user decorated their homepage with 10 product recommendation modules, the backend RT alone would require at least **0ms * 10 (yes, our integrated middleware rendering logic renders all modules serially). Adding **0ms for network transmission, the TTFB would be **0ms. Therefore, our optimization strategy was to make category modules asynchronous.
Results
We first refactored frequently used modules to be asynchronous. After launch, we saw good results: initial page load time improved by about 100ms.
Overall RT was shortened, and TTFB decreased by approximately 12%.
Mobile Storefront - Migrating from Weex to React Isomorphic
Background
The old mobile storefront was a Weex-based asynchronously rendered page, with an initial load time of **s+. After a series of complex optimizations, it was barely improved to around **s, and there were significant efficiency issues in development. After an in-depth analysis at the time, it was decided to upgrade the mobile storefront’s frontend architecture, migrating from Weex to a React isomorphic H5 storefront, similar to the PC store.
A detailed background was documented in an internal company article titled ‘ICBU Storefront Frontend Architecture Status and Evolution Direction,’ which is not being released here due to compliance issues.
Solution
Given the complexity of the mobile storefront, which includes both official and third-party modules (over 50 official modules and countless third-party ones), a complete refactor and launch at once was not feasible. A solution that allowed for incremental changes was needed. Considering that most store modules are primarily for display, with fewer heavily interactive ones, I proposed two solutions in this context:
- Rax-to-React Code Conversion Solution
- As the name suggests, this involves converting Rax-based Weex code to React using Babel transpilation tools, accelerating the module migration process.
- Rax-React Hybrid Rendering Solution
- For remaining third-party modules and other lower-priority modules, a hybrid rendering solution allows both old and new modules to run directly under the new architecture, addressing the issue of too many modules to migrate.
Results
The entire project was divided into two phases:
- Phase one involved manually migrating a single List page, primarily to verify whether the React isomorphic H5 page could meet business requirements.
- Phase two began with the migration of the entire storefront using the two solutions mentioned earlier.
Achievements:
- Phase One
- Performance: List initial page load performance improved from ***s (optimized Weex) to ***s, a reduction of 39.7%.
- Business: List scroll depth increased by 3.82%, List->Detail conversion increased by 4.3%, and generalized AB conversion rate increased by 3.2%.
- Phase Two
- Performance: Overall initial page load time improved from ***s to ***s, a reduction of 37.5%.
- Business: Daily average SEO traffic increased by 29.075% month-over-month, dwell time increased by 7.681%, and generalized AB conversion rate increased by 18.673%.
Streaming Rendering
After implementing some conventional optimization solutions, both PC and mobile storefront performance reached within ***s. At this point, the store’s TTFB was around ***ms, indicating further room for optimization. Thus, we undertook a [streaming rendering transformation]:
Streaming rendering leverages the chunked transfer encoding feature of HTTP/1.1, allowing the server to return HTML in chunks. The browser can then progressively render the page as it receives these chunks, which helps with initial page display and enhances user experience.
Achievements
Both PC and mobile storefronts subsequently implemented streaming rendering. Due to a significant reduction in backend RT, TTFB decreased by approximately ***ms in both cases. Specific achievements are as follows:
- PC:
- Performance: Initial page load time decreased by about 8%.
- Business: As no A/B test was conducted at the time of launch, specific business data was not observed.
- Mobile Site:
- Performance: Initial page load time decreased by 8.69%.
- Business:
- Average visit depth relatively increased by 1.024%.
- Average visit duration relatively decreased by 0.020%.
- One-step AB conversion rate relatively increased by 0.318%.
- App:
- Initial page load time decreased by about 7.2% under 50% grayscale (A/B test rollout).
- Business:
- Visit depth relatively decreased by 2.090%.
- Visit duration relatively decreased by 2.093%.
- One-step AB conversion rate relatively increased by 0.547%.
Concurrently, an engineering solution for integrating streaming rendering was developed [[Streaming Rendering Engineering]].
Interactive Experience Optimization
PC Storefront SPA Transformation Results
Background
The PC storefront was originally a traditional backend-rendered multi-page architecture. Clicking each tab required a standard page render to refresh the page. Although we had implemented many optimization solutions such as streaming rendering and asynchronous loading of time-consuming modules, each page switch still required the browser to refresh the entire page, which did not provide a good user experience. Therefore, we carried out another upgrade for the PC storefront, transforming it into a pseudo-single-page application using frontend techniques.
Solution
The existing rendering solution was as follows:
Browser initiates request
-> Backend retrieves data
-> Calls React isomorphic service for module rendering
-> Concatenates isomorphic results into a complete string and returns it to the browser
-> Browser parses, loads static resources, and renders the page
-> After JS loads, React re-renders the entire page for event binding and other secondary rendering
-> Rendering complete.The revamped solution is as follows:
Achievements
After the storefront’s single-page transformation went live, A/B test comparisons showed that the experimental group’s initial page load time decreased by about 5% compared to the control group, the AB conversion rate relatively increased by 1.5%, and the bounce rate relatively decreased by 1.7%. Subsequently, after the preloading feature was launched (without A/B testing), performance was further improved, with initial page load time decreasing by 16%.
Mobile Storefront - SPA Transformation - Tab Data Preloading
Strategy
Mobile Storefront Tab Preloading: After staying on the homepage for 1.5s, subsequent tab data begins to preload to accelerate the user experience during tab switching.
Achievements
After release, the mobile site’s initial page load time was reduced by approximately 20%.
Mobile Storefront - ProductTab Infinite Loading Transformation
Background
The ProductTab page of the mobile storefront originally only displayed an overview of some products. To view more, users had to navigate to a new page, as shown below:
Navigating to a new page often leads to user churn. Theoretically, if all products could be infinitely loaded directly on the current page, it would provide a better user experience. Curious why this wasn’t done before, I consulted the former head of the mobile storefront, who explained that the original Weex-based storefront homepage was already a single-page application with significant memory consumption. If the Product page were to also implement infinite loading, it could put even greater pressure on device memory, potentially leading to crashes or forced exits. Therefore, opening a new page was adopted at the time.
Later, the storefront underwent an H5 transformation, no longer using the Weex technology stack. Concurrently, there was a business demand for infinite product loading on the current page. Thus, the ProductTab infinite loading transformation was implemented.
Solution
Still concerned about memory pressure from infinite loading, a month-long experiment was conducted during the project’s launch, along with implementing relevant technical safeguards.
Achievements
Ultimately, A/B test comparisons showed that the AB conversion rate relatively increased by 1.288%.
Summary
From the initial state where both PC and mobile storefronts were not optimally performing in terms of experience, optimizations have brought them to a point where PC initial page load time is 60% of what it was before optimization, and mobile is 37.5%, representing a huge improvement.
During this process, a solution for quickly integrating streaming rendering was also developed. Furthermore, significant achievements were made in business metrics, including visit depth, dwell time, and conversion.
Thanks to colleagues who collaborated throughout the process and to management for their support.
Footnotes
Templates developed by third-party ecosystem designers ↩