Users judge how well the network is, not by backstage indicators, but by how long he sees the first page. In Portal authentication, the authentication page is that first impression. The first reaction to a half-day failure of the page is that the net is not loaded, and instead of being loaded, more requests for certification are created by repeatedly breaking up the chain and re-renewing it. The certification success rate, complaints, and these indicators are often dragged down by a slow page, rather than by the authentication logic itself.
We'll have to detect where it is first.
Page loads are slow, often for reasons that are not in the authentication logic but on the page ' s own resources. If images, styles and scripts quoted on pages are all located at an external site, users will launch multiple additional requests each time they open, which are restricted before certification is passed, and whether they can be sent and depend on the configuration of the release policy. Another common reason is that a page is too large to contain hundreds of kbps without compression, and it may be loaded in areas with weak signals for long periods. The search should take place on real terminals and look at the time every resource request takes time, rather than just try it on the office network.
Loading slows the time window for the authentication.
The authentication process usually has a time-out window, from the user being redirected to the page, completing information, submitting, going back to the check and notifying the device that it is released. The whole chain is in this window. The page loads are slow, and the window is consumed before the user starts entering, and the rest of the time is shorter, and the user is slightly slower. This indicates an increase in the certification failure rate, but if only checking the account number and checkup, the root factor will never be found because the root factor is loaded on the page.
Reducing external dependence is the most effective way to optimize
Optimizing the authentication page, with input output being the highest action, reduces external dependence. All required resources on the page are localized as much as possible, without placing pictures and scripts at addresses that require access to the public network; external resources must be cited to assess whether they are accessible before certification, and if they cannot reach the option. Second, controlling the size of the page, condensing the picture by actual display dimensions, and removing unnecessary animations and effects.
Redirect the link as short as possible.
Some configurations allow users to jump over an address several times before reaching the final authentication page, each time consuming time and being particularly visible in a weak signal environment. The more many jumps, any problem with one of the middle links will result in the end page being out of order. The configuration should check the actual redirection path, merge or reduce the jump. Also, care should be taken whether the target is stable, some projects have to match the jump target with a temporary domain name, and the entire certification becomes obsolete after maturity, and such risk should be removed from the acceptance list.
The performance of different terminals needs to be measured overlayed.
The authentication page does not perform consistently on different terminals, and the screen sizes, browser kernels, systems handle web portals differently. Instead of assuming that all end performance is consistent, the program uses a coverage list to be actual at the receiving and inspection stage: common versions of mainstream mobile phone systems, varying price types, and special terminals actually present in the project. Coverage lists are determined by the user group of the project, such as internal staff and external customers, with a completely different terminal distribution.
The degree of customization and performance must be balanced.
Portal pages support high self-definition, and can be very refined, but precision often means heavier. Brands want a quality page, and the carrier wants it to load fast, which requires balance. It is more feasible to design in layers: first screens only with the necessary authentication areas and brand markings to ensure quick content; more displays are placed on successful pages after certification or subsequent delivery. This does not affect brand expression or sacrifice initial speed.
I want the first screen time included in the acceptance.
Since the first screen speed has such a large impact on experience, it should be turned into an acceptable indicator rather than a feeling. It is suggested that in receiving and inspection documents it should be clear: under specified network conditions, using a designated terminal list, the time between the authentication page and the occurrence of interactive content should be kept within range. This indicator is to be written together with test conditions, which are not comparable across networks.
The page after authentication has been successful is also controlled
Many projects focus on the authentication page, ignoring the slides that follow certification. This page will see if it is loaded slowly or simply unopened, and the user ' s judgment is that the authentication has failed, then restarts and repeats it to create a new authentication request. So successful pages also need to be able to control volume, reduce external dependence, and ensure that they are open. Successful pages are suitable for brand displays, activity information or subsequent guidance, but displays should be arranged after interactive core tips have been made to convince users that they are connected.