Rebuild Part 7: Laptops and PCs (Desktop)

In this post, I will be talking about how I have rebuilt my website for Desktop, this will also cover laptops, PCs, tablets, etc. Now for those of you solely wondering how I have improved performance of my site you can skip over the next section on writing Fluid Media Queries as it is a pretty advanced subject.

As mentioned in the previous post Rebuild Part 6: Mobile Devices, I had to figure out a way of writing media queries that would overwrite the SVG repeating patterns for my posts on a desktop appliance.

<?php if ( has_post_thumbnail()) {
$small= wp_get_attachment_image_src( get_post_thumbnail_id($post->ID), 'small' );?>

<article class="pattern-1" style="background-image: url('<?php echo $small['0']; ?>')";></article>

<?php } ?>

A simple inline style would not suffice as using code similar to the one found above would be static. The SVG pattern would never load, and the background-image could not be modified. So how about we write a media query within the inline style? Oh, wait that's not even possible! I did some research, and it was looking bleak, no solutions in sight. Then I found a post on how you can't write media queries inline, but you can use some hackery to work around the issue. Here comes my new best friend SVG. While being a fantastic feature to the majority of my websites (including this one), SVG has a great little-known trait about it. It allows styles to be written inline. Now, this isn't a secret, most designers and developers which handle SVGs and produce them using Illustrator will know that there will often be a shape and it will be given a 'fill' attribute using CSS contained within the SVG. The one thing that is overlooked is the fact you can write media queries within these SVGs! So as part of my loop I now include an inside of every post. Now while it may not be the best of practices and may have many of you biting your finger nails in horror, I have reason to believe it won't affect accessibility and is the only way of flexible writing CSS with WordPress (without a plugin). Now I will dive further into the topic of writing SVG CSS Media Queries on the fly, however, to stop this post becoming a dissertation I will move on to how I implemented my code solution. For every article with a pattern class applied, I have included the following code.

<svg>
<style>
<?php if ( has_post_thumbnail()) { ?>
<?php
$small= wp_get_attachment_image_src( get_post_thumbnail_id($post->ID), 'small' );
?>
@media screen and (min-width: 640px) {
#post-<?php the_ID(); ?> {
background-image: url('<?php echo $small['0']; ?>');
}
}
</style>
</svg>

Looks a little messy but once broken down it solely says -

1. If thumbnail exists then...
2. Grab the thumbnail image URL
3. Assign URL to variable
4. Write media query for if above large mobile device
5. Set background image to thumbnail URL

That's all there is to it, now the whole topic of how this can be used with multiple image sizes, accessibility, performance, etc. is something that I want to cover in its post. For now, just understand that I am creating fluid CSS Media Queries.

The current design has been previously discussed in the post Rebuild Part 6: Mobile Devices.

The current number of requests made to the server on a desktop device (without network emulation) are 29 requests. The requests total a file size of 1.9MB in total every time someone navigates to my homepage on a desktop device. The above result is the same as the mobile outcome. These findings show that the previous theme developed by myself was not formed to provide a small file size experience to mobile users on low data networks.

The current design has been previously discussed in the post Rebuild Part 6: Mobile Devices.

The current number of requests made to the server on a desktop device (without network emulation) are 20 requests. The requests total a file size of 539KB in total every time someone navigates to the post on building a website that scores 100/100 in the Google page speed score.

The new model uses the experimental feature CSS Grid Layout to organise and manage my latest posts. I have also implemented a fallback solution for those using older browsers (Will discuss in cross browser post). The core content of the website is showcased as done before, with more control over spacing in the CSS.

The current number of requests made to the server on a Desktop device (without network emulation) now are 21 requests. The requests total a file size of 330KB in total every time someone navigates to my homepage on a desktop device. Although this a great reduction, the main issue for the large file size previously being 1.9MB is due to the large image loading from the latest post. Now that I have removed the most recent post image at full resolution, a significant drop has occurred with the overall file size of the website.

The single post page has a modified background colour of the wrapper in contrast with the post body.

Previously 20 requests were being made on the page; now there are only 18. Beforehand the total size of the page requests amounted to 539KB, compared to the latest 263KB. However, since the previous post, it has come to my attention that the pages are loading inconsistent thumbnails for related posts. As a result, the findings cannot compare against one another.

The new website (especially the homepage) uses some unconventional methods of creating fluid CSS. This process of creating CSS was something I did not think was possible from withinside a single loop, however, WordPress, HTML and CSS have proven me wrong once again. I look forward to writing a post dedicated to this method of writing fluid CSS code within a WordPress loop. For now, I am pleased with how the website is looking and am excited to begin testing against browser support. With a reduction in my website requests and file size, it is time to test how the site performs in multiple browsers. Join me in Rebuild Part 8: Cross Compatible to find out the results.