Ever wondered how to optimize JavaScript loading on your web pages? The answer lies in understanding the different ways to include scripts using the }

As you can see in the code above, using the text tag in multiple lines helps to better manage the display part in the server code.

Problems that were solved

• Fixed the problem of finding the Microsoft.AspNetCore.App directory for some operating systems

In the previous versions, the path of the Microsoft.AspNetCore.App directory was determined according to the Microsoft.NetCore.App path; for some operating systems this type of routing did not work. In version 2.4, the path of Microsoft.AspNetCore.App directory is determined automatically.

• Fixed problem matching projects whose name does not match for namespace name.

The CodeBehind framework creates a new namespace from the project name in the final View class. When you create a new project, you may use characters in the project name that are unacceptable to create a namespace and the final View class will not compile. We at Elanat team solved this problem in version 2.4 of the CodeBehind framework.

The new namespace is created only based on uppercase and lowercase English letters, numbers, and the underscore character (_), and the underscore character replaces other characters (such as dot and space). If the project name starts with numbers, an underscore character is added to the name of the new namespace.

Example:
Project name: 123.Project - New-Module
New namespace name: _123_Project___New_Module

Note: The name of the new namespace is placed in the first line of the views_class.cs.tmp file located in the code_behind directory.

Related links

CodeBehind on GitHub:
https://github.com/elanatframework/Code_behind

Get CodeBehind from NuGet:
https://www.nuget.org/packages/CodeBehind/

CodeBehind page:
https://elanat.net/page_content/code_behind

The post Elanat Competes with Microsoft; CodeBehind 2.4 Released appeared first on ProdSens.live.

Learn about the power of worker threads in JavaScript and how they can enhance your application’s performance.

What if I say you that JavaScript is not strictly single-threaded and that there’s a way to harness the power of multithreading through worker threads? Intrigued? Let’s dive deeper into this topic.

The Myth of Single-Threaded JavaScript

JavaScript has long been perceived as a single-threaded environment, primarily because of its single-threaded event loop that handles asynchronous tasks, UI rendering, and user interactions in a sequential manner. This design choice helps simplify the development process but can lead to performance bottlenecks when executing long-running tasks.

Enter Worker Threads

Worker threads are JavaScript’s answer to achieving parallelism, allowing you to run scripts in background threads and perform heavy tasks without interrupting the main thread. This means you can execute computationally expensive operations, such as data processing or complex calculations, without compromising the responsiveness of your web application. They allow you to execute JavaScript in parallel, offering a solution for offloading processing tasks from the main event loop, thus preventing it from getting blocked.

Key Features and Benefits:

• Parallel Execution: Worker threads run in parallel with the main thread, allowing CPU-bound tasks to be handled more efficiently.
• Non-Blocking: By delegating heavy lifting to worker threads, the main thread remains unblocked, ensuring smooth performance for I/O operations.
• Shared Memory: Worker threads can share memory using SharedArrayBuffer, facilitating efficient communication and data handling between threads.

How Worker Threads Operate

Worker threads, stabilized in Node.js version 12, offer an API for managing CPU-intensive tasks effectively. Unlike clusters or child processes, worker threads can share memory, allowing for efficient data transfer between threads. Each worker operates alongside the main thread, equipped with its event loop, enhancing the application’s capability to handle multiple tasks concurrently.

A Simple Example

Consider a Node.js application where the main thread is tasked with a CPU-intensive operation, such as image resizing for different use cases within an app. Traditionally, this operation would block the main thread, affecting the application’s ability to handle other requests. By offloading this task to a worker thread, the main thread remains free to process incoming requests, significantly improving the application’s performance and responsiveness.

Code Snippet for Image Resizing Using Worker Threads

// main.js
const { Worker } = require("worker_threads");

function resizeImage(imagePath, sizes, outputPath) {
  const worker = new Worker("./worker.js", {
    workerData: { imagePath, sizes, outputPath },
  });

  worker.on("message", (message) => console.log(message));
  worker.on("error", (error) => console.error(error));
  worker.on("exit", (code) => {
    if (code !== 0)
      console.error(new Error(`Worker stopped with exit code ${code}`));
  });
}

