110 pro tips to improve your site's performance

In early April 2022, I noticed that on LinkedIn, many posts about web performance were spreading misconceptions, hearsay, and "magic" methods for having a fast website. Annoyed and saddened by the number of likes, shares, and comments on these posts, I decided to share some of my knowledge and experience on LinkedIn in turn.

Below, I have reorganized and listed the concrete, verifiable, and proven information that I shared there over the weeks, grouped by major themes. It may sometimes seem technical, but the concise format of each point allows you to understand what needs to be done concretely to improve a website's performance. I hope you enjoy this compilation and wish you an excellent read.

Browser rendering

• For a site to load quickly (LCP metric typically), the HTML must be loaded as early as possible (after being rendered server-side), followed by CSS (synchronously if less than 50 KB), fonts, images, and then JavaScript (in async or defer). JS therefore comes LAST!
• The heavier the structure of a page, the less performant it will be: browser rendering times increase. This is materialized by the DOM, which should be as light as possible (less than 1500 nodes) and with a minimum number of nesting levels (less than 32). This is a point where most WordPress Page Builders fall short.
• Preloading resources like fonts or certain scripts (preload) is a good practice. But beware of side effects: overusing it can have the opposite effect, sometimes with a major impact. It is often better to let browsers manage priorities, which they are doing better and better.
• The new HTML attribute fetchpriority allows you to change the download priority of resources. It can be useful for modifying the browser's default behavior, by de-prioritizing third-party scripts or re-prioritizing an image that constitutes the LCP, for example.
• Want to speed up the download of resources hosted on a third-party server? Prefer the "preconnect" resource hint over "dns-prefetch": the latter will perform not only DNS resolution but also the initial connection and SSL negotiation.
• Are you using Resource Hints of type dns-prefetch or preconnect? Be sure to limit their number and prioritize them (the most important ones first). As these tools offer no guarantee of execution, it often happens that the last ones are simply ignored.
• Browsers can now instantly display a page when navigating via their Back and Forward buttons. Verify that your site does not block the use of this "Back/Forward cache" feature, which ensures top Core Web Vitals (DevTools > Application > Enhanced Features).
• If your site is "Responsive," the switching mechanism must rely entirely on CSS Media Queries and defined breakpoints. JavaScript should never be used, let alone User Agent detection, to adapt the rendering to different devices.
• If your pages include animations, especially on user interaction (hover, click, etc.), implementing CSS containment can help improve their fluidity. Containment reduces unnecessary repaints and reflows, resulting in better interactivity (INP metric).
• If your pages include embeds (YouTube, TikTok, Instagram, etc.), make sure to implement native lazy-loading on their <iframe> via the loading="lazy" attribute. This will significantly improve performance, as these third-party tools execute a substantial amount of JavaScript, among other things.
• Never animate the main elements of the initial viewport, such as titles or hero images. Beyond the additional CPU load due to rendering, a delayed appearance effect artificially delays visual performance-oriented metrics (LCP and Speed Index).

Core Web Vitals

• Page Speed Insights IS NOT what Google considers! It is a testing tool (so-called synthetic) whose mobile section is heavily biased. Some third-party tools (GTmetrix, Webpagetest, etc.) offer a more accurate overview of real mobile performance.
• What Google considers are the data from REAL visitors, particularly under Google Chrome. It is this data that is found in Search Console (CrUX) and that it uses in its algorithm (Page Experience section).
• The Core Web Vitals section of Google Search Console is ideal for understanding performance issues affecting a site. It shows which sets of pages are experiencing LCP, CLS, and FID problems on desktop and mobile. It's practical for starting a performance optimization project.
• Time To First Byte (TTFB) is useful for identifying server response time and/or caching issues. It is an essential and indispensable performance indicator as it mechanically impacts FCP, LCP, and Speed Index.
• The new INP metric introduced by Google aims to ensure that a page is fluid throughout its use. It reflects Google's desire to better estimate the quality of the user experience throughout their navigation, and not just during loading.
• The "load time" provided by Google Analytics is not a relevant performance indicator: it is neither reliable, nor exhaustive, nor representative of the actual user experience. For web performance management, favor metrics like Core Web Vitals from CrUX.
• If you have to choose a single KPI for web performance, LCP (Largest Contentful Paint) is the most relevant. It is indeed easily obtained for real users (CrUX field data) and via synthetic tools, while fairly reflecting the overall page loading experience.
• Official metrics don't meet the specific needs of a site? Use the Performance Element Timing API: it allows you to define your own performance indicators with a simple HTML attribute elementtiming="name", then retrieve them with a RUM tool.

