Modern web page load testing can be a challenging task due to the vast variety of incorporated web technologies. Let’s have a look at some most known issues that must be considered upon picking the right type of testing applications to go with web page monitoring.

IFrame Objects

Nowadays web pages include loads of embedded third-party content such as advertisement sections, analytics, widgets (google maps, YouTube videos, etc. ). IFrame inline elements enable embedding another web document within the current HTML document. In short, using IFrame developers can insert content from an external source or, in other words, another web page on their web page.

Since IFrame includes a separate web resource, the content inside the IFrame element is independent of the current web page and can’t be reached by the simple HTTP request to the parent URL. As a response to an HTTP request to the web page, a web server returns HTML, but it is not exactly the same that the real browser does. To display IFrame content browsers parse the page’s HTML code and then execute third-party scripts.

Single-Page Apps

Speaking of modern trends in web development, a single-page application (SPA) is one more tricky thing in terms of web performance monitoring. SPA is a single URL web application run entirely in a web browser. Here are a few things you should consider before choosing the right application for SPA load testing.

One of the first items to take into account is that SPA logic relies heavily on JavaScript technology. Every time a user clicks a button or performs any other action on the web page (navigating between tabs, filling web forms, etc.), a browser executes JavaScript and renders the web page.

Secondly, the authentication in an SPA involves HTTP headers carrying access credentials (e.g., JSON web tokens). Access tokens are provided by an SPA server for each session. When a browser executes HTTP calls, it extracts the token from the SPA server response and passes it back with each HTTP request.

Comprehensive Load Testing with LoadView

As was shown above, modern web apps logic traits put limitations on load testing with tools that work at the protocol level and do NOT use a browser. Such tools allow emulating web requests to the target web server without testing the application itself. However, creating any requests to operate with user data on the page requires corresponding knowledge in web development.

For example, to log into a web application that requires authentication, you need to authenticate client’s calls per each session. Otherwise, page performance can’t be tested accurately.

Also, as a successful result of the HTTP(S) request to a target web page, one will receive a page load “complete” event. But at the same time, it does not mean that all the JavaScripts were parsed or executed properly. To be sure that a user receives proper content, an assert keyword or image validation seems to be the right choice. Let’s say we need to check the keyword on the third-party banner represented with the <iframe> tag in HTML. Since iframe HTML object itself doesn’t contain any content to be verified (it is loaded by JavaScript) we can’t perform keyword validation without executing the script in a real browser.

On the other hand, LoadView works like a real browser and supports JavaScript execution and authentication logic at the browser level. All that you need to do is to script user actions on the target page using the built-in recorder and set up a load pattern. It’s as simple as that!

The test will be performed in a real browser (Chrome or Edge options are available) to simulate real user experience and provide realistic test results.

 

For more information on web application load testing, see Getting Started with Stress Test Setup and Configuring Web Application Task.