// worker.js
const { parentPort, workerData } = require("worker_threads");
const sharp = require("sharp"); // Assuming sharp is used for image processing

async function processImages() {
  const { imagePath, sizes, outputPath } = workerData;
  try {
    for (const size of sizes) {
      const output = `${outputPath}/resize-${size}-${Date.now()}.jpg`;
      await sharp(imagePath).resize(size.width, size.height).toFile(output);
      parentPort.postMessage(`Image resized to ${size.width}x${size.height}`);
    }
  } catch (error) {
    parentPort.postMessage(`Error resizing image: ${error}`);
  }
}

processImages();

In this example, the main thread initiates a worker thread for resizing an image, passing the necessary data through workerData. The worker thread performs the resizing operation using the sharp library and communicates the progress back to the main thread without blocking it.

Real-World Applications of Worker Threads

Worker threads are not a panacea for all performance issues but are particularly effective in scenarios involving CPU-intensive operations such as:

• Complex calculations or algorithms
• Image or video processing
• Data sorting or manipulation on large datasets

Best Practices and Considerations

• Security: Keep in mind that workers have some limitations for security reasons, such as no access to the DOM.
• Performance: While workers are powerful, spawning too many workers can lead to memory and performance issues. Always test and optimize.

Conclusion

Worker threads offer a powerful mechanism for enhancing JavaScript’s processing capabilities, breaking the myth of its single-threaded limitation. By judiciously leveraging worker threads, developers can significantly improve the performance and responsiveness of their applications. As JavaScript continues to evolve, exploring its concurrent capabilities will undoubtedly uncover new patterns and practices for building efficient, scalable web applications.

The post Javascript is not single threaded! 🤯 🤩 appeared first on ProdSens.live.

I spend most of my time thinking about performance improvements. Refactoring is tricky work, even more so when you’re unfamiliar with the feature or part of the codebase.

Some refactoring might be simple, but in this post I’ll attempt to dissect my approach to solving performance issues in the hopes it’ll provide value for others.

Where do we start?

Before we can design a solution to a performance issue we must understand the problem. For example, is a page not loading or is it very slow? Are there more queries than necessary to get data? Can we see a slow part in the process? How do we know it’s slow? Answering these questions first is a must.

Once we can see the slow part over and over again, if code is the culprit, I start by taking that piece out and seeing how fast it could be without it even though it may break or be incomplete. This helps me to see what the maximum amount of improvement we’ll get through performance optimisation – as if code didn’t run at all.

This is the incentive. If I know how much performance improvement is possible, it’s worth investing time into figuring out a solution. If I see marginal or little to no improvement, I’m either in the wrong place or it wasn’t as slow as I thought – time to move on.

The solution to the performance problem could be as simple as adding an index and as complicated as a complete rebuild. Code optimisation will naturally take longer than query optimisation because the behaviour of the code will generally change. If the problem is not that the query is slow but that the query runs thousands of times in a single request – those are two different problems to solve.

Going from prototype to production

The easiest way I get from identifying something slow to being able to fix the problem is to prototype the way I think it should work to be fast. Creating a prototype gives me the confidence the solution works at a high level, without addressing all of the edge cases. At minimum, I try to identify blockers standing in the way.

Once I’ve proven the solution works, I can invest more time to understand the product behaviour and the experience. How does the user actually use this feature? What are they trying to accomplish?

To be clear: this is the hardest point and often where the solution can fall over. If I misunderstand requirements or forget to include some parts, however minor they may seem, it undermines the performance optimisation and deflates any confidence in it when it comes time to release it.

Confidence is a fickle thing – it can be gone in an instant and hard to get back quickly. Customers are never going to applaud performance improvements – maybe it should have been fast to begin with – but many performance improvements add up to a better experience.

Testing builds confidence

Testing a performance improvement is like any other test of a change with the addition of a specific metric that you want to improve. For example if the goal of the refactor was to reduce page load time, compare the previous and current page load speed. If reducing the number of queries was the goal, show that the number of queries has gone down. I often start with manual tests to confirm impact on the user experience supported by some quantifiable metric. Screenshots, videos or links to observability metrics all support the fact that the refactor does what was intended.

