From the last home page revision, there have been 2 years, 3 months and 5 days. Compared to the previous revision, which took a big step in the overall framework and development process of the home page (the previous two revisions summarized Portal: 2016, 2017), this revision looks like a bit of a dive — no splash. With the caution and expectation of the little giant standing on the shoulders of the giant, this revision, based on the framework and process of the continuation of the 17 versions, adds a brick to the stability, security, visual experience and barrier-free experience of the home page.

This article will be elaborated from the following aspects

  • Introduce strong type checking
  • Upgrade resource construction scheme
  • Access automation test
  • Improve the monitoring system
  • Optimize the page loading experience: skeleton screen
  • Optimize the information accessibility experience

Introduce strong type checking

With near-flawless performance, we decided to start with stability and introduce strong type verification into the project to compensate for the unpredictability of a weakly typed language like JavaScript.

The strongly typed language TypeScript has been out for more than six years, and the number of domestic app developers is slowly growing. In general, business development cycles are short and iterative, and TypeScript’s introduction is a time-consuming effort for a large number of developers. The business can go live if it’s used, and it can go live if it’s not used, so teams rarely use TypeScript in business production. But adhering to the idea of not toss about not concave and convex, the new homepage is not the mission, based on TS reconstruction.

It’s not hard to do TS refactoring, just change the js suffix to TS. To the end.

I’m kidding, of course! Obviously, such TS is meaningless. Only code that strictly follows the TS standard can maximize the utility of TS. In the project, we turned on strict mode for CHECKING TS. Every time the code was submitted, we did a complete check. Whenever there was a TS error, the submission was forbidden.

Those of you who haven’t used TS very deeply may have a hard time with your life at the beginning, but it’s all for your own good in order to keep your code robust. For example, in the past, it was very difficult to locate and find the window global variable management, developers headache, but after the introduction of TS, as long as the global variable interface Settings, each component will no longer appear redundant or unknown global variables. For example, when writing a storage class that has get and set methods, TS can help detect the type of content to be fetched:


interface MemoryState {
  testa: boolean
  testb: string
}

class Controller {
  state: StateType

  constructor() {
    this.state = {
      state: {},
    }
  }

  get<K extends MemoryStateKeys>(key: K) {
    return this.state.memory[key]
  }

  set<K extends MemoryStateKeys>(key: K, value: MemoryState[K]): MemoryState[K] {
    this.state.memory[key] = value
    return value
  }
}

Copy the code

When we use new Controller().get(“testb”), TS can detect whether testb is a string during development. Through the detection of TS plug-in, we can safely use the method of object of type string, simplify the judgment logic of heavy and complicated, can guarantee that the code in the access to the expected value at the same time by an error found in time, all the input and output is stable and predictable, is rounded when writing code to automatically go part of the test, Escort the development and iteration of the project.

Upgrade resource construction scheme

The build tool Athena, which was used in the previous home page project, helped automate the development process, but when it came to customizing the build process, Athena’s versatility made it difficult to make direct changes. The home page contains three types of resource references: direct out, synchronous and asynchronous, which require special processing of resource packaging. Therefore, we return to Webpack this time and optimize the following scheme based on Webpack 4.0:

Release process optimization

In the release process of the previous version, diff check is performed on the modified files each time to avoid unexpected changes. Webpack’s default packaging mechanism is characterized by providing a sequential ID for each module according to the order in which the module is packaged to manage the dependency of the package of the file. The entry file for the old home page contained the execution environment for dependency package management, so the entry file changed when any package was introduced in a different order. Above packaging mechanism will appear a file introduce order change occurs, could affect the compiled several even ten several files changed, and the logic code part of the documents don’t need to update, this reduces the diff code accuracy, makes the intermediate checks lost its original meaning. Home page caching mechanism and lazy loading mechanism makes the static resources, when released, need to change the file for the CDN cache clearing operations, also means that the file changes, the more the need to clear the cache resource links, and the more links, caused by the cache to clear out of sync resources asynchronous loading the higher the probability of error, Every time you go online, there is a risk.

In order to reduce the risk of release, the new homepage of packaging mechanism changed Webpack packaged logic, by setting, each module through sequence ID management no longer depend on the package, but by proprietary ID file directory to generate the hash code, and the dependence on package execution environment from entry documents as a separate resource request, In this way, every time you change a file, you can only diff the changed file and exclude other unexpected DIff conditions. With the new build solution, code changes are controlled within the expected scope and the deployment process is kept stable.

Project architecture optimization

