203 private links
All that we did to get this speedup is implement the Serialize trait using one line for the body of the serialize method!
But implementing the trait directly loses the possibility to serialize the structure with the #derive(Serialize) macro.
Instead, you should implement it on wrapper types that act like formatters.
Also for efficiency: format_args!
doesn't allocate or even apply the formatting! It only returns Arguments which is a formatter that borrows its arguments.
Even after applying various default filters and providing a GUI to search and filter the remarks, there is still a lot of data to go through.
Understanding the remarks is quite challenging. What even is FastISelFailure or SpillReloadCopies? How can I change my Rust code to resolve these remarks? Hard to say if you’re not a LLVM expert.
How class encapsulation or closure can reduce the bundle size
The plan is to import the dependencies from package.json and modify the rollup output chunks to split each dependency from the vendor bundle. A vendor array should be there with the boot dependencies.
The 512KB Club is a collection of performance-focused web pages from across the Internet. To qualify your website must satisfy both of the following requirements:
- It must be an actual site that contains a reasonable amount of information, not just a couple of links on a page (more info here).
- Your total UNCOMPRESSED web resources must not exceed 512KB.
Kafka has a good throughput with sequential Writes and Reads.
Kafka can move a lot of data because of the zero copy read principle:
Before:
- Disc to OS buffer
- Write the content of the OS buffer to the RAM
- Copy the data to the application Buffer
- Copy the data back to the socket buffer
- Copy the data from the socket to the Network Interface Chip buffer and send it
With zero-copy read principle:
- Read from the disc and load it into the OS Buffer
- Directly copy to the NIC Buffer (the CPU is not involved)
An example of optimisation
-
SSR and Jamstack
-
Active Memory Caching
In summary, if you want to increase the performance of your application, you can use server caches to speed up your APIs, but if you want to persist your app state, you should use the local storage cache.
- Data Event Sourcing
Useful for real-time applications. Connections are made with Websockets.
4.a Prefetching
Pros: Prefetching waits until the browser’s network is idle and is no longer in use and will stop when you trigger usage by clicking a link or triggering a lazy loading function.
Pros: Prefetching caches data within the browser, making page transitions faster when redirecting to a link.
4.b Lazy Loading
Lazy loading can only help you delay downloading resources and doesn’t make your resources smaller and more cost-efficient.
- Resumability
Essentially, Resumability uses the server to do the heavy lifting and then gives the client a minimal amount of JavaScript to execute via serialization.
Segmented Rendering is just a smarter way to do static rendering. Once you understand that it’s all about caching renders and then getting the right cached render for each request, everything will click into place.
To implement segmented rendering:
- Define your “segments” for a page.
Example: paid users versus free users, users from company A versus users from company B or C, etc. - Render as many static variations of a page you need, with one URL per segment.
Example: /with-jokes/my-article, /bland/my-article. Each variation matches a segment, for instance, paid or free users. - Setup a very small redirection server, that checks the HTTP request content and redirects the user to the right variation, depending on their segment. Example: paid users are redirected to /with-jokes/my-article. We can tell if a user is paid or not by checking their request cookies.
More performance?
Render the site on demand with Incremental Static Regeneration
bulk optimize JPEG, PNG, WebP, or SVG images with no discernible quality loss.
The way it works is quite simple, you just have to copy and paste the content of your Dockerfile into the interface and the site gives you a list of recommendations to follow to improve your file.
Characteristic measured | External linked .css file |
inline stylesheet with <style> |
---|---|---|
Mobile friendliness | 100/100 | 100/100 |
Mobile speed | 89/100 | 98/100 |
Desktop speed | 96/100 | 98/100 |
PageSpeed Score | A, 96% | A, 97% |
YSlow Score | A, 95% | A, 96% |
Page Load Time | 0.7s | 0.5s |
Total Page Size | 116kb | 116kb |
I’m saying: consider the options, weigh them up against the norm and test them out. As long as you have a good reason behind the implementation, it kind of doesn’t matter what others think.