Is your website or blog slow? Optimize-it!

The majority of websites are slow. The majority of blogs are not optimized and performant

Everybody has heard or read this once or has made this observation.
Each content editor, blogger, photographer find one day or another that his/her website is not fast enough without knowing how to begin to solve the issue.

Sometimes without being aware that there is an issue.

You feel that your site is slow: it’s the case most of the time. Explanations

This article will try to help you identify those performance issues. I’ll try to present helpful tools to spot the problems.

Before entering in details, a small introduction.

In this article, I’ll mainly focus on and detail performance and constraints from a “Front-end” perspective. Topics linked with resources and rendering in web browsers.
This part is standardized (by the W3C), best practices are widely shared and implemented by the software editors.

The “Back-end” part can create performance issues as well. Those problems are directly linked with a specific technology, an application server, sometimes to a version of this application server.
They appear upstream in the chan and must be handled by dedicated (most of the time customized) strategies.
I cannot and will not enter here in detail in those stories of “blood and pain” depending directly on specific products and frameworks.

I invite you also to read the previous article: How is built this photo blog? Tools, technologies, optimisations and best practices.
It presents how this photo website is built without any “out-of-the-box” content management system (WordPress, Drupal, Joomla) or platform (500px, Wix, SlickPic, Duda).

The goal is to reduce the number of technical layers and by the same way reduce the potential sources of performance issues.
In my case and for Lanuit.Paris, avoid useless maintenance of a n-tier backend architecture (application server, database, dedicated customized hosting).

Loading an internet page is the result of a chain

When you type an address in your browser:

• you give an order to contact a host on the network (a server linked to an IP address and a port)
• it will take it a delay to provide a response (network latency and the time for the server to process your request)
• you’ll receive a first message (source code) with the main content of the page (HTML and potentially Javascript)
• this content can itself have references with other resources (CSS, more Javascript, images, fonts, videos). Your browser will need to download those as well.
• Depending on the bandwidth of your Internet Service Provider and the weight of the requested resources, those actions can take more or less time
• The browser does not show resources on-going or in the order it receives them.
• The browser has to follow its own logic of interpretation and execution: some resources can block or delay the rendering of the page. This behavior can happen with some code libraries as well.

Maybe you were not aware of that but the apparent slowness of your site can be due to several sources and the layers can pile up.
The fix to provide is maybe not linked with only one place.

I’ll take the opportunity to debunk urban legends:
No, very often, a stronger server is useless, especially when dealing with content websites.

For the bravest readers, I invite you to read this complete, and technically deeply detailed document on how a web rendering engine (a browser) does work:
Link: Critical Rendering Path

Hopefully, it’s not mandatory to know all this in details to be able to optimize your website.
However, reading this documentation reminds us of some web fundamentals.

Name the obvious and fix it in priority

The most direct and easy practices do apply to the management of resources (number, size, usefulness):

• Adapt the size of images to the target (computer, tablet, smartphone)
• Don’t embed and load useless features (non-mandatory for all the pages for example)
• Put stylesheets to diet
• Use a minimal set of fonts
• Select carefully external libraries. Parsimony is key.
• Activate resource compression

The frugality is a major component. In my opinion, it’s at the center.
This is why the majority of Content Management Systems(WordPress, Drupal, Joomla) have bad results in benchmarks. They use the abundance of features as a major argument. They push to use massively plugins and modules and neglect the rendering part.
The rule if it can do more, it can do less is the enemy in our case.

How can you measure the performance of your website?

Online and embedded tools (in browsers on computers) do exist. They can help you to test and validate key points.

YSlow! is an old tool developped by Yahoo!. It seems to continue working.

The standard today is LightHouse or its equivalent online Google PageSpeed.

Is it mandatory to use Google tools?

Three main browser editors do exist on the market:

• Google does provide the technology of the rendering engine “Blink”. It’s used by the open-source Chromium project, Google Chrome, and now in Microsoft Edge.
• Mozilla provided the “Gecko” technology used by Firefox
• Apple provides the “WebKit” technology used in Safari browsers

Chrome owns more than 65% of the market, followed by Safari, the other share the remaining percents.
Source: StatCounter Usage Navigateurs

However, Google does not decide on its own regarding features and improvements to apply to web rendering engines.

The World Wide Web Consortium (W3C) drives, among other things, standards, innovations and future improvements to implement in web browsers.

A practical example of using Google PageSpeed on Lanuit.Paris: the “preload” case”

I use systematically PageSpeed/LightHouse during the developments and after every new release of this website.

On the “home page” I used the feature “preload” linked with optimization of loading CSS (Cascaded style sheets).
This improvement is part of a recommendation coming from W3C.

Editors (Google, Mozilla, Apple) usually follow those recommendations. Depending on their respective roadmaps, their releases are not necessarily synchronized. The feature is not mandatorily available everywhere at the same time.
Some of the new features can also lack (totally or partially) of retro compatibility.

This can result in a targeted degradation of the user experience while all the browsers are not up-to-date.

The adoption of new features on one’s internet website cannot be automatic. Decisions need to be made.

• Handle two modes (old and new). Maintain two versions and increase the level of complexity in the code (to go through the temporary period). In this case, add more javascript, test user-agent, inject the behavior in a conditional way
• Wait so the feature is available on all the browsers. Meaning delay potential leverage to improve user experience.

Hopefully, we can make those decisions with the help of “CanIuse.com”.
This tool shows in detail the history of versions (past and future) and features that are embedded or programmed to be embedded in browsers.

For the “preload”, all browsers except Firefox, do implement this feature.
Firefox should activate it soon.

4% of the whole potential traffic is managed by Firefox. I decided to deliver this feature despite the situation and improve the user experience for the majority of visitors.

This technical improvement, helped me to be under the one-second threshold on the indicator “First Contentful Paint”.
It does mean that the first elements are shown on the page within one second.
This improvement is available for the three versions (computer, tablet, smartphone).

Improve performances: both for your visitors but also for the planet

Generate lighter resources on the server, avoid sending heavy and useless files through the networks. Saving useless KiloBytes.
As much as possible, if you can manage it, don’t let the browsers, download, read or execute non-mandatory code.
All those efforts to ease the chain of actions can help to reduce storage needs and energy spent.
Doing it at one’s scale and on a wider scale seems a good idea.

Is LaNuit.Paris an optimized and performant website?

In the next article, I’ll try detail the different steps I applied to improve performances on this website.
Being able to confirm that this website is faster and more performant than the majority of content websites online today.
How I could build an easy, user-friendly, responsive interface following best practices and performance indicators.
Without losing the focus on my main goals and without making any concession on the quality for the photographs I publish.

Don’t hesitate to contact me if you have any questions about this article or project. You can simply send an email to photo@lanuit.paris