Once I’ve covered the performance gains, the next thing to verify is correctness. To do this, I start with a few manual scenarios and compare the result of using the feature with and without my change. The most comprehensive way to do this is through a test spreadsheet which marks pass or failure for some scenarios. A user clicks a few buttons and assert the result is the same. Using a spreadsheet helps maintain regression tests and add test cases over time. Some features won’t be big enough that you’d need it, but even if you never share the results with anyone and use it for your own testing – it beats remembering all cases every time you test.

One day you could even turn those manual tests into automated tests, if that’s not readily possible now. At least creating automated tests for any new code is a task worth doing.

How do performance improvements differ from features? Feature development creates new functionality where it didn’t exist before, so there’s often time to assess its effectiveness and test with customers who might be more forgiving if something is not working. To break an existing feature that may be slow is to take it away. We must have extra care when dealing with something that is working today for some, even if it’s slow.

A performance improvement must be:

• Cheaper or faster
• At least equal, ideally better behaviour

It’s an unforgiving task, but rewarding when you can quantify performance improvements with a better experience for customers. Monitoring the outcome after release is a good place to start, even in the short term to verify the improvement was a success.

The hardest question, which will remain unanswered, is how can we know when performance optimisations are done?

The post Refactoring for Performance appeared first on ProdSens.live.

This benchmark compares the performance of Snowflake and UUID. It was built using Go, Docker, SQLx, and PostgreSQL.

The graphs below were generated using Python3.

Understanding the benchmark

Go is the main programming language used for the benchmark. Each ID type (Snowflake or UUID) has its own .go file for running the benchmark separately. The benchmarked operations include:

• SELECTION (SELECT * FROM)
• ORDERED SELECTION (SELECT ORDER BY)
• ID GENERATION
• ID GENERATION + INSERT
• ID SEARCH (SELECT WHERE)
• UPDATE

For each benchmark, 200k IDs are generated (either Snowflake or UUID) before performing each benchmark operation. To reduce variability, the database is truncated after each benchmark run, and 30 iterations are performed to obtain a larger and more statistically significant sample.

How to run?

1. Install Go
2. Install Docker
3. Install Python3
4. Run the following commands:

docker-compose up -d

and then, run the Snowflake benchmark:

./run-snowflake.sh

or the UUID benchmark:

./run-uuid.sh

How to analyze the data

After running the benchmarks, you can analyze the data by running the following command:

python3 benchmark_analysis.py

this will generate the graphs and print the data analysis. The generated graphs will be saved in the images folder. The data from the benchmarks will be saved in the reports folder.

Results

Now, let’s interpret the results!

ID Generation

For ID Generation, UUIDs have very high variance and standard deviation, in counterpart Snowflakes were pretty stable during the 30 benchmark iterations.

ID Insertion

For ID Insertion, UUIDs have very high variance and standard deviation, the same happened with SnowflakeIDs, but with lower values, performing the operations in fewer milliseconds.

ID Selection

For ID Selection, UUIDs and Snowflake IDs had very high variance and standard deviation. Also, the mean wasn’t that different, showing that Snowflake IDs are indeed faster than UUIDs but by a small margin.

ID Search (WHERE)

For ID Search, the results were very similar to ID Selection, with the margin being even smaller. For this operation, the variance and standard deviation can be considered low for both ID types.

Ordered Selection (SELECT + ORDER BY)

For Ordered Selection, Snowflake IDs performed much better than UUIDs, having lower values for mean, variance, and standard deviation. UUIDs had a quite high variance value.

Update

For the UPDATE operation, the results were very similar to the ID Search: Snowflake IDs performed a little bit better but by a very close margin. In this case, Snowflake IDs had a higher variance and standard deviation if compared to UUIDs.

Validating Results

The results were validated by running the benchmarks multiple times (30), calculating the average and the standard deviation, and running a t-test to compare the means of the two groups. The t-test was performed with a 95% confidence level.

T-Test

T-tests are very good for saying if a benchmark or an optimization is significant, or relevant. For that, we use a 95% confidence level, which means that if the result of your T-test is within 0.000 (~100%) and 0.05 (95%), it lies in a high confidence interval, so you can state that your optimization is TRUE and relevant!

