Six simple tricks for speeding up your website - Web stranice
Web optimization is a problem whose solution includes a lot of knowledge, starting with server’s port queue theory through code algorithm optimization. It also includes many tricks whose goal is efficient delivery of the content.
This short blogpost regards the last one – how to make your web app faster without advanced knowledge and a deeper understanding of the web architecture.
Code minification is a process of removing all insignificant signs and expressions inside the code, while maintaining its functionality. When minifying code, we don't optimize the code regarding the algorithms, but we do minimize the file size, which makes it more transferrable via the internet, i.e. the transfer is faster.
In Symfony, we can use YUI Compressor or UglifyJS/CSS. In Twig it is possible to use a spaceless tag for minimizing the HTML code, even though that is not recommended – it is better to use Gzip compression.
Some of the tools from this category can also compress the code and actually change it while maintaining its functionalities, of course.
There are different formats of graphic files for a reason. For photorealistic graphics we use JPEG format, while GIF, PNG and similar ones are more suitable for illustrations, depending on requirements.
By optimizing the color palette and reducing the photo or illustration quality, we lose an insignificant part of the details, but we can dramatically reduce the file size.
One should avoid image scaling in a web browser. Also, if you are sending a version of the content to your client, you should always pay attention to his device (responsive web design issues). There are several techniques that can be used to solve this problem and they are mostly related to CSS3 media query, for example the popular "Clown car" technique.
Do not use an empty src attribute of HTML <img> tag because most of web browser will send a new HTTP request as a response.
A slight digression: empty href attributes of HTML <a> tag are similar. Although they are valid, not all browser interpret them the same, which can lead to an unwanted behaviour of your website (web app). An alternative can be javascript:void(0) and # s onclick return false values. According to HTML5 standard, <a> element is valid even if it doesn't have a href attribute.
Keep the stylesheets in the header of the HTML document, and the JS at the bottom. Thanks to the first one, you achieve an impression of faster load of the website, and thanks to the second one, the website is actually loading faster because browsers block rendering while waiting JS to load.
Try to have one CSS file without @import command and definitely try to avoid inline CSS with an external CSS file because this can slow down the page rendering. Smaller CSS instructions are good to be kept in a <style> tag for those parts of the website that are visible in the browser right away (without scrolling).
There is also a possibility of asynchronous load of JS scripts: <script src="skripta.js" async></script>. With the keyword async, JS scripts are not executed after the load and browsers load other files in the same time. IE <=9 does not support this option.
Your own JS scripts and CSS styles are always good to be delivered as a single file. To have several stylesheets, particulary if they're your own, in the same HTML document is not a good solution. Is there anyone who doesn't know CSS sprites yet? Image maps are a similar technique. Each file connected to an HTML document is a round-trip from the client to the server. Stats say that 80-90% of end-user's time spent on waiting of website load is spent on loading of the files that are connected to the HTML document.
Try to deliver separate files with as few domain names as possible in order to reduce the DNS querries, as well as the waiting time in case the DNS record are cahced.
Remove the unnecessary URL redirects such as HTTP 301 and HTTP 302. Use Apache's Alias and mod_rewrite when possible. If you are redirecting to the "same" websites, but on a different domain, think about CNAME DNS domain records.
CDN is a network of distributed servers designed primarily for delivering web content depending on server's and client's geo-location. CDN can be a great solution for delivering your own or 3rd party content that is widely used on the web, but you should be careful. Depending on user's and system's requirements, you should evaluate if it is in fact a good solution for your problem (regarding the security requirements or your need to maintain the continuance of content delivery). Statistically speaking, by using CDN, there's a bigger chance that the end user will have cached content, which enables faster preview of the website which makes is it okay (statistically) to send a new request to the CDN domain.
It is also recommended to server your "static content" from so called cookieless domains in order to reduce the overhead and latency of HTTP request. However, a recent blog post on cookieless domains says a bit more on the fact that web optimization is a problem that doesn't have an unique solution.
You should set your web server in a way that HTML, TXT, CSS, JS and similar files are delivered using the popular Gzip or deflate compression – if the client supports it (HTTP header Accept-Encoding: gzip, deflate). This is relatively easy to set in .htaccess file:
<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>
Do not compress PDF and other compressed formats because you would spend CPU time for no reason and you might get a larger file in the end.
The average size of the Gzip compressed file is 50-70% of the original.
Cache all content that will not be altered in long term or will be altered or changed rarely – for example logo, favicon, CSS, JS. Cache instructions are kept in the HTTP response header (cache-control, last modified, pragma, …). You can define caching on server level or response level.
$date = new DateTime();
$date->modify('+600 seconds');
$response->setExpires($date);
<FilesMatch ".(html|css|js|gif|jpg|jpeg|png|ico|swf)$">
Header set Cache-Control "max-age=259200, proxy-revalidate"
</FilesMatch>
You can control cache in several ways: until a particular moment in the future (expires), by defining lifetime or by asking a simple question: Did it change? (etag). You can cache different types of HTML/CSS for different devices (vary) by which you also improve your SEO ranking.
HTML5 gives the application cache manifest which enables simple offline review of your website. Also, http-equiv Cache-Control is no longer supported in this standard. Furthermore, it is bad practice to define cache-control in HTML since some of the cache systems (proxy and gateway) will not interpret them.