Get a faster web site

 

Our web platform is designed to be as fast as possible, but in order to achieve maximum speed adjustments might be required.
Loading times of 4ms for https-pages are common for optimised sites.


PHP / dynamic content

1. Is the same content viewed by all / most users ?
Make sure you do not set any cookies as the WebCDN cache can't pre-cache your content. If you use cookies when there is no legitim interest/reason, you will most likely need to display the annoying cookie consent popup.
Under no circumstances should you use cookies as a mean of site configuration (language etc). If you absolutely must store data in the browser, use local storage. However make sure the site works even if local storage is disabled.
If you cannot disable cookies, WebCDN can be configured to ignore specific cookies sent by the browser and use caching anyway. This is useful if the cookie is only used inside the browser by javascript/clientside. By default, WebCDN ignore cookies starting with underline _ for cache calculation.

2. Remove pragma/cache-control- and expire-headers which disables caching. WebCDN will figure out if the content can be cached or not.

If you run a WooCommerce store, talk to us and we can optimize caching for it further. Many plugins behave irrational when it comes to optimisation.
If you run other types of portals with a login, make sure cookies are used after you login. You might also want to explicitly set cache-control headers for cachable content for fine-tuning.

3. Make sure your service works with the newest PHP-version 8.x.
WebCDN runs the newest PHP-version by default, but some customers have configured for older versions due to compability issues.
Running an up-to-date PHP-version will make sure the site runs as fast as possible.

Static content

You don't need to do much in order to get an optimal configuration. Static content is pre-cached and compressed by WebCDN as default.
Folders which are not to be accessible from web should be placed outside of the web root.
For javascript files you may minify your files, but it doesn't increase performance much unless you have huge 5mbyte+ files. And if you do have huge javascript files, you should consider reducing it as huge js-files is quite often considered bloatware.
Loading excessively amount of css/js-files should be avoided.

Images

Icons and similar should always be in SVG format. All others should be AVIF. Don't try to compress image resolution too much. Most monitors and phones today have 4-5k resolution and your web site will look bad with low resolution images when people zoom in on images.
If you have older jpg-files and the web browser support .avif, WebCDN will check if the file .jpg.avif exists and use that instead of .jpg.
You may also want to consider using <picture> with multiple image formats instead of <img>.


Third party content

Using third party CDNs to host your content, like javascript, images or video, will slow down your web site and decrease your uptime. Static files never cause performance issues.
If you have user based static content of more than 30 TB, or you require active-active redundancy, use seperate storage servers. Otherwise, use local storage for user content. Always validate the session cookie before serving user content. Do not put user content on public static/permanent URLs (URLs with permanent token/password in them)
Make sure all content is hosted on your own site, including video files. For video files, use the <video> HTML tag instead of Youtube or similar. Do not install software or plugins telling you how to improve performance or speed up your site.
They are usually always wrong, makes your web site slower and can additionally cause issues related to security, stability and uptime.
Do not depend on third party content in your code in order to render your web page.


CSP Content-security-policy
Some CMS plugins attempt to load resources from third party sites. This is both unsecure, increases risk of code injection and hacking, may violate your DPA / GDPR / privacy policy and will slow down your web site.
WebCDN enforces 2 solutions to prevent malicious behaviour from such plugins

  1. WebCDN can enforce a no-third-party / content-security policy on web sites to prevent the web site from loading resources and communicating with foreign locations.
  2. WebCDN supports WAF Web Application Firewall which will also prevent script code running on the webserver from loading third party resources. The WAF operate a whitelist of hostnames.



Tracking / plugins

All advanced plugins designed to track the user will reduce the performance of your web site. Tracking is also blocked by default in most browsers.
WebCDN support server side aggregated statistics using JStats.



Database queries

The less queries a web page does, the faster a dynamic page will load.
If you are doing many db queries to render a single page you can save significant amount of loading time if you merge as many queries as possible into a single query. You can also use union all queries. Also make sure your page is using indexed queries.

Many CMS-systems are poorly designed for optimal database queries. WordPress is one of them, and you usually can't do much about this. It is therefore important that WebCDN can cache the page for you.

.htaccess

If you are still relying on this file, you need to stop. Htaccess will slow down any system because it needs to be parsed for every single request.
If you need a catch-all fall back page, this is already configured with WebCDN. The root /index.php will always be executed as fallback, and you can use the environment variable REDIRECT_STATUS to check if the user hit a 404/non-existant page.


Git

Don't put the .git folder inside your web root. Use a seperate folder
Don't pull from git directly to your web project. It will most likely break your site and possible cause security issues.


JSON and javascript

Solutions doing page-in-page loading of data will reduce performance and give you lower SEO score. Try to render the entire web page in one go (excluding static resources). Try not to use client side javascript to generate initial HTML output.


Compression

If the content is dynamic / cannot be cached, enabling gzip compression directly in your script for text/* content types and body size over 100bytes is almost always a good idea.
For content that can be cached, It is usually best to let the webserver do the compression and not your script.


Relative URLs

Although not very important for fast page load, use relative URLs (/folder/picture.jpg) and not absolute URLs (https://example.com/folder/picture.jpg) when creating HTML content.
Using absolute URLs quickly becomes a total mess when dealing with multiple subdomains.