Cart 0 Product Products (empty)
No products
To be determined Shipping
$0.00 Total
Product successfully added to your shopping cart
Quantity
Total
There are 0 items in your cart. There is 1 item in your cart.
Total products
Total shipping To be determined
Total
Web sites come in all shapes and sizes. Therefore, it's important to appropriately manage the development process as you progress.
For example, changes to a small blog can be made in the live environment, but the same does not hold true for a more mission critical system. As your site becomes more important (and more complex) you'll need to exercise additional care to insure unexpected mistakes are not made. Usually this means working in a duplicate environment which can be kept private in order to test proposed changes.
Review the following description to see how this can be accomplished (using WordPress as an example). Of course there are many ways to implement such a process and so you might consider an overview of the concept itself.
Naturally, there are basic and straightforward tools one can use too. Automated tests (such as this one) can be used as a basic review of your site design. Just remember, nothing can replace experienced human judgment. Bear in mind this kind of test exercises the site and its design... not necessarily the server itself. In other words any heavy, unoptimized, or poorly designed site is likely to be slow no matter how fast the server. It's important that one doesn't jump to conclusions ;-)
Given that there are a lot of powerful and easy to use web-site software packages (e.g. Wordpress, Zikula, Drupal, PrestaShop, etc), make sure not to inadvertently overload your site. Liberal use of plug-ins and unoptimized graphic images often slow things down. When this happens, distinguishing what is an acceptable design trade-off and what was just an experiment gone wrong can be tricky. A few suggestions follow:
Just because the automated test complains, that doesn't mean you've made a mistake. Very often these tests will complain about things like "too many redirects" but a redirect is a powerful technique which can guide your users to the right location. Such a benefit may easily outweigh any slight delay incurred when loading your site. In this case, you may simply ignore the issue or test the landing URL instead of the URL that's intentionally designed to redirect.
Modularity eases development, but it can hurt performance. A site which has a lot of separate JavaScript and CSS may be easier to create but can cause an inordinate number of requests by the client's browser. There's nothing wrong with the server in this case... the bottleneck is the browser. In an ideal world your development files should be compiled into a production ready state where CSS and JavaScript files are unified and minified (thereby keeping server requests to a minimum). There are a number of ways to accomplish this and we encourage you to investigate possible solutions.
It's not really absolute performance that counts but "perceived performance". Whenever possible, defer loading the less conspicuous features of your site so that more meaningful content is presented first. A typical example is to load big JavaScript files towards the end of the HTML document. In addition, since "web workers" cannot directly modify the DOM, insure that long running JavaScript periodically yields CPU to the browser by way of a "sleep". In doing so, the browser will be able to render content in a more fluid, continuous, and streaming manner. Ultimately, performance is not necessarily how long something takes... but how long it appears to take.