Hosting / server

• Combining several CSS or JS files offers a significant weight saving: 2 files of 10 KB will weigh only 17 KB if grouped together. This is linked to compression mechanisms (Gzip and even more so Brotli), which are very effective with these repetitive code languages.
• Minifying HTML code does not provide significant performance gains, mainly due to Gzip and Brotli compression. The duration of the operation can even be longer than the download time savings, negatively impacting TTFB and LCP metrics.
• If a site is optimized with a cache system + minification / combination / defer (e.g., WordPress + WP Rocket), a CDN like Cloudflare will not add much and may even generate page latency if the server is located in the target country.
• Deploying a CDN improves the overall performance of international sites. However, favor a global CDN, in proxy mode, rather than a CDN that only targets images and/or static resources. This effectively reduces the impact and can even have negative effects on FCP and LCP.
• Any Apache, Nginx, or other server must serve resources over HTTP/2. The protocol offers considerable room for improvement compared to HTTP/1.1 in terms of web performance (especially for simultaneous downloads). Yet, many sites still operate with the old HTTP/1.1 protocol.
• If your host or CDN offers HTTP3 activation, enable it! Compared to HTTP/2, the protocol allows for a significant improvement in server response times (TTFB), thanks in particular to request multiplexing and better HTTP header compression.
• Always define a Content-Security-Policy header. This approach not only improves security for your visitors but also allows you to take stock of the resources used by a site. Knowing what is loaded in JS, CSS, images, or fonts is essential for performance!
• Enable the latest version of TLS on your server (currently 1.3). The secure communication protocol is regularly updated to ensure faster exchanges between the browser and the server. This helps improve FCP, LCP, and Speed Index.
• Static resources (images, webfonts, JavaScript, CSS, etc.) should be served with a header defining a browser cache policy. The best practice is to set an expiration time of one year (31,536,000 seconds) to avoid unnecessary re-downloads.
• Systematically test your site with the latest version of PHP. If it works correctly (no 500 errors), keep it: each new evolution of the server language offers performance gains, which helps reduce response times (TTFB metric).
• Are your pages taking a long time to load without a cache system enabled (high TTFB)? This means your server is undersized for your needs (processor and RAM). Switch to more powerful hosting or reduce the volume / optimize the quality of your code.
• Enabling OCSP Stapling on a server improves TTFB on the first connection for some users. The browser no longer needs to verify the validity of the TLS certificate served by the issuing authority, eliminating costly network round trips.
• Avoid multiplying 301 redirects in your .htaccess file: this slows down Apache and therefore increases server response times (TTFB). If their number exceeds 500, prefer using a PHP script or a specialized extension if one exists for your CMS.
• Does your host or CDN allow the use of "103 Early Hints"? Enable the feature: when configured correctly, it allows critical resources (CSS, webfonts) to start downloading before the pages themselves. Gains in FCP and LCP can be significant.
• Text-encoded resources (CSS, JavaScript, HTML, etc.) should be compressed using Gzip or, even better, Brotli. This considerably reduces their size, with a major impact on loading time-related metrics like FCP, LCP, and Speed Index.
• If you use a CMS like WordPress or PrestaShop and your host offers an object caching technology like Redis, Memcached, or APCu, enable it. Object caching reduces the volume of SQL queries, significantly improving TTFB for dynamic pages.
• Always prioritize server-side security solutions. A Web Application Firewall (WAF) or malware scanner will always be significantly more performant when managed on the hosting side than through a PHP extension or script. The impact on TTFB can be significant.
• Does your CMS or page builder offer to display a selection of content (articles, products, etc.) randomly? Never opt for such a feature: it results in inefficient SQL queries that negatively impact response times (TTFB).
• Ensure that the DNS configuration of your subdomains, including www, does not use CNAME records. Instead of pointing directly to your server's IP address (A or AAAA records), this impacts response times (TTFB metric) by about 30%.
• If your web hosting has an IPv6 address, add the appropriate DNS records (AAAA records) for your root domain (key @) and its subdomains, including www. The gains in response time (TTFB metric) can be significant.

