As I am writing several articles about Optimizing websites for Google Pagespeed, rather than repeat this section in each article, I am including it here as a standalone article.
The Google Website page is https://developers.google.com/speed/pagespeed/insights/ and there are reference links from that page for more information.
Leverage Browser Caching – This is allowing static files to be stored on your local browser so that for subsequent pageloads, the cached files will be used. This is quite easy to do by adding a few lines to your .htaccess
Enable Compression – This is the method of using a compressor (typically gzip) to compress files so that they are the smallest possible while they are being transferred, then decompressing them before being rendered. Although most images etc. are already compressed and therefore do not recompress much more, scripts such as css, javascript and html are very compressible, even if they have been minified. Again, .htaccess changes can switch compression on.
Optimize images – As stated above, all modern images are already stored in a compressed format, however there are often many unnecessary segments of information left in the image files (such as camera settings and information) and the default compression algorithms of most major software packages are not optimal and further compression can be made. Also thumbnails that are dynamically generated by php are optimized for speed of generation rather than smallest possible size. Gzip and similar compression is not efficient with already compressed images, so a re-processing of images using specialized software is the best way to have all images optimized. This is rarely done on-the-fly as its a time-consuming process, so it is often performed by some triggering mechanism when an image is uploaded or changed, or periodically in a batch-optimize process.
Server Response Time – The time for your server to serve the main html document page, this excludes images and resources such as Javascript libraries, CSS and Fonts
Prioritize Visible Content – Best to concentrate on items that are going to be rendered visible on the current device on the initial page load. Other resources that would only be visible on a mobile version of the site (if viewing on a desktop) or vice versa, plus content under tabs that are not selected by default etc. should be treated as low priority and rendered after the priority content.
Minify CSS – Pretty CSS has lots of spaces, indents etc. These all add precious bytes and are only necessary for readability in case the CSS needs to be edited. In case of standard libraries, minified versions are usually served (often with a .min.css extention). Although the byte saving is somewhat negated when compression is used, it is still good practice to used minified versions of css libraries when available for optimal results.
Minify Javascript – Again, spacing, indentation, carriage returns etc. all go to make code more readable but can usually be stripped and optimized to reduce the number of bytes to be transferred. Again, this is somewhat negated by having file compression but when minified libraries are available, you may as well use them
Minify HTML – Contentiously, as html is typically dynamically produced, the overhead of minifying the html. code with so many quirks on different browsers etc. is rarely worth the effort. Fortunately, having compression enabled negates the need for this and google seems to tolerate un-minified html as long as compression is enabled.
Eliminate Render-Blocking Javascript and CSS in the above-fold content – Much Javascript and CSS is purely aesthetic and can be left until the main body has been displayed before being loaded. Good examples of these are fonts, layouts, animations etc. Even though the page may be momentarily rendered slightly differently until a resource is fully loaded (such as a font), google feels it is most important to get the first 600 pixels (what is called above-fold-content) rendered even in a basic form before fine tuning and completing the full page render with all bells and whistles. This helps low-bandwidth and particularly mobile users not waste time and bandwidth fully loading a page before being able to see it. they can cancel or go back quickly this way. So pages that are dependent on libraries to render the above-fold-content (such as Jquery) must have these libraries fully loaded before this section can be rendered. The best way to achieve this is to either inline the important code or have it load asynchronously, (not waiting for the current page to finish loading before loading it in parallel). The rest of the libraries can be left until the main body has finished before being loaded, perhaps at the bottom by the </body> tag. Alternatively, there are scripts available that load these resources on once the main body of the page has finished loading.
Avoid landing page redirects – If you have a redirection from an old site to your new one, or to force www. on your url, or force https for example, these redirections take precious time iterating through the Apache page serving protocol and is called a redirect. These are very useful in many circumstances like those listed, but it is important to rectify the source of these incorrect urls and change them to the full corrected ones. So if you have a Sitemap generating urls without the www. and you have a redirect to force the www. to be added, you need to change this to generate the full urls including the www. as a priority.
Please refer to my individual articles for how I approach optimizing these aspects for various platforms.