We can see that for UPDATE and ID SEARCH, the performance gap between Snowflake and UUID is not relevant according to the T-test. At the same time, we can notice that for all the other four operations benchmarked, the difference is evident and very clear. Snowflake IDs with a better overall in ordered selection, ID generation, and insertion.

Why is UUID’s variance so high?

UIDs, with their design focus on randomness, inherently exhibit high variance in generation times. Here’s a concise breakdown:

1. Randomness Source: UUIDs depend on a pool of entropy for random number generation. Fluctuations in this pool’s availability can lead to variability in creation time.

2. System Factors: The system’s workload and resource allocation can also impact the speed of UUID generation, causing inconsistent timing.

3. Inherent Entropy: With 122 bits dedicated to randomness out of 128, a UUID is highly entropic by nature, leading to intrinsic variability.

These factors combined mean that UUID generation can be a process with variable timing, reflecting the complex interplay between system entropy and resource demands.

Conclusion

Is UUIDv4 bad?

No way! UUIDs are excellent and very useful. UUIDs are perfect for huge distributed systems and for scenarios where uniqueness is the most important factor. Even though those are the main strengths of UUIDS, they are also its main weaknesses. UUIDs are purely random and unique, making them unpredictable, unsortable, and too big. It can be a problem sometimes.

When to use each?

UUIDs (v4): if you want simplicity, easy setup, and compatibility, at the same time your system doesn’t expect a very high throughput; use UUIDs. A UUIDv4 has a size of 128 bits.

Snowflake IDs: Snowflakes are an “enhanced” BigInt, so if you are willing to improve performance, sort your data, and maintain secure public IDs; use Snowflake. A SnowflakeID has a size of 64 bits.

To improve

This benchmark isn’t perfect and has some points to improve and to cover in the next version. Some of them:

• Concurrent testing
• Test in different databases besides Postgres
• Benchmark other UUID versions (ULID, UUIDv7)
• Display results in req/s (requests per second)
• Use even larger samples
• Measure the disk used by each

Links

Github Repo

Gist about UUIDs performance

Preparing and Evaluating Benchmarks

The post Benchmark: Snowflake vs UUIDv4 appeared first on ProdSens.live.

The primary reason is that javascript is an interpreted language

Interpreted vs Compiled languages

JavaScript is an interpreted language, meaning the code is executed line-by-line by an interpreter at runtime. In contrast, C++ is a compiled language, where the source code is translated into machine code before execution. This means

1. Additional overhead while running
2. Compiled languages can perform lot more optimisation before runtime like when to do memory cleanup

But why Javascript has to be Interpreted

Security

As a language primarily used in browsers, executing in a sandboxed environment, being interpreted adds a layer of security. It’s easier to impose restrictions and monitor executed code in an interpreted language.

Rapid Development

For web development, the ability to write code and immediately see the results in a browser is important (what would you do without hot reload ). Adding an additional compilation step would mean rebuilding the entire app. Interpreted language fits well into this rapid development cycle, allowing developers to quickly test and modify their code.

Platform Independence

Being interpreted allows JavaScript to run in any environment with a compatible interpreter, such as different web browsers. This is crucial for a web scripting language, as it needs to operate consistently across various platforms and devices. C++ needs to be compiled separately for each target platform

Dynamic Features

JavaScript was designed to be a flexible and dynamic language, with features like dynamic typing. If you’ve used any type in typescript you know exactly why we like dynamic typing. A compiled language needs to know the exact type of each object before runtime. An interpreted environment is more conducive to these dynamic features, as it allows for on-the-fly execution and changes.

So, while Javascript is a bit slower it works well for the use cases it’s designed for. And that what’s programming is about – right tool for the job

The post Why Javascript has to be slower than C++ appeared first on ProdSens.live.

Half of the users close a web page if it takes longer than 3 seconds to load. This not only negatively impacts the user experience but also leads to higher bounce rates and lower search engine rankings. Google takes into account page load speed when evaluating the ranking of websites. Therefore, the speed of website loading plays a crucial role in attracting and retaining visitors.

Today we’ll look into the impact of website load speed on user experience, conversion rates, and search engine rankings. We will also discuss factors that can affect website load speed and provide tips on how to increase website load speed.