CSS (styles)

• The larger the CSS volume, the worse the performance. The penalty is twofold: a larger file takes longer to download, and its execution time by the browser's rendering engine is extended. This impacts FCP and LCP.
• CSS offers several very useful properties from a web performance perspective. This is the case for aspect-ratio, which can be used as a last resort to reduce CLS. Also, content-visibility, when set to auto and combined with contain-intrinsic-size, reduces rendering times. And contain: content, which reduces the risk of repaint/reflow.
• Any ad space whose content is loaded via JavaScript (like Google Ads or Taboola) must have a minimum height defined in CSS. Without this "space reservation," it will generate Layout Shifts during its loading. This is very often the primary cause of CLS on editorial/publisher sites.
• If your site uses animations, especially looping ones, ensure they are based on the CSS transform and opacity properties. These are the only ones that allow you to take advantage of the highest level of graphical performance available in modern browsers.
• NEVER embed images, let alone webfonts, encoded in base64 within your CSS files. This contributes to exploding file sizes, which heavily penalizes FCP and LCP. CSS files should only contain CSS.
• The mobile-first approach should always be preferred when targeting a device type via CSS. With this in mind, favor Media Queries based on min-width rather than max-width: the default behavior is the small screen, which is then enhanced for tablets and computers.
• The popular hack for asynchronously downloading stylesheets (preconnect with onload event) can have negative effects on performance. It can generate Layout Shifts as well as repaints and reflows that increase page rendering time.
• Avoid changing the order of vertical elements using CSS Flexbox's "flex-direction" and "order" properties: this can generate Layout Shifts (CLS metric) and Blocking Time (TBT metric). For optimal rendering, prefer changing the order directly in the HTML code.
• Limit the use of CSS declarations that include the universal selector (*): browsers must evaluate them for every DOM element. This generates high CPU resource consumption, which lengthens rendering times and can impact INP during interactions.
• CSS functional pseudo-classes like :is(), :has(), :where(), and :not() offer great flexibility in DOM targeting. However, this comes at the cost of increased CPU consumption, with a potential impact on Blocking Time and the INP metric. Therefore, limit their use.
• Do you use CSS preprocessors to create your stylesheets? Limit nesting levels: this generates very specific CSS selectors that weigh down resources and slow down browser rendering engines. This particularly impacts TTI and LCP.
• With rare exceptions like font-smooth, text-stroke, or box-reflect, vendor prefixes targeting webkit (-webkit), Firefox (-moz), Opera (-o), and IE/Edge (-ms) browsers are unnecessary. Using them unnecessarily increases the weight of stylesheets and the CSSOM generation times.

Is your site as fast as your visitors expect?

Discover how we can help you

JavaScript