The performance optimization scheme of the old version of the page included some JS fragments, which were the base functions that the project depended on and needed to be started before the core JS code was executed. But such a plan has some drawbacks:

  • Because the code needs to be straight out of the page template, it can’t use some of the advanced syntax for compatibility reasons, and every time you change it, you have to make sure that your code doesn’t have compatibility problems, resulting in huge maintenance costs. At the same time, the template of the home page is managed by the background, and the changes of the straight code need to be released by the background, so the iteration cost is slightly higher and the risk is not small.
  • Due to the limitation of packaging, the core code and the template code have the same set of common code. Apart from code redundancy, once this part of code changes, both parts of code need to be modified and released at the same time, which increases the maintenance cost of code.

In view of the above problems, the new version we will put the code back into the core code, template code no longer carries any logical code, iterative release version no longer involves the template release, only the release of static resources, the development process of unified use of JS advanced syntax, remove the manual maintenance of compatible grammar code process.

So far, we have optimized the resource distribution solution by enhancing the predictability of resource packaging and optimizing the project resource architecture.

Access automation test

After the completion of a page development, before it is tested, the page self test is an essential link. On the one hand, ensure that the page developed functions can normally operate; On the other hand, ensure that the development of one function does not affect the normal use of other areas of the page.

Under normal circumstances, self-test requires manual testing, but this will have two disadvantages, first, the number of areas to be tested is too large, similar test operations are too frequent, waste of manpower, but also affect the efficiency of the test; Second, the artificial self-test because there is no unified self-test specification, so it is easy to be careless in the test, so as to ignore some seemingly small, in fact, the impact of the huge bug, spent a lot of time, but can not be self-test required effect. In response, we came up with the idea of implementing automated testing. Taking the new home page as an example, we created an automated test script for the new home page by using Nightwatch.js to automate the 73 use cases of the new home page.

The results show that the test of 73 use cases of the new homepage is completed in less than three minutes through the automated test, which means that the self-test time of any page can be controlled in less than five minutes and the accuracy is higher. Check test cases before and within 5 minutes after the release of automated test applications to ensure the security of each release.

Improve the monitoring system

The front-end monitoring system of the old version of the page covers browser information, page loading speed measurement, and floor hiding, but the information notification lags behind and only covers the onLoad time of the page. When the alarm information is received, the problem cannot be quickly located.

Referring to the current monitoring mechanism of JINGdong shopping small program, the new home page adds reporting monitoring for code errors and interface availability.

Code error monitoring: BadJS

The page error is captured by BadJS framework, and the error information is analyzed and processed and reported to JD.com BadJS service. By reporting the data, we can get detailed information about the errors reported and how often they occurred. By analyzing the reported data, some potential problems can be found and repaired in time to ensure the robustness of the home page code. At the same time, according to the number, can also estimate the scope of influence caused by a problem, easy to estimate the loss.

Service availability monitoring

In this revision, specific decision rules are added for the home page in the availability reporting system, including the number of calls, availability, and TP (performance indicator) three dimensions. On this basis, these three dimensions can also be compared to each other to reduce the possibility of false positives. Recently, the system has also launched the red light alarm – voice notification function.

Availability reporting systems are generally used to monitor interface availability, but for home pages, in addition to the interface, there is also a need to pay attention to floor hiding. In the current pocket scheme, the current floor will be hidden when all module interface pockets in each floor fail. Once the floor is hidden, it means that there is a serious problem that needs to be addressed and addressed quickly. When alarm rules are triggered, the availability report system pushes notifications to the interface within 1 minute, facilitating fault detection and loss stop in time. It is important to set a threshold that accurately reflects the occurrence of problems and reduces false alarms. After all, too many cries of Wolf mean no monitoring.

Speed report

In this part, the old Version of Athena speed measurement report scheme is extended, and some parts that are repeated with the service data report are subtracted. Meanwhile, the speed measurement report of the interface is added to improve the fault traceability data system.

Optimize the page loading experience: skeleton screen

In the old version of lazy page loading placeholder scheme, unified area loading animation mode is adopted, which has the advantages of low reuse cost and strong adaptability. However, in the case of large area of modules or dense modules, the experience of loading animation in the region decreases ———— Either the blank area is too large or the loading animation is too dense, the visual difference perception caused by the module loading process is obvious. And for THE PC home page, the white space is too large is the main problem.

Loading experience of the old home page with low network speed

