Preface:To do the front-end architecture for a long time, often to me here are some difficult problems, before the formation of a very good habit of recording problems, will strive to write, accumulate. So there is this article today. Solving and thinking about the problem of Ajax content-download time too slow
Event Background:Developer feedback give me a bug,ajax. The corresponding speed is slow, the location, the speed is slow, because the content-download time is too long, there is a 2s+ delay in Chrome, after confirmed in our mobile client also has this delay. As follows:
Process Analysis:
1. Location Reason:First, seeing this delay, the first reaction is not a front-end bug, and feedback to the backend classmates. But, through the back-end location to find the interface feedback time very quickly, read the facts of foreign documents, this is due to the browser event is not standard caused by the bug.
2.bug Analysis:Through the communication of the development students, I found that there are two characteristics of the bug, first of all, this delay only need to pull the load to cause the AJAX request, and the unified environment and the browser latency is similar, both in 2-3s. Second, part of the pull-up component, although it also triggers Ajax, has no delay. So began the front-end, the reason for the positioning, first find the point: Because of our project architecture design, all the pull-up load is done by a basic component Pagger, and its part of the code, the principle is through the browser scroll events and resize events to detect whether the component is in the visual area, If yes, the Hasmore function is triggered.
Second, look at the business pages that have latency issues and the business pages that do not appear to be facing this component's call differences. By contrast, there is no difference between the two components. (So this mystery, interested students can contact me to discuss .....) I can send you the source code. After several recurring problems, it is obvious that chrome on the PC, using the touch mode delay occasionally disappears, and uses the MouseWheel delay to appear again. Therefore, the problem is located in the MouseWheel event and its similar corresponding scroll event.
Bug fixes:In combination with the reasons for the appeal and the discussion of several posts viewed, the following conclusions are drawn: 1.chrome Browser MouseWheel event is the cause of this delay (MouseWheel event is not a standard event, not recommended for everyone), of course! I did not use the MouseWheel event in the code, but the use of the scroll event could cause a conflict with the MouseWheel event, and WebView unfortunately hit this flaw in our characteristic mobile client. 2. To solve this problem, you can try to listen to this event (if the browser does not have this event, will not respond to this listener, no conflict), and when the event is triggered, cancel all its default behavior: So by listening to its event model of the DeltaY (mouse vertical scrolling amount) when it has vertical displacement, Trigger Preventdefault, so the code is as follows:
1 window.addeventlistener ("MouseWheel", (e) + = {2 if (e.deltay = = = 1) { 3 e.preventdefault (); 4 }5 })
By adding this code to the page initialization code of the front-end base library, the magical discovery of the related page content-download latency problem has been resolved.
Summary:
the nature of the compatibility issue:WebKit architecture, some modules are generally not shared in the browser, some modules in the browser are some features are not shared, and can be changed by different compilation configuration of their behavior. Therefore, many browsers that use WebKit may behave differently.
solve these "magic" problems, or need patience, collaboration and a strange alternative ahReference: https://stackoverflow.com/questions/47524205/random-high-content-download-time-in-chromehttps://github.com/ tryghost/ghost/issues/7934
The solution and thinking about the problem of Ajax content-download time too slow