• The larger the JavaScript volume, the worse the performance. Third-party scripts like Google Analytics, Google Ads, or Recaptcha notably consume a lot of processor time to execute, which generates latency and stuttering in the browser (TBT and FID in terms of metrics).
• Some tools like WP Rocket allow delaying JavaScript execution until the first interaction (click, scroll, or hover). Do not use it on your theme's scripts, or you risk making your mobile menu dysfunctional, or even generating CLS on poorly coded themes.
• Need to highlight reassurance elements like your Trustpilot or Avis Vérifiés customer rating? Do not use the widgets provided by your partners, as they are not optimized. A simple image with a link will have the same effect and considerably improve loading times.
• GDPR CMPs / cookie managers offer a significant performance gain for new users and synthetic testing tools like Page Speed Insights. Third-party scripts are indeed only loaded later, after the user has consented.
• Never modify the initial style of a page via JavaScript or jQuery. Any visual modification should be done directly in CSS and not by dynamically adding classes or styles. This practice leads to resource-intensive CPU repaint and reflow operations and can generate CLS.
• The asynchronous loading tags provided by most third-party tools, including Google Tag Manager, have a major impact on performance. Prefer a native call via a <script> tag with a defer attribute rather than async: this is the only solution to avoid blocking page rendering.
• A/B testing tools like Kameleoon and AB Tasty should be used very occasionally and disabled at the end of each test campaign. Their impact is indeed major in terms of Blocking Time, which contributes to increasing FID and LCP metrics.
• A third-party script only executes on button hover? Implementing a "facade" can reduce its impact on page loading (TBT, FID...) by conditioning its loading to hovering over that area. VOC tools like Zendesk are particularly well-suited for this.
• Need to display social sharing buttons? Do not use third-party tools like AddThis or ShareThis, which load tens of kilobytes of JavaScript resources and generate Blocking Time. Prefer self-hosted tools with minimal JavaScript and CSS.
• If your site offers an interactive feature requiring significant user-side calculations, use a Service Worker or Web Worker. These browser APIs can execute JavaScript with their own CPU resources, significantly reducing TBT, FID, and INP metrics.
• Need to secure a registration, contact, or newsletter subscription form? Avoid JavaScript-based Captchas at all costs, especially Google ReCaptcha. Prefer a Honeypot (robot trap) or server-side verification after submission.

Images

• All images called via an HTML <img> tag must systematically be associated with width and height attributes. This allows the browser to know their display ratio before downloading them, eliminating any risk of Layout Shift when pages load.
• Be sure to integrate images into your content whose intrinsic dimensions are close to the dimensions displayed on the screen. In WordPress, as with other CMSs, page builders allow you to choose an image size, for both mobile and desktop.
• Use the right image formats: PNG or SVG for logos, icons, and pictograms, JPG for photos. Don't bother generating WEBP or AVIF images yourself, which must always be offered with a fallback in PNG or JPG: use a tool like an extension or CDN (like Cloudflare).
• If you use a lazy-loading mechanism, do not apply it to images visible in the viewport. This particularly concerns the header logo, but also sometimes the featured images on article pages. Disabling lazy-loading on these elements can significantly reduce LCP.
• Whenever possible, prefer native lazy-loading (HTML attribute loading="lazy") over JavaScript-based solutions (Lazysizes, Lozad…). This will be more performant, especially in terms of interactivity where TBT and INP suffer from script execution on the main thread.
• If your site only displays a few icons, do not use the Font-Awesome icon font which contains over 700 characters. Prefer using inline SVG images, which also provide vector rendering but with a much lower weight. Or, failing that, a custom icon font created with Icomoon.
• Image rendering can block the rendering of other elements, impacting display time and fluidity. To avoid this, images called via an HTML <img> tag must all have the decoding="async" attribute. They will then be displayed once decoded independently of the rest of the page.
• The use of SVG is optimal for logos and pictograms. Be careful, however: the file must be based on paths to be vector, and must never include PNG or JPEG images encoded in base64. Such use is completely counterproductive.
• If a photo-type image needs to be displayed with transparent areas, do not turn to the PNG format. Prefer classic JPEG associated with CSS styling like border-radius or an SVG mask. This will always be significantly lighter.
• Are you using SVG vector images for your icons, logos, or illustrations? Excellent, but make sure to optimize their paths before putting them online. Most files downloadable online or provided by graphic designers include unnecessary elements that make them heavier.