In this revision, we introduced the skeleton screen scheme, with the ultimate aim of minimizing the visual difference between the real module structure and the loading placeholder in the form of grey tofu blocks. Execution can be divided into two corresponding relationships according to visual differences:

  • Weak correspondence: Only the main contents of the module, such as title and sub-items, are blocked, with high reuse and medium adaptability;
  • Strong correspondence: Based on the visual effect, the sub-items are further blocked with pictures and copywriting, and the sub-items with larger occupying area and more complex content are divided into more refined blocks, with low reuse and high adaptability.

Considering the particularity of the home page, we finally chose the skeleton screen scheme with strong mapping relationship, and for the sake of extensibility, we used the skeleton screen with style rendering instead of using the image directly. In addition to higher development costs, the amount of code loaded on the first screen of the page has also increased.

The project structure

Using skeleton screens to achieve the following effects:

  • Placeholders in advance, in the page loading scroll bar does not occur more obvious jump;
  • You can also see a skeleton screen style placeholder when scrolling quickly.

In other words, the content of the skeleton screen needs to be loaded simultaneously with the page. In combination with lazy loading components, the skeleton screen components need to be introduced as loading structure in advance and ensure that the style is loaded at the first time of page rendering, otherwise the significance of the skeleton screen will be lost.

Each component that requires a skeleton screen style is split into a placeholder component. The placeholder structure within a component consists of two styles — color and size positioning, plus an animation style for the container’s outer layers. Color styles are common all over the page, size positioning styles are common with formal components:

The common purpose of size positioning style and formal component is to ensure the uniform modification of skeleton screen and formal style when the component style changes in the future, avoid the omission of style modification, but at the same time increase the maintenance cost of style. At the same time style writing and splitting process also need developers to pay attention to the compatible skeleton screen style, such as the need for placeholder tofu block container spacing padding, margin selection is very important. Therefore, this attempt at a skeleton screen on the home page is not suitable for rapid reuse in other projects.

New home skeleton screen loading experience

Optimize the information accessibility experience

Internet accessibility, that is, assistance for visually impaired people. System-level assistance mainly relies on screen reading tools, which can solve 60% of the obstacles of web side information accessibility, and the remaining 40% needs to be optimized by developers in the process of web development.

Do not do any information barrier-free processing of the web page, the use of screen reading tools to access the general presence of the following problems:

  • Redundant broadcast of useless information, such as jump links, picture names;
  • The pop-up floating layer cannot be accessed.
  • Lazy loading of content directly skipped;

In order to benefit one of the 110 visually impaired people in China (the data is from here), this revision, we decided to open the first information barrier-free practice on the desktop end of Jingdong Mall on the PC home page.

On the desktop, visually impaired users operate mainly through the keyboard. In view of the problems just raised, the initial barrier-free experience optimization scheme of PC home page is divided into several stages.

In the first stage, all tab-accessible elements are semantically defined — the A label containing the off-page jump link is added with the ARIa-label attribute, so that the screen reader can easily read the element information.

In the second stage, the access to the main module of the page is guaranteed. The placeholder container of lazy loading content sets the tab-index to a value greater than 0, so that the TAB key can be traversed to trigger lazy page loading and avoid TAB skipping directly.

In the third stage, expand the operation with elements such as the pop-up layer — add the pop-up layer interaction logic for accessibility, add the aria-Haspopup attribute to the entry, tell the screen reader that this is the entry to the pop-up layer, set the tab-index to a value greater than 0 so that the TAB operation can focus on, After the floating layer pops up, the focus will automatically focus to the floating layer.

The fourth stage is to add extra quick jumps for visually impaired users — refer to Google search results page, and add some hidden quick jumps at the top of the page. PC home page this time to the search box and the bottom of the “recommended for you” location to add a hidden jump link, only using the keyboard users can locate.

For the mall page, the first stage can meet the basic content access, and if you can do the fourth stage, can be considered a complete information barrier-free website. In the business of the mall, the barrier-free experience has always lacked corresponding norms and testing procedures. Therefore, through the revision practice of the PC home page, an information barrier-free development specification for the channel page of the mall is output, which includes:

  • Access path design specifications
  • Semantic specification
  • Screen reading test specification

In the future, the barrier-free experience optimization of other businesses in the mall will be realized by this specification.

In summary, the biggest changes for developers are that the local development experience is more comfortable, the release risk is reduced, the fault tracing is improved, and for users, the page loading jump is greatly reduced, and the visually impaired user experience is finally taken care of. As the entrance and facade of the mall desktop, the improvement of the home page must be more than this. I hope that every revision can have a trace of optimization, so that the home page of this project tends to be perfect.