Be sure to save this list and never suffer from a lack of up-to-date information. What resources would you add to the top? Share your top in the comments down below.

Website Speed impact on SEO and Search Engine Rankings:

• Website speed is a ranking factor for search queries in Google. Google also included website speed as a ranking factor for mobile searches in 2018. This means that slow-loading websites have lower chances of achieving high positions in search results.
• Search engines take into account user signals, including metrics related to website load speed. If users quickly exit a website after coming from a search engine, it can signal low-quality content on the page and have a negative impact on its ranking.
• Slow-loading mobile websites have less likelihood of appearing in top search results, as search engines actively promote mobile optimization and prioritize user experience on mobile devices.
• Fast website loading can improve SEO-related metrics such as time spent on the site, number of pages viewed, and level of engagement. These metrics influence the overall assessment of a website’s quality by search engines and can enhance its ranking.

Website Performance Analysis

There are tools available that can measure a website’s speed and performance. What metrics should you focus on? T*he optimal website load time is around 2–3 seconds*, as users tend to move on to the next site in their search if it takes longer. How can you check your website page speed? Here are a few tools that can help you with that

Google PageSpeed Insights

Free tool that helps evaluate a website’s performance and load speed. It analyzes page load time, server response time, image optimization, caching, and other factors. The tool provides an overall speed score for both mobile and desktop devices, along with recommendations for performance improvements.

GTmetrix

Gtmetrix provides a detailed analysis of website performance. It assesses the load speed, server response time, page size, and more. GTmetrix offers performance improvement recommendations, including caching, resource compression, and code optimization.

Pingdom

The service allows measuring a website’s performance and monitoring its availability. This tool enables checking the website speed from various servers located in different parts of the world. It provides detailed reports on the load time of each element of the web page, such as images, CSS, JavaScript scripts, and other resources. It shows server response time and the overall page size. These data help identify bottlenecks and determine which components of the page take more time to load.

Honorable mentions

• WebPageTest
• Site24x7
• DareBoost
• KeyCDN
• DotcomTools
• UpTrends
• WebsiteSpeedTest

Carefully review the recommendations provided by the performance analysis tool. They indicate steps to optimize your website’s loading.

For example, implementing caching, using a content delivery network (CDN), improving code, or optimizing resources. Determine which of these recommendations are applicable to your website and start implementing them. When interpreting the results, pay attention to the following parameters:

1. Page speed
   Evaluate the overall load time of your website. If it exceeds the recommended values (usually under 3 seconds), it may indicate optimization issues that need attention.

2. Server Response Time
   This is the time it takes for the server to process a request. If the server response time is high, it may indicate hosting or server configuration issues.

3. Page Size and Number of Requests
   Large page sizes and a high number of requests can slow down the loading process. Pay attention to the page size and the number of requests and try to reduce them by compressing images, minifying CSS and JavaScript files, combining them into a single file, or using caching techniques.

4. Task Prioritization
   Identify problem areas and set priorities. Focus on aspects that have the most significant impact on loading speed and performance. For example, if image size is a major issue, start optimizing them.

5. Testing and Reanalysis
   After making changes and optimizing your website, reanalyze its performance using the tools. This will allow you to see the results of the implemented changes and continue optimization if needed.

Tips to Increase Website Speed

Let’s explore some effective techniques and tips to speed up website loading. We’ll look into image optimization, CSS, JavaScript, and HTML minification, caching and CDN usage, as well as server response time optimization.

Image Optimization

• Image Format
  Each image format has its advantages and is suitable for specific types of images. For example, JPEG (or JPG) is suitable for photos and images with many color shades. It provides good compression and retains image details. PNG is the preferred format for images with transparency or text. It preserves sharper lines and is a good choice for logos and icons.

• Compression
  Image compression tools help reduce the file size of images without significant quality loss. They remove unnecessary information such as metadata and hidden colors while preserving the visual quality of the image. Some popular compression tools include:

1. Kraken.io
2. TinyPNG
3. Compressor.io

• Lazy Loading
  Lazy loading allows images to load only when they become visible on the user’s screen. This is particularly useful for pages with many images or long-scrolling pages. Various plugins and extensions are available for content management platforms (CMS) that automatically apply lazy loading or optimize the loading process. For example, WP Smush for WordPress.

