How do you test and optimize website speed for different devices, browsers, and locations?

Website speed is a very important factor for user experience and the retention. The biggest hurdle for any new user is the speed. Imagine that a person is waiting to load a site for 10 seconds. The first impression will be a very bad impression and the user will drop off. Only when the user survives this shock, that he/she will go ahead in the flow and the question of the content and user engagement will come into picture. Sometimes the sites are so slow, that the users will bounce off even before the analytics of the page capture the bounce. Hence the first entry point of the user flow always need to have a fast page experience. Just compare user experience of the search.google.com which contains only the search bar.

Indeed, Website speed is crucial for user experience, conversions, and SEO. What I have been seen so far, website speed widely varies for the website visitors because of 3 major reasons: - User Devices Processing Power and ScreenSize - User Network Speed - Distance of the User from the Hosted Server Location Certainly understanding the user personas and then optimising the website speed for them is the right approach rather than optimising the speed for everyone. With right design and content, A fast website experiences: - Exceptional User Satisfaction Rate - Enhanced Conversion Rates, Hence Revenue - Less Bounce Rates - Better SEO (If passing CWVs)

Beyond the categorisation of websites as “faster” versus “slower”, there are stark differences observed within the same website across different landing pages (accessed by short URLs, or direct links), based on the relative page-load time measurements for those pages. One ‘rule of thumb’ practiced in the industry is the 3-second rule - established as the cut-off for page loading, beyond which visitors’ abandonment of the page increases exponentially.

Speed matters, but -although not mentioned here-, so does your audience. Your website's audience and their conditions is an important aspect. And those will stay unknown, as when not knowing those conditions you don't know what to synthetically test for (for example using Lighthouse). A few examples where Real User Monitoring (RUM) is able to remove those blindspots: - differences per device-group (device memory). - differences per traffic source (as each will have their own query strings, and expose different gaps in your caching strategy). - et cetera. The above are reasons I co-founded RUMvision. To supplement any lab data testing, remove those blindspots and get data in bulk and real-time.

.. Google has pagespeed as one of it’s ranking factor’s. On June 16th, 2021, Google began to roll out a broad core algorithm update called "The Page Experience Update." This update is intended to bring a better experience to users by prioritizing pages that offer a quality page performance — ie fast load times, and a non-shifting, stable page. But slow websites are also within the top 3 of annoyances of website users. So for sake of a better user experience you need to get pagespeed under 2 seconds.

There are 2 ways to measure the website speed, a. In a lab, which we call synthetic measurement, and b. In the real world, which we call real user or RUM. It is always better to measure the real user speed, provided you get the readings with lot of attributes, you get the readings in real time and the answer is not skewed towards any extreme. Google Pagespeed offers 2 set of results which are a. field data and b. lab data. While field data is the moving average for 28 days of data and is based on real user samples, lab data is measured from the US location simulated on a bandwidth. As free tool this data is good, but for more in dept analysis, try to use an advanced RUM tool like Gemini. P.S. I am part of the company which developed it

Website Speed Testing is a continuous process, as website speed and performance many degrade over time, similar to Human health, it needs proper monitoring time to time. There are 2 ways to test website speed: - Lab Data (aka Synthetic Monitoring) - Field Data (aka CWVs or RUM) For Lab Data Testing you can use tools like Auditzy which allows you to Test your website speed and performance across 5000+ personas spanned over a spectrum of Devices, Networks and Test Locations. Lab Data is good for understanding issues in the development itself, and also for post development issues identification across personas in a more detailed manner. For Field Data you can use RUM solutions, or can rely on Core Web Vitals too!

Next to synthetic checklists that Lighthouse and GTmetrix are offering, you might want to know about other pagespeed opportunities as well. This -again- is where RUM comes in, providing insights that lab data tools might be missing. Such as: - exact browsers and device memories of you audience (you don't know what to test for if you don't know your audience) - changes in your audience conditions over time. - new query strings being introduced by third parties (Pinterest once introduced a new parameter that no-one added to their server side caching rules). - collect pages missing a lazyload and fetchpriority strategy in bulk - back/forward cache opportunities - additional INP insights that lab tests won't expose - et cetera