Videos

• NEVER load YouTube videos with your pages, especially not in auto-play (bad UX practice) because the iframe calls a lot of JavaScript but also CSS and a font. Defer its loading with native lazy-loading (loading attribute) or a facade library like LazyTube.
• Never offer MP4 videos by default: prefer Webm, which supports more modern codecs and is therefore lighter. The MP4 format should, however, always be offered as a fallback using a <video> tag associated with the appropriate sources.
• Your site embeds videos hosted on your own server? Always provide a preview image using the "poster" attribute of the "video" tag. Not only does it display on mobile by default, but this image will constitute the LCP element if the video is in the initial viewport.

Fonts

• Watch out for fonts! If possible, use one font family, possibly two but no more. Limit the number of variations: one Regular (400) and Bold (700) version are often sufficient. Many themes and Page Builders load all variations of styles and weights, thus slowing down performance.
• Fonts should always be loaded locally. Google Fonts and Adobe Typekit are convenient, but they are performance drains. The negative effect is twofold: longer download times due to network latency and the inability to pre-load fonts.
• Not all fonts are equal in terms of web performance: depending on the complexity of their glyphs, files weigh more or less (for equivalent subsets). Prefer lightweight webfonts like Poppins, Jost, Albert Sans, or Oswald, all around 10 KB in Woff2 format.
• If you use a font available in "Variable Font" format, prefer it over classic individual weight variations. There will only be one Woff2 file to download and pre-load, and you will have access to more weights.
• If you self-host variable font files, congratulations. However, make sure they only include what's necessary: they often contain unused "axes": weights (Regular, Bold...), slant (more or less italic), or width (more or less condensed). Their weight will decrease.
• Locally hosted text fonts must be pre-loaded using a "link rel=\"preload\"" tag to ensure faster text rendering and reduce CLS. Be careful, though: only the woff2 version should be pre-loaded, with one file per weight variation.
• Font files should never include unused subsets: this unnecessarily increases their weight, with a major impact on LCP. For sites in French and/or English, the "Basic Latin" and "Latin-1 Supplement" subsets are generally sufficient to display all texts.
• When declaring a font stack using the CSS "font-family" property, only the first font should be custom: the following ones should be system fonts. Declaring multiple custom fonts can lead to downloading multiple unused files, causing LCP and Speed Index to drop.
• Many third-party tools and extensions displayed in the front-end (CMP, VOC, marketing pop-ups, etc.) use their own font sets. Whenever possible, modify their behavior so that they inherit the default font of your pages (value "inherit").

UX/UI

• Limit the number of animations: they are generally as costly for performance as they are disruptive in terms of UX. If you must include them, they should ideally rely on CSS transform and opacity properties. Avoid JavaScript frameworks like animate.js, Lottie, etc.
• Full-page loaders like "spinner" or "loading bar" are strongly discouraged. They penalize the User Experience by hiding all content for several seconds. This results, in terms of metrics, in a significant increase in LCP and Speed Index.
• Limit the use of sliders and other carousels. They make some content invisible to visitors while imposing a less natural navigation interface than scrolling. They also often rely on large amounts of JavaScript, significantly increasing TBT and INP (more info).
• If you use sliders, carousels, or horizontally scrolling areas, make sure to include content of the same height. Many extensions adapt the height of the area to its visible content, causing the entire page to experience constant Layout Shifts.
• Do not modify the native scrolling behavior of browsers with JavaScript. This is justified for "fullpage" type sites that function like slideshows, but it is unnecessarily costly for the browser and disruptive to the User Experience in any other context.
• Do you want to display sensitive data (phone number, email address, etc.) while preventing it from being read by unscrupulous bots? Instead of using images, favor JavaScript with base64 encoding. This way, the text will remain selectable and clickable by (real) visitors.
• Is text "too long" to display on your mobile site? Never hide it via CSS (using text-overflow: ellipsis, for example). In a mobile-first approach, all text must be readable regardless of the resolution of the viewing device.
• If a page template has a limited width, never use options to extend areas horizontally outside of it via JavaScript: this is very costly in CPU resources and generates Layout Shifts. Prefer native full-width templates.
• If your site offers push notifications, never activate a subscription invitation pop-up on first load: this behavior is intrusive in terms of User Experience and generates Blocking Time. Prefer a button within the pages, ideally after the content.
• It is not recommended to provide a specific mobile version of your site, including AMP. Native browser APIs and tools integrate what is necessary to ensure optimal mobile performance. Simplify your stack with a single "Responsive" site based on CSS Media Queries.

