Tag: Optimization

  • CSS optimization

    CSS resources are render-blocking. Here are the steps for optimizing your CSS:

    • Consider using not so deep CSS rules (e.g. this is deep rule: “.mydiv .second-layer > p > span.too-deep”),
    • If CSS is one-time-only and you’re sure you’ll not need it again on other pages you can inline it.
    • Minify files (removes all white-spaces and comments).
    • You can move all CSS styles with media queries from render-blocking CSS (e.g. style.css) into non-render-blocking CSS file (e.g. mobile.css) with setting media attribute to link tag:
    <link rel="stylesheet" href="style.css">
<link rel="stylesheet" href="mobile.css" media="(max-width: 768px)">
<link rel="stylesheet" href="print.css" media="print">
    • Compress the CSS files,
    • Cache those files on the server side.

  • JavaScript Optimization

    JavaScript resources are parser-blocking so consider doing this to speed-up your JavaScript on your website:

    • If the script does not affect the DOM tree (does not add or modifies HTML) and is not affecting stylesheets then you can put it inside external file, call it inside <head> element and add an “async” attribute
    <head>
  ...
  <script src="analytics.js" async></script>
  ...
</head>
    • defer Javascript execution (The script tag can also take a defer attribute, in the same way that it can take an async attribute. The difference is that with defer, the script waits to execute until after the document has been parsed, whereas async lets the script run in the background while the document is being parsed.)
    • Minify, compress and Cache JS.

  • WordPress optimization

    For page to be downloaded and processed faster we need to:

    • Minimize bytes (smaller code takes less time to dowload),
    • Reduce critical resources (minimize use of render-blocking CSS and parser-blocking JS files)
    • Shorten CRP (Critical Rendering Path) length.

    Page rendering path: https://developers.google.com/web/fundamentals/performance/critical-rendering-path

    • Begin DOM construction by parsing HTML,
    • Request CSS+JS resources,
    • Parse CSS and construct CSSOM
    • Execute JS (these are render-blocking JS files)
    • Merge DOM + CSSOM into the Render Tree,
    • Run layout on the render tree to compute geometry of each node and
    • Paint the individual nodes to the screen

    Place Any Non-CSSOM Querying JavaScript Before CSS; Place Any CSSOM-Querying JavaScript After CSS!!!

    All non-essential scripts that are not critical to constructing the visible content for the initial render should be deferred.

    WHY SO? If the files do not depend on one another, then you should place your blocking scripts above your blocking styles—there’s no point delaying the JavaScript execution with CSS upon which the JavaScript doesn’t actually depend.

    Broadly speaking, this is why CSS is so key to performance:

    1. A browser can’t render a page until it has built the Render Tree;
    2. the Render Tree is the combined result of the DOM and the CSSOM;
    3. the DOM is HTML plus any blocking JavaScript that needs to act upon it;
    4. the CSSOM is all CSS rules applied against the DOM;
    5. it’s easy to make JavaScript non-blocking with async and defer attributes;
    6. making CSS asynchronous is much more difficult;
    7. so a good rule of thumb to remember is that your page will only render as quickly as your slowest stylesheet.

    HTTP/2 has made obsolete:

    • Domain sharding
    • concatenation
    • image sprinting

    RESOURCES:

    • https://web.dev/fast/#prioritize-resources
    • https://developers.google.com/web/fundamentals/performance/critical-rendering-path
    • https://csswizardry.com/2018/11/css-and-network-performance/

    While open Google DevConsole click CTRL+SHIFT+P and search for:

    • Coverage (to see what portion of external resources is actually used and to see which part)
    • Lighthouse (to generate report on performance).

    Further optimize Bootstrap4 resources (remove CSS and JS which is not needed)

    Use imagemin webp package to convert all images to webp format. https://web.dev/serve-images-webp/

    for file in images/*; do cwebp "$file" -o "${file%.*}.webp"; done

    Use critical tool to detect the critical assets which should be preloaded.  https://github.com/addyosmani/critical/blob/master/README.md

    Use https://gtmetrix.com/ plugin to test web page speed.

    Create our plugin which would work as: https://perfmatters.io/features/

  • Web server optimization

    Weather your web server is apache or nginx you should:

    • disable image hotlinking: when other websites serve images directly from their website by using the URLs from your website, instead of uploading them to their own servers. In effect, they’re stealing your web hosting bandwidth, and you don’t get any traffic to show for it.
    • Use the latest PHP version (the fastest)
    • Limit post revisions:
      define(‘WP_POST_REVISIONS’, 4 );
    • Use DNS level website firewalls (block malicious requests even before they reach your website, blocks brute-force attacks, hacking attempts and malware) like Sucuri and Cloudflare.
    • Add page caching,
    • Minify & compress (gzip) your HTML, CSS and JS files
    • Use Object cache (cache database query results) Redis.
    • Use Page cache (no PHP or MySQL requests at all, static page served from the Page cache)
    • Compress your images.
    • Fix Crontab to use the UNIX system time events, not on the user hitting the server.
    • Best Tech stack to use
      • Nginx over Apache (Nginx can use PHP’s FastCGI process manager called PHP-FPM)
      • Varnish over FastCGI (Varnish is more flexible, but FastCGI Cache is easier to configure, uses less resources and performs better. Also FastCGI cache i easier to maintain because it comes included with Nginx)
      • Memcached vs Redis (Redis is a newer, more modern in-memory data store than Memcached. It has more features and seems to be a more popular choice in the WordPress community)
      • MariaDB over MySQL (MariaDB is faster and fully open-source)
    • Constant Application (Server) Monitoring (New Relic)(constantly pinging the server and making sure that it’s always up and running. Monitoring high resource usage (CPU or SQL). If Nginx or PHP appear at the top of the list for CPU usage we should check our access and error logs, if it’s MySQL then we need to enable the slow query log.
    • Ongoing Maintenance (keeping WordPress core and plugins up to date) Checking for newly discovered vulnerabilities and making sure the website can’t be attacked.