Lazy loading is good for users. Images, videos and iframes below the fold wait until the user scrolls to them, so the first view appears sooner and the initial page weight drops. But it also changes what your server sees, and most load test scripts don't account for that. If your script doesn't follow the way a real user scrolls, you are testing a page that no real user loads. 1. Lazy loading changes the shape of the traffic Without lazy loading, a page load is one big rush. The browser asks for every image, script and iframe as soon as it finds them. With lazy loading, the same page becomes a smaller first burst, followed by more small bursts as the user scrolls. The total work can also be lower, because users who never scroll to the bottom never trigger the deferred requests. That makes scroll depth part of your test design. If your analytics show that only some visitors reach the reviews section, then only that share of your virtual users should load it. 2. What reco...
You ran the load test, the numbers looked good, and the release went out. Then production slowed down anyway. If that sounds familiar, the problem usually is not the test itself. It is the gap between the test and the real world. Here are the five gaps I see most often, and how to close them. 1. The test environment is smaller than production This is the most common one. Your staging environment has two app servers while production has eight, or the test database holds a fraction of the real data. Smaller environments respond differently under load , and the results do not scale in a straight line. Fix: make the test environment as close to production as you can, and where you cannot, write down the differences. A result with known gaps is useful. A result that pretends the gaps do not exist is not. 2. The test data is too clean Test data is usually tidy. The same hundred users, the same product IDs, the same search terms, and everything already in cache. Production data is messy. User...