SEO

• The impact of web performance on rankings in Google search results pages is unknown: no study proves its effects on SEO. However, optimizing improves user experience, and therefore conversions.
• Contrary to popular belief, obfuscating links to optimize a site's crawl is simple to implement with about ten lines of JS. There is nothing complex about it, and it can have very beneficial effects for both SEO and good control of "crawl-budget".
• Google Search Console offers a detailed overview of how Googlebot crawls sites. This little-known feature is accessible via the Settings menu > Crawl Stats > Open Report. You can find the average response times and daily crawl volume, which helps understand indexing issues.
• Some tools in the Alphabet ecosystem, such as Google Discover, are particularly sensitive to the web performance of sites. To integrate the tool and remain visible there sustainably over time with publications, it is therefore essential to pass the Core Web Vitals at the site (origin) level.

WordPress

• On WordPress, post revisions and auto-drafts can quickly bloat the database size. It is important to regularly clean these elements to reduce the execution time of SQL queries. This improves TTFB.
• Gutenberg is good. WordPress's native editor has evolved enormously over the last 2 years and can now be used as an alternative to historical page builders. Combined with block libraries (GenerateBlocks, Ultimate Blocks...), it allows you to create any complex layout by generating minimal DOM and CSS.
• If you are not using the Gutenberg block editor as a Page Builder, disable its stylesheets on your site. This is not automatic and can unnecessarily increase the CSS volume, thus contributing to increased FCP and LCP.
• As a WordPress site evolves, the theme and plugins may change. However, when they are deactivated, they generally leave traces in the wp_options table. Manually deleting them reduces the size of this crucial SQL table, improving TTFB.
• By default, WordPress runs background tasks when pages are opened, which can lead to increased load and slowdowns. Prefer running server-side cron jobs every 2 to 5 minutes. This will improve the TTFB of dynamic pages.

Themes

• If you want a fast WordPress site, don't buy a large popular theme from Themeforest. The best approach is to start with something lightweight and adapt it to your needs through plugins. The opposite approach (disabling many features) often comes at a high cost in terms of loaded CSS and JS.
• Beware of certain "responsive" themes whose header actually relies on the presence of 2 distinct headers: one for mobile, the other for desktop. All header links, especially the main menu, are present twice, which bloats the DOM and is not optimal for SEO.
• When creating or redesigning a WordPress site, always use a child theme. This will allow you to integrate modifications, for web performance among other things, while continuing to benefit from base theme updates.

Plugins

• There is no magic plugin to improve WordPress performance. Even the excellent WP Rocket requires configuration and its options to be finely tested to maximize its impact on Core Web Vitals. The configuration differs for each site.
• On WordPress, caching plugins drastically improve FCP and LCP for visitors and bots. They also relieve the server in terms of processor and memory resources, which reduces response times for logged-in users.
• When a WordPress plugin requires a database update (WooCommerce, Yoast SEO, etc.), do it quickly. Otherwise, SQL queries will not be optimized, which can slow down loading times in the admin area and for uncached pages.
• When installing a WordPress plugin, always check the weight of the CSS and JS resources loaded on the public site. Plugins often represent more than 2/3 of the CSS volume, which contributes to increasing FCP and LCP.

Do you appreciate this sharing but need operational support to go further? Do not hesitate to contact Agence Web Performance, it's our job!