Frequently asked questions


Performance - how do I improve it?
This is a summary of several ways of improving performance for websites on our webservers.

General tips

  • Keep file sizes small. Not everybody has a state-of-the-art Internet connection. Even when things to quickly for you, it may be slow for others.
  • Do not use the WIDTH and HEIGHT attributes for IMG SRC to resize your images. Pre-create resized thumbnails instead, and link with A HREF to the bigger image if you want people to see it.
  • Test viewing speed with a netbook (small, slow laptop).
  • Test viewing speed with a mobile phone without high-speed coverage.
  • Remember that Flash and PDF often are used for spreading viruses, spyware and other malicious software, and also can be tougher to load for the web browser, especially for small or mobile devices. Use HTML and CSS instead.
  • Minimize the use of external content (images, ads, Flash, movies, etc.). "External" means any content you fetch/load from other websites and display on your website.
  • Add-ons, extensions, modules, themes, plugins etc. may slow down your website. Some programs, e.g. Joomla, will slow down even if they are not activated, only installed.

Tools on your own computer

Anyone working with webpage performance ought to test their websites with several different browsers, and perhaps a mobile phone via a mobile data subscription (not WiFi). The following browsers should be tested on your own computer:

  • Firefox (Linux, Mac, Windows)
  • Google Chrome (Linux, Mac, Windows)
  • Internet Explorer (Windows)
  • Opera (Linux, Mac, Windows)
  • Safari (Mac, Windows)

For testing, we recommend that you use browser add-ons that let you test and monitor resource usage. Google Chrome (View->Developer->Developer Tools), Opera (Tools->Advanced->Opera Dragonfly) and Safari (Develop->Show Web Inspector) include these in the browser itself, but you may need to enable these features specifically. Check your documentation.

For Firefox, we recommend using both the following add-ons:

PHP and CGI in links and includes

When we mention PHP in the sections below, the principles also apply to CGI, which works similarly.

On our servers, PHP runs as CGI under suphp. PHP pages and scripts therefore runs as separate processes for every web request, using your own Unix user (FTP username). These processes terminate when the webpage is finished loading, and neither the code nor the results are stored in the webserver.

This results in decent security, but at the sacrifice of some performance. You should therefore avoid some typical coding styles for "acceleration" or "caching" with PHP, which simply will not work. In worst case, you may run afoul of the webserver's self defence mechanism, which is triggered by too many simultaneous elements, pages and scripts.

  1. Images should always be loaded statically with
    <IMG SRC="/path/to/image_4711.png">
    and not via a PHP/CGI script, e.g.
    <IMG SRC="/path/to/image_viewer.php?image=4711.png">
    Corrolary: pre-resize images to thumbnails when you upload the originals to the server, do not resize images dynamically every time they are displayed.
  2. CSS and JavaScript should, for the same reasons, also be loaded statically, not via PHP.
  3. Compression content should be performed before it is uploaded to the server, not via PHP. If you know how to enable and use ob_gzhandler, then you may consider that an exception to the rule.
  4. Do not cache content in PHP files, save to static HTML instead.

    <a href="/cache/1/1a/1a23bsadf.html">Cached document</a>
    Also good: cache the information in your MySQL database.

    <a href="/cache/1/1a/1a23bsadf.php">Cached document</a>
  5. Do not use include(), include_once(), require() or require_once() with absolute URLs. Use relative references instead.

    Good code:
    Bad code:
    The above will start a new PHP process for every include(), and will slow down your webpages considerably.
  6. Try to avoid the use of cookies and sessions where you do not need to have them. This means that our servers can cache static information from one user to the next.

Database usage

  • Connect to the database only once per page view.
  • Specify the exact database columns you need to fetch, e.g.
    SELECT family_name, given_name, birth_place FROM people
    Avoid the general selector, do not use e.g.
    SELECT * FROM people
    if you do not need all the columns.
  • Frequently updated and queried tables will often be slow with the MyISAM engine, consider switching to InnoDB:
    ALTER TABLE people ENGINE innodb;
  • Tables where lots of data has been deleted, or many changes have been performed in varchar, varbinary, blob, or text fields, should be optimized regularly. For the "people" table, use this SQL command:
    OPTIMIZE TABLE people;
  • See also the MySQL documentation's optimization chapter. Keep in mind that you do not have system access or SUPER privileges.


Avoid using TimThumb or similar solutions for thumbnails and images, they do what we specifically not recommend in the first point of the above list ("PHP and CGI in links and includes"). WordPress developers recommend using built-in functions for thumbnails, with several functional benefits compared to TimThumb etc.

High-traffic/large Wordpress sites should consider e.g. WP Super Cache. It is very important that caching uses method 1, mod_rewrite. Method 2 and 3 does not improve performance with our webhotel service.

The Wordpress admin pages tend to slow down with an increase in extensions, plugins and themes, because they usually check with the vendor's website for updates. This is a feature, not a bug, but consider removing extensions etc. that you do not use.


The examples below use screenshots from Chrome 8. In Chrome 9 and more recent versions, use the "Network" panel instead of "Resources". Usage and interpretation is similar in Chrome 9. You can read more about this at the Google Chrome developer webpages.

Our first example is via our 1 Gbps connection, download times will be longer with slower connections: loads its content from several sources, e.g. other servers belonging to VG, and e.g. the external provider For the most part, loading is quick anyway, even though the external content and content from other servers could have slowed down page loads considerably. If we had scrolled down in the resource usage list, we would see what caused the additional second of load time.

Domainnameshop FAQ

And here is a similar example for the FAQ entry you are reading now:

FAQ 246-resources

As you see, faq is mainly resource limited by the CGI script itself, while image loading is quick. The target for optimization must then be the code for faq itself.

See also:

© 2024 Domeneshop AS · About us · Terms · Privacy policy