Do i have a bug in my way of thinking? Or is this approach correct and efficient?
There are many adjusting screws one can turn to optimize loading time. Some of them are easy, other not so easy, i.e. because of outdated CMS or non-available IT ressources.
Is it not better, instead of many optimization steps just to prerender any (or most important) pages and to guarantee, that Google and visitors get a plane HTML page, which loads blasingly fast from server cache?
Prerendering can be bought as service or launched on own server. This will be a single action we need - in comparation with many optimization steps, what means simpler implementation and maintenance.
Rendering is already used for prerendering of Javascript-based websites - could it not be used to prerender any website, made by PHP/MySQL?
I even optimized an outdated CMS site (PHP+MySQL) with an affort of 15 minutes from 42 to 95 PSI points - only with prerendering.
Why not everyone do it on the same way? Why all are struggling with things like TTFB, images, LCP, javascripts, stylesheets…?
@chilly_bang I think you misunderstand what prerendering does vs general site optimization - they are not competing with each other, they compliment each other.
The goal of prerendering is to preprocess the rendering that one or more JavaScript libraries may be doing to create your page’s DOM. Essentially it is running JS on the server side so that the HTML shouldn’t need to change when the page is loaded on the client side and caching those results (like CloudFlare caches my static HTML files). So you might get the improved TTFB on the initial base page request - so this is not useless - but its also not everything.
Note that on a website like mine (with no JS modifying the DOM on page load), prerendering will implement a 0% improvement to my website performance. There are no JS based DOM changes for a prerendering service to cache - I already built it with a static site generator (hugo).
Even with pre-rendering the core principles of conserving overall bandwidth to reduce latency, reduce mobile device battery consumption and reduce CPU load, reducing number of requests or implementing http/2 to save TLS handshakes, serving images of an appropriate size and format for the content, etc. ALL STILL APPLY whether “pre-rendered” or not. So it’s not either-or here.
You cannot defy physics. The majority of web traffic is now mobile browsers. Majority of mobile browsers have more resource constraints, smaller CPUs, or lower clock speeds, wireless connectivity and not wired, etc. You’ll find all the optimization techniques recommended are catering to conserving resource usage (particularly important on mobile devices).
But at the end of the day part of optimization is… Test it yourself and measure! Personally, I enjoy the technical challenge of site optimization something like a chess game. My homepage now gets a perfect score on WebPageTest, GTMetrix and Google Pagespeed/Lighthouse. Is their some diminishing returns to go from like 96% to 100%? Yes, for sure! It’s unlikely that the last couple percent matter as much as the jump from 50% to 95%. It’s up to you to decide if your use case requires that last 5% of perfection or not…