Website Speed Optimisation is the real pain in the industry because of the variety of technologies and coding patterns used widely by different set of website developers. Having said that, below are the steps that I have been implementing and it goes like this: - Consider 3 ICPs (ICP = Device + Network + Location) - Set Performance Benchmark for 3 ICPs - Run Performance Tests in Lab to Identify Issues - Minimise Main Thread - Remove Unused Javascript from Bundle Chunks - Optimise Image, and Assets - Use a CDN for website and Asset Hosting - Lazy-Load the Code Components (in SPA) - Put Skeleton Loaders to minimise Layout Shifts Test. Optimise. Repeat

The method for performance optimization is important than what tools to be used. As there are many tools available to execute various tasks. Optimization should start with basic html which is being received by the browser from the server. 1. Make sure the html is small and is having all the div structures to complete the above the fold elements. 2. The html needs to contain no blocking dependency on resources like js, css and fonts for its painting. 3. The html need to have critical css in order to allow it to paint freely without dependency. 4. Preload the LCP element early for better LCP. 5. Ensure that no CLS happening on the page by adding the placeholders and min heights for images etc. You should have a better performance now.

An important nuance here is that the "geographic location" advantage really applies when the main HTML pages (and thus the whole domain) is served from the same hostname as well. Otherwise, such change might stand in the way of HTTP/2 perks, where re-using an already opened connection would outperform the geo advantages of a CDN. Do note though that (image) CDN's often comes with other features and advantages as well. Such as transforming images into webp or AVIF, reducing image size while not harming image quality or resizing them on the fly. Another not mentioned optimization is to lazyload all other below-the-fold as well as non-visible images. This prevents download competition with your main (product/hero) image. Often a quick win.

Website speed monitoring holds paramount importance as it provides insights into your website's performance trends. Over time, comprehending data-driven analytics helps unveil speed patterns, which tend to fluctuate based on varying traffic levels. To facilitate this monitoring, consider employing tools such as: - Auditzy, offering both Synthetic Testing and Real User Monitoring (RUM) capabilities. - New Relic, which stands as a reliable option for in-depth performance analysis.

There are different solutions out there: - lab data monitoring (Lighthouse) - CrUX (Google's public data) - and more detailed RUM On web.dev, even Google is strongly recommending to "supplementing [CrUX] with your own RUM". This way, you're able to spot: - regressions instantly after a deploys. - changes in caching strategies (or new query strings in your ads and campaigns) - differences per templates - and even differences per user-group (and their speed + device memory). To start with own RUM, BigQuery + DIY is one option. Do note that browser API's keeps evolving as well (check Chrome Origin Trials). This means one would need to update libraries and add new dimensions themselves. Choosing a dedicated RUM partner is a second option.

5 points to improve speed & web vitals for mobile devices 1) Minimize the initial HTML size. 2) Utilize async/defer attributes for CSS and JavaScript, inline critical CSS for above-the-fold content, and rely on HTML for an early page rendering, thus enhancing the first contentful paint. 3) Preload crucial static resources, including LCP images. 4) Specify dimensions for images and videos, and introduce placeholders for advertisements and banners to minimize layout shifts. 5) Give lower priority to third-party tags and pixels to optimize page loading performance.

Almost 50% of the traffic that comes to a website these days are from Mobile Users, and it even goes upto 80% if you are running an online business like E-comm, PropTech, etc, and Website Mobile Speed matters in that case. To optimise for Mobile Sites: - Identify you ICP Device, Network and Locations (At-least 3), you can use GA for the same - Set Performance Benchmark for 3 ICPs - Run Performance Tests in Lab to Identify Issues - Minimise Main Thread - Remove Unused Javascript from Bundle Chunks - Optimise Image, and Assets - Use a CDN for website and Asset Hosting - Lazy-Load the Code Components (in SPA) - Put Skeleton Loaders to minimise Layout Shifts - Use Web Workers to Load 3rd Party Scripts

.. images are most likely responsible for high load time of your website. Improving your images is the ‘low hanging fruits’ of optimization of your load time. - Use next-gen image files like .webp and .avif (Use WP plugin shortpixel or Imagify to do this automatically). - use the right measurements for your images. It’s useless to serve an image of 2100x700px when you need a thumbnail of 700x100px. Use the default WordPress image sizes, if this won’t suffice you can make some more custom image sizes in your function.php - code your responsive image correctly. Srcset and sizes are useful to define multiple dimension variants of the same image. This will serve your images in the right size for each device. (1/2)