Website Code Optimization

Another way to optimize is by reducing the size of CSS, JavaScript, and HTML files by removing comments, unnecessary spaces, and line breaks. Combine CSS and JavaScript files into a single file to reduce the number of server requests. This can be done using build tools like Webpack or Gulp.

It is also recommended to place CSS code at the beginning of the page and scripts at the end. This approach allows the browser to start rendering the page before loading all the scripts, reducing load time and improving the user experience.

Caching and CDN

Enabling caching on the server allows you to store static resources such as images, CSS, and JavaScript files on the client side. These resources are loaded and cached by the user’s browser, allowing for reuse without having to fetch them from the server on each request. This significantly reduces page load time for repeat visits and improves performance.

Utilize a Content Delivery Network (CDN) to distribute copies of your content to servers located in different regions of the world, providing accelerated website performance. The CDN operates based on the following principle: the nearest server serves user requests, reducing latency. When a user requests a resource from your website, they receive it from the nearest CDN server rather than the main server.

By caching resources on the client side and distributing them across CDN servers, you have the ability to deliver content with minimal delay and ensure fast access for users anywhere in the world.

Minimize Redirects and Broken Links

Avoid excessive use of redirects on your website. Redirects add a step in the page loading process, which can slow it down. Check your URL structure and encoding to ensure they are optimized and minimized. Aim to use direct links wherever possible and avoid chains of redirects.

Regularly check your website for broken links and fix them. Broken links that lead to non-existent or inaccessible pages can have a negative impact on user experience and page load speed.

Cloud provider and Server

When choosing a hosting provider, it is recommended to pay attention to their performance and reliability.

A well-selected hosting provider with optimized infrastructure, high bandwidth, and low latency can significantly improve server response time.

Keep your server’s software and components up to date, such as the web server (e.g., Apache or Nginx), PHP, or other programming languages. This allows you to take advantage of the latest security patches and performance optimizations.

How to speed up the site

1) Choose a suitable cloud provider

• Cloud hosting platforms offer scalability and flexibility, allowing your site to utilize resources from multiple virtual private servers (VPS). This enables handling high traffic volumes and ensures high availability.
• VPS provides an isolated virtual environment that mimics a dedicated server. It offers more resources and control compared to regular shared hosting.
• Dedicated server provides full computational resources of a single server for your website. It offers high performance and control but may be more expensive and require more management.

2) Optimize server settings to enhance performance
3) Keep your server software up to date
4) Optimize the database for quick data access and processing

• Use the EXPLAIN command in your database to analyze and understand which queries are performing slowly. This may involve modifying query structure, adding indexes, or reevaluating table usage and relationships.
• Caching responses to frequently repeated queries can significantly speed up database operations. Instead of executing the query every time, the database can serve the pre-saved result from the cache. This is especially useful for dynamic websites where content is generated frequently and may be the same for multiple users.
• Configuring indexes in the database allows efficient data retrieval from tables. Indexes are created on indexed fields and greatly accelerate the search process.

5) Load balancing and clustering enable distributing the load across multiple servers, improving performance and providing fault tolerance. The principles include:

• Traffic distribution among multiple servers to evenly distribute the load and ensure high availability.
• Clustering multiple servers together to handle traffic and ensure fault tolerance. Clusters can involve data replication, resource sharing, and automatic recovery.

6) Use SSD storage

SSD storage offers faster data read and write speeds, speeding up request processing and content delivery.

7) Network infrastructure
Hosting your site with providers that offer high-speed network connectivity and utilizing network technologies such as CDNs help ensure fast content delivery to users worldwide.

Performance optimization is not a one-time effort. Websites and their requirements constantly evolve, and users expect faster and more responsive sites. Therefore, it’s important to understand that optimization is an ongoing process that should become part of your everyday website development and maintenance practice.

Serverspace is an international cloud provider offering automatic deployment of virtual infrastructure based on Linux and Windows from anywhere in the world in less than 1 minute. For the integration of client services, open tools like API, CLI, and Terraform are available.

The post 🔥 FAST & FURIOUS WEBSITE 2024 🔥Tips & Links for performance optimization appeared first on ProdSens.live.